Choosing the technology on which to build a mobile application is a core decision that will impact many factors including accessibility, functionality, and longevity. There is no immediately obvious choice, so deciding the technology needs to be based on market expectations and application objectives. It’s also important to keep application trends in mind to develop on non-legacy technology.

We want to try and help you understand the benefits and drawbacks of the three most common app development methodologies. The guide below outlines the differences between Web, Native, and Hybrid application frameworks, and will help you decide the path forward.

The largest deciding factor in choosing the type of application is the operating system. In this case you need to understand which platform is most popular in your market and industry, and therefore which you should prioritise, unless you have the dedicated resources to manage both app platforms simultaneously.

Regardless of the type of application you want to build the constant factor is the operating system. Whatever your choice it’s important to make sure your application can work (and is available) on both iOS and Android. Unless you need specific technology to build an exclusive app, going for both platforms is your best bet for maximum reach. 

 

Choosing a distribution platform – iOS and Android

 

 

As of July 2018, 72.44% of the mobile operating system market is controlled by Android, whilst iOS on the other hand controls 25.73%. This is true for most markets, however one must keep in mind that a big portion of Android phones do not run the latest versions of the OS, which means you need to consider the added cost of testing an app, and supporting multiple versions of software that might work differently. This problem is not found on iOS.

Whilst Android users downloaded more apps during Q1 2018, roughly 19.2 billion compared to iOS users downloading 8.2 billion, the number of downloads on iOS is slowly starting to catch up with Android, although Android is the more common OS in Europe.

In the past year, iOS has closed the download gap by 10%. Considering the large difference in number of devices running iOS compared to Android, this is an impressive feat.

 

 

Despite a smaller number of app downloads, the iOS App Store records a larger gross consumer spend.

During Q1 2018, iOS App Store saw a consumer spend of nearly $12 billion, compared to Google Play recording close to $6.5 billion in consumer spend.

 

 

Depending on what your app will offer, such as in-app purchases or whether your content is free, should have a profound effect on the platform you decide to build for first. After all, if you are going to rely on making money through in-app purchases, you want to ensure your app is available to those with a larger spending power.

Android devices are very popular in developing countries thanks to their lower cost. In these areas, users may have less access to bank cards and rely more on cash for purchases. Where Google has been slow to roll out carrier billing, it could be an impediment to these users being able to spend money on the Google Play Store, leading to the large deficit in Android app store spend versus iOS.

In addition to this, the varying screen sizes of Android could prove troublesome and cause extra development work. Where Apple create their own devices, you don’t have different brands creating different size screens, which could lead to display issues with your app. By developing for iOS and set screen sizes, you can thoroughly optimise your mobile application for conversions.

Unfortunately, iOS and Android are totally different and there are no overlaps in terms of coding. This means you need to build two separate applications. iOS apps won’t run on an Android device, and Android apps won’t run on an iOS device. This makes selecting an OS to focus on more critical. However, there are some ways to skirt around this issue which we will discuss later in the article.

 

Web Apps

 

(Source: live.cctrader.com)

 

A Web App is an application that is accessible via a web browser or network. It differs from a website in the sense a website is there to provide informative, static content such as our Brand & Pepper website. A Web App provides a functionality, such as the ability to trade stocks.

One main advantage of Web Apps is that they don’t need to be downloaded to a user’s device. They open within browsers like Chrome, Edge, Internet Explorer or Safari. Essentially a web application is built within the boundaries of a web browser, so it’s capabilities will largely depend on it.

They are built similarly to a website, using HTML5, CSS and Java. However, developers don’t have access to a software developers kit (SDK) when building a Web App. An SDK is similar to a box of cake mix in the development world. It has all the ingredients ready to go to make your app work perfectly, requiring less time to build and you don’t necessarily require as much knowledge about app development, or any experience.

Web apps typically use APIs instead. These are similar to the recipe for a cake. They tell you what you need and how to combine the various parts of your app, but it is up to you to actually put the sections together.

When building a Web App, you have the ability to make it a Progressive Web Application (PWA), meaning your app can work offline, send push notifications and load on the home screen. This has a lot of advantages, and companies such as Google are pushing PWAs with developers. These are great for low data usage, pushing updates faster (since there is no approval process controlled by a third party store), and can be accessed by all devices with a web browser.

Although there are advantages, PWAs come with their own issues, mostly when it comes to technology. They depend on web browser technology, so they will only work on browsers that support them, typically cannot make use of the latest hardware developments, may not support features that apps have by default (such as notifications on iOS), and are not easily found in the device store – the person will need to manually add the app to their home screen using device settings.

As mobile browser technology improves however, we might see an increase in PWAs since they are more cost efficient, and the technology gap keeps shrinking. It may also be the case that people do not have every single app installed, for example Twitter and Pinterest PWAs can be a good alternative to the native app for non-heavy users. Finally, PWAs offer better shareability since they open in the device browser, and the user does not need to separately install the app to access a link. Companies making use of PWAs can also see a boost in search engine optimisation, since each page in a PWA has an indexed URL that can be great for organic search.

 

