Developer: iPhone SDK “crippled,” jailbreaking to continue
Posted 10 March 2008 @ 10am in Development, News
While Apple’s software development kit for the iPhone has been lauded by a host of major software companies that were trotted out during Steve Jobs’ introduction as well as a number of independent developers hoping to strike an early bounty through the “App Store,” some open-source developers are panning Apple’s restrictions and voided functionality and vowing to continue the creation and promulgation of unofficial, “jailbreak” applications.
Jonathan “NerveGas” Zdziarski, one of the most noted underground iPhone developers who recently released a book through O’Reilly Publishing dubbed “iPhone Open Application Development” that explains in how to create iPhone applications using Objective-C and the iPhone API, told iPhone Atlas “The Apple SDK, as many have come to find, has arguably crippled much of the functionality that set the iPhone apart when first released. Even simple features like the ability to run a program in the background, have been crippled in the Apple SDK.”
Signed applications that run under Apple’s scheme lack the ability to run in the background, as many of Apple’s own applications — including the Mail program and Clock — do. Unofficial applications created under the jailbreak umbrella carry no such restrictions. Apple’s motives for limiting this functionality aren’t clear, but some have cited stability concerns.
“Jailbreak” applications also are not subject to any run-rights restrictions, and hence immune from Apple’s discretion. Though Apple has yet to precisely detail its guidelines for blocking official applications from the iPhone, the company has stated that it will not allow pornographic, “malicious” or “illegal” applications in its system. Apple will also bar applications that “execute another program’s code,” a stance with which Zdziarski takes issue.
“Apple has secured (itself) potential contracts with game manufacturers, such as Nintendo, and with companies such as Sun and Adobe by banning any software that ‘executes another program’s code’ on the iPhone,” said Zdziarski. “This means companies will need to ink a special deal and pay a hefty ransom to Apple to release things like Java, Flash, and video game emulators (many of which are already available using the open tool chain).”
Apple’s SDK is not so much a groundbreaker as it is a proprietary spin on a well-traversed system. Not only do “jailbreak” iPhone applications exist in abundance, developers have created a fairly robust unofficial SDK, including a complete guide to iPhone development that integrates Apple’s XCode, an integrated development environment for Mac OS X. Instructions for setting up a staging area, creating a mountable iPhone filesystem, installing the iPhone toolchain, and finally setting up XCode with a custom iPhone application template are all included.
The unofficial development community has also established a distribution scheme that represents a precursor to Apple’s “App Store”: Nullriver’s Installer.app. Installer.app offers over-the-air downloads/installations, easy updating and uninstallation of applications, and many other advance features that Apple has replicated with the “App Store.”
Zdziarski says “Apple is embarrassingly the one trying to duplicate the open source community today. As a result, many of Apple’s SDK restrictions appear specifically targeted at this established community. Apple has banned NullRiver’s installer app, as well as PXL and other software installers, essentially locking out any third party distribution channels from iTunes (which may equate to unfair competition).”
In fact, says Zdziarski, the unofficial application development tools offer a greater breadth of system accessibility than Apple’s tools, which the company pitched as “the same ones” it uses.
“The APIs that the open tool chain uses seem to reflect more closely to the ‘real SDK’ used by Apple to create their own applications,” said Zdziarski. “While the Apple SDK lets you write applications that look somewhat like iPhone applications, the open tool chain allows you to get right down to the metal and write applications using the same objects as Apple’s own applications - and use the same spectacular effects that are otherwise restricted.”
The possible answer to open-source developers’ frustration? A two-tier system. Early indications are that iPhone OS 2.0 is likely to run all existing applications written on the open tool chain, providing that the new OS iteration can be properly jailbroken (allowing full read/write access).
Zdziarski makes the bold prediction:
“As it stands today, the open tool chain is likely to be the dominant tool chain going into 2009, as the Apple SDK is clearly not ready for general adoption yet. […] The open tool chain works today, and has had almost a year to mature into what has become a very robust SDK with a large distribution base. I encourage developers to continue using it, and think it’s going to be around for quite a while.”
Feedback? info@iphoneatlas.com.
Previous coverage:
Print This Post
5 Comments
Posted by lastcosmonaut
10 March 2008 @ 2pm
Question to those with (SDK and (iPhone or iPod Touch)):
is it possible to install an app on the device without Code signature, when you edit your project.pbxproj inside of the xcodeproj bundle to something like this:
… /* Release */ = {
isa = XCBuildConfiguration;
buildSettings = {
ARCHS = “$(ARCHS_STANDARD_32_BIT)”;
CODE_SIGN_IDENTITY = “”;
CODE_SIGN_RESOURCE_RULES_PATH = “”;
OTHER_CODE_SIGN_FLAGS = “”;
PREBINDING = NO;
SDKROOT = “$(DEVELOPER_DIR)/Platforms/Aspen.platform/Developer/SDKs/Aspen1.2.sdk”;
};
name = Release;
};
???
Posted by lkrupp
10 March 2008 @ 2pm
Sounds like someone with sour grapes in their mouth. For some self-important “coders” nothing but their own is good enough or worthy enough. The iPhone SDK will greatly curtail the jailbreak crowd. I’m betting that the official SDK apps will not run on a jailbroken iPhone so the majority of users will decide to stick with the official apps. Then there’s always the security (mainly lack thereof) aspects of third party hacks. Of course there will always be a few malcontents who will still do it their way but they’ll be in the same crowd as the “I can run OS X on a Dell so look at me!” goofballs.
Posted by jimstead
10 March 2008 @ 3pm
Some “bold prediction”. Here’s my bold prediction: other than a few developers who want to play there won’t be 10 people among actual users who will want to jailbreak their iphone when they can easily download free and cheap apps from itunes.
Posted by coisbot
11 March 2008 @ 8pm
The official SDK is severely crippled, and I think the millions of people who have already jailbroken their phones and ipod touches will realize this the second they download apps from the App Store (if they have not realized already; word gets around fast in these types of communities). The new crowd may not realize this, and of course, won’t know what they’re missing when they use App Store apps.
I think it’s a stretch to say that the toolchain will be dominant all the way to 2009, but it can certainly do much more than the SDK can right now, and many will still have a viable reason to use it.
Posted by luz_info
14 March 2008 @ 3am
While I really apprechiate Jon Zdziarski’s work (and his excellent book on Open iPhone development), I am a bit surprised about him (and others) being that upset about Apple’s beta SDK. It all sounds too much like a competition of the Evil (Apple) vs. the Good (the open hacker community), which is dramatic nonsense in my opinion.
Unless you completely condemn any commercial approach, I don’t see why it is so difficult to see that Apple *has* to take a different approach than the hackers. While the hacker’s reputation lies in his or her technological in-depth expertise alone, Apple’s reputation consists of several conflicting factors that must be brought into equilibrium: openness of the platform for developers, commercial success, development ressources available, security concerns, PR, constraints from contracts with the MI and the mobile carriers and so on.
This is an optimization process. To do optimization, you need a starting point from where you can still modify the factors that define your optimization target. And not every modification is reversable. Once an API is officially made part of the SDK, there’s no way back. While those low level APIs Jon is talking about are sure technically interesting, its also pretty obvious that they were sketched and implemented under severe time pressure, and are not very well aligned with each other. They need room for optimization and clean up.
So for me it’s entirely logical and inevitable that the official SDK provides a higher abstraction level, and does not let us (officially) use too much of the low level stuff directly. Yes, these are restrictions, and yes, many of them are annoying for me as well right now. But restrictions on what third party developers can do provides more freedom to what Apple developers can do in optimizing the entire platform. This is not about hacking fun for the next few months, but about establishing a mobile platform which has to last for years, and for this is needs a SDK (and licensing terms!!) that are carefully balanced between the we-can-do-everything and nothing-is-allowed extremes.
So I hope for more focus on the *process* going on between now and June, and exploring the ways to influence what the first SDK release will be, by pointing out the distinct problems and suggesting actual solutions - publicly and using Apples bugtracker.
Promoting the perspective that the official SDK as a whole was an evil thing and the open toolchain was the only alternative to save our souls in my opinion does not help too much to actually improve the iPhone platform.