From iOS to Android: Setting Expectations

Written by Michael Kryzhanovsky
Published on Jul. 23, 2013

Imagine you have a great iOS team and an app, but no Android developers. If you can’t find anyone with relevant experience consider hiring Java developers. Android's main language is Java and it inherited a lot of best practices from SWT (Standard Widget ToolKit), so experienced Java developers are quite fast to pick up the technology.

 

The development environment can be downloaded from the developers portal (http://developer.android.com/sdk/index.html). The SDK comes with Eclipse and all tools needed to build a project. However, you don't have to use Eclipse, IntelliJ Idea works just as well, but you might need to spend some time configuring your environment. We tend to compile our projects under Eclipse with Maven Build Manager. On the development portal you'll find references to the Ant for making your builds, but we prefer Maven, as it's a powerful 'build system', rather than just a build tool.

 

Comparing iOS and Android API's, you may find a lot of commonality in class names, but that's where the similarity ends. Android's app architecture and principles are different (check out this article for more info http://developer.android.com/guide/components/fundamentals.html)

 

An iOS developer may envy Android’s release procedure. Actually, there is none. You just compile your package, upload it to the Playstore, and voila - within a couple hours your build is available to your clients. No verification, no waiting. Made a mistake? Fix it immediately. You can even make several builds available simultaneously, so users may choose more stable builds over new ones.

 

How iOS & Android Environments Differ

 

Being an iOS developer, you can get used to the predictability of how your apps work for your clients. Indeed, all iOS devices are made by the same company, following the same design and manufacturing standards. While the operating system gradually evolves from version to version, even serious changes can be easily walked around after some debugging and tuning. Most users migrate to the newest OS quickly, and typically upgrade their devices every 1-2 years.

 

Not so on Android.

 

In general, Android has 3 variables affecting the stability of your app:

 

        1) Phone model

        2) Hardware revision

        3) OS version

 

Let's consider them one by one.

 

1) Unlike iOS, Android devices are made by different manufacturers. Android OS is Linux based, so it's capable of running on almost any hardware. Thus, every manufacturer comes up with their own flavor of Android OS, which takes into account the unique specifics of their hardware. Yes, this means every Android phone or tablet is "slightly" different from another. In fact,  there are 2600+ different devices officially listed in the Playstore. So the variety of solutions is HUGE. To make things worse, two devices made by the same company may work differently because of differences in the hardware. For instance, Samsung's Galaxy Tab 2 (tablet) and SIII (phone) have a lot of differences on the OS level, which causes differences in the browser app (different webkit versions), camera app, keyboards, UI elements, etc. And that's saying nothing about devices made by different manufacturers.

 

2) Working with two phones of the same model and OS version, we noticed that our app crashed on attempts to access the camera. Digging down we realized that one device was much older than the other. We opened up the phones and noticed that some of the hardware components had different revisions. Thus, we suspect that the phones had different driver versions, causing variances in camera performance.

 

3) Finally about the OS. Android users tend to stay with older versions, rather than upgrade (seehttp://developer.android.com/about/dashboards/index.html). As you may notice, 40% of the users are still sitting on the system released about 3 years ago. Why? The explanation is quite simple - unlike iOS devices, Androids are made by fiercely competing companies. Each of them make their own flavor of the system, so only they can push an upgrade. Why would they encourage upgrading the OS on old phones when they can sell a new phone with the new system? This strategy brings in more revenue.

 

However, it really limits the developers in what API's they can use. Some of the developers choose to go with newer API's and offer backward compatible, but limited solutions for older devices. Understanding the problem, the dev portal offers developers advice on how to walk it around (http://developer.android.com/training/backward-compatible-ui/index.html).

 

This complexity inevitably raises a concern: How can I make sure my app works for my customers?

 

There are two answers:

 

        1) Use as many standard components as you can. E.g. if you need a camera, call a standard camera app as an activity and take the results from it.

 

        2) Test. A fair question would be test against what? All 2600+ devices? Of course, this is not possible.

 

We solve this problem by studying our customer base first. If you have a website, check with Google Analytics to see what Android devices are visiting it. The information will not be precise, but will give you a sense of what is going on there. Check the statistics for similar apps, if you can (for instance http://www.appbrain.com/stats/top-android-phones). Obviously, you have to use real hardware for testing. If your company provides phones for employees - buy different models and test against them. You can also find some phones on the second hand market.

 

There are companies offering real hardware for testing through their remote access tools, like  DeviceAnywhere (http://www.keynotedeviceanywhere.com/) or PerfectoMobile (http://www.perfectomobile.com/portal/cms/services/android). Though, at ~$20/h + $100 a month their prices may be not that affordable.

 

Finally, An Obvious Question:

 

Can I lower my dev expenses by using a cross platform solution? The short answer: mostly no, but it depends on your app. There are solutions like Phonegap (http://phonegap.com/), which can solve the double effort problem, but with them you lose the look and feel of a native app. In fact, we found it more effective porting iOS applications to Android, rather than using cross platform solutions.

 

Michael Kryzhanovsky is a VP of Product Development at Engineerus. Engineerus ( http://engineerus.com/) focuses on providing outstanding software products for their clients.

Hiring Now
McDonald's Global Technology
eCommerce • Food • Information Technology • Mobile