ArsTechnica has a very good (though high-level) look at developing for the Android phone. What interested me most was drawing comparisons.


  • Google created their own implementation of Java (Dalvik). The only way to deploy an app on the phone is to code it in Java.
  • The Dalvik engine is slower then normal Java (it’s optimized for small memory devices). Like Java, developers don’t have to worry about dealing with memory or pointers. Many developers have experience with Java.
  • The development environment for Android is Eclipse. But the tooling is still immature. GUI development requires editing XML files by hand to describe interface elements.
  • The Android platform is completely different from any other platform on the planet. It’s Linux but the run-time elements are different - different C library, different command-line utilities.
  • Android is very open. Most of the user-level code is licensed as ASL. The app market is very open. You can run processes in the background.


  • Apple used Objective-C. That’s the “official” language of the phone. In reality, anything that can compile to the processor on the phone and interface with C and Objective-C libraries can be used.
  • Objective-C is a compiled language. It’s also C. You can write slow, dynamic code or fast, compiled code. Developers choice. It is a “weird” language. Personally, I hate the syntax. On the iPhone the memory management has been intentionally disabled. Developers have to track pointers and release memory.
  • The development environment for iPhone is Xcode. That’s both good and bad. Xcode (like Objective-C) is a different animal. But it offers some interesting benefits. Interface Builder is really, really good and let’s you build and prototype your interface without touching code.
  • The iPhone is running macOS. That’s hard for most people to believe but it’s no joke. The phone is really, truly running macOS. Mac developers had a massive leg up on initial iPhone development.
  • The iPhone is locked down. Apple signs off on all apps before they can be released to the public. They impose arbitrary restrictions - no processes in the background.

Android was designed by engineers and polished by the marketers. iPhone was designed by marketers and implemented by engineers. The technology is the “easiest” part of the mobile devices. Getting the user experience correct is harder because its difficult to define.

It’s easy to see the iPhone roadmap. Apple is clearly positioning it as an extension of the desktop. Technologies are flowing in both directions. As Apple gets more comfortable with the real-world performance of their choices they’ll start loosening restrictions, adding background notifications and bluetooth access.

Android is a little murkier. They decided that the tradeoffs Apple was making weren’t worth it. All of the iPhone restrictions to conserve battery power were ignored. And the Android has lousy battery life as a result. The question is how (or if) they’ll pull back. Users have to accept permission requests from Android apps. On the iPhone it only asks if the app can get access to your current location. Will Google have a “safe” library of apps and an “open” library of apps? That’s why it’s harder to predict the Android development path.