The roadmap for building digital products is fairly straightforward.

1. Identify real people that are experiencing a real problem.
2. Come up with a clear solution that helps solve that problem.
3. Build out the product and introduce it to your audience.
4. Iterate over time based on the feedback you get as real users actually use the product.

The problem with the roadmap I just laid out is that it’s wildly more complex in practice. How are you sure that you’ve identified a real problem? How do you know that your solution is the best? Should I build it myself or with others? How do I effectively market the solution? How should I distribute it to users? How in the world do I fund this thing?

So many great ideas never see the light of day because of barriers that can paralyze individuals and teams from ever even attempting to build a solution. And even as products are being built, features naturally evolve due to shifting priorities or unforeseen complications. Like many others, I work on teams that are constantly working to shape ideas into solutions that can meet user expectations within the natural boundaries that come with smaller teams.

On mobile app projects, we’ve invested heavily into React Native as a platform for building products that scale for both end users and development teams. And why shouldn’t we? The product is backed by Facebook (now Meta) and has been implemented by well established teams like Microsoft, Salesforce, Shopify, and Uber. It allows development teams to use a single code base to write apps for multiple platforms, eliminating the need for speciality platform-specific teams. Since the framework is just rendering native components under the hood, creating a Text Input in React Native will look and feel proper to both your iOS and Android users alike. While this is all true, it can be really easy to be enamored by the convenience of React Native and miss the “native” part of the platform.

The React Native team even addresses this in their Team Principles right off the bat, calling out that their “top priority for React Native is to match the expectations people have for each platform.” Take a second and think about what makes an app “native”? In other words, what makes an iOS app, well, an iOS app? An Android app? macOS? Web? There are likely a couple of things that jump to mind right away like navigation, gesture controls, and input styles. What often happens is that we limit the definition of a “native” app to just the way our app functions while users are inside of our application. A truly “native” experience breaks beyond the borders of our own applications and expands across the entire system.

Matching Consumer Expectations

Consumer expectations for mobile apps vary greatly from device to device. Each operating system offers a unique approach to platform specific features that set a precedence for entire application categories. And even within each platform, special consideration is taken based on the device that platform is consumed on (for example, iPadOS and AndroidX are unique expressions of iOS and Android built for large-screen devices). Users are consuming our products on a device of their choosing because of features that their device convinced them was better than the competition. But how is that relevant to us? Isn’t that just Google and Apple’s problem to battle out?

There’s an inherent symbiotic relationship between platform creators and developers. The hardware and software features offered by each platform are really only useful when they’re consistently presented to the user. The push and pull is for the platform creators to make these accessible to the developers so that platform features get used by more apps and therefore shown more often to their users. These features set the device your user is holding apart from the one sitting next to them. Apple wants your app to run differently on an iPhone than on an Android – It’s the unique features that are offered on these platforms that convince users to buy their devices. What we’re seeing as time goes on is that developers who invest extra time in all aspects of native applications will get more on-device promotion. In short, iOS and Android reward apps that adopt the “native” aspects of their operating system by making those apps more visible to users. And this means more time spent in your application.

What can happen when using frameworks like React Native is that development teams get so excited about the conveniences that React Native offers that they forget the main point: “to match the expectations people have for each platform.” The biggest return earned by development teams who invest in React Native is simple: time. The time that we earn during the development cycle should be reinvested back into more nuanced native experiences in order to provide more value to our users than we could have otherwise offered.

Now’s the Time to Get Native

Like most things in life, integrating native experiences within React Native is easier said than done. You have to invest extra time in understanding React Native under the hood, still need to know additional programming languages, and need to truly understand the expectations that each native platform is setting for its user base. Thankfully, React Native is Open Source, which means this is a burden that we all share as React Native development teams globally.

At the end of the day, you shouldn’t have to choose between scaling your product and adding rich, native features to your product. I would encourage you and your team to invest time in understanding each of the operating systems that your product will be offered on and invest in third-party tools that make it easier for your team to both scale and provide deeply integrated experiences for your users.

At Differential, we’ve begun to take next steps toward investing time and effort into bringing the “native” back to “React Native”. Since the announcement of Live Activities and Dynamic Island (launched with iOS 16 and iPhone 14 Pro), we’ve been working on integrating Apple’s new ActivityKit framework into React Native. In a follow up to this (coming soon), I’ll break down how we used the concepts discussed above to build this package, and how you and your team can get started on these exciting new features.

Thanks for taking the time to read this. Now go build some dope 💩.