Apr
10
Reflections on Apple’s New iPhone Developer Agreement
Filed Under Computers & Tech, Software Development on April 10, 2010 at 11:44 pm
Apple have added in a few lines of extra language to their Developer Agreement for the latest version of their iPhone SDK. You can read the exact wording changes on Daring Fireball, but the effect of the language is that you have to use Apple’s XCode development environment to compile all your code. This has had the effect of killing some unsupported means of making iPhone apps, most notably MonoTouch and Adobe’s about-to-be-released iPhone Flash bundler in CS5. My initial reaction was very negative (ask my Twitter followers), but that was purely an emotional response because Apple didn’t give us any reason for this change. Because Apple didn’t explain themselves, we were left to come up with our own explanations, and the first few that came to my mind were none too positive. Ultimately, I greatly dislike Objective C, so I was pissed off at the alternatives getting the chop. But, slowly, a different story is emerging. I still haven’t heard anything official from Apple, but I think I understand what’s going on, and it changes my opinions significantly.
I’m still grumpy about non-C alternatives being curtailed, but one potential reason for their curtailment makes all the difference. Some people are saying that the reasons for this change is Apple’s highly specialized support of Multitasking in iPhone OS 4. The iPhone is running right on the edge, RAM is highly constrained, CPU is highly constrained, and power is very highly constrained. Getting the iPhone to multitask without massive performance and battery life losses is no mean feat. Apple are doing something cunning at a low-level to make this work, and it’s not even the slightest bit unreasonable to assume that they are using specialized compiler extensions to implements parts of their solution. After-all, that’s how Grand Central Dispatch was implemented in OS X.
We don’t know this for sure, because Apple haven’t confirmed or denied this explanation. But, as a computer scientist, it makes sense to me. Unless some other evidence comes to light, I’m prepared to accept the assumption that Apple have customized their compiler to help them deliver multitasking without the suck. Remember, this is Apple’s own unique hardware, so a customized compiler from Apple is hardly shocking.
From a developers point of view, what does this mean? It means that the only way to write programs for Apple’s device is using Apple’s tools. That’s not actually unusual. If you want to write for a console you use the tools provided by the vendor! What that specifically means is that you can only write in languages supported by Apple’s compiler. I believe that leaves C, C++ and Objective C. Programmers all have their favorite languages. Me, I’ll use Java, Perl or JavaScript wherever I can. However, the skill of programming is not language specific. I didn’t learn Java in college, I learned to program. The course was not called “CS101 – Java”, it was called “CS101 – Principles of Computer Programming”, it just so happens we used Java to learn those principles. The next year we programmed in C. The year after, we used a number of languages including Lisp. The point is, a programmer can program in any language, they just need to take a little time to learn the syntax. Apple can’t possibly support all languages, and supporting three flavors of C is not bad at all. There can’t be many programmers who’ve never met any variant of C before!
Anyhow, what I’m driving at here is that this excludes no programmers. It just means that they may have to take a little time to brush up on their C, C++ or Objective C. For me personally it means I’ll have to put my hatred of all things C aside if I want to program for the iPhone.
Another very important point to make is that there has only ever been one officially supported way to write for the iPhone, and that has been Apple’s free developer tools (the very low $99 fee only comes into play when you want to publish your app). Apple have always worked under the assumption that people who are investing massive amounts of time and money to make an app would do so via the officially supported methods. No one who has been doing that has been in any way affected by this change.
I can think of only one word for any company that would bet the bank on an unofficial and unsupported back-door, and that’s ‘stupid’. Anyone who thought that it was a good idea to risk their business on writing an iPhone app in anything other than XCode was taking a HUGE risk. Choosing to bet the bank on creating such a back-door is even more daft, and that’s what Adobe were doing with their iPhone support in CS5. Apple never invited them to do this, or supported them, or in anyway recognized their tool as an officially supported development environment for the iPhone. Adobe assumed that Apple’s tools would not evolve over time, and that they could depend on their back door, which works now, working for ever. That’s insanity. Just ask Palm! They chose to make a feature they had no control over one of their key selling points for the Pre. That worked out TERRIBLY for them, and Adobe have done exactly the same thing, with predictably similar results.
It should also be noted that this does not rule-out tools from third parties to help developers build apps quicker or more easily. All it does is place a requirement on any such tools that they must produce as their output an XCode project in C/C++/ObjC. You simply have to use Apple’s compiler to turn your code into an app. Apple don’t insist that the C/C++/ObjC has to be 100% written by humans, just that all code that makes you app must come through their compiler, and no other compiler. Remember, XCode writes code for you! When you use InterFace Builder it auto-generates code.
Finally, what effect will this have on end-users? Certainly no negative effects. Multitasking that doesn’t suck is really positive for users! Having all apps use the standard libraries and hence be consistent is also good for users. And no company that’s serious about developing for the iPhone will be affected by this. Any company with a brain at the helm would have been going the XCode route anyway! The only apps we won’t get are opportunistic apps where someone creates some junk Flash app and clicks a button to make it an iPhone app.
Finally finally, I personally lament the end of Mono Touch because C# is a more modern language than ObjC. I really hope Apple expand XCode to support more languages over time. It used to be possible to write full native Cocoa apps in Java using Official bindings from Apple. Sadly those bindings were seldom used so Apple deprecated them, and they finally vanished in SnowLeopard. If Apple wanted they could expand their compiler to support more languages. I hope they do. But, for now, I guess I’m just gonna have to get over my strong dislike of C/C++/ObjC!
[…] bartbusschots.ie/blog/?p=1584 […]
I’m quite surprised by this move, I thought the entire reason that you were able to compile a binary and throw it onto the phone rather than the android way was so that people could create their own compilers thus expanding the developer base.
Perhaps part of the reason is that apple are worried that they will have to share or even lose their developers to google or in a year perhaps even microsoft. A legitimate business reason.
Whatever the reason it’s going to annoy more than a few people and is characteristic of Apple’s immaturity or maybe simply their short sighted attitude when it comes to operating such a platform IMO.
Interesting, because I’d say Apple characteristically look to the long-run and eschew short-term gains for long-term domination. But I digress.
I think this is for technical reasons, as well as other strategic reasons, but if we assume this has nothing to do with tech, then I’d say John Gruber has it nailed: http://daringfireball.net/2010/04/why_apple_changed_section_331
Actually, it’s not just me that thinks Gruber nailed it, the media are reporting that Steve Jobs himself has pointed people to Gruber’s post approvingly.
Bart.