maplibre
Migrate to new Architecture
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
@birkskyum is this ticket to track progress on general support for the new architecture or migrating this project completely to the new architecture?
@KiwiKilian , let's convert this to a 0.76 ticket. Thanks for adding the compat layer!
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.
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 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.
@birkskyum thanks for the feedback. I guess that would need a bigger user base?
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.
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.
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.
I've started the migration process with #828.
Going all-in on the new Architecture
RN and Expo are pushing towards new architecture. So we will do too, from v11 onwards this library will be new architecture only. Those of you who can't upgrade to the new architecture should stick with v10. We have started releasing v11 alpha versions today.
Shameless self-plug
Right now I'm mainly doing the migration in my spare time. If you like what I'm doing and will profit from this migration, consider sponsoring me on GitHub or reaching out to MapLibre and request to funnel the money explicitly to this project. If you are here for company work, talk to your management 😉.
Great news, @KiwiKilian!
I’m in the middle of upgrading our app to the latest React Native, and New Architecture support in maplibre-react-native will be critical for us.
My company (@lineinspector) already sponsors the MapLibre organization. Is there a straightforward way to have part of that contribution earmarked for React Native work?
I’ve also just added a one-time sponsorship for you — thanks so much for driving this effort.
To everyone else depending on this library: now is the perfect moment to chip in and help keep the momentum going!
One last question: do you have a rough (even very rough!) timeline for v11? A ballpark would help us plan our own rollout. 😊
Thanks again for all your work!
@KiwiKilian That's awesome news! Thanks a lot.
What do you think about creating a sponsorship goal/target? I think I saw something like this in other open source project. Something like I need XXX to fully focus on finishing this migration and so far I have YYY. Also, I read that crowdfundings with clear goals are more successful.
Thanks for those of you who already came forward, highly appreciated! @jaltin
Are you already using MLRN with old arch or are you migrating from another map framework?
My company (https://github.com/lineinspector) already sponsors the MapLibre organization. Is there a straightforward way to have part of that contribution earmarked for React Native work?
It's more an idea that initially came by @tyrauber. @birkskyum what could be an approach regarding this topic, while MLRN is not a core project? Nevertheless, this project only exist, because the other core projects exist. Therefore any kind of split should be considered carefully.
One last question: do you have a rough (even very rough!) timeline for v11? A ballpark would help us plan our own rollout. 😊
I would really hope to have the biggest issues fixed within two to three months. Hopefully v11 released no later then the end of this year, more wished around autumn. TBH this is really wild guess, as the first two month (of spare time, not developer hours) went into the setup, which is sometimes a bit trial and error. So actually code migration can of course go faster or slower, as I've only touched the first module in #828.
@caspg
What do you think about creating a sponsorship goal/target?
As I'm not yet quite sure the exact hours I will be spending, I find it hard to set a goal on this topic. I also can't/want to pressure myself by setting a goal. I really want to do this migration from an intrinsic motivation. But I figured if people benefit from this work financially, they could channel there benefits here. Which of course also helps the momentum of my work while not entering a contract. But I will see how this develops along the way.
Furthermore, if I get the feeling everything went much faster, there will still be enough to do in overhauling this library in other ways.
Are you already using MLRN with old arch or are you migrating from another map framework?
Yes we are using MLRN 9.1.0 with RN 0.73.11. We tried updating to RN 0.76 and MLRN 10 a while back but rolled back as there were too many blockers, and the bugs in new arch for MLRN 10 was one of the main reasons.
So the faster this can happen, the better it will be for us.
As an intermediate step I can only recommend to upgrade to v10 and sticking with the old arch. For us v10 with old arch is really stable, as we migrated from RNMapbox to this library. It also eases parts of the tooling, like bumping the MapLibre Native version independently of MLRN.
But for sure the migration to new arch is in focus now.
For us v10 with old arch is really stable, as we migrated from RNMapbox to this library.
Yes we are attempting that path right now, but it gives us headaches with other packages that dont support old arch on latest RN (an example is react-native-mmkv). Hopefully we can find fixes for that though.
Looking forward to hear on the progress. And let us know if we can assist with testing or anything else.
Hi @KiwiKilian, I hope you’re doing well! 👋 Just wanted to check in to see if there’s been any progress behind the scenes on this, or if you have a sense of whether it’s on the horizon or more long-term. Totally understand this is volunteer work — just curious what to expect.
Thanks again for all your efforts on the project! 🙏
I'm making progress on migrating the MapView and Camera. I think their migrations are close to beeing feature complete on both platforms. Next up is testing and fixing bugs (for example normal child Views aren't working right now). These two components are the most complex and had quite a few bad API choices. These also contradicted some of the patterns for React Native new Arch, for example it used a single event type to send different kind of events on the MapView. For the long term maintenance of this library I choose to cleanup these messy parts and improve those APIs, which will also give much cleaner JS/React API. So I would say finishing these two components is on the horizon, hopefully no later then end of November.
Then I'll have to figure the biggest blockers on other components, as most reported bugs seemed to be on those two components. I'm also trying to get allocated time through my employer, but that's a lengthy process as some customer has to fund it.
I must also note, that this library is rather complex for RN and is hitting some boundaries on React Native new architecture, see https://github.com/facebook/react-native/issues/49920 for example. Resources and documentation on these usecases are really dense and RNMapbox only did the bare minimum to get everything working on the new architecture. So a lot of research, digging in other RN libraries and trial and error was necessary. And I'm also no native dev... I hope this helps to understand, why the migration is a rather lengthy topic, especially because I'm not able to work full time on this.
Quick update to this issue, the migration of MapView and Camera has been released as 11.0.0-alpha.9. I've created further steps as sub-issues of this one.
Sorry, didn't want to close the parent task. If anyone is interested to take one of the sub issues you can comment there.