Musings from The Software Underground

There's a great post by Brent Simmons (he's had a few good ones lately actually) about the thought process and decision making that goes into adding even what, to the average user, would appear to be a simple feature:

I recently added a pretty easy feature to NetNewsWire — a Send to Instapaper command. (It will appear in 3.2.)

It really is just a quick http call to the Instapaper server to add a URL to the Read Later list.

Piece of cake.

But of course it’s not as simple as just writing a quick script. It’s tempting to think that adding a feature like this is just about adding the functionality — but there’s a bunch more to it than that...

It’s not enough just to write the basic functionality and add a menu item that runs it. Even a feature as simple as this one requires some up-front thinking, some design.

Anatomy of a feature

There's a good follow-up post by Daniel over at Red Sweater too.

Funny Brent should post about this very subject. I just finished going through something similar for MacGourmet 3. I'm revamping the ingredients list in the editor to be an outline instead of the existing table. Sounds simple, right? Wow, it wasn't. Sometimes adding or redoing a feature, even when planned, has unexpected consequences that must be dealt with, and hours later, when you've finished, you realize it turned out to be a much bigger change than expected, even though you thought you knew exactly what needed to be done.

Brent's post gives a good example of just how much thought must go into even what appears to be, on the surface, an easy change. I was actually thinking of doing a similar post. I don't have to now, read Brent's post instead, he pretty much hits the nail on the head...

I've never gotten the cash for feature offer, but I couldn't agree with Brent more...

But here’s the important thing: the developer you’re talking to has one thing in mind: to make great software that delights people.

With that in mind, the developer may or may not want to do that feature. The $50 is nothing. If it’s the right feature and the right time to do it, the developer will do it. If it’s not, then it won’t get done.

So many things go into how and why we add every new feature, the least of which is any kind of cash compensation. The wants and needs of users and heck, how much actual fun we'll have adding a new feature, are all much, much higher on the list than any cash offer would be.

Don’t offer $50 for your favorite feature

Since the release of Leopard, there has been an "additional" selection rectangle that gets shown by default when you right click (or control-click) on a table. This second selection is in addition to the current selection. I've always found this behavior to be confusing. Not helping matters is that if you use Mail, or iTunes, this behavior isn't visible, but when you use the Finder, it is:

So what's right? Well, in my opinion, there is one major problem with the "focus ring" displayed when the contextual menu pops up. When you don't click on the selection: the original selection remains and the row you clicked on to display the menu gets a focus ring. What is the actual selection that will be used when a command is chosen? Well, it's hard to say. I think a valid argument could be made for either the original, or the new one.

Now, personally, I don't like the focus ring at all, and much prefer the way that iTunes and Mail handle this situation: no focus ring, and a click on something other than the selection changes the selection to the row clicked.

Changing this behavior in your app is easy enough, you just have to use your own NSTableView subclass and override the menuForEvent: method:
If you like the default focus ring, then just return the result of the call to super instead of the menu.

So, here we are, one year into the iTunes App Store... Where are we, exactly? For some, the App Store has brought fame and riches... for others... not so much.

In January MacGourmet touch was released, after months of development. How did it go? Well, I can honestly say that considering the amount of time and effort that went into it, it still hasn't broken even. This is one of the main reasons why a) it's not a free add-on and b) why it's priced at $4.99. As much as I'd like to spend time doing things for free or for the "ultra low price of just 99¢", it's just not possible with this app. It can be complicated and every minute of every day has a dollar tag attached to it, and I'm just not at a point where I can give away my time for free... Still, it's sold well enough that I am planning and working on future free updates, so stay tuned.

As a Developer

One thing that's killing me, as a developer... is that there is absolutely no way for developers to comment or respond to comments in the App Store without including a rating. This is a huge hole in the process. We'll often see things posted there that could be responded to, but at the same time we don't receive email about the issue... so what are we as developers to do? Post a comment with a 5 star rating? A 3 star rating? If the reviews were all truly reviews that'd be one thing, but often comments are made about problems or misunderstandings that could be cleared up for the poster and other users... but there's no way for us to do that. There is also no way for us to send them email.

Another thing I have trouble with is the loss of control over my product releases. You never know how long it will take for your release to get through the approval system. Sometimes, rejections happen for very simple reasons, but the related rejection can set you back for weeks now. Things have only gotten worse since my January post entitled: The App Store Product Release Cycle: An Exercise in Frustration

As a User

As an iPhone user, I see a TON of apps of dubious quality, and it gets worse every day. More and more one-off 99¢ apps that are clearly money grabs. There are people out there who clearly see the "shot gun approach" as a quick (or possibly the only) way to make money, but all I see is more and more noise. Searching for apps is getting harder and harder.

For all the frustration we developers have with the App Store approval process, Apple seems to have no problems letting apps of questionable value into the store. And the more of those that get submitted, the longer it takes for all of us to get approval.

A post on pocketgamer.biz, on the 10 lessons learnt about the future of iPhone gaming has some interesting but not particularly surprising observations.

Almost all iPhone game developers we spoke to are increasing their number of releases...

