This is the second article in a two-part series. Read Part One here.
Below are some 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.
One possible counter-argument to this guideline is if a cross-platform solution gives you much better team scale. For example, if you already have a team of 20 Javascript developers ready to go, but only a small handful of native developers, you should consider React Native because you can start moving more quickly. If you’re having trouble attracting the right talent, though, take a look at your compensation guidelines — mobile application developers cost ~20% more than senior web developers, according to Robert Half Technology’s salary guidelines.
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 of the current team.Below are some 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.
Prefer a tech stack that your developers are familiar with
Most software developers will only ever achieve fluency in one programming language and are uncomfortable working in others. If the team you have in mind mostly knows JavaScript, consider a web option or React Native. If your company has deep C# and .Net experience, consider a Xamarin app with an Azure backend. If you have a lot of in-house Java experience, definitely consider a fully native app, since Android apps are usually written in Java (or Kotlin), and Java developers can usually pick up Objective-C or Swift quickly.
If you want to support tablets, TVs, or smart watches, prefer a fully native tool chain
Many great non-phone features, like smartwatch UI, picture-in-picture tablet video, split-screen multitasking, etc. are difficult or impossible to implement using non-native features. While any feature can be implemented cross-platform using bridging, extensive use of bridging can make your application more complicated and expensive to maintain than necessary. If these type of cutting-edge features are important to you, prefer a fully-native solution. If you’re leaning towards something less than a fully-native solution, strongly vet its support for the features you need.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, to staff your team this way.If your developers are strong but 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, fixed 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, geolocation, 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 this application provides a competitive advantage for your business, prefer a fully native application
Business investments are typically either tactical or strategic. If this mobile application is tactical — say, an app solely for paying bills for a real-world service — you may want to consider a less expensive option. But if this is a strategic investment — it’s intended to give your organization a long-term advantage over your competitors — you should strongly consider a fully native application, individualized to the operating system you’re running on.If your application needs a “wow” factor, or the best user experience available, prefer a fully native application
Consider the “wow” factors your application might provide. Imagine buttery smooth animations, drag-and-drop multitasking support on iPad, augmented reality, ease of use for the visually impaired, on-device machine learning, background processing, and more. If these appeal to you, a fully-native application is likely the best long-term bet.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 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 you want Google and Apple as marketing partners, prefer a fully native application
If you want your app featured in Google Play or the App Store, go fully-native. Google and Apple can drive large numbers of customers to your app if they’re so-inclined. If your app is a product, where a large number of new downloads would be successful, consider fully native. But if your app is just a channel for reaching existing customers (like a utility company’s account management app), you’re unlikely to get featured, and it’s unlikely to benefit you anyway. One exception to this guideline is games: cross-platform games written using tools like Unity are commonly promoted.If the market is very competitive, prefer a fully native application
Using the fully native toolchain will give you the best opportunity to adopt new technologies because you won’t need to wait for abstraction layers (or roll your own). Many innovations take a while to be ported to cross-platform tools; in the meantime, your competitors’ apps may be outperforming yours.One possible counter-argument to this guideline is if a cross-platform solution gives you much better team scale. For example, if you already have a team of 20 Javascript developers ready to go, but only a small handful of native developers, you should consider React Native because you can start moving more quickly. If you’re having trouble attracting the right talent, though, take a look at your compensation guidelines — mobile application developers cost ~20% more than senior web developers, according to Robert Half Technology’s salary guidelines.
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.Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.
