Mobile Applications: native vs cross-platform vs hybrid vs PWA

First question, and let’s get straight to the core – how does a client choose which type of an application should they get?

Well, it primarily depends on their business and their needs. Some clients know right from the start exactly what they want – for example, they come to us with a brief that clearly states that they need a mobile application for iOS. On the other hand, a majority of clients come to us with a general idea of what the final product should be, and they let us propose the ideal type and handle the specifics.

As I said, it’s all about understanding our client’s business and their needs. And in order to do so, we conduct a detailed discovery process that enables us to get as much information about what they’re trying to achieve. Once we go through the discovery workshop, we have a pretty clear idea of whether our client needs a web app or a mobile app, and even what type of a mobile app we should be building.

Unfortunately, there is no general “if this, then that” type of a formula to choose the right app type – it completely depends on the business, target groups, specific needs… But there are some variables – for example, if you need a platform that should be working offline or that heavily revolves around connecting to specific hardware, then a mobile app is the way to go. On the other hand, if you need maximum flexibility, a web app is usually a better choice, because the App Store and the Play Store have strict guidelines… But as I said, there are no general rules, and it’s always defined on a case by case basis.

Can you give me an example of those guidelines?

There are a lot of rules and regulations and the documentation is quite extensive. For example, if you’re trying to build a gambling platform, or let’s say a platform for trading binary options – store guidelines even advise that you do that through a web application.

OK. So, are there any other variables that you could mention?

Let’s see… OK, yeah, if you need something that can be quickly built and launched, or a platform that will be used only for a short amount of time, then a web application is the better option. Mobile applications usually take a bit more time to design, develop and launch, and you should look at them as long-term investments that grow together with your company – you can build upon them, iterate, improve them… that’s the strength of a mobile app.

And what if I need both a web app and a mobile app?

That’s also an option. We had a lot of clients that needed a mobile application as their main platform, but they also needed a web app to serve as their CMS. I mean, there are a lot of different possibilities when it comes to combining the functionalities of web and mobile apps, but it often boils down to the mobile app providing the functionalities that need to be accessed on the go and at all times, while the web app is focused around more robust systems that require more inputs from the users.

In the end, it’s all about playing to the strengths and limitations of available devices, and providing users with options – a lot of them enjoy and even demand to have the option of using a specific platform whenever they like through a mobile application, and then get access to more complex functionalities when they power up their laptops or desktops.

Now that we briefly covered the issue of web app vs mobile app, let’s get a level deeper. Native mobile apps vs hybrid mobile apps – what’s the difference?

I would actually split this into four distinct types. The first ones are native mobile applications – these are the ones created specifically for the Android or the iOS platform by using the official SDK provided by Google or Apple, and they fully support all of the functionalities of these operating systems and the devices they are built for.

The second type would be cross-platform frameworks that are used to generate a native-like UI. They can take advantage of a part of the functionalities that native apps have access to, but that part is still wide enough to create an almost identical look and feel to the native apps.

The third type would be some kinds of web-based solutions, that are also known as hybrid apps. This technically isn’t a mobile app in the real sense of that word – hybrid apps are basically websites embedded into an app form, and that web is used to simulate the look of a mobile application. But in the end, it is still a website and it comes with all of the limitations of the web – for example, the performance of such an application is noticeably lower than the performance of a native mobile application.

And the fourth one would be PWA or progressive web apps. As the name suggests, this is also not a real mobile application, but it’s being put into the same conversation more and more. But PWAs can be, for a lack of a better word, installed on the homescreen of a mobile device and simulate a real mobile application. But in the end, it kind of ends like being a shortcut that takes you to the website, although it offers you a set of more advanced functionalities that websites don’t have – for example, PWAs support offline mode, push notifications, background sync…

If I get this right, native would be the ideal solution because it provides the best user experience?

From the user’s perspective, native mobile apps are the ideal pick. But from the client’s perspective, it depends on the business case and needs…

OK, let’s focus on native apps. Tell me a bit more about them…

Well, one of the key elements of native applications for Android and iOS is that they’re fully supported by Google and Apple. They have access to all of the functionalities of these systems, they have their own SDKs, they have access to all native components… Also, when a new version of the operating system comes out, they get immediate support and can take advantage of the latest advancements and upgrades. In addition to that, native apps have comparatively the best performance out of all the types and provide the best user experience.

That is why native mobile apps are the top choice if you’re looking to build an application that is made for the long-run and that needs to take advantage of device hardware… basically, every app that puts a heavy emphasis on performance and the overall experience should take the native route.

And with full support when it comes to continuous maintenance and first access to new system functionalities, with native apps you have the means to create an application that has the finest user experience.

And the other types are good for…

The other types I mentioned are better suited for some short-term or one-time activations or campaigns, or if you’re looking to build an application that is simple, that isn’t performance-heavy or that has no business logic in the background – for example, if you need an application that should just display data received from the server, then you probably don’t need a native application.

But all of this is defined on a case by case basis – through a discovery we conduct with clients before we start working on the project.

OK, tell me more about this discovery. What is it that you get from it?

