Why developers should build on iOS before heading to Android

Paul Gaubil is the chief executive and co-founder of Sensopia, the maker of home improvement app MagicPlan.

Recently, there has been much debate as to whether developers are better served beginning mobile software production iOS- or Android-first.

[aditude-amp id="flyingcarpet" targeting='{"env":"staging","page_type":"article","post_id":837006,"post_type":"guest","post_chan":"none","tags":null,"ai":false,"category":"none","all_categories":"business,dev,mobile,","session":"C"}']

While this may be different for each developer, and certainly there are good reasons for each approach depending upon specific circumstances, we at Sensopia chose an iOS-first approach for the development of MagicPlan. We are now releasing our software on Android, after having developed and iterated on iOS for a while. Our software is unique in a number of ways, and may offer some insights into the current debate among developers, or at least illustrate some of the deeper concerns when choosing between the two platforms.

In our case, the decision was made easier than for most, as Apple was the first OEM to release a mainstream device equipped with a gyroscope, (the iPhone 4) which is essential for our application.

MagicPlan is an application that captures the shape and the dimensions of rooms to create comprehensive, accurately-measured floor plans. This capture process leverages every available sensor in a mobile device (the accelerometer, the gyroscope, and the camera) to do this without the need for drawing or measuring tools. In our case, supporting each new device requires more than simply developing a new interface — it requires understanding the total hardware combination and interpreting output data correctly. For this reason, complexity of development scales proportionately to the diversity of hardware.

To reduce complexity and more quickly create software that was usable and useful, development began and continued exclusively on iOS for a couple of years. Rather than supporting an ever-changing list of devices from competing OEMs (and mobile operator exclusives) that had huge variances in hardware and sensor calibration, we were able to bring a stable and useful product to market quickly by focusing our attention on Apple’s more cohesive product line. We were then able to concentrate on iteration and incremental improvements in our product to meet market demand. Only after reaching a certain level of maturity did Android development become a realistic possibility for us.

After two years on iOS, more than five million downloads, and users creating more than 20,000 floor plans each day, Android became a “must have” for us.

In order to begin, we had to do some basic analysis of the hardware and devices available for Android in order to determine compatibility and feasibility of development for them. There were, at that time, 11,865 unique devices running some form of Android OS. Reaching approximately 50 percent of the active market required supporting 86 of those, while reaching 80 percent required support for 509 unique devices. While Samsung is far and away the leading manufacturer of Android devices, flagship models such as the S3 comprise only six percent of the total installed Android base, while the S2 takes 3.9 percent. This year’s model, the S4, has about 1.5 percent of total market share. Now, these numbers and the metrics behind them can be debated (our source is androidfragmentation.com) but the basic issue of hardware diversity and “fragmentation” was clearly troubling for development of an application like ours.

Our first decision was to restructure and refactor code as much as possible into a common software development kit (SDK) platform, all written in C++, and subsequently design a unified multi-sensor and multi-threaded architecture compatible with both Android and iOS. This allowed us to validate all critical sensor processing code on one platform and easily port to another, as well as to provide SDK integration options for a range of partnerships.

Secondly, we quickly realized that we had to abandon the idea of individual device calibration and certification, as the multitudinous combinations of different hardware would make this a too-costly exercise to complete on our own.

[aditude-amp id="medium1" targeting='{"env":"staging","page_type":"article","post_id":837006,"post_type":"guest","post_chan":"none","tags":null,"ai":false,"category":"none","all_categories":"business,dev,mobile,","session":"C"}']

We instead went to the Android community and those people who had informed us of their eagerness for an Android version of our application. Our development team went to work on a piece of software that could be installed on our volunteers’ devices and send sensor and calibration data back to us. This was so that we could better understand the different variations out in the wild.

We consider ourselves very fortunate to have such a loyal and eager community that we would be able to count on them in such a way. This experience, in and of itself, highlights two of the primary strengths as well as perhaps the greatest weakness in the Android platform. As previously mentioned, we were helped immeasurably by the community of individuals with Android devices willing to help us alpha- and beta-test our software; this and the ability to run beta testing either through the Google Play Store or via self-installation make the refinement and information gathering phases of app development extremely pleasant for us as developers. Neither of these things is available in the same way for iOS. However, the hardware fragmentation that made this step even necessary strikes quite the opposite note.

In our case, it is sincerely doubtful that a large enough group would have been willing to help us out with the fragmentation issue had we not begun on iOS and had a working, legitimate product. “Fragmentation” on Android tends to be mentioned almost exclusively with respect to versions of the OS or the (usually horrible) custom OEM skins/features. These certainly did become an issue, such as when we found some manufacturers who had included a gyroscope in a device (and spec sheet), but had not enabled it in their software.

In our case, though, the fragmentation and diversity of hardware was our largest challenge. We could not allow our software to run on devices we had not tested and certified, since the result of un-calibrated sensor fusion would do our customers a disservice and reflect poorly on our company and product.

[aditude-amp id="medium2" targeting='{"env":"staging","page_type":"article","post_id":837006,"post_type":"guest","post_chan":"none","tags":null,"ai":false,"category":"none","all_categories":"business,dev,mobile,","session":"C"}']

This is a tough issue to reconcile, since Google counts on the competition amongst OEMs to make great and differentiated hardware in order to advance the platform in new and exciting ways. The thinking is that the platform is improved by competition, and competition is improved with a larger number of competitors. Interesting hardware innovations come out of the desire to differentiate, which is usually a good thing for consumers.

This does, of course, make any development of professional or hardware-intensive applications (i.e.: games) much more of a challenge. And it all but ensures that these types of software will begin first on iOS, in order to test their popularity and commercial viability on a simpler-to-develop-for platform, before porting to Android.

As for MagicPlan, we were able to use this strategy successfully, and after nine months of development work and “social testing” by our intrepid followers, our Android release is now ready for prime time.