Dear Aunt TUAW: My "private" APIs... aren't

This is one of those things where I actually think Apple wants to be legitimately helpful. Let's face it Touch OS will continue to improve and develop, which will eventually lead to private APIs being exposed in the future. So they are trying to give developers a leg up to help with future OS revision compatibility.

One does have to wonder why the automated software is offered to developers. It might be due to security with Apple not wanting to expose future OS directions. Or it could be the tool being in a really crude state right now. I don't know but would hope that future SDK revs offer up the tool.

As to developer whining yeah it could be a problem with existing apps but you can't really blame Apple here. The OS would evolve with or without the checks. Without the checker we would simply have more apps breaking as a surprise. Some may not like this but I do believe it is up to the developer to choose naming conventions that are durable and avoid namespace collisions. Generally any program of even modest complexity needs to have thought put into naming conventions, especially if third party libraries are used.

What seems to be objectionable here, at least to me, is the small minority of people raising objections to Apples efforts here. People need to get with the program here and realize that Apple is actually helping them out long term here. I know the current mind set is to bash Apple for any and all reasons but people are making themselves look stupid lately with respect to app store and the approval process.

This is not to say that Apple is perfect with respect to app store management just that I've seen a lot of complaints from developers over things they really have no basis to complain about. This is in reality one of them. Especially considering it is a long term positive for developers.


Dave

IMHO, private methods should always start with underscore( _ ) so that name collisions will never happen.

Very funny. The finished app does not contain any method or property names, only machine code that might be checked for calls to known API's.

I think whats missing here is that if Apple is going to use an automated validation system, they should make a tool available to developers that will allow users to scan their code and pre-validate it. that way a dev can submit with relative assurance that the machine wont spit it back at them.

I guess I don't understand how the linking works in an Objective C app. Wouldn't they just look at the undefined symbols in the executeable+dynamic libraries that application delivers? If they're looking at all symbols in the application, that just seems to be a descent into madness.

What bothers me about this is that apple is not just checking class names, but method names. If it were just classes the best solution would be to prefex each with your company name, such as apple does with NSWhatEverThisDoes. But doing so with each and every method you create would be burdensome.

Flagging a method name such as -setOrder is going to cause a whole lot of false positives, -setThumbnail probably not as many but it's still something I can see being used quite a bit by developers.

I agree that the automated checks are a necessary evil but I think that apple should be using them as a flag to spend a little more time reviewing the app to be sure those API's are not being used. I do not believe that they should be using the information to simply reject the app.

So any use in my code of a name that's used somewhere in Apple's API's will cause a rejection?

Even common things like getID() or process()?

That sucks. You'd at least think they'd check the library the symbol is bound to and figure out that it's [my process] and not [apple process].

Every time you think the App Store is as bad as it can possibly be, Apple proves you wrong by making it worse.

Nooo... is this whats holding up my Tweetie 2 update :(