Introduction

If you’re here, you probably already know why switching your apps over to react native apps is a good idea. But regardless of:

1. You are in the planning stage,
2. Your migration has already begun, but something went wrong,
3. If you want to assess how well you transferred your app,

It’s wise to take a step back and consider the opinions of experts.

You’ll learn about:

How should you go from Native to React Native?

Greenfield development

• Greenfield software development – what is it?
• Risks associated with greenfield development
• What considerations should you make when preparing a greenfield migration?
• Greenfield – an overview

Development of a Brownfield

• What things need to be considered when planning a brownfield migration?
• Brownfield: An Overview
• How Brownfield is Used by Syndell

How Can You Switch From Native to React Native in The Right Way?

With a greenfield or brownfield software development, the migration process can be carried out in one of two ways. Let’s examine these two strategies, highlight their key distinctions, and discuss the advantages and disadvantages of each to help you decide which is best for your team and product.

Greenfield Development

What is greenfield software development?

Greenfield came up with ideas starting from scratch in a brand-new setting with no existing legacy code. With this method, we start from scratch with no constraints or reliances. We can migrate our app much more quickly with this method than with the brownfield method, but there are hazards involved as well that we cannot ignore.

Greenfield development’s potential risks

You don’t usually want to “kill” the native app and then rebuild react native apps from scratch. It’s far better to let the “old” app do its job until the new, cross-platform one is ready to replace it. And maintaining the “old” app while also developing the new one can become overwhelming for your team. As a result, the new app may contain more bugs and errors than it would with a well-rested development team. As a result, migration using a greenfield approach should be thoroughly thought out and planned, with a special emphasis on the features map.

What should you keep in mind when planning a greenfield migration?

It is critical to create a features map when planning a greenfield migration to react native. It requires a significant amount of effort (and, as a result, money), but it will ensure that you do not overlook any features while working on migration.

This is where you should begin: examine your current app, create a features map, and provide solid project documentation.

It is critical to create a features map when planning a greenfield migration to react native web app. It requires a significant amount of effort (and, as a result, money), but it will ensure that you do not overlook any features while working on migration.

This is where you should begin: examine your current app, create a features map, and provide solid project documentation.

The following are typical problems we encounter in the wild that slow migration:

There is no official documentation for the code.

Code comments that describe the code but not the reasoning behind it.

The documentation is dispersed across the teams.

It’s difficult to find a single owner of a feature or the entire product. Sometimes, there are multiple people (managers, developers, etc.) who only have a partial picture.

Unused legacy code obscuring the contents of the feature.

We propose creating user stories, which are informal, natural language descriptions of one more feature of a software system. The user story describes the feature from the perspective of the end user, the type of user, what they want, and why. Simply put, user stories are stated requirements that express what users require, the “to-do” lists that assist developers in determining the steps along the project path.

The primary goal of the user story is to define how a specific feature, functionality, or other feature will provide value to the customer.

‍The majority of user stories follow the same, straightforward pattern:

The role identifies the end-user, who is a real person who interacts with the system. It should be described in as much detail as possible.

‍The action represents the system’s behaviour and should be written as such. The system is implied in the action section and is not written in the story, which should be written in the active voice.

‍The benefit should present a real-world outcome of the action and describe the value of the system interaction for the users.

Greenfield – Summary

To summarize all of the advantages and drawbacks of greenfield software development:

Pros:

• Greenfield is significantly faster than brownfield.
• It can be started in a specific direction.
• There are numerous opportunities to enhance existing technological solutions.

Cons:

• More effort is required from the team.
• There is a high risk of bugs and errors.
• With so many development options, it can be difficult to choose the best approach.
• Concentrates a large number of development resources on a single project.
• Risk of “people problems” – dividing a team into a “legacy app team” and a “new app team” typically slows feature development and may also be a “people problem” (if the legacy team is not comfortable working with legacy tech for a while).

Brownfield Development

Because it enables the integration of new features (cross-platform in our example) with React or native apps while maintaining their business continuity, brownfield software development appears to be a wonderful technique to move apps from one framework to another.

‍In relation to that, brownfield enables us to incrementally convert native apps into cross-platform ones, feature by feature and screen by screen, without having to completely rewrite the app. We can gradually replace a working app’s existing native or React components by integrating new inclusive cross-platform components into it. The nicest part is that standard cross-platform features behave nearly identically across all platforms with no effect on performance.

What things need to be considered when planning a brownfield migration?

You should be aware that the entire procedure requires more time than completely redesigning an app, as in the case of the greenfield method. To “plug” into this architecture or establish some bindings between the architecture and the migrated portion, you will need to know both the native platform from which you are migrating and the architecture of the entire product.

Additionally, it might be required to communicate some data between react native web app and native during the migration, which will probably need a lot of your time and effort. The features map, however, is more of a “nice-to-have” that enables the progressive rewriting of new screens than it is an essential component of the strategy. With this method, the map or documentation can even be developed gradually along with the migration, but before any development work is done.

To summarize the main differences, the brownfield strategy has fewer modifications than the greenfield, but the entire process takes longer. However, the danger of faults and errors is considerably lower with the brownfield approach, and they are much simpler to discover and correct during the rewriting of the screens.

Brownfield – conclusion

Considering all the benefits and drawbacks of developing brownfield software:

Pros:

• Once created, a cross-platform component functions identically on all platforms.
• No chance of platform-specific features becoming inconsistent.
• Gradual migration process without affecting the app’s business continuity.

Lower development expenses because an app is developed by one team for numerous platforms.

OTA and live updates. Without going through the app store update cycle, add features and upgrades.

Cons:

• It takes more time than the greenfield method.
• Needs native expertise to move the project along properly.
• It may end up costing more in the end.

