ApplicationReview
Latest
Confirmation of Apple rejecting an app for accessing UDID
Paul Haddad of Tapbots confirmed that Apple is rejecting apps which send out UDIDs. The developer posted a rejection notice for version 2.2 of its popular twitter client Tweetbot. The notice says that Tweetbot was rejected because the "app does not obtain user consent before collecting their personal data" and points to the UDID as the culprit. Tapbots says it was using the UDID for its push notification service and has disabled the code in the most recent version of Tweetbot that it submitted to the iOS App Store. Haddad advised other developers who rely on the UDID, "If you are an app developer and depend on UDID for any functionality it's time to migrate away from it, sooner or later Apple will catch you."
DevJuice: Apple begins unique identifier crackdown
The Verge writes that Apple has apparently begun to crack down on apps submitted using the now deprecated UDID (unique device identifier) APIs that allow developers to track individual devices. The programmer interface used to return an alphanumeric string unique to each deployed device. It was built out of a hash of the unit's serial number and other internal details. Apps that use the uniqueIdentifier API will automatically be rejected as this policy rolls out to its full complement of review teams. Instead, developers are directed to create unique identifiers specific to applications. Those identifiers can then be stored securely in the device keychain and retrieved regardless of application uninstalls/reinstalls. Although some developers have turned to using other approaches to track devices (for example, using the unit's MAC address), it's clear that Apple does not approve of any device-specific user tracking. For now, in-store apps that use UDIDs do not seem in danger of being yanked. The policy seems to apply to all new and updated apps, however. This may be the knell of doom for my Ad Hoc Helper app. Not sure where I'm going to go with that. If you have suggestions, drop a note or leave a comment.
Apple approves third-party email client for the App Store, violates its own policies
Recently we were sent a PR email about an iPhone app called BdEmailer. No big deal, press releases about new iPhone applications show up in our box in large bundles every day -- but this one was different. According to the release, the program is the "the first wide email iPhone app that supports client SMTP." That means, in essence, that it duplicates an exact function of Apple's Mail application on the iPhone and touch. That's kind of a huge deal, because up until this point we've been led to believe that this duplication of functionality is one of the company's red flags when it comes to approval. Now mind you, we're not complaining. The idea of having more apps to choose from for doing things like sending email is a great idea, but Apple... what the hell is going on? You refused MailWrangler and Podcaster for similar reasons, yet BdEmailer passes through your review process, SMTP functionality intact? This means one of two things as far as we can tell -- either you've relaxed your policies on duplicate functionality, or you've gotten incredibly lazy when it comes to approving applications. We're inclined to believe it's the latter, as BdEmailer has a fair share of bugs that need working out, but really, people need some clarification here on what will and won't pass -- and moving the goalpost all the time isn't going to help.