Well, outputs of the discovery workshops give us all of the necessary information about the app we should be building – from the main goals of the app and its core functionalities, to specifics about the target user group and the look, the feel, the experience it needs to have.

As all discovery workshops are conducted directly with clients, we can get a lot of information from them and then use that information to define the specifics of the app. For example, if a client primarily wants to target the US with the application, that signals us that we should put an emphasis on building the iOS application as that operating system dominates that market, as opposed to targeting the Croatian market which heavily leans on the Android side.

You see, when you know the business goals and the demographics you’re targeting, you can fairly easily determine if you need a native application for a specific system, or an application for both, or even if you need some other type altogether.

So you can basically create just one app for one system to test the waters…

Exactly, and that is something that is being done more and more. If you know your target, you can create and launch an MVP version only for Android or only for iOS to test out your business model among the users. And if you see that it works, you can then build your application for the other operating system.

But if you need both systems at the same time, then cross-platform is the way to go?

Well, as I said before, if top performance, hardware integrations and user experience are your main priorities, native is still king. But if those elements aren’t that important in the grand scheme of things and you really need an application that will work on both iOS and Android, cross-platform frameworks can make a very functional final product.

There are now a couple of cross-platform frameworks that are most commonly used to create mobile apps, but they have their differences, so choosing between them also depends on the goals of the app.

OK, tell me more about those specific cross-platform frameworks and their limitations…

Well, before we cover the frameworks, I should point out that that using them as opposed to building a native application will in most cases result in:

1. decreased performance
2. UI that is close to native, but not quite what the users are used to
3. depending on framework providers to implement new features and functionalities and maintain the framework as a whole
4. dealing with an app of a larger size which can sometimes be an issue

You see, the main benefit of cross-platform frameworks is that they enable you to build an app for iOS and Android in one codebase – they basically take your code and generate a native-like app for Android and a native-like app for iOS. That is great because you get an app for both platforms at the same time, but since you’re doing it all off a single codebase, you can’t really nail all of the native elements for both platforms to look and function exactly as the users are used to on native apps. You can still create the native elements in the native SDKs and use them in your cross-platform app, but it requires some additional work to connect those two… and you also lose a bit of that “one codebase” advantage.

Now that we know the gist of cross-platform, let’s dig a little deeper into the specific frameworks.

So, what are those most-used cross-platform frameworks for mobile app development?

There are three main frameworks:

1. Xamarin
2. React Native
3. Flutter

They basically do the same thing, but they have their differences when it comes to the overall performance of the final app they generate and the functionalities as well as integrations that can be built and integrated.

When it comes to current popularity, React Native is currently on top, followed by Flutter and then by Xamarin. But Flutter has the highest potential to take over the cross-platform world. I won’t talk about Xamarin so much, as that framework used to be quite popular, but has really fallen from the scope as React Native and Flutter took over.

OK, let’s start with React Native. What’s the deal with that framework, how does it work, what are its benefits?

As the name suggests, React Native is based on React, and it is Facebook’s framework. Its biggest benefit, and some would say that it’s also its biggest weakness, is that it is built in JavaScript, which is the most popular programming language in the world. Because of this, a lot of people can quickly figure out how it works and how to use it, and it also enables the programmers who use React on the web to get a hold of React Native.

The point of React Native is that it uses a JavaScript bridge that transforms your code into a native code for Android or iOS. It also comes with a wide selection of functionalities and UI elements that can be implemented – as I said, a lot of people can quickly understand how it works, so the community around it is very big, and that means this base of both first-party and third-party elements is being updated quite rapidly. And because, there isn’t a lot that you can’t do with React Native today.

But all of this comes with its own set of limitations – and app performance is hit the most when it comes to React Native. You see, as this JavaScript bridge is running on top of all the native elements, it takes a toll on the system, so the overall performance is not on par with a fully native app. It also comes with its own set of specific UI components which differ from the ones that are usually on Android or iOS, and that’s something you have to take into account when choosing to build your app with React Native.

But, then again, these limitations are present on all cross-platform frameworks. At the moment, you just can’t get the ideal UX on both Android and iOS by using a single codebase. There are just too many differences between those platforms – from the navigation, UI elements, the physics of the app… and there are some aspects that will require you to make some compromises. And that is especially true when you take into account that operating systems get major changes and upgrades every year or every few years.

A great thing about React Native is that if you need something extra, an extra UI element or a functionality that isn’t supported by the framework, you can create it natively, and then use a JavaScript bridge to connect it with your original code.

And Flutter?

Flutter is a much newer framework, it was launched by Google in 2018, and it has experienced exponential growth ever since. And that is because it doesn’t use a dedicated JavaScript bridge like React Native – Flutter has a quite vast library of widgets and UI elements that automatically compile into their native variants. And that means that the performance of mobile apps built with Flutter will be much better than those built with React Native.

It uses its own Material theme that enables you to create an application with UI elements and widgets for both Android and iOS. They also have a dedicated Cupertino theme which is specifically tailored to creating iOS apps, but it’s not the ideal option when it comes to building apps for Android.

As I said, every framework comes with a set of tradeoffs, but it seems like there’s a lot less of them with Flutter, than with React Native – and that’s primarily because of the performance.

