ronin coder

Since the Android phone announcement on Tuesday, there has been a decent amount of wild speculation going around the ‘tubes about the differences in “developer experience” between the iPhone and Android platforms. While my opinions on Apple’s legal and business restrictions on iPhone developers are pretty clear, I haven’t really written much about the technical underpinnings.

Generally, both platforms mostly abstract away the underlying UNIX-y system, and heavily sandbox 3rd-party applications to limit their ability to corrupt or expose the user’s data. Android gives users more options to replace or augment core applications, but the underlying sandbox mechanisms remain in place — i.e., an app can’t access your contact list unless you explicitly grant it that privilege at install time.

Also, both platforms rely heavily on code signing. You can’t distribute an iPhone app through the App Store unless it’s been signed with an Apple-issued certificate; The Android OS, on the other hand, allows developers to use the certificate of their choice to sign apps. (Carriers could lock this down further, of course, but there’s been no indication that such a lock will be in place for the G1.)

In terms of the actual toolchain, there are some major differences. While the iPhone uses a simple cross-compiler to build Objective-C projects, the Android tools are designed to support compilation to VM bytecodes, which are then transferred to the mobile device and JIT-ed in place. The XCode/Eclipse distinction is really one of personal preference, and both systems provide first-class support for command-line compilation and packaging, so you could configure Emacs/Vim/TextMate/etc. to handle project build tasks.

I also have the sense (and this is where my lack of access to the full iPhone SDK becomes a problem) that that the iPhone tends to package shared services as Framework libraries (ala OS X) while Android relies on a high-level IPC framework and reusable sub-processes (called Activities) to allow applications to invoke each other to perform common tasks.

Of course, one of the biggest distinctions to my mind is that Android projects can make use of multithreading and background daemons (Services in Android-speak) to handle long-running and GUI-less tasks. The notification APIs provided in the iPhone may cover a lot of asynchronous messaging use cases, but having full use of threads opens  up a lot of other interesting possibilities.

Overall, both platforms offer an interesting environment to work with. iPhone apps are likely to be less inter-dependent, with better protections against any one badly-authored app causing the phone’s performance or battery life to suffer. However, iPhone developers will struggle much more than their Android-targeting-colleagues to find ways to integrate their applications, both due to their inability to coordinate between simultaneously-running threads, and due the the NDA’s restrictions on information-sharing amongst themselves.