Open letter to Apple iPhone Developer Support

I’m a big fan of all things Apple, and as you can tell from my past blog posts I’m a big fan of iPhone development. I’ve even dusted off my aging C skills, and have learned to love Objective-C. The one thing I haven’t learned to love, like all other iPhone app developers, is their application release process, and the seemingly arbitrary app store acceptance department.

Don’t get me wrong, I think how Apple fiercely guards the App Store to prevent bad, buggy, or offensive material from getting on there is a great thing. Some of my mother-in-law’s students in the class she works in have iPhones or iPod Touches, and these little 10-year-olds love the little apps I’ve put out. They’re fun, light-hearted, and they get a lot of enjoyment out of these and other apps. It’s reassuring to know that if I install an app, it won’t crash my phone (too badly) or that a child won’t be offended by them (too much).

However, the level of detail they give in their rejections seem both arbitrary and unnecessary. You develop an app and have to throw it over the fence to Apple, after which you wait with no level of detail as to the status, or success, or any sense of progress through whatever queue they have. Finally, you more often than not get a big fat rejection letter that gives you no detail as to why your app didn’t meet their secret criteria.

In my experience so far, this has actually been a virtue. My apps actually did have minor race conditions, or problems on specific platform versions. So, fair enough, I fix my changes and submit them in. But recently, the framework I work with and have been helping develop seems to be under fire from Apple for no apparent reason. And it’s the contradictory nature of their message that is what gets under my skin.

In a long thread on the PhoneGap mailing list, a number of developers writing their applications under PhoneGap have been given rejection letters saying something like:

Upon review of your application, cannot be posted to the
App Store due to the usage of private API. Usage of such non-public
API, as outlined in the iPhone SDK Agreement section 3.3.2 is

” An Application may not itself install or launch other executable
code by any means, including without limitation through use of a plug-
in architecture, calling other frameworks, other APIs or otherwise.
No interpreted code may be downloaded and used in an Application
except for code that is interpreted and run by Apple’s Published APIs
and built-in interpreter(s).

The PhoneGap API implemented in your application is an external

For those new to PhoneGap, it’s a project that gives you an XCode project directory with Obj-C classes pre-made that allow you to develop iPhone apps in HTML / JavaScript. It wraps up several of the iPhone’s native controls and exposes those capabilities to JavaScript. In this way, an application developer could write their app in a hybrid of native Objective-C code and the iPhone’s own native browser control, the UIWebView.

It seems though that Apple constitues the use of their own controls as a 3rd-party library. Apple’s own developer documentation includes code sample projects, much like PhoneGap’s, intended to get a developer started on using their SDK. Is it incorrect to assume that others can do the same?

Additionally, there are 3rd-party companies such as AdMob, Medialets, and a number of others that provide ads, application tracking, and other resources to iPhone developers. Their code is given to you as pre-compiled libraries, that are most certainly not included on the iPhone when you pull it out of its shrink-wrap. So how is it that all these apps are released to the App Store with these 3rd-party libraries linked in, and an app framework whose source code is freely available and uses officially documented features can’t be?

I decided to put an end to the speculation, and wrote a letter to Apple’s developer support on this matter. I’ll give it a chance to percolate through their support department, and if I don’t hear an answer back via email, I plan to call their support department until I can get an answer.

For future reference, and in the interests of keeping the discussion open, here’s a copy of the letter I sent in to Apple.

From: Michael Nachbaur
Date: May 17, 2009 6:04:28 PM PDT (CA)
Subject: Library classification clarification

Hello, I’m an iPhone software developer, and one of the core developers of the PhoneGap project. A number of users of PhoneGap – a set of Objective-C classes aimed at leveraging the UIWebView to access iPhone-supported hardware features – have reported that their apps have been rejected from the App Store because they supposedly use a “3rd-Party Library”. I wanted to get some clarification about this, as this is not only untrue, it is completely at odds with the goals of our project.