Can you tell me a bit more about the programming language that’s used in Flutter?

Ah yes, Flutter uses Dart – it’s generally a great programming language, but there aren’t a lot of developers who use it. I mean, not a lot when compared to JavaScript.

The great thing about it is the performance, which is excellent, and that it enables developers to quite easily create standard UI elements. As for some limitations, the language is quite new so there aren’t a lot of third-party plug-ins that can be used, it currently has a smaller number of available hardware integrations and the community is much smaller when compared to those of React Native and JavaScript.

All in all, Flutter is a great choice if you want to quickly create an MVP variant of an application that isn’t extremely reliant on hardware integrations.

At the beginning of this interview, you mentioned PWAs. Why would anyone choose a PWA instead of a native app or a cross-platform solution?

In my experience, progressive web apps are primarily used when you need some kind of a smaller internal application that doesn’t rely on taking advantage of the system functionalities or hardware specs, or if you’re looking to build an application that isn’t in full sync with the App Store and Play Store guidelines.

Also, PWAs are great if you already have a web app, and you want to quickly create a mobile version of it. Yeah, that is actually an ideal use case – if you have an existing web application, you can give your users an extra option by leveraging the power of PWAs to create a “mobile extension” of the app. And the great thing is – that process can be done relatively easily.

This sounds like a great thing, so is there a chance that PWAs will replace traditional mobile apps?

Not really, at least at this point in time. PWAs are quite powerful and we’ll see more and more of them in the future, but there are still a lot of limitations when compared to native apps, or even cross-platform solutions. For example, PWAs on iOS can’t use functionalities like push notifications, background sync… and that’s a deal-breaker for a lot of apps.

And again, there’s the issue of performance and user experience – if the application needs to use native or native-like elements, or it’s heavily reliant on hardware and system functionalities, you’ll most certainly want to use native or cross-platform.

I mean, the potential is there, but in terms of fully replacing native, I don’t see that happening any time soon. At least when it comes to more powerful mobile applications.

Let’s get back to native. We talked about apps specifically for Android and iOS, but are there any differences when it comes to creating apps for specific types of devices, like iPhones, iPads, Apple Watches?

There are differences, but they are not huge. Now, I’m primarily talking about the Apple side of things as they really managed to build the entire ecosystem with the iPhone, iPad, Apple Watch, Apple TV, Macs…

Although there aren’t a lot of applications that would benefit from having a dedicated Watch app or a TV app (it’s mostly some fitness, health and sports apps) Apple has great support that enables you to use one codebase to easily create app for iOS, iPadOS, WatchOS, tvOS and macOS – you can use the same codebase to create one integrated cross-platform app for all Apple devices. There are more and more apps that use a single codebase for an iOS and a macOS app, and this is really a game-changer because previously not a lot of app developers had the time and the resources to create a macOS version of their iOS app.

As for some specifics when it comes to creating apps for one device or another, there are elements that you need to think about – from the layout, differences in design elements, multitasking on iPad, support for the Apple Pencil and the like… That’s why it’s crucial to determine right from the start if the application is only being built for one type of device or if it will be used on multiple types – as that will impact different phases of the production process. But as I said in the beginning, we cover and define all of that during the discovery workshops.

But what if that changes during the production – what if the client wants an iPhone app, but something changes in the middle of production and now they also need an app for iPads?

I mean, the ideal scenario is that we define it all in the beginning, but… depending on the application, its design and functionalities, there generally is a way to support a different type of device without the need to do everything from scratch. But this really is decided on a case by case basis – if the application is simpler, the chance of doing something like that is much larger. Of course, this is much more time-consuming and therefore more expensive than defining the supported devices upfront.

Whenever we build mobile applications at Bornfight, we always make sure that the UI elements can adapt to different screen sizes, so we can ensure that the app will perform as intended on any device, but there’s always a need for a bit of tweaking to make sure that every aspect of the app is right where it needs to be and that it works just as well on one device as it does on the other.

Got it. I have just one question before we end. Are there any functional differences between Android and iOS?

No, not really. They are constantly neck and neck with each other – when one side comes up with something new, the other will have it in the next update and vice versa. The only bigger thing that differentiates them is the fact that iOS users spend more money on apps, while on the other hand, Android has a much larger user base…

So yeah, when it comes to the hardware side of things, it’s pretty much the same. But the OS limitations are where the real difference happens – Apple has a very strict policy and guideline on what you can and can’t do with the device, while Android is a bit more lenient. For example, with Android apps, you have a high level of control over what you could access with your application, while Apple only gives you a small number of actions – Apple only recently enabled apps to use general purpose background tasks, while Android had that for what feels like forever, on the other hand Android gives app developers a chance to customize a lot more elements outside the app itself, while Apple pretty much just says no.

To conclude…

Yeah, to conclude I’d just like to say that native, hybrid, cross-platform apps and PWAs are all viable options – it just depends on what you’re trying to achieve with the application and what are your needs. Every option has some strengths and benefits, as well as some limitations, so it’s always a great idea to think about the bigger picture around the app itself, or join us on a discovery workshop where we’ll define that together.