How is Brownfield used by Syndell?

We have developed our own strategy that has shown to deliver the finest developer experience with the least amount of effort by resolving a number of our clients’ problems over the years and creating an Open Source library devoted to brownfield development.

Screen per screen, we typically work on components and register them using the “AppRegistry.registerComponent” API. Because of this, some react native apps components can be found by the native interface, which can then load the proper initial props into them. To achieve maximum integration independent of React Native, a specific collection of components is then packed in a platform-specific manner.

We want to create a static library (a file with the “.framework” extension) for iOS that contains all wrapped components as part of the user interface. A “fat aar” file is produced by a similar method on Android. The public interface components can now be used by native developers without explicitly relying on react native web apps, as “node modules” and even “node” don’t need to be installed on the developers’ computers. The most popular brownfield technique for switching from react to react native uses such solutions to embed React Native displays into native apps.

However, everything is ultimately a React component. Therefore, that abstraction can be expanded further to enable additional sharing mechanisms for complicated components between various settings and to provide consistency in layout.

By building the interface from pre-existing UI components that function and appear the same in both native and react native apps, Android and iOS developers can work more quickly. This ensures consistency between brownfield-created applications, where native and React Native screens coexist during the migration, and other entirely native apps, where React Native  implementation is not yet in the pipeline.

Web-Based React to Native React. Are You Moving or Changing?

We decided to shed some light on it because we’ve heard a lot of questions about the migration of web apps made from convert react app to react native.

‍ It is not a migration type, as we previously mentioned. It is more akin to adding cross-platform functionality to your React web project. Therefore, “conversion” is a better term to use in this context than “migration.”

‍Platform-specific “host” components are frequently used with composite components in the majority of existing React web projects. This simplifies things for web developers because the JSX that we generate is quite similar to HTML.

Source:  callstack

But by taking this approach, we’re not making the most of the opportunities that JS bundlers give us for writing platform-specific code. Only environments that comprehend “div” and “span” elements, such as the DOM or a testing environment, can render the MyButton component.

‍If we adopted React’s component model and transformed this component:

Source: callstack

Thanks to the React Native renderer, we could render it on almost every platform that React supports, such as Android or iOS. By default, we would implement our own components, like “SecondaryText.js,” to render a “span” element. Additionally, add more React Native implementation in “SecondaryText.native.js”. We will utilize a bundler that is intelligent enough to import the appropriate implementation for a certain platform, whether it is Metro or Webpack.

And we proceed in the same manner with each component that uses web APIs and declares HTML.

That is only React. Additionally, it is incredibly forceful in addition to being gorgeous.

Every time we use a platform-specific component, such as a portion of an icon, button, or another button that is not from the lowest level of the component tree and we use it in the wrong places in the app, we expand the scope of future platform migrations that are not web-based.

As a result, there were numerous well-liked methods that let developers create an app without changing any React (or another library) components while still rendering it for mobile. Even so, it was merely a WebView—a tiny browser in which the web app was running—rather than the “traditional” programme.

The same is true for electronic tools like Slack and Discord. There are online applications that use electrons to render on the browser, eliminating the need to rewrite their components in React.

‍On the other hand, we wouldn’t require any major rewrites if we had built our online application from the ground up using React Native (thanks to the react-native-web project). It would function right out of the box; we would just need to make a few minor adjustments to our components for each platform to render as expected. This is due to the fact that the JSX of the React Native renderer does not support any mystical host components like “div” or “button.”

The “react-native” package or native third-party components must be imported for any platform-specific components, such as View or Text.

In JavaScript, one good feature of importing is that we have to specify from where we import.

Source: callstack

Additionally, the “location” that we import from is aliased by our bundlers. We may set up Webpack to alias “react-native” to “react-native-web,” which supports web implementation and comprehends Views and Text.

Source: callstack

Reaction Native Migration: Conclusion

To summarize, we can identify the success factors of the migration to React Native based on our successful migration of the Kiwi.com app, where we employed the brownfield approach:

• Screens made with React Native load instantly.
• Navigation functions as it should.
• React Native allows for the reuse of native code.
• Everything is contained in a single repository, and React Native is updated.
• When there are JavaScript updates, CodePush is functional; thus, there is no need to wait for the App Store any longer.
• When we grow a React web app, the app retains a native feel and is not dependent on WebView.

To do this, we must create a thorough plan for the migration, which must include a features map (essential in a greenfield approach), and have a clear understanding of the goals we want to accomplish as well as the amount of time and effort we have to devote to the migration process.

‍Before developers begin to work on rewriting screens, it’s crucial to create a thorough and comprehensive documentation of the migrated software. Without a defined app structure, there is a higher chance of defects or even the unintentional omission of some functionalities, which raises migration expenses.

Your team must be ready for the migration, understand why you are moving your product to React Native and know what their responsibilities will be once the process is complete. They must comprehend the benefits that React Native offers, especially in relation to the technologies that surround it. Things include the simplicity with which new cross-platform functionality may be implemented on all platforms simultaneously and the vast array of Open Source libraries that offer excellent assistance to developers in their job.

Summary

As previously mentioned, converting native and React apps to React Native is a difficult undertaking that calls for extensive expertise and vast experience not just in React Native but also in native and, in some cases, web development. Fortunately, the team of Syndell engineers is the one with everything.

We are always eager to assist you at every stage of your migration process as a team of React Native experts who are trusted by the community, skilled in many challenging and demanding projects like migrations from React web and native platform to React Native, and creators and maintainers of many Open Source libraries useful in migration process like Paper or React Native Brownfield.

Just contact us if you think you might need assistance. View the services that our react native app development services has to offer while you wait.

FAQs