AT&T Welcomes Programmers for All Phones Except the iPhone
An anonymous reader writes "Apple's reasoning for keeping the iPhone a closed platform is that they don't want to 'potentially gum up the provider's network'. An article in the New York Times, though, points out that there are hundreds of phones out there working on open platforms that don't seem to be causing network interference. AT&T and Palm, in fact, welcome experimentation on their platforms. In AT&T's case ... on every phone but the iPhone. 'Hackers who have explored the workings of the phone say it uses the frameworks and structures that Apple uses on its other platforms to enable development; it just hasn't been documented. So if Apple is going to allow applications later, is there any reason -- other than vindictiveness or obsessive interest in control -- that it would want to cut off those developed by the pioneers who figured things out ahead of the official launch?'"
I've said from the beginning that the reason Apple's iPhone was closed to outside development was due to Apple, and not to AT&T. Apple is obsessive about controlling the end-user experience, so they don't want any third-party development on the iPhone. And what happened? I got accused of starting flamewars by rabid, foaming-at-the-mouth Mac fanbois.
There's nothing wrong with Apple intent on the iPhone. It's their product and they can market and sell it how they see fit. If you don't like it, don't buy an iPhone.
My blog
I remember back when Apple was going after people selling mac roms for Amiga emulators.
Apple has always been proprietary and exercised iron-fisted control over what THEY want done with the hardware they sell for a profit. Why are the iPhone actions such a surprise?
The most obvious reason for me would seem to be simply avoid responsibility for the API until it is fully matured? Surely, if they were to release their API for the entire multi-touch aspect of the iPhone and iPod Touch at this point, they would be in a position where they have a lot of responsibilities:
* extensively documenting the API for a broad base instead of only for internal usage
* testing for possible bugs for usecases which are not relevant in Apple's internal usage
* making it feature complete
* making it secure
* when upgrading the API, supporting older applications built on that API (in other words, keeping full backwards compatibility)
All in all, this can be summed up as the basic fact that officially releasing the "mini OS X" that Apple uses on its portable devices as a development platform requires a whole different approach then simply using it themselves and not publishing it. All these responsibilities are easily avoided by simply not publishing the API and is a no-brainer if the company is on a tight deadline. Given the iPhone's short development lead time, i can fully understand that there was no time to get all of the above in order, so avoiding responsibility of the API for the time being seems like a logical thing to me.
That said, the above reason would steer them towards a tolerance stance regarding 'hackers', while Apple seems to be leaning more towards an 'active prosecution' stance, which i considere pretty much unjustified, together with the rest of the world.
"Apple's reasoning for keeping the iPhone a closed platform is that they don't want to 'potentially gum up the provider's network'."
Yes, and I'm sure that's why they're keeping the iPod a closed platform, too.
Gifts for Geeks - Stuff that really matters!
The design of good APIs is several orders of magnitude harder than getting a program to stand up & run in time for release. It tends to take several iterations to get things right. It's likely that they have given rough-cut APIs to internal teams (and perhaps some select partners) for developing apps. (perhaps the iTunes WiFi store is one example). Feedback from such developer projects may result in changes to, and perhaps even radical restructuring of, the underlying frameworks.
And, to answer your question, that is why an update could break something. If I have a program that calls a library, and the interface to that library changes, my program falls down, goes boom.
I bet they'll release a kit when they're sure they've frozen the API.
The "cue the foo posts in 3, 2, 1..." posts will commence with no subsequent foo posts in 3, 2, 1...
Apple recently released the Human Interface Guidelines for the iPhone, which says at one point: "Currently, developers create web applications for iPhone, not native applications." (emphasis added). I suspect the iPhone API is still very much in flux, which probably explains the fairly small updates we've seen so far.
Apple hasn't shied away from games on the iPod, so why not the iPhone? Because the API isn't set in stone yet. Once Apple firms it up, you'll probably start to see third party games from companies like EA. If that works out, then you may finally see a public API.
--
The internet is the greatest source of biased information in the history of mankind.