As a decision maker, your job is to find the best way to get things done. When building a mobile app, one of the first things you’ll find is that there is a wide array of technologies available to build your product. Deciding between sci-fi-sounding technologies like React Native, Ionic, or Native can be quite overwhelming when you are getting started with mobile development.
If you happen to choose a technology that doesn’t match your use case or starts to show its limitations, it’ll force you to either build a sub-par product or start over again, neither of which are fun (or cheap) things to do.
To help you make this choice, we prepared a short guide that covers the main alternatives you have when you want to build a mobile app with the main pros and cons of each option. And, more importantly, a set of recommendations to hopefully point you in the right direction.
There are four main options to keep in mind when you build a product for mobile:
- Progressive Web Apps (PWA)
- Native Apps for iOS and Android
- “Hybrid” Apps with Ionic & Cordova
- React Native Apps
For the rest of this article we’re going to assume you want to ship your product for both iOS and Android while making sure both products have a similar level of quality and polish. Some companies try to save money by building their product for just one platform (or abandoning one and focusing on the other). All that does is make users resent you. I’ll cover each one of these alternatives in this article, including the strengths and weaknesses of each platform based on our experiences working with startups and big companies at Aerolab.
Also, at the end of the article you’d be able to download our business-oriented cost comparison guide that will give you a clear picture of how much money and time would cost you to build a mobile app in each one of this technologies.
Building a PWA
Building for the web is and has always been the most effective alternative to get your product in the hands of the largest possible number of users. Even if Progressive Web Apps aren’t mobile apps in the strict sense of the term, we had to include this option somewhere in the article because it can be a great option for shipping Minimum Viable Products (MVPs) or trying out a new market without having to invest a ton of time and money.
A PWA is effectively a Web App that’s heavily optimized for mobile and has some very popular features like offline support and notifications. What’s more, they can be added to the home screen in a way that makes them look like a mobile app, and because you don’t have to deal with clunky app stores, you can have conversion rates that are many times better than a typical app from the store.
There’s one caveat, however: PWAs are web apps at their core and they are designed to run in a browser. This means that you don’t get access to most of the native technologies apart from notifications and offline support. And even those two features are limited to Android (though iOS support is expected to land sometime in 2018).
What makes them so enticing is the fact that you can build a single product for Desktop and Mobile with no app stores to deal with. It’s a great way to expand your product line at a very low cost, since most startups offer their products as web apps anyway, and adding PWA capabilities doesn’t take a ton of effort or development costs.
While they don’t cover most of the use cases for Native Apps, PWAs can be an amazing alternative for media and ecommerce companies. You can read up on them in our article on why you should consider building a Progressive Web App.
- PWAs are web apps, so they’re easy to access from any device since all you need is a link and a browser. There are no app stores or complicated install processes to deal with.
- Unlike mobile apps, properly built web apps are indexed on search engines (SEO) and can be shared on social media very easily. On news and media sites, Facebook and Twitter are essentially your entire user acquisition funnel, and this helps offer those users a better experience.
- PWAs are quite friendly to low-end devices, which makes them a great option for emerging markets. Since they are extremely lightweight they can be added to the home screen instantly, and users don’t have to start deleting stuff from their phones to free up enough space for a new app.
- PWAs are mostly intended for media products like news sites, lightweight social networks, or online stores-all products that work very well as a web app. For other use cases (mobile banking, social networks, or complex apps in general) you’re going to hit the limits of the technology pretty much instantly.
- The nicer features of PWAs (notifications and offline support) are only supported on Android devices, and partial support for iOS is expected for late 2018. While that’s far from being a deal breaker, you need to keep this in mind so as to not disappoint iOS users with features that don’t actually work.
Google has some very good case studies featured on its developers site, but if you want to skip straight to the best examples, PWAStats showcases the best PWAs for both big and small companies and there are some pretty amazing gems in there.
One of the crowd favorites is Forbes’ success story, where building one of the best Progressive Web Apps in the media industry got
On the ecommerce side of things, results are even more dramatic: Housing.com improved its conversion rate by an impressive 38%, which even pales in comparison with Alibaba, who got an insane 76% increase in conversion on mobile. All of these metrics have a direct impact on the bottom line of these companies, and they clearly prove just how much users prefer fast, mobile-friendly products.
So when should I choose a PWA?
If you are building a news/media app or just focusing on emerging markets, a PWA is the way to go. You can tackle all devices with a single product at a much lower cost and get some of the most popular features for native apps (notifications and offline mode) on Android, which is the platform of choice for 90%+ of the users in Latin America and emerging markets.
Building Native Apps
Native Apps are the gold standard for mobile app development, and they essentially mean that you are building your products with the official technologies and SDKs from Apple (iOS) and Google (Android).
This effectively gives you access to the latest and greatest for each platform, as you have full access to the Beta SDKs, and most vendors release their plugins for native development first, hoping the community fills in the gaps for other options at a later date. From a purely technical point of view, this is the best option and the one that gives you the greatest degree of freedom, since you are working very close to the bare metal.
There is, however, one big downside to native apps: each platform uses different technologies, practices, and standards, which means that if you want to go native you are essentially committing to building and maintaining the same app twice: once for Android, once for iOS. As you can imagine, this can get expensive very quickly.
What’s worse, native platforms have some steep learning curves (iOS being a bit harder than Android), which makes finding and training developers for your products an expensive and time-consuming ordeal. This makes it difficult for your dev team to switch back and forth between each platform, making management harder as well.
This high degree of specialization required for native development on Android and iOS means that you’ll often end up having your releases go out of sync due to issues on one platform, which makes development much more expensive.
Some companies deal with this level of complexity by focusing on just one platform and leaving the other by the wayside, which only serves to enrage a large chunk of your users and is never a good idea.
While it’s the strongest option from a technical point of view, building native apps can only be a solid alternative if you actually have the resources to build and maintain two high-quality products in parallel, which is rarely the case for startups. As such, it’s an option we rarely recommend unless you have a clear path to being able to sustain the product in the long run.
- You can get the best possible performance out of each platform (if you know what you’re doing), since using the official technologies gives you a much greater degree of control over your app, as well as letting you heavily optimize your code for your specific use case.
- You get access to the latest APIs and techniques, since you are working with the official tools and technologies for Android and iOS, including access to Beta versions. So, basically you can support new features the second a new OS goes live.
- Having the latest tools and technologies of the platform and the ability to finely tune your code means that going native effectively removes most of the technical barriers and limitations to build your product, giving you more freedom and a greater arsenal of tools and libraries.
- It can get really expensive. You’re essentially committing to building the same product twice (once for Android, once for iOS, with very little shared code), for the rest of the product’s life.
- Good mobile developers are notoriously hard to train and find. And if you’re working with less seasoned developers, you won’t be able to take advantage of most of the benefits of the platform.
- Handling two developer teams working on two products with different technologies can be difficult to manage, and you’ll often get the releases out of sync due to issues with one particular platform.
One of our favorite projects at Aerolab was the work we did for Taringa, one of the most popular social networks in Latin America. The app is essentially a news feed populated with a massive amount of images, videos and has a very complex notification system.
On this app’s news feed, we had to spend a ton of time optimizing the code behind the scenes to load multiple GIFs seamlessly, including support for WebM and many custom plugins in order to squeeze in a bit more performance and faster load times. This would have been very hard to do on anything but native code.
Something similar happened to the notification system, which was completely redesigned in order to take advantage of the latest features in Android, including merging notifications so they behaved in a much smarter and less intrusive way.
So what is it good for?
If you want to take advantage of the latest tech, building a Native app is the way to go. While it’s more expensive and harder to manage, if you have a talented team you can squeeze every last bit of performance out of the hardware, and you get prime access to the latest technologies from iOS and Android.
Building a Hybrid App with Ionic
You’ve probably heard of this option if you’ve ever complained about the costs of building a native app, since it effectively allows you to build a single app that works on both Android and iOS. Sounds amazing, right? Ionic + Cordova (previously known as Phonegap) is one of the most popular alternatives for writing mobile apps.
If you want to draw a parallel, Ionic is kind of like writing a PWA and giving it access to the platform’s SDKs so you can ship it in the app stores. As a result, this technology can be much cheaper than going native, so it’s widely used for internal corporate apps, where costs are always paramount.
The reason why these “Hybrid Apps” are so much more affordable is that the core of the product (all the integrations and business logic) is written only once and shared across both platforms. Even the UI is written as generic components that automatically look different on Android and iOS, saving some device-specific tweaks. As a result of this, development costs are roughly 40% cheaper than going native in our experience, and that includes a bit of extra time to do some fine tuning on the design for each platform.
Ionic has a massive downside, however. Since apps built with Ionic are basically web apps that are expected to perform like native apps, performance on low- and mid-end devices is often somewhere between abysmal and atrocious, which just feels cheap. While that can be acceptable for internal corporate apps, for end users this leads to terrible products.
Building web apps can be deceptively prone to horrible programming practices, so most of the apps we’ve audited on the platform are pretty much unmaintainable. As a result, this ends up being a case of “you get what you pay for.”
While it’s possible to build good apps with Ionic, working around the bugs and limitations of the platform can be so time consuming that at some point you might as well just switch to writing native apps and save your team a few headaches.
- It’s cheap! You get to build an app for both platforms with half the team. There are also lots of resources for this technology so you can build basic apps relatively quickly.
- Web technologies are easy to learn and HTML+CSS+JS is the most popular platform on the planet for building apps, so it’s much easier to find and train developers to work on your product when compared to native apps.
- It can be a good alternative for internal apps where costs are paramount and quality standards and expectations are a lot lower.
- In most cases performance is terrible. Cordova as a platform is also notoriously prone to weird bugs and compatibility issues.
- Apps from the store are subject to much higher quality expectations, so this ends up surfacing as a bad user experience.
- You often have to wait for months for new features to become available on the platform, and even then they are often riddled with bugs.
Due to its low performance and the visual and technical glitches you get from this approach, we don’t really work with Ionic at Aerolab. There are, however, some good examples being featured in the Ionic Showcase, like Pacifica, a meditation app, or Marketwatch, a stock news and data application.
So what is it good for?
If you are building an internal app, both Ionic and React Native (discussed below) can be a solid alternative. Both alternatives have similar costs and require the same underlying technical knowledge, so the choice is really up to the technologies your team is the most familiar with.
Building a React Native App
React Native takes the best from both worlds (Native and Hybrid), making it the first approach to building mobile apps that actually allows us to build products that feel amazing at a cost that makes management happy.
But there’s one key difference here: instead of using a browser with HTML+CSS, React Native takes your code and effectively turns it into a native app behind the scenes. This means that the entire UI, which is what ultimately drives the user experience, is running the same technology as the best apps in your phone, with no compromises.
This diagram shows the process at a high level: On the left you have the actual React Code, and React Native transforms it into the native code used to actually draw the screen. The code itself is fairly straightforward as well. The Status Bar is a Button is and so on, and you don’t have to bother with any of those pesky implementation details.
While it’s a relatively new technology, React Native is very approachable, and one of our favorite tools for showing the power of the technology is Expo, a tool that lets you easily start building mobile apps with React Native with a live preview on your own device, something that’s hard to do right even with native apps. If you want to give it a shot, try Expo Snack, an online IDE for trying out ideas in React Native without installing any development tools whatsoever. While it’s only there to get a feel for the platform, it’s an absolutely amazing tech demo.
This approach finally bridges the gap between the great performance of native apps and the cost benefits of hybrid apps in a way that makes us happy. Incidentally, React Native is what we’re now using for all our mobile projects at Aerolab after working purely native for the past few years.
- Performance is excellent and on par with a native app, due to running native code behind the scenes for the UI. Because of this, new features are readily available, and you can use native code if you need to do anything more involved like AR, VR, or handle sensor data.
- It’s also cheap! Since you are building the same app for both Android and iOS with very minor tweaks, you can build an app with half the team compared to fully native apps.
- For CPU intensive tasks (like complex news feeds, for example) JS can show some performance drops.
- There’s a vast array of libraries for basic things (like UI or navigation), which can be overwhelming at first and require a bit of research before building your app.
React Native is used in a ton of apps by big companies. Of course, one of the first ones was Facebook (creators of React), using it both in the Facebook App and the Ads Manager, and there’s also UberEATS, Airbnb, Instagram, Wix, and many other React Native projects with thousands of users and product teams that focus heavily on user experience.
So what is it good for?
If you want to build a great MVP that scales over time, React Native is a fantastic option from a product perspective. You get the great performance from a native app and the very significant cost savings from building a product for all platforms at once. The technology is also flexible enough that you can easily grow your product with native components as time goes on.
This was an introduction to the technical side of building your mobile product. Each one of these technologies has its pros and cons, with costs and timelines varying between each option.
Discover exactly how much time and money would cost you to develop your mobile app with each one of these technologies. Download our business guide for mobile projects👇