Hybrid Cross Platform Info

TL;DR: It depends. 

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. 

But first, what do you want to build? 

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. 

OK, you need a mobile app. How are you going to build it? 

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. 

Native Development Pros & Cons

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. 

Advantages of Native development 

    • The code is - at least in theory - lightest in native, meaning your app will perform faster
    • More support for offline activity, because of less reliance on APIs and third party plugins to deliver functionality
    • Developer access to new features of the device operating system (like Apple’s lock screen widgets) is immediate when the feature is released to beta 
    • Taking full advantage of the hardware and software capabilities of the device, leads to a smooth and responsive user experience
    • The SDKs and tools provided by the platform vendors are increasingly sophisticated, meaning in skilled hands, the basic building blocks of an app are easier than ever to link together
    • Native apps may be more secure as fewer third party libraries and integration points are needed
    • If you have a user base that prefers one platform over the other (or you control their choice, for example through company-issued devices) you only need one app anyway 
    • Native apps can feel more ‘familiar' and intuitive to users, with the position of buttons and interaction styles matched to the device UI 

Limitations of Native

    • You may need to develop two separate apps, and you need a team with two sets of skills to do this 
    • Back to back teams developing in parallel can make keeping track of choices and aligning the UX more challenging - you need good project management discipline to control this 
    • Time to market can be extended, especially if resource constraints mean developing the Android and iOS apps one after the other 
    • Project constraints might mean you need to make the choice to offer only an iOS or an Android version, excluding some of your potential users

 

Hybrid Development Pros & Cons

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. 

Advantages of Hybrid 

    • The code for the web-hosted functionality is written once and can run anywhere
    • The web-app part of the app can be shared between iOS & Android, keeping the development effort needed to create the overall container smaller 
    • Web app elements can be used as an efficient way to extend the core functionality of a mobile app and test new features
    • …which can open possibilities for running MVP projects and testing product ideas  

Limitations of Hybrid

    • Limited access to some native device features, such as the camera or microphone, compared to native apps
    • May not be able to take full advantage of the unique design and user interface elements of different platforms
    • The collection of third-party tools, frameworks, and plugins needed to deliver a full feature set can add complexity to the development process and increase the risk of bugs and compatibility issues
    • Hybrid apps may not perform as well as native apps, particularly when it comes to complex or resource-intensive tasks, due to their structure

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 Development Pros & Cons

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. 

Advantages of Cross-Platform 

    • Allows developers to write code in a single language, such as JavaScript or C# 
    • Access to native device features is well supported 
    • Often easier to develop and maintain, at least on paper 
    • Shared business logic means the code is more easily maintained and tested, and identical user journeys can be preserved

Limitations of Cross-Platform 

    • There can be a delay to access to new device features as the cross-platform frameworks ‘catch up’ with iOS and Android beta releases
    • Native feature support isn’t always as smooth, and can require manual development steps to integrate features 
    • Apps that depend on a lot of device functions may take additional resources to develop and maintain

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. 

Conclusion 

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.