Migrating an Ecosystem: An Empirical Study of How React Native Libraries Adopted the New Architecture
This empirical study analyzes the React Native ecosystem's migration to its New Architecture, revealing that while major milestones accelerated adoption among popular libraries, a significant portion of dormant, unmigrated packages remains in use, leading to a fragmented landscape where compatibility layers have become long-term infrastructure.
Original paper licensed under CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). This is an AI-generated explanation of the paper below. It is not written or endorsed by the author. For technical accuracy, refer to the original paper. Read full disclaimer
In the world of software, platforms are the foundations upon which countless applications are built. Much like a city's infrastructure dictates how buildings are constructed, these digital foundations provide the essential tools and rules that allow developers to create mobile apps. Occasionally, the owners of these platforms must replace their core systems to improve performance or add new capabilities. This is a massive undertaking, not just for the platform itself, but for the thousands of independent tools and libraries that rely on it. When a foundation changes, every structure built upon it must eventually adapt, or it will no longer fit. This creates a complex challenge: how does a vast, decentralized ecosystem of independent creators respond when the ground beneath them shifts? The question is not merely technical; it is a study of human coordination, maintenance, and the lifecycle of digital tools.
A recent study by independent researcher Revanth Krishna Maddula examines this exact scenario within the React Native ecosystem, a popular framework for building mobile applications. React Native recently replaced its old communication system, known as the "bridge," with a new, faster architecture. The transition was not immediate; it happened in three distinct stages over several years. First, the new system was offered as an optional choice. Then, it became the standard setting, though developers could still switch back to the old one if they wished. Finally, the old system was turned off entirely, making the new architecture the only option. Maddula set out to measure how the ecosystem reacted to these changes. He did not just look at the official announcements or the most popular apps; he analyzed the entire catalog of nearly 2,800 libraries listed in the community directory, focusing specifically on the 1,444 libraries that contained native code and therefore had to be rewritten to work with the new system.
The results reveal a story of two very different groups moving at different speeds. Of the libraries that contained native code, about 62 percent have successfully migrated to the new architecture. These successful libraries are the heavy lifters of the ecosystem, accounting for 95 percent of all weekly downloads. This means that for the vast majority of users, the transition is effectively complete. However, a significant tail of 519 libraries has not migrated. These are mostly old, dormant projects that have not been updated in years. While they represent a smaller share of total usage, they still receive millions of downloads every week. The study found that 115 of these unmigrated libraries receive at least 10,000 downloads a week, and 41 of them receive over 100,000. These are not obscure tools; they include widely used components for handling file systems, video, payments, and notifications. Because so many applications still depend on them, the platform owners cannot simply remove the old system without breaking a large portion of the ecosystem.
The timing of these migrations tells a specific story about pressure and response. As the platform moved from an optional choice to the default setting, and finally to a mandatory requirement, the rate at which libraries were updated did increase. The number of libraries converting each month rose from a slow trickle to a steady stream. However, the data suggests that these official deadlines did not force the unmigrated libraries to change. The libraries that remained stuck were not held back by a lack of time or a lack of warnings; they were held back because their maintainers were gone. The study found that the strongest predictor of whether a library would migrate was simply whether it was still being updated. Libraries that had not released a new version in years were unlikely to ever migrate, regardless of the platform's rules. Even among libraries that were still being actively maintained, fewer than half had migrated within two years of the new system becoming the default.
A surprising discovery emerged regarding how these libraries were updated. The platform owners had designed one specific, official path for migration, a method called Codegen that generates the necessary code automatically. Yet, the ecosystem did not follow this single path. Instead, the migration target fragmented. Nearly half of the libraries that successfully migrated chose to use third-party frameworks, specifically tools called Expo Modules and Nitro Modules, rather than the official route. These third-party tools offered a simpler or faster way to build the new system, effectively absorbing much of the migration effort. This means that the ecosystem now relies on these external frameworks as much as, or perhaps more than, the platform's own official tools. The study notes that this creates a new layer of dependency, where the stability of the entire ecosystem now partly rests on these intermediaries.
The researchers also looked at what the creators of these unmigrated libraries were saying. They found that very few of them, fewer than one in ten, had written any statement in their documentation about the new architecture or their own maintenance status. Most said nothing at all. Among those who did speak, the message was often one of abandonment. Some libraries were explicitly marked as deprecated, while others were archived or listed as looking for new maintainers. A small number of libraries claimed to support the new system, but a closer look at their code showed they were still running on the old system, relying on a compatibility layer to function. This layer acts as a translator, allowing old code to run on the new system, but it is not a permanent solution. The study suggests that for a large part of the ecosystem, this compatibility layer has stopped being a temporary bridge and has become a permanent destination.
The implications of these findings are clear for anyone building on this platform. The official "supported" label on a library does not guarantee that it has been fully updated; it may simply mean the library works through a compatibility layer. For developers, this means that checking a library's status requires looking deeper than the surface declarations. The study highlights that the most dangerous dependencies are often the dormant ones with high download counts, as they are the most likely to cause problems if the compatibility layers are eventually removed. For the platform owners, the lesson is that setting a deadline works well for active maintainers, but it does nothing for the dormant tail of the ecosystem. The study concludes that compatibility layers must be planned as long-term infrastructure, and that the platform must engage with the third-party frameworks that have become essential to the migration process. The transition is not a single event that can be declared finished; it is an ongoing process where the ecosystem has found its own, fragmented way forward.
Drowning in papers in your field?
Get daily digests of the most novel papers matching your research keywords — with technical summaries, in your language.