I think what Apple was getting squeamish about wasn’t the sexy apps themselves, but the cheesiness that the sexy apps (and their prominence in best selling lists) was bestowing upon the general feel and vibe of the App Store. One thing I wasn’t aware of before the recent crackdown was the degree to which these apps were seeping into various non-entertainment categories. E.g., like half the “new” apps in the “productivity” category featured imagery of large-breasted bikini-clad women.

The App Store is never going to be like Apple’s retail stores, and Apple knows it. Apple’s retail stores, branding-wise, convey an image sort of like between the Gap and Banana Republic — friendly premium. The App Store is more Old Navy, or maybe even Target. But these sexy apps were casting the App Store into something junkier, bordering on the skeevy.

This interpretation makes the most sense to me, too. In fact, I sympathize. When I gave my brother an iPod touch for Christmas, I showed him the App Store, and was mildly embarrassed that the number one app that day was a fart sound effects generator.

Unfortunately, the App Store’s role as the one and only way to distribute an iPhone app means that we have a dilemma. To carry something in a store is an implicit endorsement, so any store owner should have the right to decide what products to include. However, a healthy economy for apps requires a free market. Rejecting apps for subjective reasons makes development more risky than it needs to be.

Technical Requirements vs. Community Standards

The source of this dilemma is that the app review process serves two distinct purposes: to approve apps for iPhone and to approve apps for the App Store. If separated, the dilemma can be resolved.

Suppose you have developed an app and submitted it to Apple. It complies with all the technical requirements of an approved app: it sticks to the Human Interface Guidelines, it doesn’t use any private frameworks, it doesn’t execute downloaded code. However, it fails to meet Apple’s community standards: it contains overtly sexual or politically controversial content.

Enforcing technical requirements is for the benefit of the platform. Enforcing community standards is really only about the App Store.

Kick ‘em to the curb, but no further

In theory, Apple could inform you that your app is permitted to run on iPhone OS but will not be included in the App Store. This could happen in at least two ways:

They could maintain iTunes as the sole distribution method for apps, but designate your app unlisted. Nobody will find it in the store by browsing or searching, and it won’t appear in the top seller lists. However, it will be reachable by direct link. Apple will still manage the hosting and payment processing, but if you want anybody to find it, you have to market it yourself.

I obviously don’t know how the store is set up, but I bet Apple could do this relatively easily. (I’ve already discovered that an iTunes reviews page is accessible via direct link as soon as you submit an app, before the review team has had a chance to see it.)

Alternatively, if Apple wants to completely wash their hands of these dirty apps, is to provide developers with a digitally signed IPA file. You distribute the file yourself; users install your app by dragging the file to iTunes. If you want to charge, you have to roll your own payment and registration system, just like desktop shareware developers do.

This method seems less likely, mostly because it adds a big loophole for those who want to circumvent the App Store for other reasons. On the other hand, if all developers had the option to sell outside the App Store, I think it would be an overall good for the platform. But now we’re going off on a tangent.

Obviously, everybody would rather be part of the iTunes App Store than operate outside of it, but if given a choice between “outside” and “nowhere” I think outside is a clear winner. Separating the notion of “approved for iPhone” and “approved for the App Store” would benefit Apple and developers.

That’s how I noticed this new review of FatWatch, my weight tracking app for iPhone:

It does exactly what it says it does, but it’s far too expensive and the developer seems to have abandoned it. Get one of the free weight apps and save yourself the dough.

Ouch!

In a world of disposable mobile apps, FatWatch might seem expensive, but it’s actually quite cheap for what it does: tracking your weight against a moving average in a well-designed application. The average is key; it’s the only useful way to track a human being’s weight, and none of the free apps can do the math for you.

For devotees of The Hacker’s Diet, it also lets you import your weight history from the old Palm Eat Watch app and export it to your computer any time you choose.

As for the other concern, I assure you that FatWatch has not been abandoned. I use it every day! I suppose it is overdue for an update, but that’s only to add new features, as (save for a minor cosmetic issue) no bugs have been reported in FatWatch 1.4.

The good news is that I recently completed a contract project that puts me in a comfortable enough financial position to devote time to a FatWatch update. So, watch this space, and if you’re interested in beta testing, wait for an announcement soon.

MetroCost is an app for iPhone or iPod touch that helps you track your public transit expenses. I live in New York City, so I use the subway a lot, but I’m a freelancer, so I don’t ride it every day. I began to wonder: should I really be paying $89 a month for an Unlimited Ride card, or would I save money if I paid $2.25 per ride?

