Choosing the right mobile development tools — Part One

This is the first article in a two-part series. In this first part, we'll explore the five development options open to you as a mobile developer; in the second part, we'll look at how to decide which options are appropriate for your project.

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 options

There 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:

Responsive website

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.

Progressive web application

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.

Hybrid 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)

Tools like Xamarin (in the C# language) and React Native (in JavaScript) let you write native mobile applications once, and run them on Android, iOS, and sometimes Windows. They may provide benefits in letting a familiar team get up to speed faster, but have a few drawbacks. For example, these tools may lag behind the official tools, reducing your ability to adopt new innovations. Also, keep in mind that cross-platform tools which render UI at runtime (like React Native) may be slower. Finally, some features might not be available. For example, React Native components can’t run on Apple Watch. Cross-platform application development can be very powerful, but make sure you carefully and critically examine the solution thoroughly for your long-term needs.

React native considerations

React Native’s cross-platform approach is especially appealing and deserves some special consideration. React Native projects are written primarily in JavaScript and are converted to native views at runtime. This can give your team an intense advantage: write code once that runs on both iOS and Android. Another advantage is live-updating code which makes UI iteration very quick. The other advantages of React Native are very strong and are documented on their site, so I won’t rehash them here. The risks associated with adopting React Native are less well-documented. Some include:

• Your application will be slower due to the additional overhead of the JavaScript runtime thread which live-translates your JavaScript into native view layout code. For many applications this is imperceptible, but CPU or memory-intensive applications may want to avoid React Native. One noteworthy consideration is the iOS Today Widget, which has a brutally small memory limit; you’ll likely want to implement this using fully native code.
• 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.
• Your application can be written entirely in JavaScript only if all of the components you need are already available. If you need additional components, or want to embed fully native code, you’ll need to create “native modules” (iOS; Android) to bridge your JavaScript code to, say, Swift and Java. While this ability is a powerful option, there's a risk that overuse that will make your application too hard to understand, test, and debug. As your application complexifies, it may become two apps written in three languages rather than two apps written in one.
• 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.

React Native is an extremely valuable tool for many applications, but it’s important to think through the risks and your desired outcome.

Fully native application (Xcode & Android Studio)

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: 

1. It’s harder to find qualified developers, and
2. That App Store rules and submissions can slow your release process.

Neither of these drawbacks apply to creating a mobile-friendly website. If you have the time and budget to spend on a great experience, there’s no choice that will give you a higher-quality output.

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.