Mobile Application Architecture: React Native vs. Native

When it comes to mobile app architecture, React Native and Native development offer distinct approaches.

Coming from an iOS and Android development background, I initially faced challenges transitioning to React Native. This new environment marked a significant shift, having primarily focused on mobile development. However, I viewed this change as an opportunity to expand my skills as a web developer.

As I delved deeper into React Native, I grappled with the unique rules of the mobile ecosystem, such as optimizing memory usage, conserving battery life, and creating user-friendly UIs.

After mastering JavaScript and understanding React and React Native intricacies, my goal was a comprehensive understanding of app structuring. I aimed to navigate this path and gain proficiency in native development.

My ultimate objective: bridge the gap between these tech worlds by comparing React Native and Native in mobile application architecture.

Native World

Nowadays, for many people with native background , its not difficult for them to decide the architecture of their app. these people have set some good options like MVP, MVVM and VIPER (mostly iOS). These people have the following goals in their mind:

• unrelating the supply from business logics
• developing testable applications
• structuring of the app in modules for defining responsibilities

There was no right way decided by google or apple for many years, but 2 years ago google described their take at Google I/O and published a detailed blog ( detailed blog post) about structuring of app according to them and added extensive frameworks to android to support them .

The logic behind this step was to separate screens into their native components, with UI, business logics, networks and storage, all in their own entities. Look at the following diagram:

React Native

In the realm of mobile application architecture, significant influence often stems from the Front-End Development (FED) world, primarily because React Native is an extension of React. However, for React Native developers, this transition can pose initial challenges, given the distinct ecosystem and fragmentation among various solutions.

Upon closer examination of the architecture, a pattern becomes apparent: the web aligns predominantly with Flux. This architectural approach aims to establish a unidirectional and predictable data flow within your app, simplifying comprehension and debugging.

Redux emerges as the most renowned implementation of the Flux pattern, despite several alternative implementations existing.

Essentially, application state management revolves around stores like Playstore, with any changes to the store triggering corresponding updates in different parts of the app. For a visual representation, refer to the image below:

the components separate the actions, actions in return do something and update the store which changes the components in a good way. In above diagram differences and similarities can be seen.

let us view the differences and understand their existence and process parallel to them. I use android most of the time but in iOS the fragments can be switched to view controller and have feels like home.

Smart Components = Fragments

As in react native we speak about screens and in react we speak in terms of components. These components are the building units of all screens. A screen has many components and most of them are dumb , some are smart and are connected with the store or query needed by the data.

Some screens have smart components and access their own store with their business logics. for :

This example describes the addition of task screen in the to do list of the application. It contains many smart components like pick location which has its own state or store, user interface states and business logic storage and server API. This helps to develop each part even when there are different teams and have screen which is a dumb container.

Native equivalent:

The notion of composing your screen into different separate components is also present. Each smart component can be its own part in native. The screen is result of combination of several small components , each of them having its own logic and interactive environment. The logics or the states are taken out of different components, which takes us to the next step.

Actions + Store = ViewModel

This part of component is in charge of all the states of the components and logics related to business and presentation. Its the most important part as it helps in the implementation process. This is the main heart of the application.

By using Redux , we can dispatch the actions and have to wait till any change in store and we check the changes if they are appropriate or not. In each action we can request any network, ask queries related to storage and upgrade the stores. The object named store is global and not attached to any other component life-cycle.

Native Counterpart:

In mobile application architecture, managing state plays a critical role. In native development, the state remains private within the View Model, ensuring component isolation and a consistent UI. Conversely, Redux adopts a global store approach, allowing one component to impact another while maintaining UI consistency.

However, this approach has its drawbacks, including potential state leakage to unintended components, reliance on internal details that should remain hidden, and challenges when a component appears on the screen multiple times, leading to debugging complexities. To mitigate these issues, it’s crucial to make informed decisions about what belongs in the store and what doesn’t.

Remote Server

No difference.

Async Storage ≠ Relational DB

Now here lies big differences.

In react we have to use key/value storage , in native we use relational DB solutions. Both approaches have their own advantages and disadvantages so people with DB background find it difficult to work with key/value storages and its hard for them in schema portion.

Last Summary

Upon initial inspection, React Native may seem fundamentally distinct from traditional native development. However, as we delve deeper into this comparison, we discover that beneath the surface, many core ideas are remarkably similar, albeit with subtle differences.

When we turn our attention to architectural patterns, a fascinating trend emerges in the Android ecosystem known as MVI (Model-View-Intent), which strives to introduce the Flux pattern into native development.

In the realm of state management, Redux emerges as the frontrunner, serving as the most widely adopted library. While alternatives like Mobx bring a touch of the Model-View-Controller (MVC) pattern back to the web.

For mobile developers well-versed in native development, venturing into the realm of React Native is a logical step. Both approaches share common objectives, primarily centered around adhering to the SOLID principles of software engineering.

While implementation details may exhibit variations – some leaning towards functional or reactive paradigms and others involving varying levels of boilerplate – the overarching goals remain harmoniously aligned.