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

[JeffDM]

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.

With the Mac, you CAN just go to a different store for apps without having to buy a different device or crack the device. With the iPhone, you're locked into just one store.

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

Apple does offer a lot of services built into the web store, but I really don't see redoing things a bit being an obstacle.

Also, I'm not convinced that just being in the store should be considered sufficient marketing. It's no more marketing than "if you build it, they will come".

 

[Luke Redpath]

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.

Its quite simple: committing to a public API requires testing, documentation and a commitment to not break that API without reasonable notice.

All private APIs should be considered unsuitable for use for this very reason: it may not have undergone suitable testing, may be buggy, will have no documentation and most importantly may be subject to change or removal altogether. If your app depends on a private API that is removed in a subsequent firmware update (without any warning) then that application will break.

 

[justanothernerd]

Can someone clarify for me how developers find these Private APIs? Are they documented somewhere under the category of "APIs you're not allowed to use" or are the reverse engineered, or what?

 

[rwilliams]

Can someone clarify for me how developers find these Private APIs? Are they documented somewhere under the category of "APIs you're not allowed to use" or are the reverse engineered, or what?

This was going to be my next question. And thanks to the guys who helped explain the whole private vs. public API thing.

 

[amorya]

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?

An example: the firstResponder method. It returns the current text field that's in focus (i.e. has the keyboard attached). It's useful if the developer ever wants to hide the keyboard: to do that, you have to send resignFirstResponder to the currently focussed text field. If you're not allowed to use the private API for finding that field, then you have to do a bunch of extra work keeping track of which one it is.

As for why the rule is there, it's because private APIs can (and often do) change in future releases of the OS. A careful developer can write apps that check whether the API exists before using them, but if you don't do such checks then you might crash on future OS versions.

Amorya

Can someone clarify for me how developers find these Private APIs? Are they documented somewhere under the category of "APIs you're not allowed to use" or are the reverse engineered, or what?

They're fairly trivial to reverse engineer: look up "class-dump". And because they're trivial, there are plenty of web sites that document them.

Also, cocoa method names tend to be fairly predictable. I've accidentally used private APIs in the past because I've typed what I thought the method should be, and then it worked.

Amorya

 

[Luke Redpath]

Can someone clarify for me how developers find these Private APIs? Are they documented somewhere under the category of "APIs you're not allowed to use" or are the reverse engineered, or what?

It is possible to extract the header files from the SDK to find methods which aren't documented (i.e. public).

http://ericasadun.com/iPhoneDocs312/

 