Except it’s not that simple, because if you add $8 or more to a Pay-Per-Ride MetroCard, a 15% bonus is added to your total. As long as you add at least $8 at a time, a ride actually costs $1.96.

So, how does MetroCost help figure this out?

Each time you ride the subway or the bus, launch MetroCost and swipe a finger across the “magnetic” strip. It will keep a record and, based on your average ride count per day, compare the costs of an unlimited versus a pay-per-ride card.

If you’ve recorded 30 days’ worth of rides, the calculations will be exact; if you’ve recorded less than that, you will still get a useful estimate. Either way, the next time you need to buy or refill your card, consult MetroCost to see which is best for you.

MetroCost is set up for New York City transit out of the box, but it’s totally customizable. As long as the fare doesn’t vary with distance traveled (sorry, Washington, DC) you can use MetroCost to save money.

You can also frivolously change MetroCost’s appearance to match your transit system’s color scheme.

MetroCost debuted at $1.99 but for this week only you can get it for FREE on the iTunes App Store. On Saturday I’m restoring the price, and maybe raising it, so you’d be crazy not to download it now.

Don’t be crazy!

Your iPhone app includes a Settings bundle, so that you can keep your application simple and leave the settings in the settings app. Specifically, you allow the user to customize the FooColor setting, with a default value of Red.

Initially, the user defaults database doesn’t contain a value for FooColor. Although you defined a default value in the Settings bundle, only the Settings app pays any attention to it.

Take Note: Cocoa uses the term “user defaults” to refer to application settings in general. Don’t confuse that with the notion of a default value, which is the initial value of a setting before it has been changed through user action.

The proper way to load default values at runtime is to use NSUserDefaults’s registerDefaults: method. It takes a single NSDictionary object and merges it into the user defaults registration domain. (The user defaults database is divided into domains, or layers.) Values in the registration domain are only used if they are not defined anywhere else, so you don’t need to worry about overwriting a user’s preference.

You create a property list file named Defaults.plist, define an entry giving “FooColor” the value “Red”, and load it:

NSString *path = [[NSBundle mainBundle] pathForResource:@"Defaults" ofType:@"plist"];
NSDictionary *dict = [NSDictionary dictionaryWithContentsOfFile:path];
[[NSUserDefaults standardUserDefaults] registerDefaults:dict];

The only problem with this set up is that you must keep your Settings bundle and Defaults.plist files in sync. If you change the default FooColor from Red to Blue, you must change both. If you add a new setting, you must add it to both. If you’ve been programming for more than a month, you know that eventually you will make a mistake which will lead to a bug that will take forever to track down and take years off your life.

Therefore, a better solution is to dynamically generate Defaults.plist from the data that is already in the Settings bundle. You can do so with ExtractDefaults.xsl, a simple stylesheet which creates an XML property list from a Settings bundle definition, and xsltproc, which is fortunately already installed on your Mac.

First, if you really did create a Defaults.plist, remove it from your project and delete the file. It’s graduating from a source file to a build product!

Then, select your target in Xcode. Go to the menu bar and select Project | New Build Phase | New Run Script Build Phase. A window appears. In the Script area, enter the following shell script:

SETTINGS_PLIST=$SRCROOT/Settings/Root.plist
XSL=$SRCROOT/ExtractDefaults.xsl
DEFAULTS_PLIST=${BUILT_PRODUCTS_DIR}/${WRAPPER_NAME}/Defaults.plist
xsltproc -o $DEFAULTS_PLIST $XSL $SETTINGS_PLIST
plutil -convert binary1 $DEFAULTS_PLIST

You may need to edit the first three lines, depending on the path to your Settings page file and where you saved ExtractDefaults.xsl. It’s also recommended that you fill in the Input Files and Output Files lists, so that Xcode can intelligently determine when the script needs to be run (when input files are newer than output files). Following the script above, Input Files should contain:

$(SRCROOT)/Settings/Root.plist
$(SRCROOT)/ExtractDefaults.xsl

Output Files should contain:

$(BUILT_PRODUCTS_DIR)/$(WRAPPER_NAME)/Defaults.plist

Note that Xcode needs round parenthesis around variable names, unlike the shell script, which uses nothing or curly braces. There’s a good reason for this, but I don’t know what it is.

That’s it! Now, when you build your app, the script will generate a Defaults.plist file inside of your app bundle, so it can be loaded by your code. And you won’t have to worry about your app defaults mismatching your Settings bundle defaults, because it is being handled by a machine, and machines never fail!

Mini-FAQ

Where do I get ExtractDefaults.xsl? Click here to download the file. It’s free to use for whatever you want to do with it. If you improve on it in some way, kindly let me know.

