Hide full article
The iPhone 2.0 software development kit (SDK) is out, but the iPhone 2.0 software won't appear until June 2008, a year after the original iPhone shipped. Apple promised in late 2007 that it would release an SDK to allow developers to create their own iPhone software by February 2008; what's a week between friends? Especially when Apple appears to have provided more direct access to iPhone features and networking than was expected. The SDK allows use of the cellular and Wi-Fi connection, can sniff location, and offers direct access to gestures, touches, and motion, tying into the iPhone's touchscreen and accelerometer.
The SDK can be downloaded for free, and includes a simulator of the beta version of the 2.0 software; the operating system update will work on both the iPhone and iPod touch. (Apple's servers crumbled under the initial load, with developers complaining about how long it took to get the 2 GB disk image to download - they want it now!) When released in June, the software will be a free upgrade for all iPhone owners, but iPod touch users will have to pay a "nominal fee," much like the recent $20 fee to get the mail, location, widgets, and other items added in January. (Apple books revenue immediately for iPods, requiring it to either restate revenue or charge a fee to handle substantial new features; the iPhone's revenue is accounted for
over 24 months.)
Included in the June release will be a host of corporate networking features designed to enhance security, support large-firm infrastructure, and, most remarkably, interact directly with Exchange servers through a license Apple obtained from Microsoft. Might June also mark the release of a 3G iPhone? Nothing was said about it, but that's what we're thinking now.
iPhone SDK -- Apple Vice President of iPhone Software Scott Forstall said that developers would have access to the same APIs and tools that Apple uses to build the iPhone apps, including the Core OS layer, the Core Services layer, the Media layer, and a new application framework called Cocoa Touch, along with an interface simulator for testing software before it's installed on the real hardware.
Developers confirmed for us that the simulator isn't a hardware emulator that pretends to be an iPhone and runs native code. Rather, programs compile for Mac OS X and run within the interface simulator. It's a little odd, but may have been part of Apple's intent in abstracting the hardware and providing less information to phone unlockers, too; the less access to even simulated hardware, the harder it is to jailbreak the iPhone or iPod touch.
The Core OS layer is largely the same as in Mac OS X, though with better power management. The Core Services layer includes things like SQLite for database storage and Core Location, which uses cell tower and Wi-Fi network data to determine location, which only the Maps application currently employs. The Media layer enables the iPhone to play audio and video, and includes things like Core Audio from Mac OS X. And lastly, Cocoa Touch replaces Cocoa as the application framework upon which all applications are built; Cocoa assumes a keyboard and mouse for input, whereas Cocoa Touch assumes that all input comes via touch - single touch, multi-touch, and gestures.
But that's just the foundation - the environment in which iPhone apps are actually created is Xcode, running on a Mac with an Intel processor and Mac OS X 10.5 Leopard. Developers will use Interface Builder to design and implement iPhone app interfaces, with all the standard user interface elements already available. Other tools include Instruments, which helps developers check memory usage and measure performance, and the iPhone Simulator.
Apple showed a pair of demonstration applications, the first of which was an image manipulation program that allows the user to distort a photo with a touch or a pinch, and to erase the distortion with a shake, like an Etch A Sketch; it reportedly took two days to write. The second was Touch Fighter, a space shooter game in which the user controls the spaceship via the iPhone's accelerometer and fires by tapping the screen; Apple said the software took two weeks to put together.
Apple pulled other developers into their campus to work with the iPhone SDK a few weeks ago; some of those developers, it was claimed, had never written software on a Mac before. Electronic Arts showed a version of their upcoming game Spore in which the accelerometer controls the spore moving around the screen, eating smaller things and avoiding larger ones; once a certain point is reached, the player uses the Evolution Editor via the touchscreen to design a custom spore. Salesforce demoed an app that brings data down from a sales database, giving business data that salespeople need in real time. Next up, AOL showed a version of AOL Instant Messenger (AIM) for the iPhone that will eventually provide the level of instant messaging that
many iPhone users have wanted instead of SMS messaging. Epocrates showed a drug database for doctors, and lastly, Sega demoed Super Monkey Ball, a version of a console game that, ironically, needed an artist to scale up the graphics for the iPhone's screen.
In general, it seems as though Apple has pulled back the curtains on a great deal of what's possible on the iPhone, although it's not as open as the Macintosh. Needless to say, SIM unlock software won't be allowed, and access to the dock connector will be restricted, other than what's already available via the "Made for iPod" program. Nothing was said about whether Apple would enable support for the iPhone to distribute a cellular-based Internet connection to a laptop via Bluetooth, or if Bluetooth-based support for external input devices like a keyboard would be allowed.
The Free Market Costs 30% -- The only way for users to acquire iPhone apps will be through Apple's new App Store, which looks a lot like the iTunes Store and likely takes advantage of everything Apple has learned while selling four billion songs via iTunes. Free applications will be hosted in the App Store for free, and revenue from commercial applications will be split with developers such that the developer gets 70 percent and Apple keeps 30 percent. Developers also pay a $99 fee to distribute free and commercial programs via the App Store. This fee is per developer, not per application, and isn't required to download and use the SDK.
Response to the revenue sharing among the developer community was largely positive, with many saying they'd expected a 60:40 split, and would have of course preferred an 80:20 split. 70:30 is entirely reasonable in our opinion, partly because that's an all-inclusive fee covering processing, bandwidth, hosting, and marketing; in the traditional book world, for instance, the split between publishers and bookstores is often 50:50. Many ecommerce providers charge 10 to 15 percent for less than Apple will be providing via the App Store's directory and interface.
Developers can choose, of course, to price their offerings higher than they might otherwise to get back some margin, but they have to avoid charging too much. Some developers may simply release free iPhone software that's designed to work with desktop versions of their software sold on a per-seat license. That could push more sales of those applications, or increase licenses sold within companies.
Of more concern was the question of what Apple would allow to be sold through the App Store. Categories of applications that Apple won't accept include anything related to porn, applications designed to violate privacy, bandwidth hogs that could overtax AT&T's data network, malicious programs, and anything that's illegal (which is an ever-increasing amount of software, thanks to the DMCA). While a bandwidth hog over Wi-Fi might be obnoxious, it might be not be considered as much of a problem as filling AT&T's data pipe.
On the face of it, that sounds reasonable, but developers voiced worries over just how Apple would decide, and whether Apple would allow applications that seem to work around Apple's own business model. Paul Kafasis, CEO of Rogue Amoeba, wondered whether Apple would allow their applications on the iPhone. For instance, Apple might not like that Airfoil reverse-engineered the AirTunes protocol, that the listening portion of Radioshift would allow users to listen to music without buying it from the iTunes Store, or that Fission enables users to make ringtones rather than buy them from the iTunes Store. Needless to say, it would be good if Apple would provide rulings before development is complete, so developers don't waste time on
applications Apple won't allow.
Another question on our minds is if Apple will accept non-applications for the App Store. For instance, what if a developer writes a game and wants to sell additional levels for it? Or, what if someone writes an ebook reader and others want to sell ebooks in a compatible format? For more thoughts on what Apple could do in this arena, see Adam's "Open Letter to Steve Jobs: In Support of an iPod reader" (2008-03-05).
And what about trialware? Most developers offer 30-day trials of their software, or programs that come with some features locked or disabled. Paying a fee unlocks the program or activates it permanently. Since Apple wants to be a gatekeeper for programs, will they allow this kind of flexibility? Perhaps a "30-day" box that developers can check to delete the program - a la iTunes movie rentals - when the period is up if a user hasn't paid?
If Apple proves overly cautious about applications that are not obviously problematic, we suspect that the vibrant iPhone hacking community will refocus its efforts on hacking the iPhone to accept applications that Apple won't host in the App Store.
While the SDK is freely downloadable, the iPhone Developer Program won't accept all comers yet. Apple has a footnote on its developer page that states, "The iPhone Developer Program will initially be available to a limited number of developers in the U.S. and will expand to other countries in the coming months." It's not quite clear when and how Apple will open the iPhone Developer Program fully.
iPhone Goes to Work -- The iPhone was widely criticized in its first release for lacking a host of critical features for large business information technology (IT) infrastructures (networks, servers, software, computers, and handhelds), generally subsumed under the term "enterprise." It didn't matter that Apple wasn't targeting the iPhone at enterprise users; rather, those in the business world knew iPhones would be brought in to use, and company techies knew that they couldn't support them.
In the enterprise, chief information officers and IT workers want the ability to integrate any new device with their existing technology decisions - which often include specific sets of choices around remote connections (via a virtual private network client), network login policies (which may require digital certificates and keychain fobs), and mail, calendar, contact, and directory services.
Until recently, there wasn't even a way for enterprise users to pay for an iPhone on a corporate account - the iPhone was available only for personal use (see "AT&T Offers iPhone for Enterprise," 2008-01-23). Nevertheless, the iPhone saw significant uptake among executives and others in large corporations. With iPhone 2.0, Apple will be adding a slew of new features aimed at making the iPhone into a better corporate worker bee, including full Microsoft Exchange support.
Apple surprised many industry watchers by announcing that they'd licensed Microsoft Exchange ActiveSync from Microsoft, as Apple rarely licenses anything that's core to their purpose. But in the enterprise, Exchange is one of the kings, and Apple had to pay obeisance to get the pieces necessary to perform robust synchronization and communication. With full Exchange support, Apple can directly take on Research in Motion (RIM) and its BlackBerry communicators. Apple took aim at RIM by criticizing their single-point-of-failure approach to having all email and messaging pass through RIM's servers; two recent brief failures have highlighted
RIM's vulnerability. In Apple's approach, the iPhone will communicate directly with the enterprise's servers.
This will allow enterprise iPhone users to get real push services, which was one of the big early draws to the BlackBerry, and is available with only Yahoo Mail on the iPhone today. (Yahoo Mail's approach is rather insecure, too, as I documented over at Macworld many months ago.) The Exchange push support includes email, events, and contacts. A contact added to an internal directory will appear nearly immediately in an iPhone's contact list, for instance.
Other important additions include:
- Two-factor authentication. This security policy pairs a password with a key fob, card, or sensor that provides an additional code or offers biometric details (a fingerprint scan, for instance). The password is meaningless without the other detail, the second factor.
- 802.1X and WPA/WPA2 Enterprise logins. While this sounds like a bunch of nonsense to the untrained ear, it's music to an IT manager. 802.1X is generically a method to allow a device to connect to a very limited part of a network while a user confirms their identity; it's "port-based authentication" that firewalls the rest of the network away from the device. 802.1X is used with both Ethernet and Wi-Fi, although the most sensible modern Wi-Fi networks use a subset of 802.1X called WPA/WPA2 Enterprise that requires that WPA (Wi-Fi Protected Access) encryption methods are used. Without 802.1X support, enterprise iPhone users have been unable to access some corporate networks without unpleasant workarounds.
- Device configuration. It's a bear to manage handheld devices when you have to set them up one at a time. Group configuration allows a passel of devices to be configured at once from a console, and to have the same basic configuration. This is especially important when installing digital certificates; IT personnel often need to install a common root certificate for the entire firm, and an individual certificate that corresponds to the device or the user. (Back in the early days of 802.1X, only certificate-based logins were available, and Microsoft had to have each worker bring their laptop to an IT office to get certificates installed by floppy before the laptop could gain Wi-Fi access to the network.)
- Remote erasure. IT departments want to be able to "brick" a device remotely, in order to wipe sensitive information from a lost or stolen handheld, or one in the hands of an employee who is being terminated...right...now! Apple added this feature to iPhone 2.0, showing it in a demonstration where all the iPhone's data was wiped, after which it rebooted sans any information. It was unclear from the demonstration whether the device's SIM card, containing network authentication, was disabled, although that's likely.
Yet to be answered is whether the enterprise features include a persistent virtual network connection that works across whatever network you're attached to. Several enterprise products designed for mobile workers stick a server in the enterprise and client software on the mobile device that uses a special property of TCP/IP networking to suspend a connection when a network is switched. This allows something as intensive as streaming media to halt, wait for the network to change, and resume.
This would be an ideal addition to the iPhone, because it combines security with seamless access, and reduces disruption for the user. Apple could build such technology in, but there's no standard on the server side, so they would have to develop or license such technology. More likely, the SDK would allow such a client to be created, but limit its distribution to enterprise customers.
Enterprises can pay a $299 fee to create programs that can be distributed for in-house use only, via a version of the App Store that will enable a corporation to distribute internal applications securely. An internal App Store may also be how enterprise-focused software developers will distribute their packages, which are typically licensed for a site or on a per-user or per-system basis, to their customers.
Xcode Marks the Spot -- It's clear that Apple's decision to develop Xcode as a single, unified development platform has wound up being as important to the company's long-term success as their move to Unix with Mac OS X, and their switch to Intel processors to ensure having the fastest possible computer. While developers have varying opinions about Xcode, its ability to extend development so rapidly from PowerPC to Intel processors during that transition, and now to leap over to mobile devices, allowing programmers to leverage their existing knowledge, means that Apple can now throw its entire existing development community at the fastest-selling mobile device in history.
iPhone developers, start your simulated engines!
