Inside the iPhone: Third Party Software
Any chunk of interesting hardware can become more interesting with new software applications. Apple's new iPhone certainly has the potential to run new applications, and its various motion sensors, radio networking, and computing features all beg for full exploitation in software.
That's left a lot of people wondering: will there be any third party development for it?
Apple executives have made comments that have been construed by some analysts to mean that no third party software will ever appear. At the same time however, Apple reps at Macworld were actively soliciting iPhone ideas and directing interested parties to its developer relations group.
Remember that Apple also refers to the existing iPod as a “closed platform,” despite the availability of both third party games sold by Apple and alternative software from both open source and third party commercial developers.
Factors in the Development of Third Party Apps
There are a few different reasons why third party developers might avoid a platform like the iPhone:
Demand below a critical threshold: There are many examples of open, promising platforms that simply died because too few people cared. The Linux based Zaurus PDA, the Sega DreamCast, and the BeOS are all examples of systems that could not establish enough demand to remain viable.
In many cases, a dying platform may attempt to open up in order to find new developer interest, but being "open" in itself doesn't necessarily solve the problem.
Difficulty of development efforts: There are platforms with sufficient demand, but which have features that are so difficult to support that they simply remain impractical to target.
The unique complexity of Apple's Newton--combined with poor development support by Apple--helped to repress interest in the platform by third party developers.
Artificial limitations on development: Some devices with promising hardware potential and sufficient demand are artificially closed by their vendor. The existing iPods, as well as Microsoft's Zune and Xbox series, all present barriers to developers interested in doing unique things on them.
In the case of the iPod, third party developers have been left on their own in efforts to run Linux or other custom software in place of Apple's, and are prevented from running unauthorized software on top of Apple's own software.
The only third party development currently sanctioned by Apple is the 5G iPod's games, although outside efforts have created both an independent Linux software platform for iPods, as well as the alternative Rockbox software. Apple doesn't care if people put Linux on their iPod, as it simply means another hardware sale.
In the case of Microsoft's Zune and Xbox series, the opposite is true; while Microsoft actively courts games game developers for the Xbox, its actual hardware isn't merely undocumented, but actually purposely locked down to prevent the possibility of running Linux or some other custom OS on it.
Microsoft has to do that because it sells its hardware either at a loss or a minimal profit; real profits are intended to come from game licensing or subscription plans. Additionally, both the Zune and Xbox are designed to shore up the Windows monopoly, and neither can do that while running Linux.
Locked Closed vs. Managed Closed
Both Apple and Microsoft are selling closed and proprietary systems in their consumer electronics products. However, Apple typically sells unlocked hardware but manages its hardware and software as an "integrated experience." Microsoft seeks to lock down its hardware, but leaves third party applications largely unmanaged.
Anyone who argues that Microsoft's Xbox 360 is "more open" because third party developers build games for it hasn't tried to install a custom OS or develop their own games for it. That highlights a common misconception about the meaning of "closed" and "proprietary," both of which are frequently misused.
A lot of people seem to like using "closed" and "proprietary" as derogatory words, but when terms are used to enflame advocacy wars, they tend lose any useful meaning in a rational conversation.
Being "open" or "closed" isn't a black and white issue; it involves a lot of grey. Even within the realm of open software, the difference between GNU and BSD style licenses--and which is "more open”--is hotly contested.
Open and Closed
Open development has both benefits and disadvantages. The reason Linux has made so little impact in the desktop market is largely because a fully open system tends to devolve into anarchy.
Who supports what? What version is the standard? Where is the commercial incentive to develop for it? Who makes it all work together in a nicely integrated package, and once that happens, it is still open?
Linux works very well in service oriented business; Red Hat, IBM, and many independent technicians use it to build custom solutions that may not be possible or practical when using closed source software from a vendor such as Apple or Microsoft. 
Different development models simply fit different tasks. This is lost upon people who only know how to use a hammer, and therefore think everything in the world is a nail.
Closed iPhone Panic
As anticipated in Ten Myths of the Apple iPhone, one of the key grandstanding pre-complaints about the iPhone is that Apple has done exactly as expected: deliver a software model that works like the existing iPods, rather than, say, the Palm Pilot or a Windows PC.
That same article explained why: Apple wants the iPhone to work reliably, not to be known as a toy that can load various shareware apps, but which freezes erratically and is plagued with spyware and security hazards.
If Apple comes anywhere close to its sales expectations (more on that later), there will certainly be a demand for iPhone software. Using the iTunes Store to distribute and sell iPhone software--the model used for existing iPod games--will actually enhance demand, because developers will have a real market for their software.
A sustainable market with a sufficient demand volume will enable Apple to offer software from third party developers at low prices. Recall that iPod games are $5; comparable Palm Pilot games are either in the range of $20, or are offered as unsupported shareware by developers who can't stay in business and have no motive to develop anything really cool.
Anyone who thinks that Apple won't offer the same kinds of applications that are already available on the Palm is being disingenuous. Demand will be better than the Palm, and demand drives solutions.
Low priced, high quality software will enhance the iPhone far more effectively than the hit or miss Palm software market, where titles tend to either be overpriced or go entirely unpaid, ensuring that serious developers ignore the platform.
Practical Development
But what about practicality? Will the use of OS X make the iPhone easy to develop for, or will the iPhone's development be so different--or so complicated by Apple--that any new software is unlikely to ever show up?
A recent Apple job listing for a "Bluetooth/WiFi SW Engineer - iPhone" specifically asked for experience in developing drivers for the Mac OS X I/O Kit, as well as familiarity with Mac OS X's Mach kernel and the ARM processor architecture.
That strongly suggests Apple has ported key chunks of its existing OS development to ARM for the iPhone, and that developers familiar with today's Mac OS X will be at home on the iPhone.
What's Not Included?
Macworld: Scorecard and Secrets of the iPhone presented a quick list of items to give a picture of how the iPhone's version of OS X might differ. Several readers have taken issue with some of the items, which were presented as examples, not as an exhaustive guide. Here's a second look at them:
with no disk drive, it doesn't need the elaborate caching Mac OS X does to speed everything up
The desktop version of Mac OS X is optimized to run from a hard drive. In order to speed up booting, the system caches settings and preferences into shortcut files. This allows subsequent boots to skip a lot of unnecessary steps. Without using the cached shortcuts, it would need to read and process the same settings on each boot from the relatively slow hard drive.
One specific example of this is with kernel drivers. On first boot, a Mac running Mac OS X reads through all of the many available kernel drivers to assemble a list, and compares it to the list of devices identified by firmware as actually being installed when the machine was turned on.
This information does not change unless new hardware is installed, so the step is usually unnecessary. To skip having to repeat this on every subsequent boot, Mac OS X writes a cached listing of its kernel drivers to disk. Similar caching tricks are used to speed up other internal systems.
However, on the iPhone there is no variety in hardware, and it will only ever have drivers installed that are necessary; no cached listing is useful, because there is no shortcut to take. Because the iPhone boots from electronic memory rather than a hard disk, caching is not really useful anyway. It won't even benefit from the type of "read ahead" caching that hard disk based iPods perform.
without overlapping windows, it has no need for Mac OS X's double buffering overhead
As demonstrated, the iPhone sports various Exposé style animations that will be familiar to Mac OS X users. These no doubt use conventional frame buffer and compositing techniques, but it appears that the device won't have to use the same resource heavy system that Mac OS X uses to do things like smooth window dragging.
In contrast, one of the reasons why Microsoft Windows appears to be "snappier" than the Mac in some cases is because its lightweight windows do much less. Dragging windows around on Windows XP frequently leaves behind a trail of garbage as new windows are drawn faster than the old ones are scrubbed away.
Since the iPhone won't be redrawing conventional resizable and overlapping windows, I suggested this as a possible way that the equivalent of Quartz graphics may differ on the iPhone.
it has no need for elaborate font rendering or a printing architecture
Again, an obvious example of functionality that can be greatly simplified for use on the iPhone. It still has to render fonts, but it doesn't have to provide as fancy of a font rendering system as Mac OS X does. Of course, I'm no expert in typography, so I could be wrong.
My list of key iPhone features would not include support for font ligatures, however.
it doesn't have to support a variety of hardware devices or scan for changes in hardware
In conjunction with the example given about kernel drivers, hardware support on the iPhone can be simpler. However, it will still need to support scanning for Bluetooth hardware, changes to the network as WiFi becomes available, and adjustments in relation to its various sensors, so this may have been the weakest example given.
The More Things Change...
The above examples highlight how development for the iPhone could conceivably be different from the Mac. However, it's also useful to look at how development for the iPhone may be very similar.
The easiest example is in Dashboard Widgets, which are not really applications at all, but merely mini web pages with a snippet of Javascript offering a few simple features in a familiar "flipping widget" interface.
Widgets can run anywhere Safari's Web Kit can. Existing Widgets could "just work" on the new Intel Macs without any transition work or recompiling. They can also be adapted to run on other environments outside of Mac OS X. Since the iPhone runs Web Kit, it would have no technical barrier to running existing Widgets, apart from actually getting them installed.
Web Pages and Exchange Integration
Of course, since Widgets are just web pages, anything that could be done by a Widget can also be done by a web page. Other more sophisticated web apps, including Microsoft’s Outlook Web Access (OWA is Exchange’s web page interface) and companies’ own custom web apps can also be run from the iPhone’s web browser.
Existing iPods already come with software to sync contacts and calendars with Outlook on a Windows PC, so direct sync using the iPhone also seems like a given. Since the iPhone can also visit the web, it can use OWA for mobile access to company email.
It is also much simpler to remotely sync to Exchange from wireless devices that it was just a few years ago. Apple already provides the ability to sync data with Exchange Server from Mac OS X Tiger, and could certainly reuse that knowledge to build integrated Exchange sync for the iPhone.
Incidentally, Treo and WinCE wireless devices actually sync with Exchange via OWA, as does Entourage and Tiger’s Address Book and Mail. There are no secrets to synching with Exchange Server that are beyond the grasp of Apple, as it has been providing Exchange integration for years now.
Front End, Back End
Beyond simple Widgets and web apps, there are many examples of existing Mac apps where much of their core functionality could be brought to the iPhone, simply by building a new front end interface specialized to work within the iPhone’s specific limitations.
Safari is a good example of an app in Mac OS X with a front end interface and a back end engine. Users interact with its Cocoa based front end, which offers its brushed metal interface, bookmarks, and RSS features.
Internally, Safari is driven by the Web Kit, a library that other apps can also use. For example, Dashboard uses the Web Kit to draw Widgets; other browsers, including OmniWeb, can also internally use the Web Kit to render the web pages they display.
Apple's Web Kit is based on the KHTML open source browser; Apple also offers the Web Kit as open source. That allowed Nokia to use the Web Kit to built a web browser for its own mobile phone.
On the iPhone, "Safari" is clearly using a highly customized front end to accommodate its much smaller screen. However, the back end rendering engine of the iPhone's Safari is likely very similar, if not identical, to the existing Web Kit.
Model View Controller
This idea of separating the user interface from an application's data and logic is a key part of modern application design. Mac OS X, as with its predecessor NeXTSTEP, intended to enforce this MVC design to create modular apps where the interface could be wholly independent from the data used by an app, and the code that defined how the app actually works.
The opposite of closely following this model results in "spaghetti coding," where data and interface components are all mixed into the core logic code, making it difficult to port applications to new platforms or maintain them as projects as they grow and change.
Apple has been designing its apps and OS X libraries to run anywhere, and to not make assumptions about the underlying hardware. That enabled Apple to quickly and seamlessly move to Intel, and it appears that it is also enabling Apple to move the same technology to the (apparently) ARM-based iPhone.
Mac Face, Unix Brains
A similar principle commonly applied in Mac OS X is the use of native Apple development libraries (Carbon, Cocoa, or a combination of the two) to build a Mac like interface for existing code that serves as an back end engine.
This allows developers to draw from the wide selection of open Unix code libraries already available, and "wrap" that back end functionality with a familiar and nice looking front end interface.
Apple commonly builds a graphical front end for apps which draws upon core function libraries. Disk Utility, for example, is a nice looking front end for the command line diskutil, which can also be run from the Terminal without any fancy graphic interface.
This allows Apple to reuse code as much as possible, rather than writing one tool to run from the command line and another graphical app that handles the same set of features, and then having to maintain two sets of code that both do the same work.
Code reuse not only saves development time, but exercises the same code repeatedly, resulting in fitter code. Combined with modular development principles, Mac OS X makes it very easy to create native Mac software ports of existing Unix code that is already proven to work well.
Creating refined and stable applications was much more difficult under the old Mac System 7 or on the Newton, neither of which were designed with a foundation like Mac OS X's.
Demand, Difficulty... Artificial Limitations?
So far, the barriers of demand and difficulty don't look like a problem for the iPhone. What about artificial limitations created by Apple?
Apple has quite pointedly stated that it believes that an unmanaged amalgam of shareware and open source would result in a phone like the Palm Treo or WinCE / Windows Mobile phones, where security is problematic and system instabilities are a common problem.
That's simply difficult to argue against. While the idea of a Linux based PDA phone that runs everything and burps out source code on demand sounds great and is politically correct, there's a reason why such a thing is conspicuously missing from the market: it makes even less sense than Linux on the desktop.
Freedom to Crash, and the Freedom to Fix It Yourself
The problem with all the freedom available in a fully open platform is that, in the words of Janis Joplin, "freedom's just another word for nothing left to lose."
It's great to have everything free and open, but that doesn't leave many options for people who can't afford the luxury of dropping out of a society based on specialized talents, and who aren't ready to join a collective.
Few aspire to being their own full time, unpaid systems integrator, or are at all interested in managing their own mobile lifeline as an experimental technology project. In fact, the majority of people who plunk down $500 for a pocket computer, mobile phone, and media player from Apple will expect it to just work.
The Managed Software Market
Apple's iPhone is a product designed to fit the needs of busy professionals and sleek gadget lovers. To serve the needs of that demographic, the company is pioneering a managed software market similar in some ways to the video game console business. 
While today’s video games commonly ship bound to optical media--following the model for selling music on CDs--Apple's innovative step forward for iPhone software will parallel the company’s introduction of online music using fair DRM as an alternative to music on CDs.
Online software for the iPhone, available in iTunes, will be reasonably cheap, digitally signed, diverse, and supported as part of a stable and tested environment.
Apple isn’t throwing the doors wide open, but will no doubt offer the majority of software users could want. For those who aren’t happy with Apple’s product, competitors will rush in to sell them different products. Even Apple haters should be hailing the iPhone for pushing the industry to innovate.
It's hard to imagine that Apple's every step will not be criticized by the same people who insisted that the Mac was dead, the iPod would never go anywhere, and that Apple's online music and media sales would never fly (or have already collapsed). I'm betting against naysayers on the iPhone software front, too.
Next Articles:
This Series
|
|
Del.icio.us |
Technorati |
About RDM :
:
Send Link
Reddit
NewsTrust
Sunday, January 14, 2007
