Apple Easing Up on iPhone Developers? Letting Private API Usage Slide Temporarily

[MacRumors]

After a series of high profile complaints, it seems that Apple is making efforts to improve the App Store experience for their developers. After taking a hard line against the use of Private application programming interfaces (APIs), iPhone developer Vimov reports that they have had a relatively positive experience in seeking approval for an update to their iSimulate app.

Despite inadvertently leaving in a programming call to a Private API, they were pleased to find the update had still been approved and they were simply warned to address the issue in the next update:

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.

In the recent past, such an oversight would have resulted in an automatic rejection that would have cost the developer weeks of time going through the re-approval process.

This past week, Apple made further efforts at improving the lines of communication with developers by offering an RSS news feed for developers with news and tips about App Store submissions.

Article Link: Apple Easing Up on iPhone Developers? Letting Private API Usage Slide Temporarily

 

[Maserati7200]

That's nice. It makes life easier for everyone. Although, I really don't understand why they limit the API's you can use in the first place.

 

[boyplunder]

I've just had the same message on an update I sent through a week or so ago. Admittedly, the Private API we used was an oversight, and should have been changed before we submitted v1 in August, but I think this is a great developer relation route for them to take. The issue was so easy to fix, but our app is still on the store until the next update, which won't be very long.

Well done Apple.

 

[johndillard]

Blackberry

I've found BlackBerry apps to be more useful than any of the apps on Apple's store. They should model the business after RIM's, in my opinion.

 

