Migrate to new Architecture

[birkskyum]

Motivation

We're currently at "react-native": "^0.74.6"

The New Architecture is default from 0.76

We can use the new arch though a compat layer #483, which can be removed by migrating the repo to 0.76.

Intro to New Architecture

In this new version async bridge is removed entirely.

This makes for better performance (lower overhead c++ <-> js), and allow sync+async, where prior is async only, which allow for some flattening of callbacks to sync code etc.

In addition the debugging experience is built around Chrome DevTools.

Read more here: https://reactnative.dev/blog/2024/10/23/the-new-architecture-is-here

[flohhhh]

Looking forward to this update :)

[KiwiKilian]

@birkskyum is this ticket to track progress on general support for the new architecture or migrating this project completely to the new architecture?

[birkskyum]

@KiwiKilian , let's convert this to a 0.76 ticket. Thanks for adding the compat layer!

[KiwiKilian]

Then you can also drop the 0.76 version reference – new arch is supported already quite a bit earlier. Also upgrading to this version is not exactly updating to the new arch.

#483 fixes issues, which prevented to make this library work in apps using the new architecture through the Interop Layer. This is fixed by adhering to these guidelines.

The next step could be migrating the whole library to the new architecture. How to do it is described here. This also states:

Before proceeding to convert your library to natively use TurboModules/Fabric, you should ensure that it is compatible with the Interop Layer. There is no known performance cost imposed by the Interop Layer, but it will be removed at some point in the future. Today, it's safe and recommended to use the Interop Layer as a first solution to make your library compatible with the New Architecture quickly, and then you can consider migrating to the native APIs in the near future.

So there is no date yet available, when Interop Layer will be removed.

@birkskyum do you think switching to the new arch could be supported by a bounty? It looks like quite a bit of work, see the migration of rnmapbox (safe to view, it's MIT licensed). Software Mansion (big consultant/player in the React Native ecosystem) was contracted to do it on behalf of Expensify, looks like they did most of the work.

[tyrauber]

We have a released 10.0.0.alpha.24 which includes an interop layer for the new react-native architecture, thanks to @KiwiKilian, @rxnvee and @thibaultcapelli. alpha.24 should be backwards compatible for those that want or need to use the old architecture, for both iOS and Android. If you run into issues, you can lock at alpha.23, comment or open an ticket.

We were noticing some weird intermittent build issues with the new architecture (see the packages/expo-app which is now configured for the new arch):

CommandError: Malformed xcodebuild results: "UNLOCALIZED_RESOURCES_FOLDER_PATH" variable was not generated in build output. Please report this issue and run your project with Xcode instead.

If you run into this, clearing everything, DerivedData, .expo, ios/build, android/build, etc, seems to resolve the issue. We are currently attempting to debug this build issue, but wanted to get something out to test and discuss issues that may come up with the new architecture. Feel free to comment or here or open a new ticket. Thanks!

[birkskyum]

@birkskyum do you think switching to the new arch could be supported by a bounty?

@KiwiKilian for the normal bounty system to apply, the maplibre-react-native repo has to be elevated first to a Core tier.

[KiwiKilian]

@birkskyum thanks for the feedback. I guess that would need a bigger user base?

[birkskyum]

In general yes, if it appear to bring a lot of value to the community, it will be prioritized - OR if we see a need from one or more sponsor of MapLibre, that's being paid attention to as well.

We walk a fine line in balancing our spendings, because the organization only can prioritize investments in community needs, to the extend that we at the same time can provide more value to our sponsors, per dollar donated, compared to their alternatives, which historically often have taken the shape of an in-house fork.

[brentforder]

In general yes, if it appear to bring a lot of value to the community, it will be prioritized - OR if we see a need from one or more sponsor of MapLibre, that's being paid attention to as well.

We walk a fine line in balancing our spendings, because the organization only can prioritize investments in community needs, to the extend that we at the same time can provide more value to our sponsors, per dollar donated, compared to their alternatives, which historically often have taken the shape of an in-house fork.

I'm honestly surprised that maplibre-react-native isn't more popular, or a core tier. When I saw this option for a multi-platform, open-source geographic map library that works with Expo, I rejoiced that I wouldn't have to mess with native code, native build configurations or inhuman programming languages like Swift. Expo even supports OpenGL ES... And for the cases where you need platform-specific functionality not covered well by Expo (i.e. content sharing between apps), you can generally bootstrap in custom Expo config plugins to maintain that native functionality without too much pain.

[tyrauber]

Thanks @brentforder, really appreciate the kind words and agree 100%.

I think an huge opportunity exists for MapLibre within the expo eco-system and community. The Expo team is absolutely killing it right now, eroding the barrier between react-native and native, and I think a solid, stable open source mapping library that fully embraces these changes - like the New Arch - will gain significant marketshare in the next year.

While the recent alpha releases is compatible with the New Arch, a lot of work is required to migrate fully to the New Arch. Right now, we are working hard to get to a stable 10.0.0 release that utilizes the latest MapLibre native sdks. We've started building a great community of contributors and maintainers. (Shout out to @KiwiKilian for some serious heavy lifting over the last few months).

Once we get to 10.0.0, I think full Arch support should be the focus. Hopefully, we can gain enough momentum and support with the 10.0.0 release to make that happen.