iPhone SDKs are like buses these days, the appear so frequently. Since my introductory piece on iPhone development, Apple has rolled out an initial SDK preview, a second iteration of the SDK (Beta 2) while a third beta followed not long behind. The second beta included the much-anticipated Interface Builder application but Beta …
although, if they had made provisions for opening up the iphone to development, there would have been far far less articles on the web written about the iPhone. this way, everytime they release a firmware update or patch, and everytime the h4xx0rs release their tools, Apple get a bunch of free advertising
RE: free press
Can't argue with that! ;-)
Apple can't bash MS like this.
Hm... the Ts & Cs specifically say "cannot use undocumented APIs"? The only difference was that MS didn't document some APIs, then used them, but it dodn't prohibit others from using them. MS just withheld *how* they worked.
Apple took it a step further, not only will you be unable to know how these work, but "legally" prohibited to use them at all! Then add up the "no background apps" and such, and it looks more like Trusted Computing gone wrong.
Even if Symbian and RIM have their signing schemes, they are there basically for protection against virii, not to cripple what devs can or can't do. The main reason I moved from Mac to PC (DOS, Windows) was the developer edge I didn't have in Mac, where the most tinkering I ever did was monkeying around with ResEdit.
How is this different?
How is this different from any other legal agreement? Let's face it, MS put all sorts of things in their EULAs... not tranferring licenses, not running in a VM. Symbian has similar - don't screw around - gotchas.
It's called good business. If developers prefer to distribute apps through cracked phones that's fine, but if they prefer the advertisements and the listings on apple.com which, no doubt, make a massive difference to sales - that's fine. Apple have always done a great job supporting developers, and I'd prefer to see a stable platform that is somewhat shy of perfection, than a nasty looking Palm or Series 60 brought down in seconds because the app didn't respond, or better, Windows Mobile brought down by it's own - built in, no less - sucky apps.
Apple's not all bad
There can be (and in fact are) good reasons for many of the things Apple does.
If you allow undocumented API's to be used then you can't change or remove them without breaking apps. Preserving undocumented behaviour because existing apps depend on it is something MS specialise in, and on the whole it soon becomes a bad thing.
If Apple open up the iPhone to unregulated development and software distribution, it becomes undifferentiated, more susceptible to competitive pressures, less amenable to future innovation.
If you allow background processes and unrestricted app installation, millions who don't even know what a process is will be complaining their iPhone is slow and doesn't hold a battery charge. Apple will have to create "Apple certified iPhone support specialists" to tell users to kill the apps they didn't even know were there. We'll have whole ghastly industry of so-called "professionals" just like Microsoft's. The users are happier with something that just works.
It's actually true that you can do a great deal just with web apps. And they have the advantage that they run anywhere, not just on iPhones, even if tailored for iPhones. If Apple had released an SDK at iPhone launch, it would have been a horrible mess, and the APIs would have been in constant flux. And web apps would never have got a look in.
What Apple are doing is managing the roll out of a new platform. By all means say what you don't like about it, but wait and see how it all works out before claiming you know a better way.
opening up iPhone
Of course Apple intended to open the platform up. Steve has a long term strategy!
Getting the platform and development kit right is a massive job, especially with completely new interface. it's just taken them until now to get all the pieces in place... by June.
people should read daringfireball.net and http://www.roughlydrafted.com/ for accurate, insightful analysis.
As "sleepy" says above, the use of undocumented API is disallowed for a very good reason. Apple would be forced to support them no matter how much a hack-job they are. This is how Microsoft created huge problems for itself. Once some large Corp. with 10 thousands of employees uses undocumented API's in a vertical app, Apple might have to support it for years, even though it conflicted with newer goodies they wanted to add. Apple doesn't want to be forced into eventually having a mobile OS full of buggy old code. And they definitely don't want the OS to degenerate into a sewer of malware.
Hindsight is a wonderful thing...
The only hindsight that the author, Dave Jewell, has -- is -- hindsight up his own rear end...
RE: Hindsight is a wonderful thing...
Thanks, Eliakim for your insightful, tightly-argued, and perceptive debating skills. Or not.... ;-)
Hi zato. I would never disagree that you should use the documented API's wherever possible, but in this case Apple are clearly using the "don't touch undocumented API" strategy to limit what third-party developers are allowed to do in relation to Apple's own apps. That's the key point.
Check out Jonathan Zdziarski's blog at http://www.zdziarski.com/ where you'll see he's built a Nintendo simulator for the iPhone. Point here is that Jonathan is using a lot of private/undocumented API calls, and none of this stuff is changing from one iteration of the SDK to the next. Why not? Because this is the real API that Apple use internally. The official, documented API is just a tightly restricted subset of this. To me, that can't be right. Background/foreground app issues aside, Apple are simply not providing a level playing field for third-party developers.