What if React Native Could be Used to Build High-Fidelity Apps AND Add More than 11 Platforms to its Reach?
Having only heard the elevator pitch, I assumed that it was just a UI framework that we could use to sit on top of our JS APIs, but I quickly learned that RN was an entire framework and workflow, rather than just a JS library. It achieves cross-platform support by mapping JS methods to native methods, which I like to call a pass-through approach.
I have a soft spot for JS bindings for C++ APIs. Shipping more than 500 million copies of an SVG player on mobile devices and using multiple scripting engines to bind the SVG DOM API to JS was where it all started for me back in 2003. Naturally, React Native sparked my curiosity and I took some time to dig into the approach.
So here were my initial thoughts about RN.
RN has many benefits, but for me the top three are:
- it enables JS for application development without needing a web view,
- it removes the performance bottleneck of a web browser by going native, and
- it opens the doorway to sharing a percentage of web code written in React.
It was a compelling start and enough to keep me interested. However, there were three limitations that were also striking;
- Lowest common denominator apps
This is a typical challenge for ‘pass-through’ cross-platform approaches. The more platforms that are supported, the more complex it becomes to maintain and find common ground. Since these approaches need to map their abstractions to the native controls, they need to keep up to date as the OSs change and progress. Because of this abstraction, it typically leads to ‘lowest-common-denominator’ apps or ones that don’t quite leverage all the uniqueness of the native controls but only the common functionality found in each. In my opinion, this leads to apps which are generic at best.
Based on the first two challenges it’s likely no surprise that platform reach is somewhat limited. Roku, PS4, Xbox One and Samsung Tizen to name some of the more common ones, are not part of the current supported field. True cross-platform support gets rather tricky given how this abstraction is handled.
- UX workflow
However, one of the biggest and most obvious challenges from my perspective stems from the gap between UX design and software development — especially if the UX design has a lot of nuanced animations. Coming from a world where the UX workflow has designers and developers as equal partners in the app creation process, this was a step backward from my point of view.
From the above challenges, it has been made clear to us by our customers and prospects that larger platform reach and compelling, rich apps top the list. Let’s see what adding You.i Engine One as a supported platform on React Native can do on both these fronts.
To start, I looked at the RN code base as well as the UWP port. My excitement grew as a learned more about the codebase and eventually came up with a preliminary architecture.
To me, the key component was the cxxreact library which implements the API bindings from a JS engine to C++. I started with our basic “Empty Sample”, which essentially is an empty C++ app that links in and builds our You.i Engine One, specifically using the OSX build in this case.
Integrating the cxxreact library in this way proved to be very effective. I started to see events and methods being sent to our C++ layer, specifically UI creation methods with constants and settings. As I began to hook these into our engine, I realized we would have to deal with layout. React Native makes use of the flex layout system, based on the easy to understand and open specification from the W3C. Our framework also has a layout system which has some overlap with the flex feature set but also some features which we find allow more control to the designer.
As an example, a critical part of any layout system is not just defining how the components layout relative to one another, but also how they animate. And when I talk about animation, it’s not just self-contained animations within the boundaries of a given component, but how they animate and move in relation to each other. A key element of our animation and layout system is the ability for the UX designer to describe what is essentially a deterministic animation but applied to non-deterministic starting and ending — in other words, relative rather than absolute attributes such as position. Take the example of animating a card in a list to move a given way when it scrolls into view. This can be defined in our UX workflow, but at runtime, it is applied to the UI layer dynamically based on what the layout system has calculated while keeping all the complexities like bezier curves for easing. Knowing that we have solved these problems with our engine — and had things working nicely with layout, I was confident that we would be able to bring this type of workflow to an RN-based framework.
However, for this prototype, I simply disabled our existing layout rules for a container and used the open source Flex layout library which Facebook provides to generate positioning information. Once complete, I began to see UI components positioned in the correct locations. Next was rounding out other UI components like images and lists by adding to the sample. This lead to hooking up keyboard and mouse events and sending them into the cxxreact engine.
Eventually, I had an app on OSX looking like this screenshot
To me, this was incredible and a clear demonstration of RN supporting You.i Engine as a platform.
What does this mean exactly? It means that our You.i Engine One framework can bring RN to 11+ more platforms, with the performance of a gaming engine. It also means that we could bring our patented design workflow into RN and use it to develop engaging, high-fidelity apps — by eventually giving the ability to augment animations and other visuals in AE.
RN is highly accessible and has made great progress when it comes to cross-platform app development. The exploratory work we did demonstrated how we could fill a couple of areas that React Native struggles with — platform reach and a UX workflow — based on our You.i Engine One technology.
The next step? Take the learnings from the POC work and to really dig into a sustainable architecture. Specifically, how would we design an easy to use mechanism for binding our C++ APIs to React Native. Sounds like a topic for our next blog post.