The latest X3watch iPhone app update got rejected. Here some of the highlights from the rejection email:
We have reviewed your application and have found that it is accessing and displaying the contents of the iPhone OS filesystem outside of your designated container area. The iPhone Developer Program License Agreement provides specific guidelines about this behavior in section 3.2(e).
There is no public method for obtaining the device's restriction settings.
You will need to revise your application to read only within your directory container and resubmit your binary to iTunes Connect in order for your application to be reconsidered for the App Store.
They think that I'm using some private API and going outside of the application sandbox to see if Safari is enabled. This made me laugh. I'm just being really clever. Here's the code to see if Safari is enabled:
I sent them an email with this code explaining I didn't break any rules. They never replied, but we got an approval email 2 days later. Silly Apple.
December was a month of rejection for me. The X3watch app another of my client's apps, and LifeChurch.tv's Bible app (which I wrote most of but am no longer a part of) got rejected.
What Changed
Apple changed the rules recently, which is fine. They change the App Store every month or so. Normally, you just click accept to the new terms and go about your business. Do you ever read EULAs? I don't. Basically the same thing.
The important change to note (that they obviously didn't highlight, but expected you to read the massive terms in legal speak) was their new policy on undocumented APIs. Before, private APIs were not allowed and undocumented APIs were just frowned upon but still allowed.
The Difference Between Private and Undocumented
Private APIs are basically anything in a Private Framework (found in /System/Library/PrivateFrameworks on the device) like JSON.framework or XMPP.framework. Undocumented APIs are APIs found in one of the public frameworks (found in /System/Library/Frameworks on the device) that are not in the header files or documentations. (You go about finding this with a neat tool called class-dump).
Why Apple Did This
Apple's rules for the App Store are intended to keep the apps in it good and the garbage out (one could argue to make developers lives horribly, but I'll leave that to your judgement). The reason for an API being undocumented is that Apple could change it whenever they want because they haven't taken the time to really finalize it. This means that an update could break your app because they changed something. They don't want apps that will randomly break on updates in the store, I get that.
Why I Care So Much
I understand Apple's reasoning for this, but I don't like it. There are a lot of things that many apps rely on that are undocumented. Even worse, Apple will let certain apps use undocumented APIs which is so unfair. We just want consistency Apple.
All of the apps that I mentioned earlier that got rejected, got rejected for UIWebView (the view that shows Safari-like content in an app) undocumented APIs. Bible was using undocumented methods for scrolling. Without the use of these undocumented APIs, the ability to scroll the webview without the user is impossible. X3watch got rejected for the same thing undocumented API (as well their keywords). My other client's app got rejected for disabling the scrolling of a webview with an undocumented API. So frustrating.
One Warning
I contacted my friends at LifeChurch.tv when the X3watch app got rejected, because I remembered using very similar undocumented APIs in Bible when I was still working on it. They informed me that they were rejected for using the undocumented APIs that I mentioned earlier. A few minutes later, they received an approval email saying their app had been approved and that they needed to take out the undocumented APIs before submitting another update or it would not be allowed into the store.
I guess it's kinda cool that Apple gives you a little grace if you were already in the store. My client and the X3watch app weren't already in the store, so they were just rejected.
Thoughts To Apple
Apple, a lot of developers rely on undocumented APIs. We understand why you won't allow them. We are just ask that you start documenting popular ones. I know a lot of people really want so see the scrolling and UIScroller in UIWebView documented, methods in UIApplication for airplane mode prompts, and many others. Please start an effort to documented these methods. Any effort to try to more clearly communicate App Store policy changes like this besides having us read the massive agreement would also be very welcome.
So Joel Comm (funny story, he offered me a job awhile back, anyway) who most notably made iFart released a video (watch below) today begging Steve Jobs to let his new app into the App Store.
Like the other apps from his company, the don't do much besides play an entertaining sound. Apple rejected the app because it "contains minimal user functionality". He goes on to show many other apps that also just play a sound.
Here's my take on the whole thing. If Joel or anyone else wants to release a bunch of fun little sound, fine. Personally, I think they are dumb and wouldn't pay for one, but a lot of people have enjoyed iFart and other similar apps, so more power to them. (By the way Joel's company also makes other kinds of apps like this, this, and this. Cool stuff.) My big issue with all of this is the same as Joel's: consistency.
Apple, please be consistent. As a developer that has submitted several apps to the App Store, and experienced this frustration many times before, I really wish they would publish a set of rules and stick to them.
Joe Hewitt
Joe Hewitt was the developer of the Facebook app. He tweeted that he was no longer going to work on it because of his frustration with the App Store.
My decision to stop iPhone development has had everything to do with Appleās policies.
I understand that Joe and everyone else in the community is frustrated with the process, but I don't like just walking away from iPhone development and the fabulous platform Apple has built is the answer.
As for Joe specifically, I don't understand why he is complaining so much. His app, Facebook, gets approved in days with special attention from Apple. Many, like myself, have waited over a month for an app to get approved.
Sure there are limitations for everyone, including Joe. Getting feedback from Apple in a day or two on what is wrong with your app would make the whole process a lot less painful. It's so frustrating to wait weeks only to find out they didn't like your app's description.