A large retailer’s reported shift away from React Native towards native Swift and Kotlin has revived a long-running argument about cross-platform mobile development. The trade-offs are well understood, even when a single company’s reasoning is not public.
Key takeaways
- Discussion on Hacker News about a major commerce company reportedly moving mobile development from React Native to Swift and Kotlin has drawn a large volume of comments, indicating an unresolved debate rather than a settled question.
- React Native lets teams share business logic and user-interface code across iOS and Android using JavaScript or TypeScript, while Swift and Kotlin are the platform-native languages maintained by Apple and Google respectively.
- The usual arguments for going native centre on startup time, animation smoothness, memory behaviour, and immediate access to new operating-system features without waiting for a bridging layer.
- The usual arguments for staying cross-platform centre on hiring flexibility, a single codebase for shared logic, and faster delivery of features that do not depend on platform-specific behaviour.
- No framework choice is universally correct: the decision depends on team size, app complexity, performance sensitivity, and how much of the product is genuinely identical across platforms.
What is actually happening
Reports circulating on Hacker News describe a large e-commerce company shifting its mobile application development away from React Native and towards the native toolchains: Swift with SwiftUI or UIKit on iOS, and Kotlin with Jetpack Compose or the older Android View system on Android. The specific internal reasoning, timelines and scope of that migration are not something that can be independently verified here, and the details discussed in a comment thread should not be treated as a complete account.
What can be described accurately is the class of decision involved. A company that adopted a cross-platform framework at one stage of its growth is reported to have concluded that, at its current stage, the trade-offs point the other way. That reversal is what generated the volume of discussion: it runs against a common assumption that cross-platform adoption is a one-way door.
Why this is being discussed now
Cross-platform mobile frameworks have been through several cycles of enthusiasm and retrenchment. Each time a well-known engineering organisation publicly changes direction, the debate reopens, because relatively few large consumer apps document their reasoning in public. Engineering teams facing the same decision have little hard evidence to work from, so a visible example from a company with a large mobile user base carries disproportionate weight.
There is also a technical backdrop. Both Apple and Google have invested heavily in declarative user-interface frameworks — SwiftUI and Jetpack Compose — that address some of the productivity gap that made cross-platform tooling attractive in the first place. Kotlin Multiplatform offers a middle path, sharing business logic while keeping user interfaces native. React Native itself has undergone significant architectural rework. The comparison that teams made several years ago is not the comparison they would make today, which is part of why old conclusions are being revisited.
The background a newcomer needs
Mobile applications for iOS and Android were historically written twice: once in Objective-C and later Swift for Apple’s platforms, once in Java and later Kotlin for Android. That means two codebases, two sets of specialists, and two implementations of every feature.
Cross-platform frameworks attempt to reduce that duplication. React Native, which originated at Meta, lets developers write application code in JavaScript or TypeScript using React’s component model. Rather than rendering through a web view, it maps components onto the platform’s real native views, which is why apps built with it can feel closer to native than a wrapped website. Communication between the JavaScript layer and the native layer historically passed through an asynchronous bridge; a newer architecture reduces that indirection.
The competing approaches include Flutter, which draws its own widgets rather than using platform views; Kotlin Multiplatform, which shares non-UI code; and simply writing two native apps. Each makes a different bet about which layer of the stack is worth sharing.
Who is affected and how
The teams most affected by this argument are mid-sized product organisations. A company with three mobile engineers cannot realistically staff two native platforms at depth, and cross-platform tooling is often the only way to ship on both. A company with sixty mobile engineers can afford platform specialists, and the coordination overhead of a shared abstraction layer starts to outweigh the code reuse it provides.
Individual developers are affected in a different way. A React Native specialist’s skills transfer across employers but are tied to the framework’s fortunes; a Swift or Kotlin specialist’s skills are tied to a platform that is not going anywhere but is narrower in scope. Neither position is safe or unsafe in the abstract.
End users are affected mainly through performance and platform integration. Users rarely know or care which framework an app uses, but they notice slow launches, stuttering scroll, unexpected battery drain, and features that arrive on one platform months before the other.
Where informed people disagree
The sharpest disagreement is about whether performance problems in cross-platform apps are inherent to the approach or an artefact of how specific teams used it. One camp argues that any abstraction over two different rendering systems imposes a cost that cannot be optimised away, particularly for list-heavy, animation-heavy interfaces. The other argues that most reported performance issues trace back to ordinary engineering problems — unnecessary re-renders, oversized images, poor state management — that would also occur in a native codebase.
A second disagreement concerns total cost. Advocates of native development point out that a shared codebase is rarely as shared as promised, because platform-specific workarounds accumulate and someone must still maintain the bridging layer. Advocates of cross-platform development counter that maintaining two full implementations doubles not just the code but the testing surface, release coordination and defect backlog.
A third strand of disagreement is about organisational fit rather than technology. Some argue the decision is really about whether a company wants its mobile engineers organised around platforms or around product areas, and that the framework choice follows from that structure rather than driving it.
The practical implications for your own decision
For a team weighing this, several questions narrow the field faster than any general argument.
How much of the product is genuinely identical across platforms? An app that is mostly forms, lists and content delivery shares well. An app built around camera, sensors, background processing or platform-specific hardware shares poorly.
How performance-sensitive is the core interaction? If the primary screen is a long, image-heavy, continuously scrolling feed, that is exactly the workload where framework overhead is most visible. If the app is used in short, discrete sessions, it matters less.
How quickly must new operating-system features be adopted? Native toolchains get them on day one; cross-platform frameworks need a release cycle, and sometimes community maintenance, to catch up.
What can be hired for in your market? A framework choice that cannot be staffed is not a viable choice regardless of its technical merits.
Finally, consider incremental options. Both native platforms can embed React Native screens, and React Native apps can call into native modules. Many real migrations in either direction happen screen by screen rather than as a single rewrite, which limits the risk of committing to a decision that later proves wrong.
What to watch next
Watch whether other large consumer apps publish comparable reasoning. A single example is an anecdote; a pattern across several organisations with similar scale would be more informative.
Watch the maturity of the middle path. Kotlin Multiplatform and similar approaches that share logic but not user interface may absorb much of this debate by making the question less binary.
Watch how the declarative native frameworks develop. If SwiftUI and Jetpack Compose converge on similar enough models, the productivity argument for a shared UI layer weakens, because writing the interface twice becomes cheaper than it once was.
Finally, watch for follow-up accounts rather than initial announcements. Migrations are usually reported at the point of decision, when the costs are still theoretical. The useful information — whether the change delivered what was expected — tends to emerge much later, if at all.
Frequently asked questions
Is React Native being abandoned by the industry?
There is no evidence of a broad industry retreat from React Native. Individual companies change direction for reasons specific to their scale, product and team structure, and such changes attract attention precisely because they are notable rather than typical. React Native remains actively developed and widely used. A single high-profile migration in either direction is not a reliable indicator of where the wider industry is heading.
What is the difference between Swift, Kotlin and React Native?
Swift is Apple’s programming language for iOS and its other platforms. Kotlin is the primary language for Android development, supported by Google. Both are native: code written in them compiles directly for their platform. React Native is a framework that lets developers write application code once in JavaScript or TypeScript and render it using native components on both platforms, trading some direct platform access for shared code.
Does React Native make apps slower than native apps?
It can introduce overhead, particularly for interfaces with heavy animation or long scrolling lists, because application logic runs in a separate layer from the native rendering system. Whether users notice depends on the app. Many performance complaints attributed to the framework stem from ordinary implementation problems that would also affect native code. Careful engineering narrows the gap considerably, but does not always close it entirely.
Should a small team choose native or cross-platform development?
Small teams generally benefit from cross-platform tooling, because staffing two native platforms at sufficient depth is expensive. The calculation changes as headcount grows and as the product comes to depend more on platform-specific capabilities. The honest answer depends on what the app actually does: content-driven apps share well across platforms, while hardware-driven or performance-critical apps share poorly.
What is Kotlin Multiplatform and how does it differ?
Kotlin Multiplatform allows shared business logic — networking, data models, validation rules — to be written once in Kotlin and used on both platforms, while the user interface is built natively with SwiftUI and Jetpack Compose. It targets a different trade-off from React Native: less code sharing overall, but no abstraction layer between the application and the platform’s rendering system.
How difficult is it to migrate between the two approaches?
Migrations are usually incremental rather than wholesale. Native apps can embed React Native views, and React Native apps can call native modules, so teams commonly convert one screen or feature at a time. That said, a full migration in either direction is a substantial multi-quarter effort for a large app, involving retraining, rebuilt tooling and a long period of maintaining two systems at once.
Sources and further reading
- Hacker News — the discussion thread where the reported migration was debated, useful for the range of practitioner opinion but not a verified account of any company’s internal decisions.
- Official React Native documentation — the maintainers’ description of the framework’s architecture, including the rework of its native interface layer.
- Apple developer documentation — reference material for Swift, SwiftUI and UIKit, including guidance on performance and platform integration.
- Android developer documentation — reference material for Kotlin, Jetpack Compose and the Android View system, including migration guidance between the two UI approaches.
Surfaced from the hackernews signal “mobile framework migration debate”. AI-assisted draft, editorially reviewed.
