As a developer we want to be able to produce nice maintainable code, ideally a single code base and deploy that on as many platforms as possible. While on the desktop this is pretty simple, come to the world of mobile and well, things get more complicated, with Android I would say a mess really.
Things to consider
I don’t want to talk about cross platform development etc. rather there are a few blogs I’ve written on this subject already (see Cross Platform Mobile Development – CloudZync blog, and one of my recent blog posts, Cross Platform mobile app) , so for the point of this post, we will presume that you are going to build a native app with a technology like Xamarin (Monotouch). So what challenges are there then to build an app that works on multiple platforms?
Well first off what platforms are supported? At the moment, that’s limited to iOS, Windows Phone and Android devices (no Blackberry in there at all – though I hope this changes if Blackberry 10 starts getting some form of traction in the consumer market). For each of these operating systems we still need to take into consideration the actual platform style, there is no point in trying to deliver a Windows Phone type app to an iOS device as it simply won’t work (they don’t share the same controls and the look and feel would be a very jarring experience). You may be thinking that that means you still need to maintain separate code bases, even with our cross platform technology, but you would be wrong.
The beauty of C# and the whole Microsoft development environment is the way you can structure applications. If you are familiar with MVVM then you will understand my point. MVVM (Model View ViewModel) allows a developer to separate concerns within the application, to be very basic, it means we can separate out the UI elements from the actual working code. (Have a read here if you want to undertand MVVM) So we can maintain a single code base in essence for the app across the multiple platforms even if we change and modify the UI.
Fragmentation
This is the point of this article, while we have to do different things for different operating systems, we have to do different things still for the same operating systems even, well in the case of Android quite a lot different.
With Windows Phone and iOS, life is pretty easy, the only real issues relate to image sizes, so you have to package up a couple of different size options for icon images (which can be a pain). With iOS you do have to consider if you are deploying to an iPhone 5 as opposed to an earlier device, due to the screen sizes. For example, in the CloudZync Zync Terminal app (an app that allows merchants to raise and process mobile transactions), on an iPhone 4, we had to place a “done” button into the keyboard in order to hide it and show the rest of the screen, in the iPhone 5 this wasn’t needed as the screen was longer and we didn’t need to hide the keyboard (something that only really got spotted in testing).
So while doing these few extra things can be a pain, they are all pretty small. Then we look at Android, and this is when things get a little harder and a pain to be honest.
Android not only has a fair few flavours on the market, it also has a number of issues with the types of devices it can be found on. So while we are packaging up 2 versions of an image for iOS, on Android we find we could be packaging as many as 10! That’s a real pain to say the least, but not a real head scratcher.
The real problems arise when we look at the different flavours of Android and how they act. When testing apps across different Android flavours we notice we get different experiences. What is really frustrating is how different those experiences can be and what that means in terms of coding and testing. But things get worse still. For example we looked at developing our Zync Terminal App for Android and looked at a few different Samsung Galaxy devices. All consistent you would think, but nope, they aren’t. On top of that we noticed we had to use different API calls on different phones to access different parts of the device, such as the camera. That becomes so frustrating, not to mention time consuming in terms of development, but also in terms of testing, and time consumption means expensive.
Let me give you a little interesting point about our development, it seems that the cost of building and testing our app on iOS and Windows Phone together was about the same as the cost associated with just building for the major Android devices (so that’s us cutting corners and not supporting a lot of Android devices officially). To me, that can’t be right and is not a good place for Android. I can build an app for two very distinctly different operating systems with completely different experiences for the same price I can build an app for a single platform, Android…
Technically I’m not being fair, as this article suggests I’m looking at Fragmentation, so I’m actually developing for 3 versions of Android and umpteen Android based devices – as opposed to two operating systems in iOS and Windows Phone.
Conclusion
I want to maintain as much code with a common base, and we use Xamarin to deliver our apps on Android. The sad fact is that it doesn’t make much business sense to support all of the Android flavours or devices. The fragmentation issue just makes it too expensive to really develop for all Android variations (especially when we look at the demographics of a number of Android users).
While Android holds a very healthy market share (across all flavours) it makes sense to build for Android, but I do find myself hoping that iOS, Windows Phone and Blackberry start taking large chunks of market share away from Android. As an OS to for businesses to build for, businesses that want to maintain code across multiple operating systems, who want to deploy apps with great consistent robust experiences, Android is miles behind Apples iOS and Microsoft Windows Phone.
Recent Comments