C++less Android template

[cortinico]

tl;dr: From React Native 0.71, you will be able to enable the New Architecture without having to add any C++ code in your app. Similarly the app template has been cleaned of all the C++ code and the CMake files, you can still add it if needed

Hey all,
As the release of 0.71 is coming closer, we'd like to share some of the recent improvements for the New Architecture that we'll be shipped in 0.71 so you can get a sneak peak of how they will look like once 0.71 lands.

What has changed

Here a screenshot of how the Android template will change between 0.70 and 0.71 (iOS folder is omitted for brevity):

(So much red! 🟩🟥🟥🟥 red == good).

Practically, we did the following:

• Removed 7 C++ files that were used previously for registering Fabric Native Components and Turbo Native Modules (both user provided and autolinked).
• Removed 3 Java files used to provide JNI apis to those C++ files.
• Removed the CMakeLists.txt file needed to build those files.
• Removed all the custom logic inside the build.gradle file needed to enabled the NDK.

All the C++ files have been moved inside the framework in the /defaults package.
Those files provide a convenience wrapper over the API inside React Native core by making registration of custom components easier.

The OnLoad.cpp and the CmakeLists.txt files have been moved inside the default-app-setup inside the framework. Those two files are autolinking-aware, and takes care of properly registering C++ components/modules coming from 3rd party packages. They're working in conjuction with the React Native CLI.

The custom build.gradle logic has been moved inside the React Native Gradle Plugin which we were already using for the Codegen. More on the React Native Gradle Plugin in the new dedicate page in the website

Why is this important

Practically, we reduced the template LOC size by ~600 lines. This is crucial as less code == less things can go wrong during upgrades and less anti-patterns can spread around.

While removing code is always good, removing code from the template is even more crucial as it has a greater order of magnitude impact as those files gets copied over and over in new projects.

This also comes with a series of wins:

• It addresses one of the major concern that (web) developers approaching React Native New Architecture had: They don't want to deal with C++ unless they really need to.
• We greatly reduced the number of steps needed to enable the New Architecture in OSS. You can get a sense of it by looking at the diffs on the website (we removed nearly 2000 lines of content from the website!)
• Reducing the size of the build.gradle file by LOC and entirely removing the CMakeLists.txt file from user space. Smaller build logic in user space => Less things can get misconfigured and go wrong during a react-native upgrade.

What if you really want to have C++ code inside their app

In general, app developers should not need to use C++ code at all.
You should just include library (which can contain C++ code inside their module/component implementation), and write code in JS or platform (Java/Kotlin/ObjC).

However, if you still needs to include custom C++ code in your app you can still do it. You'll have to copy the files from the default-app-setup folder in user space and expand the default React Native's CMake setup. Beward that you'll be effectively "ejecting" from our setup,
so you'll be responsible of their own upgrade to the CMake/C++ files.

We consider this an advanced use case, and we'll publish more docs around it in the future if needed.

How was this possible

I'd like to stress how this was not just moving files inside the framework, but it was possible thanks to:

1. The previous work on CMake migration for our build (more context here)
2. A lot of underlying work on .71 to add prefab support and to publishing our libraries to Maven Central (i.e. RFC #508).

---

We're happy to collect feedback on this specific change here and answer questions/follow-up if there are any.

[danilobuerger]

Does it make sense to also move the iOS template AppDelegate.mm back to .m as it used to be before 0.68? All the C++ code was removed there too.

[kelset]

cc @cipolleschi what do you think?

[cipolleschi]

Does keeping it .mm create some issue we are not aware of?

If not, I personally would keep the .mm. It is true that we moved away all the C++ code but:

1. we already asked our users to rename the files from .m to .mm. Moving back to .m would require to people who already have migrated to rename the file again.
2. it is more future proof. If we have to add back some C++ code/invocation, the file is already in the right format. If we move back, we have to ask again to change the extension.

[danilobuerger]

I dont think so. I just noticed it and thought I would mention it but your arguments make sense!