What if I have also default values not defined in my Settings bundle? You can manually enter them into another property list file, and load both. It’s totally cool to call registerDefaults: several times with different dictionaries. Totally cool!

What if my Settings bundle contains multiple page files? In that case you could run the script over each one, generating several Defaults.plist files, and load them all at runtime. Or, if you’re really clever, figure out some way to merge them all into a single property list at build time. I can’t do everything for you.

Many of the mercenary testers I encountered were motivated to scrape the system for bugs, as ridiculous as they may be. They logged them into the bug system and then defended them at all costs, as if their lives depended on it. And it turned out, they did. At least, their paychecks did.

I would not be surprised to learn that App Store reviewers are working under a similar structure. A system that rewards “unique, valid rejections” would certainly explain the behavior we have seen coming to light in the past year.

QA teams, like the ones Daniel writes about, reward “unique, valid bug reports” because all the testers are testing the same piece of software. If a group of testers repeatedly file duplicate bug reports, clearly you have an inefficient team, and can afford to let some of them go. The team has an incentive to reward unique reports.

The App Store review team, on the other hand, has one reviewer per app, and each app is different. Even if the team was perversely trying to justify its existence by beefing up its rejection numbers, there would be no need to come up with “unique, valid rejections.” In that case it would be more efficient for them to reject apps with increasingly vague reasons, or no reason at all.

It is more likely that reviewers are severely punished (i.e., fired) for approving an app that later causes a problem. That’s the kind of situation that leads to overzealous reviewers without assuming that management is dumb.

And there are problems: all the writing on the Ninjawords rejection pits Apple against enlightened liberal people. Not pictured are the parents who have purchased an iPod touch for their young child and want to let them download games from the App Store, but maybe don’t want to let them downloading Motorboat, which is not actually about boats, but involves rubbing your nose on the touchscreen.

When Apple added ratings to the App Store, it did not do so in a vacuum. It has quite a few customers with children, who I suspect express themselves by making phone calls instead of posting on blogs. So while we’ve read a lot about the helpless developers who are being persecuted by puritannical Apple, we haven’t read the testimony of parents who are trying to give their child a little bit of freedom without having to worry that they will get the idea that sticking your nose in a woman’s cleavage is an acceptable thing to talk about during Thanksgiving dinner.

I submitted an update to Apple, changing as little else as possible, hoping that it would get through their review process in time for the public release of 3.0. Unfortunately, it was rejected for violating the iPhone Human Interface Guidelines. That’s right: I was nailed for something that they previously approved.

What I got away with

I could bitch about it, but they were right: the objection was to the Wi-Fi Import/Export feature, which in FatWatch 1.4 was enabled by a simple switch.

If you want to import or export a CSV file containing your weight history, all you had to do was turn that switch, and a new row would appear beneath it with an IP address to connect to.

If you didn’t know what to do with all those geeky numbers and slashes, hopefully you would tap on it, because doing so would display an alert explaining that you are supposed to enter that into the address bar of a web browser on your computer.

Even when working properly, this is a spartan interface. I’d honestly be surprised if anybody who doesn’t describe themselves as a “geek” figured it out. What’s worse (and this is where I got into trouble with Apple) is when you turn on Wi-Fi Import/Export and you’re not even connected to a Wi-Fi network. You get a blank row.

So yes, I could say to Apple, but that’s how it worked all along! But that’s like telling the police officer you shouldn’t get a ticket because you run this red light every day and nobody gave you a ticket before.

Making things right

Initially, I tried to fix things by detecting whether a Wi-Fi connection was available and, if not, snapping the switch back to the OFF position and displaying an alert with an error message. While that would have been an improvement, it still felt… terrible.

After sleeping on it (always more productive than hammering away all night, will I ever learn?) I realized that Wi-Fi Import/Export really deserves its own screen, rather than the series of alert views I had allocated it. In practice, you aren’t going to use your iPhone or iPod touch for anything else while you are importing or exporting a file, so there’s no need for it to operate in the “background” of the app.

So in FatWatch 1.4.1, the Wi-Fi Import/Export changes from a switch to a menu item.

When you tap it, you see a screen that explains what Wi-Fi Import/Export does and how to use it. It also tells you that you can use Bonjour, instead of typing in a series of dots and colons and numbers. FatWatch always used Bonjour, but there wasn’t enough space in the old interface to explain it.

FatWatch will now remember the last time you imported or exported a file; very useful if you want to export a file as a backup every so often and you can’t remember when you did it last.

