After rapidly maturing over the past few years, React Native has ironed out a lot of the initial performance issues, easily making it into Stack Overflow’s “most loved framework” list. As it passes its 5th birthday, how many fans does it have in the Financial sector?
I was delighted to host the second in my series of React Native Leadership forums, this time with leaders from Fintech and Finance communities. If you’re interested in attending the next one, please get in touch. A massive thank you to my facilitator Liz Warner and my speakers Stefano Restaino, Omer Duzyol, Shaun Bohannon and Aubrey Stearn.
“Learn once, write anywhere – are we finally at the Holy Grail?”
The ability to write cross-platform apps is one of React Native’s biggest selling points. So how much does it really live up to the hype according to my attendees?
Undoubtedly, performance isn’t perfect – though React Native supports many different platforms, it doesn’t necessarily run with the same potency on them. There were doubts as to whether it would be able to sustain a highly intensive app with a substantial visual element, like a game or an Augmented Reality experience.
However, it comes down to picking the right tools for the most job. Most finance apps are essentially displaying data, something React Native can do comfortably, and their users are more likely to expect robust functionality over beauty in their apps. Although React Native doesn’t completely eliminate the need for some native language skills, attendees were pleasantly surprised by how much they could achieve with pure JavaScript without delving into the native layer.
Ultimately, we may not ultimately reach true interoperability until mobile operating systems agree in some shared standards amongst themselves, as the major browsers have done.
Security and building apps in a regulated space
As well as discussing React-specific topics, attendees also delved into what it means to build Mobile Apps in a highly-regulated space like banking. In particular, marrying financial regulations with the requirements of testing is a perpetual difficulty. This is where start-ups and challengers have the potential to gain an advantage by employing workarounds with a flexibility which incumbents generally can’t reconcile to their security posture.
One prime example is around how to share credentials for testing purposes on the production site for the App Store reviewal process. Start-ups are able to employ workarounds like creating designated credentials for a disconnected bank account, where logging in gives you only the “read only” permissions necessary for testing. As this practice is technically “insecure,” it’s unlikely to be approved in major banks which are more risk-averse. Start-ups, on the other hand, have more freedom to weigh up decisions around risk and therefore get through approval processes more quickly.
Often, there are a myriad of solutions for meeting security regulations, as it’s highly likely that other companies will have already developed best practices which can be drawn on. For aspects like strong customer authentication from the PSD2 regulations, what requires more creativity is how to employ appropriate security whilst maintaining the best user experience.
With regards to React Native itself, it was suggested that securing a RN application is not any different from securing native mobile apps. Whilst it is key to secure your JavaScript bundle from being reversed, the source code in native languages like Java is open to the same threats. Risks are most likely to come from the propensity of some React Native developers to use untested community libraries which may not comply with financial policies. However, once again this also applies to native libraries – as long as you do your due diligence, React Native itself doesn’t increase security risks.
Deployment, Continuous Integration and Testing
Some of our attendees are web dev to mobile converts, and one key subject of discussion was the increased complexity of deploying to mobile compared to web. In particular, they raised the issue of ensuring the backwards compatibility of their newly released API packages so they can be deployed to the App Store reviewers without breaking the old version of the mobile application for their users. Techniques to combat this which were discussed were version-based routing, deploying multiple versions of the core API and using GraphQL to ensure backwards compatibility.
To ensure that all the moving parts work together, Continuous Integration tools have a complex job in front of them, managing immutable deployments of the mobile application and APIs with every minor change. Tools cited as helpful were Fastlane, a Continuous Integration tool, which reduces the complexity of deploying to IOS and Android, as well as Circle Cl or Travis and Kubernetes on the back-end pieces.
Given this complexity, Continuous Integration for Mobile apps is more costly and more time-consuming than for web. With standard React Native mobile applications requiring at least three languages, compilation can often drag, leading to a long build queue and what feels like inefficient process. One attendee suggested waiting time can be cut down by up to 75% by separating the time-consuming compilation of the native code from the comparatively quick compilation of the JS, and incorporating a Continuous Integration design that only compiles the JavaScript if these are the only changes being made.
In terms of other tools: Detox and Appium were mentioned for test automation, whilst several attendees had used TestFlight for manual IOS tests prior to AppStore deployment.
React Native vs Flutter
It’s hard to have a conversation about React Native without mentioning Flutter – a newer Cross Platform mobile development framework, backed by Google and in direct competition with React Native for popularity. So whose side was everyone on?
From a functional perspective, Flutter had both fans and detractors. It’s often suggested that Flutter has the upper hand performance-wise as its compiled to native libraries, making it faster than React Native which has a JavaScript “bridge.” However, it also still doesn’t eliminate the need to write native code.
Moreover, the skills surrounding Flutter are less easily transferrable – it’s written in Dart, which despite purportedly being more “loved” than JavaScript is nowhere near as popular, with just 4% of developers currently using it compared to JavaScript’s 67%. This increases its overhead, enhances its risk factor and makes it more difficult to find talent. If Mobile leaders choose Flutter, they are somewhat backing themselves into a corner, having built a team around a framework.
Building teams for the future
One of the major benefits of React Native is the ways in which it allows leaders to approach building teams. Choosing to write their mobile application in such a popular language gives businesses access to a wide talent pool who can build on a lot of established best practices informed by what’s come previously.
With JavaScript ubiquitous across the stack, writing in React Native further opens up the possibility of structuring teams around full-stack developers who can own whole features rather than employing specialists. This reduces the capacity for the classic miscommunications between the front and back end, and inefficiencies which derive from individuals only regarding themselves as responsible for one part of a siloed process.
Moreover, building in React Native allows leaders to think strategically and build teams with flexible skill sets, should you outgrow the stack, as Airbnb did. One of the powers of choosing this framework is knowing you’re getting a certain standard of engineer who is multi-disciplined and can work with many different technologies. Even should you decide that web is the way forward, a certain amount of work can be transported away from your native application, instead of being left with a lot of unusable resource.
I’m Jacob Brown, a Mobile Consultant specialising in React Native, iOS and Android at La Fosse Associates. To learn more about this or future events, please reach out to me on LinkedIn, email, or call on 07923206342.
Learn more about our executive and leadership recruitment specialism.