PhoneGap only uses officially-supported features of the iPhone, as documented within XCode’s iPhone SDK documentation. We even make sure that we don’t even use deprecated features of the iPhone, as we want to ensure 100% compatibility. All the software we use is exposed natively by the iPhone, and is in use in many other apps on the App Store.

So I wanted to get an official clarification from Apple as to why these apps are being rejected, and what, if anything, we as the maintainers and developers of the PhoneGap project can do to rectify the situation. We are trying to empower developers with quality starting-blocks for developing their own applications, much as the Apple sample applications do.

So please, if there’s anything we’re doing wrong, we would more than happily change our code to accommodate Apple’s policies. As far as we can tell, we support Apple’s licenses even better than other apps on the App Store, because we don’t import 3rd-party libraries such as AdMob, Medialets, or any of the other ad and tracking libraries that are obviously featured on almost every app in the App Store. And these are quite plainly 3rd-party libraries, and as such should they not be even more restricted than we are?

As a community, of both software developers and of business-people, we are very anxious to hear back from you, and would like to discuss this with someone at Apple to get an official answer, instead of the conversation being one-sided and filled with speculation.

Thank you for your time, and I look forward to hearing back from someone soon.

What are your thoughts on the matter? Can anyone reading this find some reason why Apple would target PhoneGap?

Update: I got an update on this problem from Steve, one of the app reviewers, over at Apple.