But, most importantly, if you are not connected to a Wi-Fi network, FatWatch now makes it abundantly clear.

As a bonus, now that I have a whole screen for this feature, I was able to get rid of the alerts and do some nice things, like display a progress bar so that you know things are working when you’re importing a large file.

I won’t claim it’s perfect: even now I want to edit some of the text in those screenshots. I held myself to a fairly tight schedule because I didn’t want people to be waiting too long for the bug fixes that was supposed to be the primary focus of this release. However, I am glad Apple challenged me to improve this feature, because it has gone from an embarrassment to something I can feel mildly proud of.

More

A few other improvements that are coming in 1.4.1:

• The Wi-Fi Import/Export web pages are easier on the eyes.
• FatWatch puts today’s date in the exported file name, for example: weight-2009-06-29.csv. Useful if you let those files accumulate in your downloads folder.
• The Go To Date screen displays its buttons in a navigation bar; looks a lot nicer.
• Fixed a bug where BMI values were calculated incorrectly. Basically, if you select your height in feet and inches, FatWatch always added an extra centimeter to your height. That has been fixed.

Everybody cross your fingers, and hopefully it will appear on iTunes soon!

If you are using FatWatch 1.4 (the latest version at the time of this writing) then you can safely upgrade to iPhone OS 3.0 if you are willing to suffer a cosmetic issue. Specifically, if you have BMI Monitoring enabled and use the control on the top of the Log view to switch between BMI and Variance, the values will not update unless you force them to by either scrolling the table or switching to and back from another view. It’s annoying, but not fatal.

I submitted an update to Apple that fixes this issue (and a few others), hoping it would be available on iTunes before the 3.0 update was released. Unfortunately, Apple rejected the update for a human interface issue concerning a feature that I hadn’t changed. It feels a little unfair to be rejected for something that was previously approved, but “I got away with it before” is not really a defense. They are right, it is something I should fix, it’s just that the timing is obviously less than ideal.

I intend to fix this issue and resubmit today or tomorrow, which means that FatWatch 1.4.1 should hopefully be available sometime next week. Or maybe not. I wish I could say. In the meantime, should you want to install the iPhone OS 3.0 update you can continue to use FatWatch 1.4 and be mildly annoyed at the display issue.

While you’re waiting for that to become available and/or affordable, you might be interested in FatWatch, an app for your iPhone that also estimates your caloric intake, although it requires you to step on a scale and make a note of the number once a day.

(P.S. I found the above news via The Skeptical Hypochondriac. Recommended if you’re interested in health news without the hysteria.)

Sorry, but Apple ain’t gonna do it.

First of all, there is no way Apple is going to offer a binding approval based on a design. You and they may have interpreted the design differently, and if your finished app does something they didn’t expect, they will want to reserve the right to reject it. Thus, even with a design review, you still risk rejection.

Even so, a design review that offered only an early rejection result would still have some value. To you. But it would be insanely expensive for Apple, because of supply and demand. Specifically, the supply of and demand for an app reviewer’s time.

It’s basic economics

Although iPhone Developer Program membership only costs $99/year, there is an additional hidden cost for every app you want to submit to Apple: the expense of creating an app in the first place. This effectively limits the amount of work that Apple’s review team has to do.

A design review program would effectively be a huge decrease in the cost of a reviewer’s time. Creating a good design and mock-ups takes substantially less effort than building a complete application. And creating a hastily put together paragraph with poor spelling about your app idea takes even less effort than that. So, with next to no effort at all, you will be able to send your app idea to Apple for review.

And I’m certain that lots of people will, because there is a huge surplus of ideas out there. It’s easy to come up with an idea. Everybody I know with an iPhone has told me about their idea for an app. Apple will be absolutely flooded with these design review requests. In order to handle them all, they will have to hire more reviewers and train them.

What does Apple get in exchange for that expense? Well, nothing. At best it might reduce their app review load, since some ideas that would have become app submissions will be stopped at the design review stage. But that number will be insignificant. Meanwhile, the expense of maintaining a design review team will be enormous.

It might work if the design review team was entirely financed by the people requesting reviews. A per-review fee could accomplish that, but it would have to be a non-trivial amount. In the end, most developers would scoff at it. (“Design review? What a waste of money! Why not just develop the app and submit it?”)

A happy ending

Given that iPhone apps must go through a review process, somebody must do the work of evaluating whether a design will be permitted on the App Store. Right now, Apple is asking the developers to do the work, since they have little to gain by doing it for you. True, they don’t publish an Ultimate Approval Guidelines Document, but you do have access to the iPhone Developer Program Agreement, the iPhone Human Interface Guidelines, trademark and copyright law, and a catalogue of all apps previously approved. So it’s not like it is completely impossible to figure out what’s allowed.

