Neil HughesDeveloper Vimov, creators of iSimulate, said Apple approved the latest update to their application for developers, even though it uses a private API, which is against the company's terms. The application allows developers to use the iPhone's multi-touch and accelerometer capabilities within the iPhone simulator software on a Mac.
The developer said Apple acknowledged the issue, and provided a warning, with the following e-mail:
- 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.
On the company's blog, the developer praised Apple for its approach. The iPhone maker was within its rights to reject the software and force Vimov to resubmit its application for the approval process. Instead, the developer said it will address the issue in its next update, and its application can remain up for sale.
As Apple's App Store has swelled to more than 100,000 applications and been embraced with more than 2 billion downloads, some developers have criticized the company's hands-on approach which requires software to be reviewed and approved before it can be made for sale. Some developers have claimed that Apple's process is not transparent enough, and there have been reports of applications neither approved or rejected for some time.
The most high-profile application in limbo is Google Voice, which Apple said it has not approved, but has not outright rejected either. Google disputes that claim.
Apple made a step towards transparency in September when it expanded its Resource Center for developers The private page details how the approval process works and provides tutorials. The company then went a step further in November, when it added a feature that allows developers to view the approval status of submitted applications.
Charles Martin
Sponsored Content
Amber Neely
Malcolm Owen
Andrew Orr
Christine McKee
20 Comments
Hopefully this is not just an exception to the rule and is instead a change in strategy.
We had an app rejected two days ago "MagiCam" for use of private APIs - using augmented reality on 3.0. The issue was that we weren't using any private APIs. It was a false positive rejection based on Apple's new private API checker. We submitted our code showing it to Apple, they unrejected the app and approved it the following day.
I too hope this is a change. Most developers will be happy to comply, but Apple has always been to mum as to what is acceptable and what isn't. Letting things slide once and letting the developer get it fixed for the next release is a great compromise.
We had an app rejected two days ago ...
There's a big difference between an app submission that uses private APIs and an update that does though. Myself, I would hope that this new policy only applies to updates. There's no reason to de-list a good app for a small mistake that can be corrected, but an app that uses private APIs to begin with is a different story altogether.
I like this approach, but I hope it is applied more widely than just private APIs. I'm no programmer, but from what I understand, the use of private APIs is a decision, not an accident. As long as one is aware of the rules against their use, it's hard to be surprised by a rejection due to their use. The rejections that seem to be causing the most problems are judgement calls and things applied inconsistently (use of Apple imagery comes to mind). Those issues still need to be addressed, but allowing an app with minor violations that don't effect users through will at least lessen the aggravation over those things.
Maybe they can make tiers of violations. Urgent things like serious bugs warrant rejection, less urgent things like private-API use get a warning to fix.
We had an app rejected two days ago "MagiCam" for use of private APIs - using augmented reality on 3.0. The issue was that we weren't using any private APIs. It was a false positive rejection based on Apple's new private API checker. We submitted our code showing it to Apple, they unrejected the app and approved it the following day.
I too hope this is a change. Most developers will be happy to comply, but Apple has always been to mum as to what is acceptable and what isn't. Letting things slide once and letting the developer get it fixed for the next release is a great compromise.
No. it is the evolution of growing up.
Did you put out the garbage this week without your better half reminding you?
I did. But that is not normal, nor is my wife's definition of maturity.