The thinking is so many games are being released on the App Store, there's less point spending a long time polishing your game. Best take a shotgun approach and immediately support any success with fast updates and sequels.

Translation: more and more cheap no-effort dreck to wade through. Honestly, I hate to sound like a "Mac snob" but more and more the App Store is looking like Windows software sites on the web: lots and lots of apps that individually and as a whole, aren't really worth a damn. We don't see this lack of quality and overabundance in the Mac software market. That's always been a difference from the Windows-world. Now, we're seeing this weird convergence of the Mac and Windows applications worlds in the App Store...

Pricing

At least the iPhone game-makers seem to realize that the crapware model is unsustainable:

Cheap games are long term suicide

The contrary attitude, particularly from more established developers, states that selling games at 99¢ - despite micro-transaction support - isn't sustainable even for the smallest companies. Of course, there will be some examples of success, but the majority of examples of using 99¢ for both the razor and the razor blades will end in failure.

Craig Hockenberry, in an extensive year one review entitled Year Two (recommended reading) also says:

I’ve talked about pricing before, but not much has changed. The addition of in-app purchase is great for certain kinds of applications: our upcoming title, Ramp Champ, makes great use of it. But most apps cannot take advantage of this new feature and are left struggling at the ringtone price point.

These low prices are making decisions for us... The problem is that the long-term success of the iPhone platform will be defined by killer apps, not throwaways that you replace on your home screen after a few months.

Potential Piracy Issues

The App Store also seems to give rise to an easy single point of failure for piracy, again, according to pocketgamer.biz:

Not widely spoken about, especially on the record, but iPhone piracy is certainly out there and growing. One developer told us he thought it was running at about 25 percent on iPhone - compared to 90 percent for his Java games.

From a Mac app sales perspective 25% isn't just bad, it's TERRIBLE. True, there is piracy in the Mac universe too, but we all use a variety of registration systems, so one hack won't typically break the security of all Mac apps... this isn't true when talking about talking about iPhone apps. With the App Store and Apple's security, there is one single point of failure. Break that, and you open up every single iPhone app. This, on the surface is not a huge issue, but when you're talking apps that use servers, bandwidth, etc. all of these pirated apps could be costing small developers a bundle in bandwidth and support charges.

The Future

So where do I think we go from here? I do really appreciate Apple opening up another venue that Mac developers can use to generate much needed revenue, don't get me wrong. But personally, other than Cloudburst, a simple 99¢ app that I recently released, and new, improved versions of MacGourmet touch, I don't see myself dedicating much time to iPhone development.

Unless you have an iPhone companion to a Mac app, like MacGourmet touch does, how do you find any kind of traction? Unless Apple finds your app interesting enough to feature, most apps are liable to get lost in a sea of releases. With that in mind, it can be hard to justify spending a lot of time on something, only to see it sink like a stone in a sea of mediocrity.

There's also the matter of coming up with an app that never gets approved... after you've finished it and submitted it to the store. That can be quite a deterrent. I think Craig Hockenberry puts it best in Year Two when he says:

At present, it’s a crap shoot. When you roll snake eyes, you have no other channel to sell your product and you’ve lost a lot of time and money."

