Mobile App Dev: A Guide for 2024

Published in

Version 1

5 min readNov 3, 2023

Customers often think that having an icon on the phone requires a native mobile app, but advances in browser compatibility and usage mean that for most scenarios a Progressive Web App (PWA) is a more immediately accessible and updatable solution. But there are many ways to approach the problem, so this guide should help you through it.

1. What is a Native App? What’s a PWA?

A PWA is a web application that can be ‘installed’ in the mobile device, creating a native app-like experience with a full icon shortcut, but being rendered via the browser and without the browser’s wrapper, so it runs in the full screen. It’s worth noting that the browser can access many device capabilities like location, camera, and microphone, as well as having local storage for offline use if required.

A Native Mobile App, by contrast, is a software package that is distributed through the main stores — iOS App Store, Google Play Store primarily, plus Amazon, Windows, and other manufacturer stores. They can have better access to deliver features, and they run directly on the device operating system, so avoid some of the performance overhead of the browser.

Advantages of Native Apps

User perception — solid investment in the app in each store gives a more solidifying presence and reassurance that a full development cycle and user testing has taken place.
Some native features (e.g. geofencing with native notifications) can be easier with a native application.
No limitations on local storage or device / iOS compatibility (although this gap is closing)

Advantages of PWAs

Speed to develop, maintain, and distribute a PWA is way faster — there is one code base, and you can deploy as fast as a browser refresh.
Release cycle: Effort and time is required to get each app version published on the app and play stores, and then for end users to update.

Our Advice: start with the PWA and really try to figure out what is not possible — updates on iOS have improved push notification support, for example, and offline storage is already there — so why would you need a native app at all?

How do we build?

While it’s a challenge already to think about the type of app we want, we also have to consider how we want to build it. These days most web and mobile apps are built on top of a server-side storage with corresponding services, normally enabled by APIs, so we’ll focus on the differences in the app itself.

Native apps

Typically we see three approaches:

Native app languages

There’s no doubt that programming in Objective-C and Swift can get some performance advantages and push the boundary in terms of what can be done on the phone. But you end up with having code in a fairly niche skill set, which is different for Android vs iOS, and the independent skillset can be hard to source. Coding at the bleeding edge of phone development can also leave you susceptible to laggards in phone upgrades, so the newest features take a while to turn mainstream.

2. Hybrid code

Frameworks like Ionic, Cordova, Xamarin and ReactNative allow the developer to code once and deploy to both major app stores. By using a framework, the platform-specific nuances are abstracted, so development is faster than with separate native apps.

Ionic in particular are now promoting the super-app concept, a term first coined by Mike Lazardis of Blackberry. The main app handles device interaction, events, authentication, and authorisation — and then sub-apps, which can be written in different ways, can be plugged in to give a seamless customer experience. This kind of composable architecture can help with app sprawl, where employees have half a dozen different apps to use in their jobs.

3. High-Performance Low Code

Another approach uses a Low-Code platform like OutSystems. Here a developer can code the full stack, not just the mobile app — and make use of common client and server actions to ensure consistent behaviour across web, PWA, and native mobile channels.

Building PWAs

It’s relatively straightforward for an experienced web developer to build a PWA; add a manifest and service worker and a few details, and you can have a shell working fairly quickly. Most Javascript frameworks have guides on how to handle that — Angular, React, Vue, Node — but if you don’t have these skills already it can be hard to source and maintain in the long run.

Again, the low code option allows the same app to deploy as native, PWA, or responsive web application, from the same code base, without the additional overhead of managing the functionality.

Other Considerations

Deployment to store: Note that while frameworks allow the source code to be generated from the same configuration for each device type, each store has its own submission/test/approve/release cycle to work through before a native app gets in the hands of an end user. A PWA of course only relies on the testing and deployment of the product team.

Licensing costs: There is a sliding scale of license cost, ranging from free tools, through developer-centric frameworks like Ionic, through to broad-based development platforms like OutSystems, which are priced more for end user scale and complexity.

Local storage: PWAs in particular can handle a handful of records stored locally, but start to suffer if a large collection of data is held locally to be used offline. When selecting a build pattern, some consideration of function is needed to ensure the best match versus expectation.

We would advise that platform choices are made not for one project at a time, but with an architecture view so that fewer technologies are needed across the enterprise. But that is for a different blog.

References

OutSystems own guide to native vs PWA

What web can do today: list of features available in the browser

About the author

Andy Borthwick is a Solution Architect here at Version 1.