Listeners found this review helpful

A major feature of the App Store are the user reviews about the software being offered. There’s just one problem: software is not music. I’ve never had an MP3 crash or lack features. Applications also evolve and improve; I’m pretty sure the Jimi Hendrix track I’m listening to right now is the same one he recorded in 1969.

The App Store in iTunes fails to address these fundamental differences between their latest offering and what has been offered previously (media.) There is so much potential here: iTunes could be a great way for developers to collect feedback and find problems. Instead, we get gems like these:

The icon to this App scares me so much… That I’m too afraid to install the App. That bird looks angry like it wants to peck my eyes out for even concidering [sic] to install the application.

If you are gullible enough to watch FOX “News,” then you are gullible enough to download this app and work for them for FOX for free– you already are in a way, just by watching. This would be a great app for those of you that like to monitor “ethnic” types when the nation goes to “Code Orange,” or, God forbid, “Code Red!” Make sure you have this app when you’re digging your bomb shelter or spying on your neighbors’ subversive activities.

What makes this worse is that flagging reviews as inappropriate content seems to have no effect. I have flagged reviews of my own products, and those of other developers, and nothing has changed. If Apple wants developers and users alike to take this system seriously, they must address this problem immediately. Yes, it’s tedious and costly to do this review, but with continued neglect this system will end up being like YouTube for software.

If you have doubts that this will happen, take a look at the most helpful review for Band. Users are already learning how to game the system.

Some have suggested that buying the app should be a requirement before leaving a review. I agree, but this will not completely mitigate the need to vet content. A large percentage of applications are free: the trolls will just download before going on their merry way.

If all of this wasn’t depressing enough for developers, I’ll leave you with my biggest disappointment: reviews are a one way street. I’m not one to feed the trolls, but many of the reviews I’m seeing would benefit from a “Just try this…” or “We’re working on that…” type of response. There’s not even a link to our support on the reviews page.

I remain hopeful that someone at Apple will see what’s going on and have the power to fix it. My only advice would be to act quickly: the longer you wait, the harder it will be to clean things up.

Brain surgeons

Unless you’ve been stranded on a remote Pacific isle, you’re no doubt aware of the current furor over third party iPhone applications not being able to run in the background. To be blunt, I’ve never seen so many experts without a fricken’ clue. If you haven’t written code using the jailbreak tool chain, your opinions on the iPhone SDK, based entirely on what you see in a simulator, just aren’t relevant. You might as well be explaining the nuances of brain surgery.

As someone who has been involved in iPhone development for the past six months, please let me offer you a healthy dose of reality.

Twitterrific on the iPhone could definitely make use of a background process to gather new tweets. In fact, a prototype version of the software did just that. And it was a huge design failure: after doing XML queries every 5 minutes, the phone’s battery was almost dead after 4 hours. In fact, the first thing I said after giving Gruber this test version was “don’t use auto-refresh.”

The heart of the problem are the radios. Both the EDGE and Wi-Fi transceivers have significant power requirements. Whenever that hardware is on, your battery life is going to suck. My 5 minute refresh kept the hardware on and used up a lot of precious power.

(Those of you under NDA with the iPhone SDK should take a look at the documentation for Core Location. After reading about how it should be used, you’ll understand why getting your location in Maps and similar applications is only done on an “as needed” basis.)

And right about now, you’re thinking “But I’ll be smart about how I use the hardware.” Sorry, bucko, but you’re the exact reason why we don’t have background processing in the current SDK. You’re living in your own little dream world.

What happens when App A uses the network at 5 minutes past the hour, and App B uses it at 10 minutes past, and App C uses it at 15 minutes past, and so on? There’s no way for you to know what other apps are doing is there? And yet the battery is still taking a pounding.

In my opinion, such a scenario is quite likely. As a satellite device, the iPhone requires contact with other machines to do interesting things. Periodically hitting the network is the primary reason that developers want to run in the background.

Some have stated that Apple is limiting innovation. My opinion is that they are helping us from collectively shooting ourselves in the feet.

It takes several months of actual iPhone development before you eventually realize that the iPhone requires a completely different mindset. Until that happens, you’ll make assumptions based on desktop experience, and that in turn will lead to a lot of bad designs.

