Steve Jobs announced the iPhone development platform at last week’s Worldwide Developer Conference to sighs of disappointments. Mac developers were anxious to develop new applications for the the most anticipated consumer electronics device in years, only to be told they should code fancy websites instead. The 9-minute iPhone development demonstration during the WWDC keynote was a bit confusing for anyone new to Apple widget development. In this post I’ll break down a few Apple widget components, transport you to the iPhone development world, and explain a few restrictions and lock-downs common in the mobile phone industry.
Dashboard under the hood
Apple’s Dashboard application acts as a bridge between web technologies and your desktop. Basic widgets contain HTML, CSS, and JavaScript describing widget structure, styling, and interaction respectively. Multiple widgets utilizing this same base technology form a single process group on OS X 10.5 (Leopard) and minimize the total amount of system resources (CPU, memory, etc.) required by each new widget.
Dashboard widgets can access the local operating system’s look and feel through the Apple JavaScript classes inside your system’s WidgetResources directory. These specialized JavaScript resources expose a scrollbar, slider, buttons, animations, and widget flip controls specific to the operating system and Apple’s UI of the moment.
Apple Dashboard widgets may also tap into local resources such as your computer’s iSight camera, your MacBook’s current battery levels, songs in your iTunes libraries, or contacts in your Address Book. Any application may add a widget-plugin as a Cocoa bundle to allow widget access to application-specific data and functionality.
Today’s Dashboard widgets take advantage of web browsing technology, plugins, and local application resources exposed to the widget engine via specialized plugin interfaces. Dashboard is an part of your computer’s Dock application. Dashboard widgets exist behind a single Dashboard icon; they do not have individually callable Dock icons out of the box.
Dashboard experience ported to iPhone
What if Apple’s desktop widget were ported to a mobile device such as the iPhone? The iPhone runs OS X, and contains the essential components necessary for widget operation on a mobile device.
iPhone widgets would operate inside the mobile WebKit library. They would have access to device-specific UI elements such as stylized buttons, smooth transitions, and personalization options. Pieces of the underlying operating system and installed applications would be exposed via widget plugins. Widget files would be distributed as a bundle, downloaded to the iPhone over the air or via a tethered sync. Each widget could have access to limited system resources such as iPhone battery life, WiFi signal strength, the local Address Book, or the iPhone’s built-in camera.
iPhone developer features announced at WWDC
There were two types of iPhone announcements at WWDC last week: public statements made by Steve Jobs and Scott Forstall during the conference keynote and NDA-bound statements to developers during conference sessions. I’ll only cover the public statements in this post.
iPhone applications will “utilize the full Safari engine” and “look exactly like apps on the iPhone.” Interpretation: Applications created for the iPhone will be powered by WebKit technology and have access to Apple-specific JavaScript libraries to create the look-and-feel of the underlying Apple OS. This behavior is similar to the current Dashboard experience.
Write applications using Asynchronous JavaScript and XML (Ajax). Interpretation: The iPhone’s web browsing technology supports XMLHttpRequest as a data retrieval method. This statement could also mean Apple will support JavaScript programmability of a local sandboxed CoreData store delivered as XML but that’s more advanced and unlikely due to no current offline storage support on the desktop browser.
“Integrate with iPhone services.” You can make a phone call, send an e-mail, or lookup a location in the built-in Google Maps application from any web application. Interpretation: The iPhone’s Safari browser contains the same data detection features for phone numbers, e-mail addresses, and address data seen in Mail.app in Leopard. This detected data can be passed into its default handler as an automatically-generated hyperlink. This statement could also mean WebKit applications will have access to special plugins created for system-level services similar to the desktop API but that may be too hopeful.
“Instant distribution.” “Easy to update.” “Sandboxed on iPhone.” Interpretation: Widget bundles are not stored on the iPhone. All files are retrieved from the a remote server and treated as a web resource. Your files are cached and have the same access restrictions as a standard public Internet site.
Safari vs. widgets
iPhone widgets are small applications powered by WebKit launched from the iPhone application menu. Web applications created by third-party developers for the iPhone are three clicks away from the same home screen — Web, Bookmarks, bookmark name — but have similar functionality. Personalization data such as stock tickers or your local ZIP code is stored inside a browser cookie.
iPhone widgets store resource files such as images, HTML, CSS in the iPhone’s local storage and update the entire widget with the operating system. iPhone widgets pull data updates such as stock prices or the latest weather report from a remote server or could also access locally stored data such as a dictionary.
Safari-based applications request each resource from a remote server and poll for cache updates with each page load. If your weekly weather display contains a sun, cloud, and cloud with rain your application might poll a remote server for possible changes to each of the three images with every display of your weather page.
AT&T or Apple restriction?
Apple developers wanted at least iPhone widget-level application marketing and were visibly disappointed by Apple’s keynote announcement last week. It’s still unclear if AT&T or Apple is keeping third-party developers off the main app menu. I can only postulate based on existing developer programs from each company.
AT&T certifies applications to operate on phones in its network across multiple operating systems. Productivity applications receive an enterprise solution certification after successfully passing security, reliability, and network usage tests and paying fees starting at $1000 a test. Enterprise applications are usually available for free and side-loaded (updated via a tether) by corporate IT departments. Consumer applications are typically distributed through AT&T’s MEdia Net portal after similar testing and certification fees for a purchase fee split between AT&T and the developer. This process is the “orifice” Steve Jobs referenced in a 2004 Wall Street Journal interview.
Current video iPods feature games purchased from the iTunes Store. Apple currently distributes 14 games created in-house and through external companies such as Astraware who specialize in porting games to PDAs and cell phones. The current iPod games platform is not open to third party or “homebrew” creations. Anyone can create their own iQuiz, using a specially formatted text file (essentially a fancy Note).
New developers could enter the iPhone application menu through AT&T, Apple, or both.
Ten days until iPhone
The iPhone will be available at 6 p.m. on June 29, or a little over 10 days from the time I write this post. More developer documentation may emerge after the device’s official release. Hardware and software hackers will likely pull the device apart in search of custom modifications already present on Palm Treo devices or the Sony PSP.
Hopefully this long post clarifies the data we already know about applications and widgets on the iPhone. The device and its software was certainly under a tight release schedule and it’s reasonable to assume new features are on their way in new versions of operating system hardware and software expected over the next six months. There is a developer story on the iPhone, but Apple has not communicated this story very well to their developer base over the past 6 months. They’re battling the same closed carrier system as any other mobile application provider, so expect slow change assisted by market leverage.