[Compile 'em all]

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.

8 weeks for an update is effing brutal! what's your app btw?

 

[Quapps]

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.

Yep, thankfully they accepted the next day but this topic now brings up another issue and is one that i have been victim too on several occasions.

Rule Bending: Why are some developers able to get away with it but others don't? I hope it isn't a case of "reviewers discretion" as this makes the game uneven and opens a whole new can of worms.

This isn't the only case of fair vs unfair reviewers / policies. One of my games which is still yet to be accepted called Bunny Bang has been resubmitted around 5 times due to the review policy and each time rejected for different reasons.

This game has an animated bunny strapped to dynamite! You guess the code and the bunny lives, you don't he dies. No blood or gore or flying bunny debris at all but it is deemed as not suitable. Apple allow you to squash bugs, shoot people and astonishingly snipe/shoot deer so how does that differ from my game?

I think it is important that Apple concentrates on this area and opens up a better system such as a ticket system. Maybe this will need more employees but it can't be a bad thing right? Apple make a nice profit and will still do so even if they do create several more jobs in these hard economic times.

A simple Approved / rejected system was always deemed to fail right?

 

[kasei]

Wow. Where were they 3 weeks ago when we submitted and got rejected for an undocumented API. Weeks of waiting and on the 9th of December the good news.

 

[JonKean]

I can vouch for this. A few weeks ago Apple approved an update to one of my applications that was (indirectly) using private-apis. I received the same email this article mentions. The private api call wasn't actually used, and instead was only defined in an external library (ImageMagick). The api definition had been there in all previous versions of the app, but Apple only caught it using static code analysis they recently added to their review process. I imagine that since this analysis is catching all kinds of present issues (that previously would almost certainly be overlooked), they are letting it slide for now.

This probably has little to do with them easing up on developers -- in fact the static analysis is only making things more restrictive.

 

[alent1234]

I can vouch for this. A few weeks ago Apple approved an update to one of my applications that was (indirectly) using private-apis. I received the same email this article mentions. The private api call wasn't actually used, and instead was only defined in an external library (ImageMagick). The api definition had been there in all previous versions of the app, but Apple only caught it using static code analysis they recently added to their review process. I imagine that since this analysis is catching all kinds of present issues (that previously would almost certainly be overlooked), they are letting it slide for now.

This probably has little to do with them easing up on developers -- in fact the static analysis is only making things more restrictive.

the private API's aren't public either because Apple wants them for their own use or they are still in development.

if a big change is made to a non-public API that breaks a lot of apps who's fault is it? everyone is going to be screaming at Apple. same thing happened to MS in the 1990's and Apple learned from it

 

[djdole]

If Apple is letting Private API Usage Slide Temporarily,
then wouldn't that only mean that Apple is Temporarily Easing Up on iPhone Developers?

 

[Stridder44]

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.

Please, elaborate.

 

[sigalert]

Does this mean we will finally get to use a Bluetooth keyboard with the iPhone?

 

[eastcoastsurfer]

Um, Apple breaks public APIs all the time with new releases of the SDK. Saying that only using public APIs is the right way because they are tested and promised to work is not true. Apple has shown in the past they have no problem changing everything right underneath the developer.

For good or bad MS has generally tried to not do that to a developer, but it's also painted them into corners before.

 

[zorinlynx]

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.

Umm, genius, there is no "different store" unless you jailbreak your iPhone. I for one prefer phones like the Palm Pre because you can install anything you want on them. You can either play it safe and install only App Catalog apps, or install as many homebrew apps as you want, knowing that Palm won't support you if you have any issues with them.

This is how it should be done, and why I dislike Apple's iPhone division. (Though I like Macs. Go figure...)

 

[twoodcc]

this is very nice of apple. i guess they are learning as they go. good for apple, the app store, and the developers. without the developers, there is no app store

 

[NSMonkey]

An example: the firstResponder method. It returns the current text field that's in focus (i.e. has the keyboard attached). It's useful if the developer ever wants to hide the keyboard: to do that, you have to send resignFirstResponder to the currently focussed text field. If you're not allowed to use the private API for finding that field, then you have to do a bunch of extra work keeping track of which one it is.

You can use a category method to avoid the private API (via StackOverflow):

@implementation UIView (FindFirstResponder)
- (UIView *)findFirstResonder
{
    if (self.isFirstResponder) {        
        return self;     
    }

    for (UIView *subView in self.subviews) {
        UIView *firstResponder = [subView findFirstResonder];

        if (firstResponder != nil) {
                return firstResponder;
        }
    }

    return nil;
}
@end

And isn't there a simpler way to do this on iPhone OS? Something akin to [NSWindow makeFirstResponder]?

 

[shamino]

Umm, genius, there is no "different store" unless you jailbreak your iPhone. I for one prefer phones like the Palm Pre because you can install anything you want on them. You can either play it safe and install only App Catalog apps, or install as many homebrew apps as you want, knowing that Palm won't support you if you have any issues with them.

This is how it should be done, and why I dislike Apple's iPhone division. (Though I like Macs. Go figure...)

I would normally agree with you until a few weeks ago, when we started reading reports of malware spreading through jailbroken iPhones. Like it or not, Apple's strict control over what can be installed has prevented these worms from spreading into the general iPhone population.

Phones aren't desktop computers. You don't have lots of extra RAM, hard drive and CPU cycles to devote to antivirus software. And when things fail, customers will cast all the blame on the manufacturer (or the carrier) even if they themselves installed the software responsible for the failure. So it makes perfect sense that Apple should have a different set of rules for installing apps on an iPhone (or iPods, for that matter) and for Macs.

You don't have to like the decision - it's far from a perfect solution - but I don't think the product or user experience would be improved by switching to your solution (allow everybody to install anything they want without restriction.) You eliminate one problem and replace it with another, which I (and I think most customers) would consider a much worse problem.