Private(daringfireball.net)
daringfireball.net
Private
http://daringfireball.net/2008/12/private
11 comments
To be fair the reader is warned thusly:
"Some of the nicest bits of iPhone programming are included in the public iPhone frameworks but not in the SDK. Apple's unofficial policy on this is clear: You can use these items in your programs, but you do so at your own risk. Your code may break at each firmware release. Striking the balance between risk and reward if up to you."
"Some of the nicest bits of iPhone programming are included in the public iPhone frameworks but not in the SDK. Apple's unofficial policy on this is clear: You can use these items in your programs, but you do so at your own risk. Your code may break at each firmware release. Striking the balance between risk and reward if up to you."
+1 for "thusly"
edit: I guess I'm still getting the hang of HN etiquette. I was impressed by the clint's usage of an unusual word and got downmodded for expressing that concisely. So, next time do I use a complete sentence to express my admiration, or do I avoid any discussion of word choice / writing style?
edit: I guess I'm still getting the hang of HN etiquette. I was impressed by the clint's usage of an unusual word and got downmodded for expressing that concisely. So, next time do I use a complete sentence to express my admiration, or do I avoid any discussion of word choice / writing style?
the rule is: if you're not adding something to the conversation, then don't post. "+1", "lol", and other "attaboy" type comments, including yours, should be expressed with an upvote.
He brings up a good point though. I'm guessing if he posted something along the lines of "I am impressed with your usage of the word "thusly"" rather than "+1 for "thusly"" he would not have been downvoted, even though they're approximately equivalent and neither adds much to the conversation.
Good article, but making headlines more descriptive like "Private iPhone APIs" can save people reading through RSS few clicks.
Perhaps it would be wise of Apple to introduce versions into the App Store. I think using private APIs should be fine, but maybe after an update the developer should have to go in and select that it works with the new version.
This is what Mozilla does for plugins and it works pretty well.
This is what Mozilla does for plugins and it works pretty well.
The difference is that very few if any plugins are sold and it is somewhat easy to downgrade to an older version of Firefox. Could you imagine what would happen if iPhone OS 2.3 came out and 10% of the apps in the itunes store stopped working? It would be a PR nightmare for Apple.
Well, another big point is that Mozilla pre-releases it's software. I'm not 100% aware, but I don't think Apple provides the same convenience to developers.
Wouldn't you like three days to see if your software is going to run smoothly after the update?
Wouldn't you like three days to see if your software is going to run smoothly after the update?
If there's a header file for an API, does that mean that it's public? Or does it have to be in XCode's documentation? I'm wondering specifically about AVAudioFoundation / AVAudioPlayer.
Anything that's "public" is documented on developer.apple.com (and in the Xcode documentation window). Everything else is "off limits."
It's downright irresponsible to recommend such things in a book on developing for the official SDK. The people reading the book are likely people who don't understand the system well enough to safely use private/unpublished APIs like Gruber outlines.
That said, Apple should open up most of these APIs (CoverFlow, prox sensor, etc).