It’s tough at the top. When you’ve got tens of thousands of developers vying for your acceptance, your every decision is scrutinized and criticized. Such is the case with Apple; if they approve a thousand applications and deny one, that one that got cut off will be the one you hear about.
It looks like Apple might be making moves to loosen up their restrictions, if only ever so slightly. Earlier this week, Apple finally let a live video broadcasting app through the gates, after apps of that genre sat on the review backburner for months. Today, they’ve willingly approved another application that calls upon one of Apple’s private (and generally blacklisted) APIs.
For the sake of those who might not have their programming acronym cheatsheet nearby, API stands for application programming interface. In a nutshell, an API is a set of programming functions provided as part of a piece of software (such as the iPhone OS) to allow you to do certain things (such as access the camera hardware or the GPS) without having to reinvent the wheel. Apple keeps a small chunk of these APIs private, for reasons of security, standards, battery life efficiency, and God knows what else.
The application in question, iSimulate, allows developers to test the multi-touch and accelerometer functions of their applications in the OS X iPhone Simulator – generally, such tests would require the app to be loaded onto the handset. They made use of private API UITouch._touchFlags, to which Apple responded:
Thank you for submitting your update to iSimulate to the App Store. During our review of your application we found it is using a private API, which is in violation of the iPhone Developer Program License Agreement section 3.3.1; “3.3.1 Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs.” While your application has not been rejected, it would be appropriate to resolve this issue in your next update.
The non-public API that is included in your application is UITouch._touchFlags.
Please resolve this issue in your next update to iSimulate.
Does this mean that all private APIs are open game now? Of course not. Try to sneak background processing support into your app, and Apple will most likely drop the banhammer in a heartbeat. But until we hear otherwise, we’re taking all of this week’s progress as a sign that someone over in Cupertino finally said “Hey, guys – relax a bit.”
Well an app of ours here at Life360 has been denied 17 times in a row over the past 12 months. Once we gave up and didn’t resubmit for a month or two, and we got a call from a real live person at Apple asking us why we didn’t send in our app again.
We explained that we had been rejected for almost a year, and he said that we would be good to go if we submitted again. So we did, and they rejected us again with no explanation.
If someone from Apple really is keeping an eye on the developer pulse, we’re still a bit bitter. Hopefully things are changing.
That’s messed up.
I think we need to create an iPhone App support group. We were rejected recently for an API issue, fixed it and it looks like we’ll be approved soon (hopefully). It’s really hard to build a business around this app approval process. I just wish they’d change it so that we can push an update dynamically and deal with issues after the fact with another update. Not saying that Apple hasn’t been good to us, they have. It just makes life difficult for us.
Whoa now that truly sux!
why was it rejected 17 times?
We had our app, eTicket, rejected for unintentionally using two private API’s. We fixed one, but the other slipped past us again before we re-submitted. This time we were finally approved and got the same message as quoted in the post.
We’ve since fixed the remaining API issue and will submit the update as requested so we stay on Apple’s good side.
It’s nice to not have the door slammed in your face for minor transgressions.
Considering that less apps out there means a loss of opportunity in sales, it behooves Apple to have the app available and then fix it later, provided the API call isn’t something that will be unstable due to a firmware API update later.
If any one from Apple is reading…Thank you!
We look forward to hearing more news like this. Please begin allowing more Private API’s like MPTVOutWindow class, so that we (developers) can expand on the powerful devices you dream up. If you are concerned about things like power consumption no worries limit the App to work when the phone is charging. (just like WiFi only for large downloads from the App Store).
There are some really great applications which the community would like to work on that sometimes require private API’s. Gaming for one!!
Thanks.
Except it’s inconsistent, still.
I had a client accepted using an older version of three20, with the private APIs included. They got the standard “We’ll accept it but you need to fix it for next time.”
Less than 12 hours later, another application of mine was rejected for using the same older version of three20. With the same private API usage.
The problem with the app store is one of speed. Sure, make us wait 2 weeks when you first submit an update or a new application. After it’s rejected that first time, give us a 24 hour grace period. If we resubmit an update within that grace period with the issues resolved, don’t make us go to the beginning of the queue again.
The development world has changed. Agile is in. Apple clearly hasn’t figured that out yet, and it’s hurting everyone.
http://www.crunchgear.com/2009/12/11/video-more-odroid-gameplay-odroid-being-an-android-gaming-device/
They’re always going to be aggravating someone. Too easy to get an app through the gate or too hard.
Variety has to be a good thing though, and if this relaxation on the rules achieves that – so be it.
Apple needs to be tightening the reins on the app store not loosening…
hold on here me out….
There are a lot of spam like apps out there. Single developers will release hundreds of almost identical apps to the app store all paid apps in the hope they get a number of unlucky punters that pay for them.
here is a couple of examples “Touch Scanner” and “All About” and now the “Peg !” ones (and this is just ones release in the last week).
Each one has dozens if not hundreds of variations of a very dubious (read pointless) app… they just hope that a few people accidently buy them and they make a few bucks…. like spam it only works on a large scale (lots of apps and a few suckers)… (for more see http://www.clockworkapps.com/blog/app_spam.html).
Apple need to get rid of these stupid apps as the legitimate developers are drowning in the spam apps.
Our app got almost the exact same letter when we updated a couple days ago. It uses the private API for UI terminate. Since our app is a dialer it seemed like a nice feature to allow users not to have to go back to the dialer app immediately after the phone call, instead we call UI terminate to prevent the app from reloading. Unfortunately Apple doesn’t like this. That means we have to remove this feature and all users will have to reload the app after a call no matter what, which is obviously annoying.
Anybody knows what happened to OrbLive?