When beginning a mobile project, one of the earliest technical decisions is which tech stack to use. For many applications, this decision can have bigger long-term consequences than a similar decision for a website, because migrating an existing user base from one stack to another can be very difficult, and it’s sometimes impossible to do iteratively.
This article outlines the major options, their pros and cons, and provides guidelines to help you decide.
Five architecture optionsThere are several options, but the line between them is blurry since it is possible to mix technologies in a few ways. That said, there are five general categories:
A responsive website is called 'responsive' because it’s designed to respond to the users’ environment, which may include different devices, form factors, interaction modes, and connectivity states. Three CSS techniques — fluid grids, media queries, and flexible media — ensure that the site is appropriately sized and adjusts to different devices. And the use of advanced image strategies, like expandable and compressive images, high-DPI raster images, vector images, and SVG, can quickly render the site correctly for even devices with very modern displays.
This is generally the cheapest option, and it’s definitely preferred over creating a separate 'mobile-optimized' website. It’s also usually the fastest to create, and the easiest to find enough developers to work on. But it’s also the most limited, with the lowest performance, slowest ability to adopt new innovations, and poorest integration with more advanced features like push notifications, Bluetooth, on-device storage and cryptography, background sync, Siri / Google Assistant integration, and many others.
A progressive web application (or “PWA” for short) is newer technology that’s a responsive website with extra features added to improve offline usability, speed, and user engagement. Supported browsers (like Chrome, Firefox, Opera) can treat the website like a native app with features like offline and background access, push notifications, and a home screen icon. Unsupported browsers (Safari has only very minimal support, for example) fall back to the “responsive website” behavior, although may still benefit from the optimizations teams typically make as part of a PWA implementation. Other “native-like” features are typically implemented although not technically part of the PWA minimum requirements, for example, native/web credential sharing, geolocation, deep linking, Google Payments API / Apple Pay, etc.
Progressive web application
There are many types of hybrid architectures, but at their core they all include a native application that relies on webviews for rendering and displaying content. If you consider a hybrid application, you’ll also have to decide where on the native-to-web spectrum your app will fall, since the decision is not binary.
Native wrapper around WebViews
The webbiest approach is to take a shell of a native application and render all content and UI controls in a web view. From there, you might add some native features like interactive push notifications to make the app feel more native. This approach is typically used to move quickly when the app is still wanted in the App Store, or when only a few native-required features are needed, and the user experience isn’t critical. When investigating this option, keep App Store Review Guideline 4.2 in mind:
"Your app should include features, content, and UI that elevate it beyond a repackaged website. If your app is not particularly useful, unique, or “app-like,” it doesn’t belong in the App Store."
The most popular tool for this is Apache Cordova, but with the availability of PWAs (web), React Native / Xamarin (cross-platform; below), and fully native options, it’s difficult to think of a new project where Cordova is the best technology choice.
- Native interaction with some WebView content
A more robust hybrid app uses mostly native controls for navigation but uses webviews for rendering content, or as a temporary fallback for very new or rarely accessed content until a native version can be developed. This approach can be very helpful for dynamic views which should look nearly identical across platforms. For example, an airline application might use a webview to render a boarding pass from the same code on Android, iOS, and mobile web.
One novel approach is to use web views for new content or new content types, and replace them with native experiences as your development team’s capacity allows. Basecamp 3’s hybrid architecture uses this approach by loading all content from a URL. If the app’s router finds a native control that can handle the URL, the native control is displayed; otherwise, it’s loaded in a webview. The turbolinks-ios library can help tremendously in organizing the complexity here.
Of course, you may have a fully native application that includes some web views. As you replace more and more webviews with fully native components, do you still consider your application “hybrid”?
Cross-platform application (e.g. Xamarin; React Native; Unity; Flutter)
React native considerations
- Many React Native components provide an oversimplified user interface or, worse, a user interface for only either iOS or Android. Android and iOS have different user interfaces. While some differences are abstracted and handled well, such as the react-native-navigation components, and while there are workarounds and mitigation strategies, React Native introduces a tension between providing great user interfaces while writing and maintaining simple, easy-to-understand code.
- There’s a risk Facebook may stop developing the React Native tool (as it did with Parse), or that its implementation of new iOS and Android features may be too slow for your app to stay competitive. This is a minor risk; Airbnb and other large companies are taking the same gamble.
- The development and debugging experience for React Native projects isn’t as friendly as either Android Studio or Xcode provide, so there is some risk you’ll spend more time than necessary debugging. While WebStorm and IntelliJ IDEA provide a pretty good experience, they’re both pricier and not as good as their free, native equivalents. If you don’t buy an IDE, you’ll likely using a text editor and Google Chrome for debugging.
A “fully native” tech stack refers to using the mobile operating system’s preferred toolchain for creating applications. This means using tools like Xcode and Swift on iOS, and Android Studio and Java for Android. This approach offers the foundation for the highest possible quality application. Graphical and app performance is fastest; new innovations are delivered here first. The primary drawbacks are:
Fully native application (Xcode & Android Studio)
- It’s harder to find qualified developers, and
- That App Store rules and submissions can slow your release process.
In the second part of this two-part article, I'll explore in more detail how you decide which approach will work best for your mobile app.