Cameron Henneke, founder and developer of GQueues, an online task manager integrated with several Google services, has ported the HTML5 mobile version of his application to iOS and Android, keeping a record of the development effort involved on both platforms and comparing the outcome in a blog post. Following is a digest of Henneke’s findings and excerpts from an interview conducted by InfoQ.
Previous Experience
Although he has over 12 years of experience in software development, Henneke told us that he had little or no previous experience with iOS and Android, placing both platforms on equal footing from his perspective:
I was an absolute beginner on Android when I started developing the app - I had not even installed the SDK on my computer before starting the project. I was pretty much a novice on iOS as well. I had created two basic iPhone games back in 2010, but they weren't nearly as complex as the GQueues app, and used a completely different set of APIs. I hadn't touched iOS development since then until I started the GQueues project this past March.
Development
Android
- 1 week for reading books, watching tutorials, and creating test applications
- 1 week for the initial design phase
- Starting actual coding which took him about 870 hours
iOS
- 2 learning weeks mostly spent getting accustomed with the Core Data APIs, using PersistentStoreCoordinators and ManagedObjectContexts, and developing a “scalable architecture for the FetchedResultsControllers”
- Another 2 weeks before he was “was comfortably coding on iOS”
Overall, Henneke said he spent double time on the learning curve for iOS compared to Android.
Regarding learning material, Henneke found Android documentation being of “much higher” quality than iOS’. The open source status of Android also helped, enabling him to look at the code and learn from it. Regarding iOS documentation, he remarked:
While there is a proliferation of iOS documentation, much of it has become outdated with the significant changes made in iOS 5 and 6, including the introduction of Automatic Reference Counting (ARC). Thus, many code samples (including Apple's official samples) and ways to approach problems are inaccurate and should actually be ignored in favor of newer methods. Sifting through it all just took more time.
Although Android development included a complete rewrite of the “syncing code for the backend servers that was previously used with the HTML5 mobile web app,” Henneke needed approximately 10% less time for writing the same application for Android compared to iOS. The overall development statistics are depicted in the next table:
Android
iOS
Start Date
Sept 21, 2012
Mar 2, 2013
Beta Ready for Testing
Dec 22, 2012
June 10, 2013
App Published
Jan 31, 2013
July 18, 2013
Total Project Time
4.25 months
4.5 months
Ramp Up Time
1 week
2 weeks
Development Time
870 hours (approx)
960 hours (approx)
Beta Testing & Fixing
34 days
38 days
Number of Beta Testers
92 people
48 people
Lines of Code
26,981 lines
23,872 lines
App Download Size
1.1 MB
3.5 MB
Tools
While personally preferring Vim, Henneke remarked the following regarding some of the tools he used for this project:
- “Search in Eclipse is ridiculously slow and cumbersome. “
- “Documentation search in XCode Organizer is infuriatingly sluggish.” He later discovered how to speed up search.
- “Filtering by log tags in Eclipse (with the logcat integration in the Android plugin) is super useful.”
- “Code completion is really good in both IDEs. “
- “Interface Builder in Xcode is useless.”
- XCode Instruments are “extremely useful in profiling, measuring and debugging.”
- “Android emulators are a complete waste of time (it's really a joke how slow they are). In my development cycle I always deployed to real Android devices for testing - it was much quicker.”
- The iOS Simulator is “very fast and made the dev cycle much more efficient. For each new piece of code I would start my testing with the simulator and only switch to device testing once it was more fully formed.”
- “With Android I had test devices on each version of Android the app supported (except Gingerbread), and then relied heavily on my beta testers to get decent device coverage later.”
- For iOS he used the “oldest and newest devices supported for testing.”
App Design
Henneke planned to design his application to layout easily on various screen sizes, discovering that the Android platform has “mature components to help developers support the variety of dimensions.” He used RelativeLayouts, noticing that “all layouts are specified in XML, which is actually a very clean, simple and efficient way to design screens - a feature I only fully appreciated after creating layouts in iOS.”
In this context, we asked Henneke what he thinks regarding Android fragmentation:
I think Android fragmentation is over-hyped. Does it exist? Most certainly, that's a fact. Is it necessarily a bad aspect of developing on Android? Not really. Google and the Android community have taken many approaches to meet this challenge and it's working. The official Support Library is fairly comprehensive and still growing. ActionBarSherlock is a powerful third-party library to bring new features to old devices. Plus, Google's recent introduction of Google Play Services takes carriers out of the fragmentation equation. Users no longer have to rely on their carriers to push out the latest version of Android to get access to the newest features. This is a huge step forward for both Android users and developers.
Interestingly enough, Henneke’s experience with layout on iOS was not so great:
Auto Layout, Apple's analog to RelativeLayouts, is quite new (introduced in iOS 6) and its integration with Interface Builder (IB) is horrendous. I spent days fighting Auto Layout in IB, as has every iOS 6 developer, building precise constraints for views only to have IB completely change all my specifications because of its "smart" system to constantly maintain unambiguous layouts. I learned all the tips and tricks to deal with this fragile part of IB to no avail. I finally ended the pain by taking all layouts out of IB and simple wrote them long-hand with pages of boiler-plate code. If you avoid IB and Apple's geeked-out ASCII art style of layout coding, the implementation of Auto Layout is actually very powerful and straightforward to use. Supposedly Apple has improved much of this with iOS 7, but I have yet to test it out.
Using Auto Layout limited him to develop only for iOS 6 (iPhone 4 and 5), and not earlier, as he told us:
The GQueues app actually cannot be installed or run on older iDevices, which is why I didn't test against them. Whenever you develop a mobile app, an initial step is deciding which versions of the OS you are going to support. iOS 6 introduced a new feature called Auto Layout which was a huge improvement over the old layout techniques, but of course it only worked on devices running the latest version of the OS. I decided that instead of creating layouts using both the old deprecated struts method and Auto Layout, I would only use Auto Layout, which would drastically reduce development time. This of course meant the GQueues app would only work on devices that could run iOS 6, but that actually includes all iDevices purchased in the last two years. I figured anyone with a phone over two years old would probably upgrade soon anyway, so I wasn't really limiting my market that much.
Other design conclusions were:
- “Supporting device rotation on Android takes a huge amount a work and is the source of many bugs.”
- “With Android, when you rotate a device it essentially terminates the entire stack of views and recreates each one when rotation completes. So to support rotation with the GQueues app I needed to ensure the current state of everything could be properly saved at anytime and restored on resume.”
- “[For rotation] iOS requires just a pinch of effort while the platform does the rest.”
- “With iOS, the platform manages almost all rotation concerns for you.”
- Both Android and iOS need extra code to simulate a Flow Layout.
Regarding beta testing and publishing, Henneke remarked:
- “On-boarding Android testers was as easy as posting a link to an APK which they could download to their device.”
- “Google has made it even easier now to test apps with real users by supporting alpha and beta versions in the Developers Console and staged rollouts.”
- “iOS beta testing was much harder, despite using the service TestFlight, which does simplify the process a great deal. In keeping with Apple's insatiable appetite for control, the UDID of every device used for testing must be added to the certificate used to sign the beta version of the app. Consequently, every time I needed to add beta testers, whether a single person or a new cohort, I had to create and distribute a new build of the app. On top of that, Apple limits you to 100 registered test devices per year, so I had to carefully allocate my spots, which is the reason I had half as many iOS testers as Android.”
- “Posting the GQueues app on Google Play was a real joy. I was able to launch the app as soon as I decided it was ready. I clicked the button and within 30 minutes it was available on Google Play worldwide and customers were installing it on their devices.”
- “Publishing on the App Store, as almost every iOS developer can attest, is a demoralizing experience. After months of intense, rigorous coding, I was forced to submit my creation to Apple and wait 7 days at which point the reviewer spent 2 minutes looking at the app before giving the almost obligatory initial rejection. I then spent a day making required changes and submitted again so I could wait another 8 days before finally getting approved.”
Henneke also made a series of notes on using data storage and management, search, regular expressions, paging, voice input, sharing and widgets, on both platforms, and can be found on his blog post.
As a conclusion, Henneke does not consider one platform being better than other, each having “areas where they are really strong and mature, and other aspects that definitely need some improvement.”
We also asked Henneke what features he would like to see in iOS and Android:
On iOS I would love to see an API for SIRI or at least speech recognition. On Android allowing some deeper integrations with Google Now would be really cool.
And last but not least, we asked Henneke why he switched from HTML5 in the first place. In his experience, HTML5 is not there yet:
Since I was such a public proponent of HTML5 before, I actually wrote a blog post explaining my drastic change in strategy to build native apps. In short, HTML5 has yet to provide the features and speed necessary to make it a competitive alternative to native apps. Plus, for better or worse, people love downloading apps from marketplaces. GQueues customers were demanding native apps, so I set out to fulfill the need.
Since this post reflects only one person’s experience developing an application for both Android and iOS, it cannot be generalized to draw final conclusions regarding development on the respective platforms, especially which is better/worse. Nonetheless, many of Henneke’s remarks are valid, expressing some of the joys and sorrows accompanying mobile development on the two most popular platforms.
