App Rejections

From Erica Sadun, a great idea – a tool that checks your source code, and hilights one of the things that is likely to cause “automatic” rejection by Apple: using private methods, or private method names. Now in beta, APIkit:

it’s a developer response to Apple’s automated API scanning system, offering a proactive heads-up about method names and function names that might trigger a problem over in the App Store system.
…
APIkit attempts to scan your applications to detect potential conflicts with private API names. The tool remains a very early beta.

We’ve seen a few examples already of apps (and even entire libraries) getting rejected for innocently choosing “the wrong names” for methods. Although in each case it’s not hard to workaround, Apple’s weak developer tools (Xcode, I’m looking at you: Refactoring was invented 15+ years ago, there’s no excuse for STILL not supporting it) make it slightly annoying to fix. Worse, though, is the time lost waiting for your app to be rejected, with no advance warning.

This tool gives you that advance warning (although this seems to be a much much smaller issue now that Apple is processing submissions in days rather than weeks).

Here’s an excerpt of what it prints out, from the docs. The tool is command-line only, but provides nice, clear, output:

Potential private framework issues:

[AppSupport]hostname override via CFNetwork
[DataAccess]cache override via AddressBook
[GMM]platform override via CFNetwork
[iTunesStore]setCache: override via AddressBookUI
[Message]sendData: override via GameKit
ALERT: -clearCache matches private framework OfficeImport.
[Preferences]busy override via SystemConfiguration

After Private Frameworks Scan:

1 whitelisted class methods, 1 blacklisted class methods
51 whitelisted instance methods, 4 blacklisted instance methods
52 whitelisted functions, 0 blacklisted functions

Potential blacklist items:

+dictionaryFromData:
-actionsView
-canConnect
-selectSegment:
-clearCache