Since its creation, React Native has been designed to create native applications for Android and iOS systems. It has been proven solid and currently supports many production solutions and has grown into a community with basically endless possibilities. Still, there are not many cases out there, especially in the neobanking space, digging a bit deeper into what it is and how it works. That is why we wrote this piece about the one codebase that can change how you do banking and business.
Introduction to React Native Web
An app written in React Native Web is platform-agnostic. O God, I love that word. Just putting it out there since you will be hearing it A LOT. Why I love it and what it actually means is that there is no reference to react-dom. The components are defined using the platform-agnostic APIs and are introduced by React Native. This allows the app to be rendered on web and native platforms.
To give you an understanding of the absolute top React Native Web features:
Accessible HTML: supports different devices and input modes, and renders semantic tags.
High-quality interactions: supports gestures and multiple input modes (touch, mouse, keyboard).
Reliable styles: rely on scoped styles and automatic vendor-prefixing. Supports RTL layouts.
Responsive containers respond to element-resize events.
Incremental adoption: interoperates with existing React DOM components. Bundle only what you use.
React Native for the web is used all over the world in a variety of industries by companies like Twitter, Flipkart, Uber, Major League Soccer and many more. That testifies its scalability and easy-to-use characteristics. The fact that it also powers web support in multi-platform environments called “React projects”, such as Expo, React Native Elements, React Native Paper, and React Native Base, makes it trustworthy.
When it comes to backend technologies and bugs, it’s usually enough to fix a problem in one place. In terms of frontend, a bug in logic results in propagation on all platforms. Using React Native Web, the problem can be fixed in one place and deployed soon after, thus reducing required resources and time.
React Native in actual day-to-day operations
As a neobank, we are constantly in change and in a state of challenging stuff and improving. Our purpose and right to exist - rests on our vision to improve financial life, to build a new kind of banking experience based on relevance, personalization and intelligence. It means we need to find smart ways to listen to our customers, to be able to update and adapt rapidly. It must never affect the relevance and our relentless search for new solutions that help us create a great customer experience is a vital key component.
Early on, we understood that with this approach, it’s an absolute necessity to have native mobile applications plus web in React Native. Because, simply put, it took too much time and effort to keep writing the same functionalities for Android, iOS and web separately. This also led to situations where three different skill sets were required to write the same thing, since most of the features are platform-agnostic and they all serve the same goal. I mean, the UX and the look and feel should still be the same across all channels.
Not to mention the time to market, which multiplies by three if you are not using a React Native approach. By having native applications you can choose one of these options:
Always wait for all three applications to be ready and have feature consistency
Go live as fast as possible creating differences across the platforms
As we always want to deliver new features to the customers, we were often choosing option two. It is a good approach as long as the customers are using one platform. It is all about aiming to offer the exact same experience, regardless of channel. To me, that is the only way forward.
Another key advantage of working with React Native is that, instead of finding three people - one expert in each area, like Android, iOS and React - you “only” need a talent with React Native skills. I am not saying these talents are easy to find, but in comparison to the classic way of doing stuff, it is - and more scalable as well.
One of the most important drivers for us to choose React Native, was the possibility to migrate the application step by step, integrating new code into the production applications.
React Native Web can be installed in an existing project, which means that current features still work and new features may be created using them. Why is this important? Because there is almost no risk choosing this approach. We don’t need to make a huge investment to rewrite the whole application, and stop a new flow of features and so on. Additionally, when something is ”impossible” to write in React Native, we can always use native implementation, without any debts. Even fancier, we can decide to stop development in React Native and go back to native, without requiring almost any time for another transition.
So, to boil React Native down from a day-to-day operation’s perspective, it’s pretty awesome. We can now go live with new features and other customer value-stuff, and embed it into existing native mobile applications, without rewriting everything from scratch. This is something a few major companies are starting to use, but it’s rarely (if ever?) used by banks. By writing these pieces, we really hope more banks and fintechs will, because I have not seen anything drive the execution of user experience as much as this. Generally, you have the ideas and the capacity, you get the feedback from customers of what they want (or do you really? Well, that is for another time) – but you lack the tools or resources to make it happen. Sorry to break it to you, but your excuses are as per today outdated!
For us, being deeply involved in the React Native project, the overwhelming feeling is that it is like a “disease” and it is highly contagious. Most likely, that’s a poor choice of words, but I want to reclaim it (!) a bit, at least for now. Because what this major project has made us do is challenge other stuff, such as old truths that you need to do stuff a certain way, or whatever it can be. We broke the barrier of being granted a Swedish banking license as a fully cloud-based bank, and we keep breaking new boundaries, because the bottom line is — it is a matter of mindset and approach. Not (just) technical capability.
React Native Reanimated
Reanimated is a React Native library that allows for creating smooth animations and interactions that run on the UI thread.
Experience shows that sometimes certain workarounds or separate animations should be done for the web although a stable framerate is achievable.
Reanimated 2 is already considered production-ready and can be used extensively.
Routing and navigation are fully usable on all platforms with one codebase.
Currently, the following additional web features are available:
URL integration in the browser
Emotion’s “emotion/native” package works great on all three platforms.
However, sometimes you should take a look at certain web-specific parts, such as the outline on the input's focus. In this situation, you should conditionally override this style rule only if Platform iOS is web.
Emotion strips unknown or wrong style values.
Storybook is an open source tool for building UI components and pages in isolation.
It streamlines UI development, testing and documentation.
A “story” captures the rendered state of a UI component; it’s a function that returns a component’s state given a set of arguments.
Stories show how UIs actually work, not just how they're supposed to work which makes gathering feedback and reproductions easy.
Storybook’s new CSF syntax is, however, not yet supported for React Native.
React Native Web limitations and compatibility
This section of React Native Web documentation best describes current web compatibility with React Native -> https://necolas.github.io/react-native-web/docs/react-native-compatibility/.
Things that were inconvenient for us include:
The lack of the KeyboardAvoidingView component (or rather because this one is simply mocked) resulted in keyboard overlapping inputs. We had to use scroll views in that place instead.
Scroll Views do not support momentum scroll events so we had to think of workarounds.
Swipe gestures’ API may be different. We had a situation where ‘locationX’ had to be used for the web and ‘pageX’ for mobile platforms.
Layout Animations do not work for the web.