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.

But I’m not working with table cells, so even though the standard disclosure indicator is perfect for this situation, if I want one I’ll have to draw it myself.

In this situation I will usually take a screenshot of the real iPhone control, add the image file to my project, and then feel kind of guilty about it. I began to do this, but I realized that the disclosure indicator is really only two gray lines. Two lines! How hard can it be to just draw it in code?

It turns out that it’s not too hard, if you’re willing to spend some time experimenting with different numbers and seeing what looks right. Fortunately for you, I’ve saved you the trouble by posting the answer here:

// Draws a disclosure indicator such that the tip of the arrow is at (x,y)
void BRDrawDisclosureIndicator(CGContextRef ctxt, CGFloat x, CGFloat y) {
    static const CGFloat R = 4.5; // "radius" of the arrow head
    static const CGFloat W = 3; // line width
    CGContextSaveGState(ctxt);
    CGContextMoveToPoint(ctxt, x-R, y-R);
    CGContextAddLineToPoint(ctxt, x, y);
    CGContextAddLineToPoint(ctxt, x-R, y+R);
    CGContextSetLineCap(ctxt, kCGLineCapSquare);
    CGContextSetLineJoin(ctxt, kCGLineJoinMiter);
    CGContextSetLineWidth(ctxt, W);
    CGContextStrokePath(ctxt);
    CGContextRestoreGState(ctxt);
}

Before calling the function, you should set the stroke color to 50% gray if you’re drawing on a white background or white if the control is highlighted and you’re drawing on a blue background. Or, you can use whatever color you like.

To be honest, I only eyeballed the result, so it might not be a pixel-perfect reproduction of the real thing. However, I think my eyeballs are at least as good as most users’ eyeballs, so I will confidently declare this code Good Enough.

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.

Instead, today was FUBAR because of code signing problems.

In my down time today, as I waited for certificates to be generated and phone calls to be returned, I searched the web for a good overview of digital signatures and public key encryption that I could use to explain the process to people who did not implement RSA in Scheme.

I found “What is a Digital Signature?” by David Youd, which manages to be simple without being misleading. He is writing about email, but the concept applies to code signing if you make the following substitutions:

• Bob → developer
• email message → iPhone application
• Pat → iPhone user
• Doug → malicious developer
• Susan → Apple Worldwide Developer Relations
• Pat’s user friendly software → iTunes

To find out, I wrote a test application which creates a mailto: URL of a specified length and then asks the system to open it.  On iPhone OS 2.0.2, I was able to successfully create an URL over 1 million bytes long and view the resulting message in the iPhone Mail app.

I tried some larger numbers, and ran into problems in both my test app or, if the URL opened, in the Mail app.  I didn’t try too rigorously to find a precise limit, because 1 MB is more than large enough for my purposes.  It appears, however, that there is no fixed limit on URL length, and the system will try to honor whatever memory will allow it to.