The eternal question, should we go native or cross-platform? This is one of the first questions to crop up when scoping a new app or a major update. At first glance cross-platform seems like the obvious choice. Write code once and get your app on all the major mobile platforms in one go. But is it that simple? There are lots of great articles weighing up the advantages of each and when to use them but here I’m going to look at what swayed our decision to go native.
A good user experience is crucial to maintain a happy userbase and make the app accessible to new users. Using cross-platform tools, especially HTML5 based ones, often leads to a slow and clunky user interface. Often this is because the performance can never match that of native frameworks which have the advantage of GPU acceleration and less overhead interpreting code. Users like smooth animations and being able to navigate around the app quickly. If your app stops users getting to what they need or frustrates them they’ll stop using it. Mobile apps are focused around quick, short user interactions so apps need to be snappy.
Going native here also meant we could do nicer animations and customize the user interface slightly for each device. On iOS back is all done in the top left. On Android we use the built in back button. This way it makes sense to users naturally on each device.
The core of the app is centered around the camera and capturing high quality images of the receipt. When we investigated a lot of the cross-platform solutions we found the level of control over the camera wasn’t low enough to allow us to implement all the features we wanted. An overlay to allow stitching receipts couldn’t be done and we would not have been able to control features such as the autofocus or detect lighting levels. Whilst a workaround would be possible it wasn’t an optimal experience and would have led to more ‘junk’ receipts which were out of focus or missing details.
Building with the official frameworks means new technologies and features can be integrated as soon as they are available when a new version of the OS is released rather than waiting for third parties to catch up and write APIs to wrap these. For example this meant all the iOS 7 features could be integrated quickly and new technologies such as iBeacons evaluated.
By using native code all the tools from Apple and Google are available to try and find the causes of crashes and performance issues. On iOS the very powerful Instruments tool can be used to find memory leaks, slow animations and various other issues. Even using cross-platform tools you would often need to be able to know what’s going on in the native code to understand what the cause is.