Should you go Web or Native then?

Well, as you might imagine, the answer is not simple, and will depend on your objective and application use. Both application types have their own uses in particular scenarios. There are some immediate aspects about functionality however that will automatically eliminate the other, we’ll try to explore as much of them as we can here.

Push Notifications

No matter what type of app you are creating, make sure you implement push notifications. They are automated reminders send directly to the user’s notification bar, reminding them to use your app.

Push notifications massively increase the chances of a user returning to your application. After all, getting someone to use your app once is the easy part, persuading them to keep coming back is the challenge.

If you are serious about your app, make sure you have push notifications. Take a look at your phone right now, we can guarantee that you will have at least 1 notification!

Enhanced Sharing

What better way to ensure your app’s user base grows than by making sharing as simple as 3 taps? With a mobile app, users can share your app or content within 3 taps and directly to their favourite platforms, whether that’s social media or instant messaging.

Sharing can be implemented in a Web App, but it is far more user friendly in a mobile app and requires less taps from the user.

Increased Ad Revenue Potential

Our final advantage in this article for mobile apps over Web Apps is ad revenue potential.

If you are planning on having ads in your app, it’s important to factor in ad blockers when calculating your ad revenue.

Web apps will be effected by ad blockers and as a result, your Cost per Thousand Impressions (CPM) will be significantly lower.

Mobile apps help navigate this issue as ad blockers don’t work within mobile apps, so ads will continue to be served within your application, enhancing your CPM.

These factors don’t necessarily mean that a Web App is not good and won’t help your business growth. You have to take your needs, and what you want to get out of your app into consideration.

There are 2 main types of mobile app, Native and Hybrid. Both have their own advantages and disadvantages. Based on your needs, they might stack up differently when compared with a Web App.

 

Native Apps

(Image Source: Revolut App)

When you think of a mobile app, chances are it is a Native App. The majority of the apps on your mobile device are probably Native.

A Native App is an application made specifically for one operating system using a specialised programming language, such as Java, C# or Swift.

These apps are written in the language that the operating system accepts and can understand.

For the most part of building a Native App, developers can use a Software Development Kit (SDK). An SDK helps developers to build the app with greater ease and face relatively less headaches down the line.

Android developers’ use Android Studio, whereas iOS developers use Xcode. SDKs provide prewritten code snippets and a testing environment to ensure the app works perfectly with every line of code that is added.

The majority of apps have been built Native to make the most of the enhanced benefits and features the app can then offer to the end user.

By building a Native app you can tap into the devices features, such as biometric security, camera, microphone, accelerometer and swipe gestures, with relative ease.

It is still possible to use some of these features with a Hybrid or Web App, but it is simplest on Native. Code libraries such as Hammer.Js enable developers to add swipe gestures to web applications and mimic a Native Application.

Another feature of Native Apps is the ability to match UI/UX to the platform conventions.

Both Android and iOS have their own unique UI/UX, and by adding these conventions into your applications, you can make your users feel like they are in part of the phone’s software. This helps to keep your users comfortable and confident with your new app.

That being said, there are a few drawbacks to building a Native App. The largest disadvantage of Native Apps are the multiple codebases you will need.

Due to the fact Android and iOS run using different languages, you will need to create a separate codebase for each OS you wish to have your app on.

This means you will need more developers, as most app developers are only proficient in one or two languages, and this takes more time. Both of which mean higher costs, which can be prohibitive in the early phases of a business.

However, Facebook recently launched React Native, a cross-platform Native App development tool. Using React Native you can build cross-platform mobile apps in Java, meaning you can save money and time when developing your app.

Using React Native is almost identical to using Objective-C and it uses the same fundamental building blocks that would be seen in all other iOS and Android apps.

If you are looking to save a nice chunk of money and get the best of both worlds, then React Native might be worth looking into.

A few large companies have built their apps in React Native, such as Facebook, Tesla, Walmart, Skype and Airbnb.

 

Hybrid Apps

(Image Source: Betfair Exchange App)

A hybrid App is exactly what it says on the tin. It is the combination of Web App development with Native App features and installation.

This should be your go to app if you have an idea for an app, but unsure whether people will like it or not.

Hybrid Apps are very hard to detect, unless you know what you are looking for. They are built using Java, HTML and CSS, exactly the same languages as a Web App, and run in something called Webview.

Webview is basically a wrapper that is installed from the App Store, like a Native App, but is a simple browser that then takes you to the Web App.

Hybrid Apps are a great choice if you are tight on a budget as they only require one codebase, meaning you need to hire less developers, and you can use your existing web developers to boot!

The main advantage of one codebase means you can easily scale your Hybrid App to as many mobile operating systems as you desire.

