A voyage of discovery
Every new project is a journey into an unknown land. The right partner will help you navigate that journey and reach your destination in great shape.
As you begin the journey of creating a mobile app, one of the first decisions to explore is whether to build the app in a programming language native to the platform, or use an alternative method.
Native, hybrid or cross platform? A quick Google search will find dozens of articles arguing for each of these fairly convincingly, so how do you decide which is best?
(Not got your app concept fleshed out yet? Try our take on what makes a successful mobile app)
Like so much in digital platform development and creation, the details of an individual project vary, meaning there is no real right answer. (Which is why it's so important to do proper discovery ahead of commencing a development project… but that’s a story for another day.)
Read on for some pros and cons of the different approaches to mobile app development.
Researching mobile app development approaches can quickly get confusing, as articles tackle the goal end-product, and the development techniques used to achieve it, often interchangeably. The language can certainly overlap, leaving the reader more confused than when they began.
So, first let’s define our end product. Each of these is a mobile app in so much as the overall goal is to let your customers access your digital product on their phone, in a way that goes beyond just opening the browser and looking at your website (which is of course beautifully optimised for mobile).
They each have different use cases, pros and cons…
End-product |
Native App |
Web App |
Progressive Web App (PWA) |
Users find and download your app in their phone’s app store - Apple App Store or Google Play. It is installed on their phone, and some or all of the features are available without leaving the app (e.g. don’t require your phones web browser) |
Your service runs on a website, but it's been designed to ‘feel like an app’ when users access it from their phone. This access happens via the phone’s web browser. Can be saved to phone home screen, but this is just a bookmark that opens the browser and goes to the website |
Your service is built to run on the web, but uses service workers and a programmable cache to allow some parts of the app to be installed on the user's phone. This means they can run without a continuous internet connection. It can be packaged for Google Play store distribution, but Apple doesn't officially support PWA distribution, and even using a tool to package your PWA, you may not get it past the App Store review process. |
|
Distribution via Google Play |
Y |
N |
Y |
Distribution via App Store |
Y |
N |
N |
Can be designed to have (some) features work without a connection |
Y |
N |
Y |
Can send Push Notifications |
Y |
N |
Y |
Can create functions that need to access phone camera, location data etc. |
Y |
N |
Y |
Can sync data in the background |
Y |
N |
Y |
Can be accessed from a desktop computer also |
N |
Y |
Y |
Development technology examples |
‘Real’ native, in Xcode or Android Studio Cross-Platform, using .NET (previously Xamarin), Ionic, Flutter |
React, Angular. |
PWA Builder React PWA Library |
Once you have decided that you definitely need to build a ‘proper’ phone app, it’s time to explore development approaches. In this article we’re focussing solely on native apps - you have decided you need to build one that runs locally on your users mobile, and you want to distribute it via the Apple and Google stores.
‘Real’ Native apps are wholly built using the programming language and SDKs provided for the specific device operating system. In mobile app terms this usually means you build two apps, one for Android devices and one for Apple/iOS devices.
Hybrid apps are a combination of a native app and features that are built using web programming languages (like HTML, CSS and JavaScript). As a minimum, developers create a shell of the app as a native app, but in some cases the native functionality can be quite extensive. A hybrid app is distributed and used like an app, but some of the content and features are delivered via a web app.
Cross-Platform apps are still delivered as a native app in terms of their end product. The main part of these apps, that contains the business logic, is created in a single programming language. Then using a tool such Xamarin, Flutter, or Ionic, developers create apps for specific platforms with minimal changes to the central code.
If we were building an app in a commercial vacuum, in a perfect world with no external constraints on our project, we’d probably choose Native every time.
Whatsapp, Spotify and ShareMyToolbox are all built using the native approach.
Hybrid development involves combining a native-built app with elements that are built with web technologies, like HTML, CSS and JavaScript.
The result is distributed and used as an app, but (some of) the content and features within the app live on the web. An end user won’t usually be able to tell the difference, but the crucial part is that a hybrid app won’t work offline.
Instagram, Evernote and the Newcastle Airport app are all built as hybrid apps.
Hybrid app development can be a good choice for projects that require cost-effective, time-efficient development, and access to some device features, but with the trade-off of potentially lower performance and limited access to native features.
Cross-platform mobile development refers to the creation of mobile apps that can run on multiple platforms, such as iOS and Android, without the need for separate development for each platform. It’s based on the principle of “write once, run anywhere” coding.
The business logic part of the app is a single, shared codebase, with the screens needed for each operating system created to present this to the user.
This practice is not dissimilar to the decoupled CMS approach in web development, where business logic and front end experience are deliberately separate.
This approach depends on using cross-platform development tools, frameworks, and libraries, such as .NET mobile SDKs (previously Xamarin), Flutter, and Ionic.
For the right projects, cross-platform offers more efficient development and a quicker time to market. It can be a great middle-ground, with the smooth and intuitive UI users are used to, and shared business logic to make maintenance easier.
Examples of cross-platform apps include eBay, Slack and Northumbrian Water.
On paper, cross-platform should be more cost effective, as the team only needs to create the business logic part of the codebase once. One place to test updates, one place to squash bugs. In practice, there can be extra effort involved in refining the experience for each operating system, especially as the platforms add new features.
The decision is far from straightforward once we start to consider the real life practicalities of building apps in organisational and commercial contexts.
The use case, audience and feature set (and long term roadmap) for your app means your mileage will vary on each of these approaches. It’s also important to bear in mind the skill set of your team, your budget and other constraints.
We see news articles and blogs emerge regularly as the teams behind the world’s most popular apps shift their approach - from native to cross-platform, and vice versa - as their audience and business contexts change over time.
Working with your development team and/or partner in a detailed discovery phase will help clarify the specifics for your project.
Representatives from business/commercial, user experience and technical teams work together to map out the project scope, dependencies and constraints. Think about the long term vision. Examine any data you already have - for example device use across your web visitors.
Beware the trap of fast now, hard to support later - compromises to help get moving might cause problems in future, meaning you struggle to scale and could be faced with a costly rewrite.
If all this has piqued your interest in app development, read our guide to building a successful app, or explore our app development projects.
Every new project is a journey into an unknown land. The right partner will help you navigate that journey and reach your destination in great shape.
... and how to fix them. Our UX team reflect on the top 10 UX mis-steps and the impact they can have on conversion.
A Design Library allows UX teams to focus on the things that matter, confident in the knowledge that they're making holistic and consistent choices.