33 thoughts on “Open letter to Apple iPhone Developer Support”

  1. It’s ridiculous. Since Phonegap does not allow the use of undocumented SDK features there’s really no reason for them to target it.

  2. I love PhoneGap and I strongly dislike the obscurity that surrounds most of the things related to the AppStore submission process. Let me know if I can join your effort in getting Apple to be more open and polite.Thanks

  3. Just a quick response to say that… and this is pure speculation on my part — it seems likely that, if indeed they are “targeting” phone gap, it’s for the simple reason that they do not want “cross-platform” applications in the app store.

  4. Please, lets try and keep this civil and professional. I don’t want to be associated with an angry mob climbing the steps to Apple HQ with torches and pitch-forks. We don’t know what goes on inside Apple, and they have a business to run too. I tried to make it very clear in my blog post that I don’t dislike Apple for the review process.I can’t and won’t try to censor people out elsewhere who want to express their opinions of Apple, or their practices, but I do have that control here.I apologize, but I deleted a few comments that were bashing Apple unprofessionally. I apologize to whom posted the comments, but I don’t want that sort of behavior on my blog. If you want to post it again, without the bashing, that’d be great, because you had some good things to say otherwise.

  5. Mike, I apologize. My comment was meant in jest and a little too much frustration. I too love Apple, but I wish they realized how stupid they look when they do these rejections so carelessly.But honestly, there are 20+ PhoneGap apps in the store. How did they get there if PhoneGap is in violation of the rules? Simple question, really.

  6. Oh, and you don’t need to apologize. It is your blog and you can remove posts that don’t communicate according to the standards you want to follow for posts on your blog.

  7. True enough, I feel the same way. @lqd on twitter just said:”i believe the #phonegap rejections are due to the online mode, since you can change your app’s code *after* it has been approved by Apple”That could definitely be it. Anyone care to try this theory? I’ll push a separate branch of PhoneGap up that removes this ability, and we’ll see if Apple will accept an app with this new code.

  8. I’m going to go with the hypothesis that it’s a content control issue. Apple has been out-and-out censorious in the app approval process, and this puts the entirety of the app’s content outside their control.Mike, if there’s some way I can assist with shaking some answers out of Apple, please let me know – the PhoneGap ban means 2+ months of wasted development for me, and I basically have to start my app from scratch.Maybe we should start a hashtag – #appstorefail? (Sounds lame, but it got Amazon’s attention.)

  9. @MikeRegarding the online mode being the problem. That’s my guess. I now understand why the Rhodes framework has the whole messaging system as part of its system.

  10. I think phoneGap will continue to have problems with the approval processes… Imagine you can hit a wonder with your app, you can have the same app get the same success on Android and Black Berry, at the end of the day Apple dosn’t have a diferentiator to sell more iPhones, remember that they make a profit from Iphone/iTouch not from apps.

  11. It’s a good thing PhoneGap was rejected, because that way the developers can focus on what the app store really needs: more fart apps.

  12. My phonegap application ( ) was approved, and I’m using the ‘online’ mode. I did get rejected once, but that was because I was using online mode and not telling people when they didn’t have an internet connection… so the app would just sit there. I actually appreciated Apple pointing this out to me, as it made for a better app.Overall, I don’t think they have a problem with the framework. There is nothing PhoneGap does that you couldn’t do on your own fairly easily. I’m more concerned with the 33 days it took to get approved than anything else.

  13. Ok, scrap that last bit. I just read the forum posts and it does seem that PhoneGap is being mentioned specifically. That sucks.

  14. Hey, I think the problem might be that Phonegap allows people to develop rich internet applications. From there, it’s only a hop and a skip to implementing a web browser, which they do not want app developers to do. Look at these two pages to see how I arrived at that theory:

  15. I’ve never used PhoneGap but if it uses the undocumented JavaScriptCore apis or links to the private JavaScriptCore framework then it is in violation of the SDK license. One way around this is to just download and compile the open source code for JavaScriptCore right in your project.They don’t want undocumented features being used since if they change it, everyone relying on those will have non-functional apps. That is something Apple wants to avoid at all costs.

  16. I know it is your choice and your project – and it is a great project – but I wish you wouldn’t disable “online mode” when we aren’t even sure that is Apple’s problem. For some applications, that method makes sense. Having a turnkey solution for that was a great resource.If it turns out that online mode is the problem, then of course it will need to be put down. I just hate to see such a useful feature cut out based on speculation alone.

  17. josiah: keep in mind that I’ve made those changes in my personal branch, so a) I can release an app update to Apple so I can test this theory, b) other people can do the same, c) Apple can see the code changes made and what an impact it would have.If Apple likes what they see, and that is indeed the problem, then we can merge those changes in to the main trunk. Of course, if that isn’t the problem, we can just roll-back those changes in my branch, and it never touches the public branch.That’s the wonderful thing about doing development in Git with branches. And of course, you don’t have to pull down these changes if you don’t want to. It’s up to you.

  18. If Apple holds firm to rejecting applications that use a private API will they start rejecting applications that utilize APIs from companies like Admob and others?

  19. Scott: I highly doubt that. For any business, rejecting ads from something is tantamount to suicide. I honestly think the issues they have with PhoneGap is due to a misunderstanding on the part of the reviewers, or some potential exploits or work-arounds that could be made by app developers to get around the app review process.I’m trying not to speculate too much though, because there’s been quite a lot of that lately. 🙂

  20. I just got a response from Apple saying “Thank you for the email. We are currently researching your inquiry and will back in touch.“I’ll post another blog article when I hear more back from them.

  21. I completely agree that Apple’s app approval (or App-app-app) needs way more transparency.I’m interested in writing an iPhone app that lets users create things with graphical programming. I wonder if my idea would hit the same obstacle as yours… an important factor, I expect, would be the levels of abstraction between the iPhone APIs and the code called in one’s application when the user’s “program” is “executed”.Regardless of my ambitions, I hope PhoneGap makes it to the iPhone. Best of luck.

  22. I am in the same boat as you jeremy. I have yet to find any examples of graphical programming systems, with the exception of jasuto, but it seems that most devs are avoiding the issue. I am excited to see how this plays out though.

  23. Pingback: Build process experiments with PhoneGap | Web Developer's Life in Beta

  24. Pingback: diamondTearz » Appcelerator Titanium Mobile and PhoneGap For the iPhone

  25. Pingback: Updates on Apple / PhoneGap | Web Developer's Life in Beta

  26. Pingback: 1.1 Online & In the AppStore Queue (again) | Blip Blog

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.