Choosing Right Way to Mobile Development

When beginning a mobile/technology 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 technology 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.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. The main tools to look at here are:

  • Three CSS techniques — fluid grids, media queries, and flexible media — ensure that the site is appropriately sized and adjusts to different devices.
  • Use of advanced image strategies, like expandable and compressive images, high-DPI raster images, vector images, and SVG that 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 a newer technology that is a responsive website with extra features added to improve offline usability, speed, and user engagement. Its key features are:

  • 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, for example, native/web credential sharing, geolocation, deep linking, Google Payments API / Apple Pay, etc. are typically implemented although not technically a part of the PWA minimum requirements.

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.

Fully native application (Xcode & Android Studio)

A “fully native” tech stack refers to using the mobile operating system’s preferred tool chain 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, however, are:

  • It’s harder to find qualified developers, and
  • 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 other choice that will give you a higher-quality output.

Decision guidelines

Developing fully native applications is like buying a sports car: it’s a fun, full-featured option, but typically expensive and not always the most practical. It should be done after carefully weighing the product’s budget, the mobile app’s strategic importance, and capabilities and cost of the developers available in the market.

Below are some quick guidelines to help you decide which tech stack would best fit your application. The best decision is rarely obvious and can usually only be made after a thorough cost-benefit analysis.

  • If you want to support tablets, TVs, or smart watches, prefer a fully native tool chain
  • If your budget is small, prefer a web solution
    The web is standard, and there are many frameworks that can move you along very quickly. Frontend web development is one of the most common specialties, so it’s easier, and often less expensive
  • If your timeline is tight, prefer a hybrid application
    Great native applications are very high quality. Like other high-quality goods, they require time and effort to build and polish. Even if you have the best developers in the world, if business conditions give you a tight deadline, native applications can be risky. Consider using a hybrid application, which allows you to iterate quickly with the web, and then once the deadline has passed, iteratively replace web content with native content if needed.
  • If your user base is mostly Android / Windows users, consider a progressive web application
    Most wealthy U.S. residents use iPhones where PWAs are mostly unsupported, but in some other segments of the population, Android is immensely popular. If most of your users will be on Android anyway, consider a progressive web application which can still take advantage of offline support, geo location, push notifications, payments, Bluetooth integration, and more. At the time of this writing, many of those features will only be available on some platforms — but if that’s not a deal-breaker, progressive web applications may be for you.
  • If your Android and iOS applications can look and act nearly identically, prefer a cross-platform application
    Android and iOS applications generally shouldn’t look and act the same; their user interface guidelines (iOS; Android) are completely different. If you don’t mind ignoring many of the guidelines and developing one UI for both platforms, a cross-platform application may be just the one for you.
  • If you’re just testing the market, consider a responsive or progressive web application
    Web apps are the cheapest to create and the fastest to iterate on. If you’re not sure whether your product will be valuable to end users, it might be better to just start with a web app.
  • If security is critical, prefer a cross-platform or fully native application
    For full control of offline support, data encryption, credential storage, certificate pinning, jailbreak detection, and other important concerns, consider a cross-platform or fully native application which will allow you to access increased security features. Also, consider avoiding very dynamic programming languages like JavaScript and Objective-C. Dynamic languages are more vulnerable to type mutation, buffer overflow, and method swizzling attacks than more static languages. If you need to use JavaScript, for example, if you’re using React Native, consider using JSX type annotations.
  • If your users are all internal customers (e.g., employees), prefer a PWA or hybrid solution
    UX should generally be considered more important for internal apps than external because your app needs to accommodate expert user productivity, rather than a more simple design that typically guides users towards through a few more straightforward flows. (See Corporate Employee Apps: Does User Experience Matter?.) That said, internal, employee-only tools often get less budget for design niceties than paying customers. If the UI/UX isn’t a major concern of yours, PWA or hybrid apps might be a good fit.