Simply create the Native part of the app, the Webview wrapper, add in the URL and submit to the app store. It’s really that simple.

In addition to scalability, Hybrid apps give you access to all the device features, just like in a Native App. However, you will need to use PhoneGap SDK to enable all the device features.

Unfortunately, a Hybrid App still has drawbacks. The performance of Hybrid Apps is considerably degraded when compared to a Native App as they rely on your mobile data/Wi-Fi.

If your users are in an area with poor/no reception, your app simply won’t work.

On top of this, Webview is very basic and lacks a lot of features that a main browser would, so users would be better off heading straight to your Web App, rather than taking up precious memory on their device.

Whilst in most cases, the cost of a Hybrid App can be considerably cheaper, it can take substantial work to make your app run perfectly on both Android and iOS.

The costs can escalate to almost the same as a Native App if you want to make the UX/UI comparable with a Native App.

In this case, you might as well cut to the chase and offer a better user experience and go for a Native App.

If you already have an existing Web App, you can convert it into a Hybrid App using a tool such as Canvas.

You simply input a few details, such as app store icon, Web App URL and app name, then Canvas will do the grunt work for you!

This is quite handy if you are after the app store exposure we discussed earlier in the article.

There are some corners you can cut and some patches you can put over ugly pieces of Hybrid Apps to make them feel more Native.

• Use a splash screen
• Add a back button to the UI
• Get rid of the 300ms double tap delay
• If you have long load/wait times, add a load bar or animation so people don’t think your app has frozen.

By implementing these patches, you can make your Hybrid App feel slightly more Native and hopefully win you a few favours with your users.

 

How to Choose

Hopefully this article has helped you to decide, but if you still aren’t sure which app is best for your needs here is our summary.

User Experience

If you value user experience then you should be looking to create 2 separate Native Apps. Your users need to be able to load up your app and be familiar with it immediately, it shouldn’t require too much of a tutorial.

It needs to be easy to use with a nice user flow. If your end users don’t like the UI, there is a high chance they will uninstall and not think twice.

We recommend you spend time and money ensuring the UI/UX is strong, after all, first impressions count.

Care – Native

Afterthought – Web/Hybrid

Time to Market

More often than not, most people looking to build an app have a specific launch date in mind. Obviously the more complex and the more features that your app will have, the longer it will take.

Native Apps take longer to develop due to their high level of complexity, and needing two separate codebases.

Interestingly, Android apps take significantly longer to develop. On average, there is around 40% more code in an Android app than in one built for iOS.

So if you are going to build a Native App and want to be time efficient, starting with iOS could be a good move.

Short – Web/Hybrid

Long – Native

Performance

There is no real competition when it comes to performance, Native Apps win hands down every single time. When you are building your app, you have to think, would you choose to use an app that has great features, but is slow, or one that is fast and has semi-decent features?

The speed of the semi-decent features far outweigh waiting a millennium for a few extra features. There is a good chance that with a sluggish app that crashes frequently or hangs because of a poor data connection, you will lose users.

Hybrid Apps are just browsers with a body kit. Just because they can look Native doesn’t mean they will ever perform as well.

High – Native

Low – Web/Hybrid

Processing Power

Depending on your app, you might require a lot of processing power. If your app has lots of animations and moving parts, like a game for example, then a Web/Hybrid App will most likely let you down here.

There will be frequent laggy periods, and possibly even disconnections when your users are on mobile data.

Native Apps can harness the full power of a user’s mobile device, giving it the edge over the other two types of apps.

High Power – Native

Low Power – Web/Hybrid

Budget

This is the only point that will matter to most people, and we understand that. There is a good chance you have a budget to build the app, especially when you consider the marketing budget required to launch the app.

As with almost any product, the more you spend, the better the product. This is the same with mobile apps.

If you have a low budget or just want to see if the market responds well to your app, then a Web/Hybrid App is the way to go.

However, we urge you to decide upon which type of app you wish to build based on the other factors, not just what you can afford alone.

If you want to give your users the best experience, try to find the extra budget and build a Native App, the rewards are worth it.

High – Native

Low – Web/Hybrid

   

Final Remarks

Most articles and agencies will tell you to build a Native App if you have a big budget and a Web/Hybrid App if you have a small budget, but we feel that approach is totally wrong.

Build your app for your customers, give your users the features and the power they need, after all, what is the point of producing an inferior product? It simply won’t sell.

Whilst all 3 types of apps have their own advantages and disadvantages, to ensure longevity of your app, and success, you should focus on your customers.

There is no magic formula to tell you which type of app you should build.

We suggest you make a list of all the features you want your app to have, then sort these points into a Venn diagram. This will give you a clear picture of which app type is best for you.

If you would like some help and advice when it comes to selecting which app type will suit your needs, don’t hesitate to reach out to us and we will do our best to guide you!