What would help? Quicker turnaround on submissions (it can take up to 3 weeks now, and it's only getting worse), a way for developers to respond to reviewers with problems and questions and better methods to search are just some of the ways that Apple could really improve things. Apple's done an amazing thing in the first year just getting the store up and running and in general working well, but we can only hope that they are listening to our feedback when deciding on the necessary changes for year two.

I recently added a side project of mine to the App Store: Cloudburst. It was one of the things I was noodling on while trying to learn app development for the iPhone. It got to a point where I finally decided to get Jordan Langille at OneToad Design to put some graphics and an icon together for me afterwhich I packaged it for release. You can get the full story here: Welcome to Cloudburst for iPhone!

Macworld just reviewed MacGourmet as a "Mac Gem" giving it 4.5 mice out of 5!

According to the reviewer:

If you’re a recipe geek and need a place to store, organize, and categorize your current and potential meals, look no further than MacGourmet. From the program’s recipe box metaphor to its flexible visuals, plug-in architecture, auto import functions, and smart searching, this is one of the most versatile and extensible programs available for any cook.

The review is pretty extensive and hits on just about everything. It's a great read for even current users: you may find out about things in the product you didn't even know were there!

The reviewer sums up her review with:

If you work extensively at cooking or event planning, or you’re just intensely organized and interested in exploring the subject, MacGourmet should be in your shopping cart. Its functionality and extensibility add convenience and ease to tasks that can become mundane over time. Its automated features and flexible presentation are appealing, and the core program is priced attractively. If you want to add features like nutritional information, meal planning, and cookbook publishing, you can add on the items you’re interested in piecemeal or just purchase the Deluxe version.

You can read the entire review here: MacGourmet organizes and helps find new recipes

Ok, at first when I heard about BumpTop I thought, "great, yet another lame desktop replacement app" but this actually looks pretty cool. It includes some elements of what you see in Mac OS X, and some that were rumored (like piles).

Hands-on: BumpTop may be desktop revamp you've waited for

It's only available for Windows right now, but the site says it's coming for Mac OS X and Linux too.

Not as good as really being featured, but still kind of neat, I must say... MacGourmet "Featured" in Latest iPhone Ad "Office"

Unlike many apps developed for the iPhone, MacGourmet touch is more of a "port" of MacGourmet to the iPhone. It's meant to work tightly with the desktop version of MacGourmet, and comes with a certain set of built-in expectations. In some cases, this makes things easier, in others more difficult. Existing users have a certain set of expectations, created by the desktop version, that will carry over into the iPhone version. Because of that, It takes some thought and planning, and a tight focus, to meet the key expectations, without building something that just doesn't work on the iPhone. That said, I have a number of things learned during the process of designing and building MacGourmet touch:

1. Remember, the iPhone is not a Mac, not even close. Don't try and include every feature from the desktop app, and every option. In a lot of cases, it won't even be possible. Simplify, Simplify Simplify.


2. Concentrate on the core feature set. Yes, a desktop app can be about every feature from A-Z (not that you SHOULD do this even for a desktop app, but it IS possible). Design for focused functionality. MacGourmet touch focuses on taking your recipes, notes and shopping lists with you. This means that quick and simple display of information is more important than say, advanced Find, advanced organization, publishing, web site import, etc. or even editing (though I do plan on allowing editing more than just shopping lists in the future).


3. Some of your desktop code will come over to the phone just fine. Some won't. Test, test, test. You'd be surprised by what does work on the Mac, but doesn't work at all on the iPhone, especially if your desktop app has been around for a while.


4. Build for the device as early as possible. As I write this, the simulator will let you include and build with libraries and APIs that aren't available in the iPhone OS. A good example bit me in the butt: I built the original sync code using NSArchiver, got everything done and working in the simulator, only to later find out that NSArchiver isn't supported, only NSKeyedArchiver is. This meant taking a huge step back and changing a lot of working code. Ouch!


5. Port your code with an eye towards improving both the desktop and iPhone versions of your application. I've found that the iPhone code I've been writing has actually been improving some of the code that the desktop version uses. This cross-pollination is a very useful and beneficial thing, if done right.

MacGourmet touch will continue to evolve in the future. There are some things, like editing recipes and notes, in addition to editing shopping lists, that definitely make sense. Something like simple meal planning would also make sense as a future feature. How the product evolves though, will be influenced and largely dictated by the points I've listed above.

For another great take on building a companion iPhone app, Cultured Code's post on how they developed their companion app for Things is a good read.

I'm not sure how others have found the App Store approval to be, but I found it anything but smooth. In trying to get MacGourmet touch approved for the App Store, it was rejected three times:

• The first rejection, 3 days after submission, was because I didn't acknowledge that there might not be an active connection available. OK, I've noticed that other apps don't necessarily do this, but I found the reference, sort of, so fine, it's a logical request. Resubmit.


• The second rejection, 3 days after resubmission, was because I didn't provide "login information" for testing... which shows a lack of understanding about syncing that the average MacGourmet user wouldn't share. Syncing is with the app, not a web site that requires a username/password... Fine, I provided a download link for the prerelease of 2.4 and a link to the set up instructions. Resubmit.


• The third rejection, after another 3 days, was the result of the wrong build hastily getting placed on the server. A 30 second fix. Turn around time on that one? 4 days.

As a developer who is used to complete control over my release schedule, and when products are "ready for release", this whole exercise is an exercise in frustration. Not to mention, the whole process is time consuming. 3 days for each turnaround, which is probably decent, is just too long. Does everyone experience this kind of submission experience? I'll bet that once Apple decided to relax their standards and let iFart into the store, that it wasn't rejected even once...

There IS a flip side supposedly too though, as detailed here: Android app uproar sparks debate over open app store model. Apparently an app store can be a little TOO loose, at least according to the writer, who advocates needing submission standards similar to Apple's. Really, though, how is software downloaded from the Android app store different from software you can download and install now for your Mac or PC? These problems are all possible when you download a Mac application, but you hope that the developers are good citizens and do their best to "do no harm" and for the most part, that works.

As you can see, the problems with the App Store go beyond just what Craig Hockeberry refers to in his open letter to Steve Jobs, Ringtone apps. Anything more complicated than a fart "Ringtone app" is bound to also be a LOT more difficult to get approved, if for no other reason than the testers don't read or misunderstand requirements, and don't know how to use the companion apps the iPhone apps are made to work with.

Add to that, it's getting harder and harder to make a compelling business reason to even produce apps for the store, at least anything beyond what you can develop quickly and sell for a buck: The future of the crApp Store as detailed by the folks at Chilli X.

Now that MacGourmet touch is out, I do plan to add to it, but I'll have to balance that time with development on the main MacGourmet product and I have no choice but to base that time on what MacGourmet touch can generate for revenue. I love developing for the Mac, don't get me wrong, and that extends to the iPhone, but everything has a cost, and if the App Store doesn't have a significant enough return on time investment, then I'll have to spend a larger bulk of my time every day elsewhere.