The good news is that, for all the complaining, rejections are not a serious problem. Rejections are not fatal to an app, and most of the time the violation is fairly easy to fix. The complaints I see on mailing lists are mostly about things like improperly used or trademark infringing icons. Even Podcaster eventually found a home on the App Store as RSS Player. I don’t know of a single case where an developer was completely unable to post their app on the store and get the opportunity to recoup their investment. (Prove me wrong in the comments.)

Anyway, I wound up writing a long email about my theory on how the App Store review process probably works, attempting to use actual data. I’m reproducing it here with some light editing.

First, here are the facts:

1. The App Store opened July 10, 2008 (about 8 months ago).
2. According to Apple’s iPhone OS 3.0 presentation:
   1. There are over 25,000 apps on the App Store.
   2. In February, 96% of submitted apps were approved.
   3. In February, 98% of approvals were in 7 days or less.
3. Podcaster was in review for about one month before rejection for “duplicating iTunes functionality.”
4. Several web browsing apps were in review for a month or more, before being approved more or less at the same time. The same thing happened to fart sound apps.
5. Tweetie was submitted around March 2 and rejected on March 10, because an F-bomb appeared on the Trends screen.
6. App Store growth (by number of apps) has been accelerating.

Now let’s work out a theory to fit the facts:

On average, Apple has been adding apps to the store at a rate of 3,125 per month.  The pace is actually accelerating (it took three months to reach 3,400) so the rate today is probably closer to 4,000 per month. That works out to 1,000 per week, or 25 apps per hour, assuming a 40 hour work week.

If each application review takes about an hour, you would need a staff of 25-30 testers to maintain this rate.  They probably install the app, tap around, look for problems, etc., then make an approve/reject decision.

In an ideal world, the entire staff would be highly intelligent and could be trusted to make carefully reasoned decisions in every scenario.  In California, where Apple is located, those people are doing more interesting jobs. The vast majority of apps are going to be fairly clear cases, so it would make more sense to hire cheaper and have the testers work from a checklist.  The checklist might look like:

• App does not require additional payment to unlock functionality.
• App uses standard icons as prescribed by the interface guidelines.
• App does not use any of the seven words you can’t say on television.
• App does not show boobies.

If the app fails any test, it gets rejected. If it passes all the tests, it gets approved.

If this were true, it makes sense that Tweetie was rejected rather quickly: the Tester, who probably doesn’t use or care about Twitter, was working down his list, saw the curse word (which is an instant reject), hit the reject button, and started testing the next app in his queue.  After all, he’s got to meet his quota if he wants to keep
his job.

On the other hand, Podcaster was in review for about a month before it was ultimately rejected.  What’s the difference?  Podcaster was rejected for duplicating the functionality of the iTunes app in a then-unreleased version of the iPhone OS.  (Unfair, but nobody said life was fair.)  This is a much less clear-cut situation. In addition to approve and reject, the Tester probably also has the option to pass the app along to a committee. Again, you probably don’t want to bother the committee too often, but sometimes you’re not sure what to do, or you don’t have the authority to release information about unpublished Apple software.

The committee probably has to do things like check with the Legal Department and iPhone OS Engineers and Designers. They debate what should pass and try to revise the checklist to handle similar cases more clearly in the future.

The committee probably also looks for similar cases to deal with them as a group. That would explain why the web browser apps were released from review limbo at roughly the same time: they probably clarified internally what counted as duplicating Safari, then re-reviewed them. Same goes for the fart machine apps, as Apple clarified their definition of obscene.

Based on my professional experience, that is how I would organize things. (I might have each app checked by two testers, budget-permitting.)  The view from the outside seems to confirm the basic idea that they are gradually improving the process as they approve more apps and update their checklist.

Given the volume of apps they are processing, it’s not surprising that there are going to be some mistakes like what happened to Tweetie: but that was hardly a fiasco, it was eventually approved.

If you’re going to say that Apple should have had a flawless process in place on Day One… well, I’m sure the view is lovely from up there on your high horse.  Before the App Store began accepting submissions it would have been impossible to write one set of rules that would clearly apply to every application.  So they did the best they could and have revised it over time, with experience.

Now, if you want to object to the rules (that Apple must approve the apps in the first place, that you can’t do porn, etc.) that is certainly your right. And if you want to complain that Apple is too secretive, yeah, but it’s worked so well for them that I don’t think they’re going to give it up.

But given that, the process hardly seems broken.