For what it’s worth, I think Apple will address this issue in the future. I can imagine a solution based on a plug-in (bundle) architecture that lets your application do things when the phone decides it’s a good time (not when you decide it’s a good time.) If the radios go on because you’re checking Mail, then you get a “network active” notification and a chance to run some short-lived TCP/IP connections. If you take too long, you’d get killed, much like Safari does with Javascript that runs too long.

Do I expect such a sophisticated system to be available in a beta of version 1.0? Hell no. And neither should you.

Hello App Store

The big day has come and passed. And you know what? We’re still in uncharted territory: for most of us Mac developers, the App Store is something new and strange.

Let’s start by looking at Apple’s cut in the deal. Is 30% reasonable?

My first impression was that it seemed a little high, but acceptable. You’re getting someone else to deal with the hassles of downloading, payment processing and, to some degree, promotion. There’s a lot of value in that. Look at what it costs to be on other plaforms, such as Xbox Live, and it seems fair.

But thinking through the situation a bit more, I realized that those things pale in comparison to the value of being associated with the Apple brand. Having their explicit stamp of approval and being included in the App Store will make any product more appealing to a customer. Buying directly from Apple means that your software won’t screw up their phone and that can be returned if it doesn’t live up to expectations. That, combined with the ease of a single click purchase, is going to drive a lot of sales. You’ll make up that 30% without even trying.

Update on March 13th, 2008: A reader, Philip Smith, wrote in with an interesting observation: how many developers have the ability to offer gift cards for their products? Traditionally, giving software as a gift has been a very hit or miss affair. But when friends and relatives can go down to the local grocery store and pick up a gift card for the App Store, that problem is solved. Yet another way to increase your sales with the help of Apple.

One thing that disappoints me about the iPhone SDK sign-up is that the entry fee of $99 is too low. I look at the entry fee as a way to filter out developers that aren’t fully committed to the platform. Unfortunately from what we’ve seen so far, including the load on developer.apple.com on the day of the SDK release, there’s a huge amount of interest. I fear that Apple is going to be overloaded with application reviews, issuing certificates, and other administrative tasks. A higher entry fee would lessen the chance of this becoming a bottleneck for getting my product into the system. Please charge me $499 and let move to the front of the line.

Now, let’s look at how this affects our current business and way of doing things. Even though writing applications for the iPhone is now incredibly easy, selling software is much more than just writing code. My primary concerns at this point are with the details of distribution.

Take a look at our Twitterrific product: we’d love to offer both free and paid-for versions. Will that be allowed in the App Store? There’s also the traditional “try before you buy” model that we’re used to having with our desktop applications. As a customer, I’d like to know what I’m getting before I put my money down. Will the App Store allow some kind of trial period?

As Apple builds out the App Store, I hope they take the approach that they have with the iTunes Store. Let me write an application “preview” that anyone can download freely. If they like it, the buy button makes us both happy. All I need to do in order to make this happen is provide two files to Apple: one is the software equivalent of the 30 second clip, the other is the real deal.

Anyone who’s been selling online for more than one major release knows how important upgrade fees are to the continued growth of a product. It drives new features and keeps the product life cycle moving along. Yet we’ve heard nothing about how this will be handled at the App Store. Will we be able to identify existing users and offer them discounts? Keeping existing customers happy is in my best interest and that of my new partner: Apple.

Update on March 10th, 2008: Another issue that occurred to me was how we’ll be able to offer the product at varying price points. For example, NFR licenses for reviewers, free licenses for contest prizes and discounted licenses for promotions like MacSanta. Again, I hope that Apple keeps our promotional needs in mind as they implement the App Store.

There has also been no indication on how we’ll be able to handle distribution during a beta test. There’s no way I’m going to release a major product without letting a significant number of users run a private version of the application. Can we get these pre-release versions of the product onto their phones without using the App Store? Will the App Store itself provide some special beta mechanism? Will we have to run our own App Store like large enterprises? Any guidance in this regard needs to happen soon, June will be here before we know it.

This is an exciting time to be an OS X developer. I feel confident that Apple will address some of the concerns mentioned above and we’ll all be happy campers by the time the App Store launches. Now, excuse me while I open up my new Xcode project…