Development effort Q&A: native Android versus iOS app
Q) What is the relative effort to develop a native app for Android versus iOS?
A) It depends on how proficient the developer is and what she’s told to do.
Some developers maintain that Android work tends to take about 20% longer than equivalent iOS functionality. Other voices maintain the opposite: that Android development—not to mention code submission—can progress much more quickly than iOS. I’d say it depends:
- on the requirements specified by those directing (and usually paying for) the effort
- on how the requirements are adapted to fit the mobile platform
Typically, a client will design an iPhone or iPad app and then dictate that the Android ports should look exactly or as much as possible like they do on iOS. UX mobile design tools (and designers) tend to propagate this trend. A small project may be most efficiently coded by a single developer, while a large project on a tight timeline may demand the collaboration of two or more specialists.
Trying to exactly match Android to iOS is probably a bad idea, because it violates common Android design guidelines like where to place tabs. Fighting against Android’s UI standards will increase the development cost.
Q) Can iOS and Android apps ever look and feel identical? Should they, even if they can?
A) No and no.
Suppose an iOS and Android app are written by the same bilingual (Java, Swift) developer from identical graphic design comps. An Android developer whose client dictates: “make it look like iOS” needs us to man-up like Monty Python’s King Arthur:
Bridgekeeper: What… is your favourite colour?
Sir Galahad: Blue-no! [he is also thrown over the edge] YEELLLLLLLLLLLLOOOOOOOOWWWWWWWW!
Bridgekeeper: [Chuckling at Galahad’s demise, then turns to Arthur] Stop. What… is your name?
King Arthur: It is ‘Arthur’, King of the Britons.
Bridgekeeper: What… is your quest?
King Arthur: To seek the Holy Grail.
Bridgekeeper: What… is the air-speed velocity of an unladen swallow?
King Arthur: What do you mean?An African or a European swallow?
Bridgekeeper: Huh? I… I don’t know that. [he is thrown over by his own spell] AUUUUUUUGGGGGGGGGGGHHH!!
Sir Bedevere: How do you know so much about swallows?
King Arthur: Well, you have to know these things when you’re a king, you know.
Recently, a client stipulated that their Android app display the iOS “Loading…” wheel-of-death. My gut reaction was to sigh and forbode the tedium of crafting a pixel-perfect replica of the much-hated spinning symbol of anti-progress. Then, I heard the wise whispers of the Lady of the Lake:
King Arthur: What do you mean? Shall I add the “Loading…” label to the lovely, blue Android toilet-swish ProgressBar? Should it be above, below, or centred in the bowl?
Q) Is Android Studio an inferior tool to Xcode? Are iOS APIs easier to use than their Android equivalents?
A) Yes and no.
While I personally find Android Studio far more intuitive than the feature-rich Xcode 7, iOS has pretty nifty built-in components for a developer to leverage. Even though iPhone screen sizes have multiplied, recent versions of Xcode provide impressive support for responsive designs, whereas Android Studio’s approach is more reminiscent of CSS’ box model and comes with the cost of supporting (and testing) many more device types.
Although the Android SDK supports many of the same features as iOS, the highly-modular Android SDK demands fine-grained choices and configuration. In other words, Android’s greater creative license comes with greater development effort to match iOS feature-for-feature. , Third-party library support is strong for both environments, but Apple’s hardware and software support models are far more dictatorial than Google’s, and iOS libraries are feature-restricted against munging system behavior where the Android default can (and often must) be overridden.
The iOS Media Player framework, for instance, while restrictive in terms of content type, is feature-rich & slick next to Android’s MediaPlayer, a quick & dirty default. The iOS player has standard controls as well as baked-in support for rotation and immersive full-screen mode. Android devs had to roll their own buttons and events until API 16, when the pre-built but still customizable ExoPlayer appeared.
Q) Is it harder to write a universally-responsive Android app because of the variety of devices available? Is the iOS platform more stable?
A) Yes and no.
Automated mobile testing suites like AWS Device Farm and Google Play Cloud Test Lab are levelling the playing field, but in most cases, the limited hardware and software versions of iOS are naturally easier to predict and support than the myriad Android phablets and sugar-coated Android APIs.
Android has the reputation of being less stable than iOS, largely because slow garbage-collection with minimal RAM leads to frequent memory-related crashes. However, iOS is certainly not immune to memory-related crashes; try accessing your Core Data from a ManagedObjectContext on the wrong thread.
The Java-based Android OS may have an ironic leg-up on iOS simply by being newer. Large or complex apps originally written in Objective-C for iOS 7 or earlier will need to be heavily refactored or rewritten to take advantage of software and hardware advances. It will be interesting to see how Swift may swing that balance.