[Compile 'em all]

Interesting. Apple also has apparently approved ustream which allows live streaming (over 3G as well).

Slightly related, I had a new app of mine Music God approved in around 8 days (typically it took 2 weeks to hear anything back from them).

 

[Becordial]

I've found BlackBerry apps to be more useful than any of the apps on Apple's store. They should model the business after RIM's, in my opinion.

Can you please highlight some specific examples?

 

[HardyMacia]

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.

 

[johndillard]

Examples

Can you please highlight some specific examples?

Easy: Solitair, Freecell, Texas Hold Em

 

[boer]

Easy: Solitair, Freecell, Texas Hold Em

OMG! Those are some killer apps!

 

[rwilliams]

That's nice. It makes life easier for everyone. Although, I really don't understand why they limit the API's you can use in the first place.

This is something I'm trying to understand as well. Can a developer give us some examples of API's Apple restricts you from using, and why that rule is in place?

 

[thetexan]

WebOS, Blackberry OS, WM, and Android all allow applications to be installed outside of their official app stores without hacking the phone. It allows greater freedom to install apps that the stores might not want, such as adult oriented applications. Not just pornography either, something that'd normally be censored due to bad language or adult situations (drug wars type games).

Apple should allow applications to be installed outside of their iTunes app store. Put up a disclaimer "Hey if you do this we can't be responsible for the content, it could be malicious, etc etc" and let us have at it.

 

[nwcs]

Personally, I prefer Apple's gated approach to applications. I don't see the need for unfettered access. After all, it's no different than any grocery or retail store. The store chooses what they offer and you select among their choices -- or you go to a different store.

 

[kas23]

If I read correctly, Apple is still not allowing private APIs as the title suggests. They are just not automatically rejecting an App having a private API, thus allowing them to change it. But there still not approving apps with a private APIs.

 

[Joe Hill]

iPhone OS is bad, Android good!

 

[Allanist]

This is something I'm trying to understand as well. Can a developer give us some examples of API's Apple restricts you from using, and why that rule is in place?

If all API's were public, Apple should support them from the day one and couldn't change the behavior or replace an API without breaking apps on the App Store. I'm not saying this is the reason to keep them private, but in some cases this might be the case. An API may just be a building block for Apple's own apps and it haven't settled for public developer use.
Just my two cents...

 

[wesleyh]

Hopefully this is not just an exception to the rule and is instead a change in strategy.

 

[kdarling]

This is something I'm trying to understand as well. Can a developer give us some examples of API's Apple restricts you from using, and why that rule is in place?

Restricting APIs is not uncommon in the computing world. It can occur because:

• The API design isn't finished and could change
• A particular API call could be slated for removal
• It goes too deep to the hardware
• It opens a security hole
• It provides features the designer wants to keep to themselves

For example, Apple might have a private API to access the camera hardware directly, that they don't want others to use. If they change the hardware, then they're okay because the new device comes with a new OS. But any application using the old unofficial API would fail on the new device.

 

[boyplunder]

If I read correctly, Apple is still not allowing private APIs as the title suggests. They are just not automatically rejecting an App having a private API, thus allowing them to change it. But there still not approving apps with a private APIs.

I can confirm that Apple are not allowing Private API's for any new apps. We submitted a new app that was rejected on this basis yesterday.

 

[rjstanford]

For example, Apple might have a private API to access the camera hardware directly, that they don't want others to use. If they change the hardware, then they're okay because the new device comes with a new OS. But any application using the old unofficial API would fail on the new device.

This is also a Good Thing. Failure to police use of their private APIs is why Windows development became such a huge PITA. Remember books like Petzold's "Undocumented Windows"? When major customers started to use really broken APIs, MSFT was forced to leave them in, often for a decade or more past the point that they should have been removed. Ever have a program break when you upgraded your OS (whatever it was)? Chances are very, very high that it broke because the development team used a private API (or a public API in an undocumented way).

Same with HTML... browsers used to accept all kinds of crap in their webpages. Now most webpages are valid, but the browser still has to be able to deal with <b><i>stupid</b></i> stuff like that, which is actually really, really hard to get right. That's the main reason that IE is so broken - its backwardly compatible with all the dreck that's out there.

Private APIs should, if possible, be changed with every patch release and removed (or fully released and supported) as soon as possible. Period. Support them once, and you may be stuck with them for the life of your platform.

 

[cloud]

WebOS, Blackberry OS, WM, and Android all allow applications to be installed outside of their official app stores without hacking the phone. It allows greater freedom to install apps that the stores might not want, such as adult oriented applications. Not just pornography either, something that'd normally be censored due to bad language or adult situations (drug wars type games).

Apple should allow applications to be installed outside of their iTunes app store. Put up a disclaimer "Hey if you do this we can't be responsible for the content, it could be malicious, etc etc" and let us have at it.

Apple "charges" for marketing and distribution. They would have to redo things if they let you get apps from anywhere. Think about it.

 

[shamino]

This particular case probably won't be setting any precedents. It is not an iPhone app that's using the private API, but a developer tool that augments the iPhone simulator (that comes with the developer tools.)

If Apple changes this API in a way that breaks iSimulate, no actual iPhone user will be impacted, only developers using iSimulate for their testing. This has a very different impact on the iPhone's perceived quality, which is probably why the app was conditionally accepted.

That's nice. It makes life easier for everyone. Although, I really don't understand why they limit the API's you can use in the first place.

This is something I'm trying to understand as well. Can a developer give us some examples of API's Apple restricts you from using, and why that rule is in place?

Published APIs can not be changed, broken or removed without breaking applications. The last thing you want is for a new release of the iPhone system software to break applications, so you make a point of not publishing any APIs that you think are likely to be changed in the future.

Some of these APIs are low-level hardware-access calls, which are (or should be) wrapped by more abstract hardware-independent APIs. Some are APIs that were quickly added in order to get a feature working, but will be reviewed and removed/replaced/updated in the future before they are made public. Some may have a negative impact on battery life or the performance of other apps (e.g. APIs for creating background processes).

As for what developers do, using undocumented APIs is always a recipe for disaster. That's one of the reasons why applications on computers often break after system software upgrades. On an embedded device like a phone or iPod, however, the customer backlash from application-breaking upgrades will likely be much more angry than when it happens on computers, so Apple has to be more heavy-handed here.

 

[justflie]

A step in the right direction. A few more of these and perhaps they will start to turn around the negative sentiment.

 

[guzhogi]

At first, I thought the headline was "Apple Eating up iPhone developers?" in terms of "Who did Apple buy now?" rather than "Yay cannibalism!" But I reread it and saw it was Easing. To make it worse, I visited Macrumors about an hour or 2 ago, & correctly read the same headline. Weird.

 

[mdriftmeyer]

That's nice. It makes life easier for everyone. Although, I really don't understand why they limit the API's you can use in the first place.

You're not a developer.

Private APIs are not immutable. They are influx. They change constantly with QA testing and redesign of the architecture.

These changes break applications.

Public APIs don't change without major updates to the platform and are noted in the release notes for Developers to be aware before they release their application to work with the latest update to the system.

 

[jbellanca]

I got that same email for an update I had pending in review for about 8 weeks. They approved the update and just said to change to a public API in the next version. Very nice of them to not outright reject the update, IMO.