Dave Smith, of Wires are Obsolete, is an Android and iOS application developer with his own take on how Apple closed the gap between available features in Android and iOS with the release of iOS 5. But there are six key areas where he believes Android has an advantage over Apple in terms of how developers create applications for the mobile operating systems, and he described how Apple has made some changes to help developers in the iOS 5 release.

1. More software categories
Android Market allows developers to distribute (and monetize) more than just traditional apps. Live wallpapers, home-screen widgets, and tools to customize the look and feel of the device are some of the most popular downloads in Android Market today. In fact, these are the types of products on Android Market that often make developers the most money.

Has Apple helped with this in iOS 5?
None of these opportunities exist on iOS at the current time, and iOS 5 hasn’t really expanded the SDK to encompass this. Unfortunately, home-screen widgets and the new iOS notification system aren’t equivalent because I as a developer cannot write software to create a custom widget to live in the iOS 5 notification bar.

I just don’t see device customization as a priority for Apple; it’s not part of their brand. I wouldn’t expect to see them add abilities for developers to write customization software anytime soon. There’s a core value difference here between Apple and Google.

2. Android is open source
This one always gets lots of fun debate going, but after developing on both platforms for a few years, I can tell you there has been more than one occasion where something isn’t working right and I’ve wanted to go beyond the documentation to see how they implemented a certain object in the SDK.

With Android, I can go straight to the public source code and see exactly how it was implemented. Then, if I need to create something custom, I can almost always use that code as a starting point. The Android documentation even links directly to the source code for every class in the SDK, so it’s not even hard to find what you need in the source—you don’t have to search the entire tree.

Has Apple helped with this in iOS 5?
iOS will never be open source.

#!
3. Background services
On the Android platform, developers can create full background-service implementations that are unrestricted by the framework. This can often spark pushback from users claiming that this unrestricted access causes poor performance on their devices, but with proper implementation, background services greatly enhance the user experience by allowing them to do long-running operations without having to keep the application open.

A perfect example of how I use this regularly is in uploading or downloading large data sets such as an album or set of videos from a server. With background services, I can let the user upload a large image they have just created within my application, a process that may take a very long time, with nothing more than a status-bar notification of progress. They can leave the app, go browse the Web, or even lock the device, and the operation can still run to completion.  

For downloading large data, we can kick off that download in the background and the user can return later when the interesting content is available. While we have had background processing since iOS 4, it is always time-limited. Once a background operation is allowed to execute, it must complete within roughly 10 minutes, unless it is a special operation like audio playback or VoIP. The same upload/download cases would require the user to keep the app open, and maybe even the screen on, or implement a complex pause/resume scheme to keep the operation in sync with the user getting bored.

Has Apple helped with this in iOS 5?
Apple has not made any significant changes to the way applications can behave in the background in iOS 5. Applications are still subject to term limits.

4. Resource Scaling
Born out of the need to support multiple devices with various screen sizes, Android includes a resource framework that is unparalleled on other mobile platforms. Despite how developers may feel about having to support multiple devices, the resource framework also provides the benefit of allowing an application to completely reconfigure its look and feel for portrait, landscape, phone, tablet, or any other configuration change without a single line of code in the application.

All the developer need do is place the appropriate resource files into configuration directories, and the framework does the rest. A significant benefit of the Android resource framework is that it enables the creation of repeatable custom styles, themes and widgets that allow the user interface to lose that “stock” appearance and become something more interesting.

Has Apple helped with this in iOS 5?
This is one area where Apple has stepped up. Prior to iOS 5, accomplishing custom looks on much of the UI toolkit was painful and caused developers to resort to doing things they knew they shouldn’t. iOS 5 brings a series of new tools to make UIs more customizable and, in my opinion, bring it more in line with Android’s capabilities.

#!
5. Accessories
While Android devices may not have a unified connector architecture, such as the iPod’s 30-pin connector, Android provides APIs that can be used by any developer with a device and a copy of the SDK. Apple requires membership in the Made for iPod (MFi) Accessory program before a developer can build accessory devices and use the corresponding iOS APIs.

As a member of that program, I can tell you that, even though it costs nothing, it provides a huge administrative barrier to small developers wanting to make accessories for Apple devices. In addition, developers can freely use the Bluetooth APIs in Android to write applications that directly communicate with other Bluetooth-enabled hardware (or another Android phone). This is something that is also allowed only for MFi members in the Apple camp. This also includes the near field communication RFID variant, which is still new to Android, but is not confirmed at all to be expected in iOS devices anytime soon.

Has Apple helped with this in iOS 5?
In the accessory game, the barriers to entry are primarily with Apple’s MFi program. Developers can’t just purchase some development hardware and start engineering without permission from Apple to build the device and access the specs of the software protocols. Again, the release of iOS 5 does not really lower the barrier for developers in this regard.

6. Portability
This one is a bit specific to my industry, but it has to do with the fact that iOS will never live outside of an Apple device. It cannot easily be ported to other machines, dropping it off the list as a viable operating system in the embedded world.

Android, conversely, has been ported to many major embedded computer systems such as the OMAP3530 CPU line. In addition, Android’s modular construction makes it ideal for building touch-enabled embedded devices. Being open source, Android can be compiled without all the default applications you don’t need in your system, allowing it to fit in very memory-constrained environments. Android’s customization ability also allows developers to write applications that replace the functionality of any major system component, including the home screen.

Just as developers can write custom launchers and sell them in Android Market, we can write custom home-screen applications that completely remove the “Android” look and feel from an embedded device, and turn it into anything we choose.

Has Apple helped with this in iOS 5?
This goes along with the iOS source code, or even a variant, being likely to remain closed. In order to port iOS into the embedded world, Apple would have to take on that task themselves (which is not their business and I don’t blame them for that), or release the source to someone else willing to take on the task. This is another fundamental decision affected by the company more than by the tools available in the SDK.

Dave Smith specializes in integrating applications on Android and iOS with other custom or embedded hardware components to create integrated systems. Dave is the coauthor of “Android Recipes: A Problem-Solution Approach.” He regularly communicates via his development blog and is available on Twitter as @devunwired.