Picking a Framework for Mobile App Development with Tanzu Labs

At VMware Tanzu Labs, we work closely with clients to deliver user-centered products across a wide variety of platforms, including mobile applications. One of the first questions we hear when consulting with clients on mobile applications is about the selection of development framework—whether to build native apps, use a specific multiplatform framework, or build a web app.

Because we work with a broad range of industries, use cases, development teams, and budgets, there isn’t a one-size-fits-all solution. However, we do follow a methodical process for picking the best framework for a specific project.

In this blog post, I’ll explore the factors that go into the decision-making process.

Let’s start by defining each of the categories:

• Native – Refers to apps written in the respective native frameworks for iOS and Android. They are highly performant, well-documented, and integrate seamlessly with features of their respective hardwares and operating systems (OSs). If you see an exciting new feature in a keynote speech for the newest phone, the native development framework will provide a way for developers to build it into your app. A downside is that they use disparate frameworks (UIKit/SwiftUI vs. Android Views/Jetpack Compose), languages (Swift vs. Kotlin), and development tools (Xcode vs. Android Studio), and can present a significant learning curve for new developers.
• Multiplatform framework – Refers to frameworks that can be written in a single language/framework to run on both iOS and Android. Two of the leading frameworks are React Native and Flutter, with each framework offering different approaches to language (JavaScript/TypeScript vs. Dart) and execution (JavaScript mapped to native controls vs. an entire app compiled to run natively).
• Web app – Refers to apps that can be rendered on web browsers, as opposed to installed from an app store. When designed correctly, they can be styled to dynamically adjust to the resolution of any phone screen. Progressive Web Apps (PWA) add additional functionality such as long-term data storage, allowing for some off-line usage.

A high-level look at framework options

So which one should you choose?

Over the past year, we have increasingly used React Native, a multi-platform framework, and have found it to be both productive and reliable. It has allowed us to develop for iOS and Android without a noticeable degredation in performance, while maintaining a single Typescript/React codebase that seamlessly integrates with multiple native APIs.

This has been a pleasant but somewhat surprising development for us. As a polyglot engineering team, we have no aversion to working across multiple tech stacks, and in fact have on many occasions delivered native iOS and native Android apps in parallel. So when React Native first came out, the idea of a unified code base didn’t present itself as an immediate draw. Instead, we were more concerned about the whispers we heard around performance limitations and interoperability issues with native APIs.

What we’ve learned more recently from actual use in client engagements, is that while there may still be some limitations, the pros of a smooth, efficient development process outweigh any cons related to performance or interoperability.

What we like about React Native

Here are some reasons we like working with React Native. While these individual factors may not be unique to React Native, we have found it to be the framework that best meets all of them.

• Ease of staffing – Unless you have an engineering team dedicated to native iOS and Android development, there will be at least some cost related to learning the respective languages and APIs. In contrast, most engineering organizations will already have a lot of engineers experienced with Javascript, and often-times with React as well, even if limited to its web-based cousin. In fact, JavaScript and React were the most commonly used language and web framework among professionals in the 2023 StackOverflow Developer Survey, making it the easiest stack to hire for, if needed. React Native is not identical to React for the web, as engineers have to learn about React Native UI components such as <Text> and <ScrollView>, and style with StyleSheet instead of CSS. However, we have found that experienced React web developers are quick to get up to speed and comfortable with React Native.
  (Note: for enabling engineers on new technologies, we strongly recommend pair programming and regularly rotating pairs.)
• Less code to maintain – Having a unified codebase simplifies the development process significantly, as features for iOS and Android can usually be delivered in parallel, using the same UI templating code. For specific cases where UX features diverge, splitting logic between devices is as simple as prepending the file with an .ios or .android designator.
• Negligible performance degradation – We found there to be a negligible impact in business-like use cases, such as submitting forms or displaying dashboards. From our user testing and interviews, we didn’t get any feedback related to responsiveness.
• Seamless integration with hardware features – We had no issues with our relatively simple use cases, such as access to the camera or location services. We have also found through some technical discovery spikes that the process for writing native modules has improved, giving us confidence that if we need to access a new hardware feature that doesn’t have a published wrapper, we can write one ourselves.
• Quick onboarding – The Expo platform for React Native, with its complementary services (e.g., the Expo Go app and EAS Build) allows engineers to configure, develop, and even build for iOS and Android without relying on XCode or Android Studio. This, coupled with the unified codebase, made onboarding new engineers a breeze.

What about other multi-platform frameworks?

While we’re pretty happy with React Native, we are open to working with alternatives for specific use cases.

• Flutter is an option if we hit any roadblocks related to performance, and it allows teams to develop in a single codebase using the Dart language, and has a vibrant developer community.
• Ionic is an option if the client has a preference for developing in Angular or Vue.
• .Net Maui/Xamarin is an option if the client has a preference for developing in .NET and C#.

What about native?

A native app may be preferable if

• Users require a touch/gesture-centered experience or highly dynamic user interface
• Users require an app that uses bleeding edge hardware/OS features such as augmented reality or virtual reality (AR/VR), as they are released
• The development team capable of picking up multiple tech stacks easily

While multiplatform frameworks like React Native and Flutter have made strides in closing the gap, native frameworks will always win in terms of performance (e.g., responsiveness to UI input, rendering/re-rendering of complex graphics), and timely seamless integrations with hardware and OS features. How big are these gaps? Not big enough to matter for most use cases. As mentioned above, we haven’t faced any issues in recent projects, where we integrated with phone features like the camera roll and location services. However, if you rely on game-like gesture inputs or integrations with cutting-edge features like ARKit, you may want to opt for building natively. 

What about web apps?

A web app is the simplest of the options, and may be preferable if

• The business/user requires an app that can be updated frequently in short intervals
• Users will use the app in a browser instead of installing and opening an app
• Users will accept limited off-line use
• Users will accept an app that makes limited use of hardware features such as VR/AR, health, or payments.
• Users can use a relatively simple UX such as buttons and scrolling, as opposed to dragging or animations
• The development team has the means of hosting the website (This could be as simple as setting up a Tanzu Application Service staticfile app, but it’s still some ops work that would be added to the development team’s plate.)

There’s no denying there’s a certain cool factor related to having your own app. Every business has a website, but do they have an app? This pursuit of the cool can lead some companies to build a mobile app when their users don’t really want one. 

It’s easy to forget that there are real advantages in limiting your experience to a web app. A principal one is that every phone has a built-in browser, so there’s no required additional step of installing an app from an app store.

Additionally, your release cadence is limited only by your own in-house development pipeline, as there is no app store approval process acting as a bottleneck to getting a production release. This means that for a well-oiled agile team, follow-on features and bug fixes can be delivered to users within hours, or even minutes of a previous release. And in terms of building that team, web apps have the broadest pool of candidates to choose from, given the ubiquity of JavaScript/Typescript, and the popularity of frameworks like React, Angular, and Vue.

Thinking about building a mobile app?

Please reach out to us! We’d love to learn more about your new or existing mobile app.

While we’ve been increasingly using React Native for new mobile apps, we have extensive experience across development platforms, and enjoy working closely with clients to build out the technologies and processes that work best for them.

The following are some signs that we may be a good fit for you:

• You care deeply about your users and believe in building features to meet their needs, ensuring product-market fit.
• You believe in balanced product teams, ensuring that business needs, user needs and technical concerns are taken into consideration in the decision-making process.

You believe in quick and frequent production deployments and are open to practices that enable that such as continuous integration and continuous delivery (CI/CD), test-driven development, and pair programming.