There are numerous ways to build a mobile app, all of which have advantages and disadvantages. The approach taken is often dictated by what a firm has experience in but when multiple companies may be bidding for your work, it can be helpful to know a little of the landscape.

In the early days, the choice was easy. You'd go full native. To build for iOS you would use Objective C in XCode, for Android you'd use Java in Android Studio. You did have Windows Mobile and theBlackberry too but thankfully neither gained too much traction in the mobile app space. Covering multiple platforms became a real challenge for many companies as they'd have to have coverage for at least 2 very different skillsets. Furthermore, many projects/products would require a web application meaning 3 code bases with nothing shared between them. Not only is this extremely inefficient but very costly.

Then came the advent of cross platform mobile. PhoneGap (now Cordova) was one of the pioneers in this space. What it did was wrap a web application into a mobile app. iOS and Android both have/had components you that would allow you to host a web page. You would host all the web application files(images, HTML pages, Javascript files etc) in the application bundle which then got distributed to the app stores. There were some compelling reasons to go this path, most notably that you you could almost create a web and mobile application from 1 code base. A team only needed to be knowledgeable in web technologies. It was a nice idea but in practice there were some big issues with this approach including:

• Pages often took a long time to render meaning users got turned off very quickly.
• In order to access the hardware on phones you'd need to use components that exposed native functionality but were callable from the web side. Developers were reliant on hobbyist developers to build and maintain libraries. It became quite the task to find components that were well written, well maintained and kept up with the pace of changes in both iOS and Android.
• The size of applications was significantly larger than native ones. This is less of an issue today with blazing mobile data speeds and mobile vendors offering larger download limits but this wasn't always the case.
  
• Things started to really hot up in the later part of the last decade with the main protagonists all releasing a cross platform mobile solution, hoping to be the de facto choice for developers. Microsoft released Xamarin, Facebook released React Native and Google released Flutter. All cross platform and all compiling to somewhat native. There are compromises in all of them but all offer compelling reasons to use them over going with 2 code bases for mobile. The 2 clear winners in this space are React Native with over 1 million weekly downloads (at time of writing) and Flutter which doesn't publish such numbers.

A future blog will look at some comparisons between each of these and when 1 should be favoured over the others.

It would be amiss not to mention Ionic. The team at Ionic took over from Cordova and have moved web based cross platform to a new level. Huge improvements from Apple and Google with their web view technology coupled with some great work from the Ionic team have made it a great choice for developers. It may not be native but in many case you won't really notice.

At Rappid, we use Flutter. We love Flutter for a variety of reasons. It uses the Ski a rendering engine to draw pixels natively to devices. This means that we can as good as guarantee the app will look the same across all devices. It is very fast and allows for a very fluent and responsive UI. We also love Dart, which is the language used to write Flutter applications.

Sometimes you won't need a mobile app. It takes just a few lines of code to turn a web application into aPWA. What is a PWA and why is it important? A PWA (Progress Web App) really is just a web application that will allow you to add a shortcut of itself to your home screen. So it looks like a normal app on your phone and in most cases functions like one too. This is a great option if you don't need features like push notifications and need no or limited access to the phones hardware. We often propose this approach first to clients as it is budget friendly and often meets all the needs of the project.

‍