iPhone Apps: Two Kinds of Approval

March 1st, 2010

Apple recently removed about 5,000 apps from the iTunes App Store on the grounds that they featured “overtly sexual content.” John Gruber believes that Apple is trying to protect its image:

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.

Tags: , ,
Posted in iPhone | No Comments »

Make Xcode nag you about unfinished TODOs

January 8th, 2010

If you’re like me, you often make promises to yourself in the form of TODO comments in your code. For example:

// TODO: make sure file exists before opening!
fooBar = [[FooBar alloc] initWithFile:path];

This is a reasonable thing to do, because sometimes you just want to get something working right now and aren’t in the mood to write all the required error checking code. But, you also know that you cannot trust your soft human brain to remember to add the check later, so you write a comment to remind yourself to do it.

Xcode recognizes the TODO: keyword in your comments and helpfully adds items to the function popup menu so that you can quickly navigate to them. In addition to TODO:, Xcode will also recognize FIXME: (when you know the code is broken), ???: (when you don’t know what it does), and !!!: (when you wish you didn’t know).

That’s helpful when you’re editing a file, but what about a TODO tucked away in some dark corner of your source code that you haven’t visited in a while? You’re likely to forget about it, and how can you keep a promise you forgot that you made?

The answer, of course, is to have somebody nag you. Fortunately, there’s a way to have Xcode fill that role. All you have to do is add a simple Run Script Build Phase which turns them into Build Warnings.

Select Project > New Build Phase > New Run Script Build Phase from the menu bar. Then, copy and paste this into the script window:

1
2
3
4

KEYWORDS="TODO:|FIXME:|\?\?\?:|\!\!\!:"
find ${SRCROOT} \( -name "*.h" -or -name "*.m" \) -print0 | \
    xargs -0 egrep --with-filename --line-number --only-matching "($KEYWORDS).*\$" | \
    perl -p -e "s/($KEYWORDS)/ warning: \$1/"

What does it mean?

Line 1 defines the keywords we want to search for. If you want to exclude a keyword or include a different one, edit this line.

Line 2 uses the find command to generate a list of all files in your project directory (SRCROOT) having an .h or .m extension. If you want to search more files, you will need to edit this line.

Line 3 uses xargs to pass those file names along to egrep, which searches inside the files for lines containing one of the keywords. If any are found, it outputs the file name, line number, and the matching part of the line.

Line 4 uses Perl to format the lines as warnings.

The output of the script will look like this:

/Users/benzado/Projects/FooBart/Baz.m:42: warning: TODO: make sure file exists before opening!

Xcode will recognize lines in this format and treat them as first class build warnings. You can see them in the Build Results panel and, just like a warning from the compiler, a double click will open an editor window and take you directly to the offending line.

An Exercise For The Enterprising Reader: modify the script so that no warnings or errors are reported during Debug builds, but TODOs are flagged as errors in Release builds.

Tags: ,
Posted in Nerdery | Comments Off

Draw your own Disclosure Indicator

January 3rd, 2010

I’m writing Cocoa Touch code to draw a button which, when pressed, pushes a new view controller onto the stack. If I was working with a UITableView, I’d simply set the cell’s accessory to be a disclosure indicator (the little gray arrowhead) and call it a day.

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.

Tags: ,
Posted in Nerdery | Comments Off

« Older Entries