Cross Platform Mobile Development Options10 Jan 2018
Over the last 12 months or so I’ve been lucky (probably!) to use a whole bunch of different technologies to build mobile apps.
I’m often asked about what’s the best strategy for efficiently building cross-platform apps, so I thought it might be interesting to look at the pros and cons of each approach to clarify my thoughts a bit.
TL,DR; It’s complicated, and depends on your business needs.
I don’t think it’s too controversial to state that apps written using native SDKs generally offer better user experiences than those written using cross-platform technologies.
Any solution that reuses the same code on both platforms by definition can only use common elements, and therefore can’t fully utilise all native elements on an individual platform.
In particular, any solutions use a browser control and use web technologies just don’t feel as slick as one using native SDK elements.
For most businesses, when they want a mobile app they want both an iOS and Android app.
It goes without saying they want to reduce the cost of doing this, but the UI quality they are happy with is a key factor in deciding what is the appropriate solution.
I inherited a project using Ionic, a Javascipt/Cordova/Angular framework that - as their website states:
… emulates native app UI guidelines and uses native SDKs, bringing the UI standards and device features of native apps together with the full power and flexibility of the open web
Once I’d got back into slight craziness of Angular, it was quite a nice way to develop. In particular the app worked pretty much identically on both iOS and Android without any extra effort.
The app is a pretty simple database-driven solution that presents information and checklists for workers when they are on a remote site. In this case functionality is much more important than a superslick UI.
Usuability was definitely more “functional” than “crafted” (although well designed), but TBH despite a lot of effort spent polishing the code, you can tell it’s a web app underneath.
Animations and transitions don’t feel native, and other UI elements aren’t quite right too - not surprising as they’re being emulated in a browser control.
For this particular app, using Cordova and Ionic was actually a decent solution. Development costs were definitely reduced compared to building two native apps, and the trade off with reduced UI quality was probably the correct one.
Despite having many years experience using C#/.Net I’d never considered using Xamarin before, mainly because it was quite expensive at first before Microsoft bought it a few years ago.
I inherited an app using Xamarin that needed completing, and I was pleasantly surprised how productive it was. All of the business and data logic could be shared across platforms, which was great saving of both development and testing time.
The app downloads lots of information from a web-based CMS to display to the user, as well as allowing them to build up a local photo gallery.
The downloaded info is stored in a local Realm database, which has a nice cross-platform Xamarin implementation.
Each platform has its own native UI code (which obviously means it was written twice). However this isn’t quite as inefficient as it sounds as much of the code is simply binding to UI elements to data objects and watching observable events in the shared data library.
The main non-reusable work is designing the native layouts for each platform. This does mean you can design the best UI for each platform, and in consumer-focussed apps this may be an acceptable trade-off.
For apps where the user experience is important, and there is a lot of business/data logic that can be shared, I’d definitely recommend Xamarin as a good solution.
I should also mention there is a “Xamarin Forms” option not used here, a cross platform UI solution that uses native elements - obviously only UI elements common across both platfors. In some cases this may be an even better solution, especially for simple UIs.
Separate native apps
For a few of my clients I’ve built two separate versions of the same app for iOS and Android, using the native SDK for each.
Clearly this means none of the code is reused, but I don’t think it’s necessarily as inefficient as it sounds.
In both cases I built most/all of the iOS app first, which meant the UI/navigation/business logic could be iterated on until everyone was happy with it. Then once all of the problems had been solved, it was “simply” a case of reimplementing on Android - a task that was really easy (if a little boring) as it was very well defined what needed to be done.
As a small team of one, this is actually a pretty efficient way of working, and probably wasn’t much slower than the Xamarin solution given above. This is especially true for apps where most of the work is in crafting nice UIs rather than writing complicated business/data layer code.
Other advantages of building separate fully native apps, including having the quickest way of implementing new technologies, plus the code written in a way that is easier to find developers to maintain and extend.
Clearly there are other cross-platform solutions out there - in particular React Native looks very interesting - but as I haven’t really used them I won’t comment on them here.
As an experienced C# developer, for projects where I get to choose the tech stack I’ll definitely consider using Xamarin again. Having native UIs and reusable business/data code is probably a good compromise in may circumstances. If you have existing .Net development skills, I’d definitely recommend looking into going down this route.
For larger teams, or on consumer-focussed projects where UI quality is important, building native apps per platform can result in the highest quality experience, even if not the cheapest solution. Finding developers with native skills on each platform is probably easier too.
Using Cordova/web-based technologies can be the cheapest way of building cross-platforms mobile apps - especially if you already have those skills in house - but there is definitely a drop off in the UI quality compared to native solutions.