iPhone developer says Apple taking more lenient approach with apps
Despite a spotted violation of Apple's rules for developers, one iPhone application was approved for released on the App Store with a warning to fix the issue in a future update.
Developer 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.
Developer 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.
Comments
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.
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.
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.
Actually this is a reaction to competition. The Apple censorship thing is going to have to be more lenient once Droids app store, etc start to come out with apps that Apple deems politcially incorrect or family unfriendly.
The application allows developers to use the iPhone's multi-touch and accelerometer capabilities within the iPhone simulator software on a Mac.
The only reason I can think of that a private API is allowed to be used in this case is because there is no Apple API that does the same function.
So Apple is telling the developer of the private API to fix it later in a update, meaning Apple is going to provide a Apple API later in a update to their iPhone OS.
Also just because Apple allow this one instance, something they intend to provide for anyway later on, doesn't mean that they are getting more lenient in general.
They just could be allowing this ONE private API, so others could use it too, only to line up their ducks later to force the new Apple API that does the same function later.
It could be their code check software will be allowed to use this one private API as well, so they don't have to repeat this manually for every private API that does the same thing as the first.
Apple does what's in Apple's interest.
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.
Using private API's is never a "mistake", it's always a concious decision. You have to go looking for them, so it's quite understandable for Apple to be strict as the excuse "Oh I didn't realise that was private" doesn't hold water.
That said, I think this could be the first sign of a change in attitude from Apple. I hope that's the case and think it would be a "Good Thing". It might also mean that Apple are finally tracking issues on Apps between reviews, something that they can't have been doing considering the inconsistency they've displayed in the past.
Actually this is a reaction to competition. The Apple censorship thing is going to have to be more lenient once Droids app store, etc start to come out with apps that Apple deems politcially incorrect or family unfriendly.
Actually, this is a reaction to BAD PRESS.
This is a good step. A logical explanation and a warning to fix it in an update.
I wish people would cut Apple some slack as far as app approvals go. The App Store is a new venture entirely and it will take time to adjust and react to the deluge of app submissions. Who would have thought we'd see that many apps? I doubt Apple foresaw it and certainly couldn't have prepared for it ahead of time.
Out of 100,000+ apps, how many (or what percentage) were rejected for questionable reasons, or none at all? I bet it's pretty low. I certainly can't blame developers, who invested time and money building apps only have them oddly rejected, to be pissed off. The App Store boycotters need to develop some perspective and hopefully this type of clear and rational explanation will work toward calming frustrated developers.
If Apple changes their APIs in a way that breaks this app, no actual iPhone users will be impacted, only developers. This (IMO), is a huge distinction and is probably the reason for Apple's atypical response.
The big difference here is that this app is not one that users will run on their iPhones. It's a developer-only app designed to simulate aspects of the iPhone that Apple's emulator doesn't simulate.
If Apple changes their APIs in a way that breaks this app, no actual iPhone users will be impacted, only developers. This (IMO), is a huge distinction and is probably the reason for Apple's atypical response.
This explanation sounds correct - no masses of non tech-savvy consumers affected, and those that will be are knowledgeable enough to mitigate and counteract its effects.
At the very least this shows consistency of approach, rather than a caving in to populist resentment or competitive platforms, as some troll-ish twerps are suggesting elsewhere.
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.
I guess you better grow up and make sure the garbage is regulated without her reminding you of your duties.
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.
The only reason I can think of that a private API is allowed to be used in this case is because there is no Apple API that does the same function.
So Apple is telling the developer of the private API to fix it later in a update, meaning Apple is going to provide a Apple API later in a update to their iPhone OS.
Also just because Apple allow this one instance, something they intend to provide for anyway later on, doesn't mean that they are getting more lenient in general.
They just could be allowing this ONE private API, so others could use it too, only to line up their ducks later to force the new Apple API that does the same function later.
It could be their code check software will be allowed to use this one private API as well, so they don't have to repeat this manually for every private API that does the same thing as the first.
Apple does what's in Apple's interest.
Apple will provide a Public API to duplicate the functionality in one of its Frameworks and the private APIs leveraged by that one API will disappear in a future release.
Hopefully this is not just an exception to the rule and is instead a change in strategy.
if i'm reading the article correctly the issue isn't that it allows something on the phone but rather if you have the simulation software on your computer (ie you are a developer for the iphone)
so it isn't really an issue with the typical user. which is likely why it was approved.
Using private API's is never a "mistake",
but use is also not the issue. the folks griping about 'private API' rejections aren't using any such thing. they just named something in their code the same as a pAPI and got a false hit with the scanner software.
so perhaps the solution is to provide a list of the names to avoid or even a scanning software to validate your code before submission.
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.
Phew... I for one am certainly glad to hear its still under review... because after all an application can only be in 3 states:
In-Review
Approved (outright or with stipulations)
Rejected (outright or with stipulations)
What I'd like to know is how long is the In-Review process supposed to take place?!?!?
- 1 week?
- 1 month??
- 1 year?!?
- 1 DECADE?!?!
Come on story writers... lets not sustain the lie Apple has told the FCC... The GV app couldn't POSSIBLY still be 'in review' after all this time. Imagine if your employer behaved in this way... All paychecks will be distributed bi-weekly after individual employee review... and then proceed to take 5 or 6 months before even the first review was concluded.
GV should be called what it is.. A REJECTED APP STORE APP.
Please don't continue to spread Apples bullshit.
Actually, this is a reaction to BAD PRESS.
This is a good step. A logical explanation and a warning to fix it in an update.
I wish people would cut Apple some slack as far as app approvals go. The App Store is a new venture entirely and it will take time to adjust and react to the deluge of app submissions. Who would have thought we'd see that many apps? I doubt Apple foresaw it and certainly couldn't have prepared for it ahead of time.
Out of 100,000+ apps, how many (or what percentage) were rejected for questionable reasons, or none at all? I bet it's pretty low. I certainly can't blame developers, who invested time and money building apps only have them oddly rejected, to be pissed off. The App Store boycotters need to develop some perspective and hopefully this type of clear and rational explanation will work toward calming frustrated developers.
Here you go
http://boredzo.org/killed-iphone-apps/
Hopefully this is not just an exception to the rule and is instead a change in strategy.
I have seen a recent free app (well - advertising supported app) approved despite the following:
Loses all data when application quits.
Technical support page is actually a generic page for the doctor and there is no place to report a problem with the app.
Seems to me that is pretty lenient.
if i'm reading the article correctly the issue isn't that it allows something on the phone but rather if you have the simulation software on your computer (ie you are a developer for the iphone)
so it isn't really an issue with the typical user. which is likely why it was approved.
but use is also not the issue. the folks griping about 'private API' rejections aren't using any such thing. they just named something in their code the same as a pAPI and got a false hit with the scanner software.
so perhaps the solution is to provide a list of the names to avoid or even a scanning software to validate your code before submission.
You're right but your explanation is off.
This developer has, for testing purposes, used a private API. When in the simulator, they need functionality that will show up on the phone but it currently isn't there. They've designed their code so that if they are on the phone, it will work right, and if it's on the simulator it will work right.
There's only one issue with your explanation, though. Unless that app was compiled for both the simulator AND the ARM instruction set, in some sort of universal binary, then NO user, even if they have the simulator, can use it on the simulator. You suggest that this app could be run on a simulator, but apps from the store can't.
The app submitted to the store can only ever run on an iPhone. Apps need to be compiled for simulator separately, and this isn't one of those apps. At no time will this ever become an issue for the end user. It'll only ever be an issue for the one developer who makes it, unless he decides to distibute A SIMULATOR version of his app to other users for some darned reason.
http://www.futuretap.com/blog/semi-r...eview-process/
Leap forward with Apple, and now developers complain and whine about the App Store (In some cases leave), when things don't go their way. Apple's doing a GREAT job with the App Store and they continue to approve upon it consistently. This minority bunch of whiners (No matter how advanced in programming they may be) need to abide by Apple's rules and SHUT UP!... Cause it's not that big of a deal.