--- title: "Why a senior React Native developer should learn native in 2026" description: "When native iOS beats React Native (widgets, day-one APIs, on-device ML), when it loses (two platforms, OTA, team) and why learning Swift adds to your toolkit instead of replacing it." author: Ramón Chancay date: 2026-09-01 lang: en tags: [React Native, Swift, SwiftUI, iOS, Expo, Mobile architecture] canonical: https://www.ramonchancay.me/blog/why-a-senior-react-native-dev-should-learn-native --- # Why a senior React Native developer should learn native in 2026 Learning native iOS when you have spent years shipping apps with React Native is not starting from scratch: you already know how to build mobile products, negotiate with App Review, measure a scroll that stutters and explain to a client why a feature costs three weeks. What changes is the layer you live in. This series starts from that premise. I am not going to explain what a variable is in Swift; I am going to explain which decisions actually change when you move from Expo to Xcode, and which parts of React Native you will miss from day one. This first post is the thesis: when native wins, when it loses, and why the right answer for a senior is not to replace one tool with another, but to add the second one.
TL;DR
**In this article:** - **The thesis** — [What changes for a senior](#what-changes-when-you-already-know-how-to-build-apps) · [When native wins](#when-native-really-wins) · [When native loses](#when-native-loses-and-its-worth-saying-it-plainly) - **The decision** — [Adding, not replacing](#why-its-adding-not-replacing) · [How to decide per project](#how-to-decide-per-project-a-table-and-three-questions) - **The honest part** — [What you will miss](#what-you-will-miss-from-react-native) · [The series map](#the-series-map) ## What changes when you already know how to build apps Almost all the material for learning Swift is written for someone who has never programmed for mobile. It explains what a `struct` is, what a `ViewController` is, how to declare an optional. For a senior React Native developer that material is noise: you already know what a component is, a piece of state, a navigation stack, a network cache, a signed build. What you do not know is what each of those things is called on the other side, and which of your reflexes stop working. That is why the approach of this series is not "learn Swift". It is "you already know how to build apps; this is what changes". Every post starts from a decision or a pain point you recognize: how do I handle global state, how do I navigate without file-based routing, what replaces TanStack Query, how do I sign a build without EAS doing it for me. The goal is that when you finish you can open a project in Xcode and make the same architecture decisions you make today in Expo, with judgment, not by copying a tutorial. There is a second reason to write it from that angle. A senior React Native developer already lives partly in native even if they do not admit it: every time an Expo module does not cover a case, every time a crash arrives with an Objective-C stack trace, every time you have to touch a `Podfile` or understand why the New Architecture changed a library's behavior. Learning native formally is not changing careers; it is no longer treating that half of the job as a black box. ## When native really wins I am going to be specific, because the generic argument ("native is faster") no longer convinces anyone who has used React Native with the New Architecture. There are four areas where native clearly wins today. **Widgets, Live Activities and everything that runs outside your process.** A home screen widget or a Live Activity in the Dynamic Island is not a view of your app: it is an extension the system renders on its own, without your JavaScript runtime, from a description in SwiftUI. With React Native you can add the target with a community config plugin, but you write the widget's interface in Swift all the same: the system renders and updates the widget under its own rules, without keeping your JavaScript runtime alive. The same applies to App Intents, Siri extensions and watchOS complications. **The day-one APIs.** Apple presents its APIs in June and ships them in September. With Swift you use them the day they are announced, in the Xcode beta. With React Native the sequence is different: someone has to write the native module, publish it, maintain it, and you have to trust that person will still be around next year. With Expo Modules writing that bridge is far more reasonable than it used to be, but it is still work in Swift, which is exactly the point. Liquid Glass, the new visual language of iOS 26, is the recent example: SwiftUI apps adopted it by recompiling; everyone else had to wait or imitate it. **On-device ML models.** Core ML, Vision, Speech and, since iOS 26, the Foundation Models framework with a language model that runs on the phone with no network and no per-token cost. These APIs are native, synchronous with the app's lifecycle and designed to integrate with Swift Concurrency. They can be exposed to JavaScript, but every bridge layer adds serialization, latency and one more surface to debug. When the product is local inference, that layer is a permanent cost. **The performance of demanding screens.** This one deserves nuance. For an app of forms and lists, React Native with the New Architecture performs in a way the user cannot tell apart. The difference shows up at the extremes: lists with complex cells and thousands of items, transitions that depend on frame-precise gestures, cold starts on old devices, memory usage in apps that open the camera and maps at the same time. In those cases the difference is not "a bit better": you can profile a React Native app with Instruments, but in native there are fewer layers of abstraction between what you measure and what you can change, and the control is more direct. ```text Where does the feature live? Inside your process, on regular screens │ ├── forms, lists, navigation, networking ────► RN or native, practical tie │ └── heavy scroll, precision gestures, cold start, memory ──────────────────────► native wins (fewer layers) Outside your process or at the edge of the system │ ├── widgets, Live Activities, App Intents ───► that part goes in Swift ├── new iOS API, the day it's announced ────► native (RN waits for the module) └── on-device ML ────────────────────────────► native (every bridge costs) ``` ## When native loses, and it's worth saying it plainly If the series only listed advantages it would be propaganda, and a senior would close it by the second paragraph. Native loses on three fronts, and all three are about business, not technique. **Two platforms.** A native iOS app is one app; the client almost always wants two. Kotlin and Jetpack Compose look a lot like Swift and SwiftUI, and that helps, but it is still twice the code, twice the tests and twice the platform bugs. React Native solves this with one codebase and one team. Kotlin Multiplatform and Compose Multiplatform are closing the gap from the native side, but they still do not offer the maturity of Expo for a small team that needs to ship to both stores in the same month. **OTA updates.** With EAS Update you fix a JavaScript bug and the user gets it the next time they open the app, without App Review. In native that path does not exist: every fix is a build, a submission and a review that can take hours or days. For products that iterate daily, that difference weighs more than any performance advantage. **The team.** Hiring JavaScript developers is easier and cheaper than hiring Swift developers in almost any market, and even more so in Latin America. A web team can move to React Native in weeks; moving to Swift takes months. If the project is going to be maintained by an agency or a team that already lives in TypeScript, imposing native is imposing a hiring cost nobody asked you for. And there is a fourth front that is not about business but about ergonomics, and it deserves its own section at the end: the developer experience of React Native is, in many respects, better. Fast Refresh versus compile times, Metro versus Xcode, a `package.json` versus a `.pbxproj`. I leave it for the close because it is the part that gives the rest its credibility. ## Why it's adding, not replacing The badly framed question is "should I leave React Native for Swift?". The question a senior should ask is "what do I gain if I master both?". And the answer has two parts. The first is that knowing native makes you a better React Native engineer. When you understand how a `UIViewController` works you know why React Navigation's native navigation behaves the way it does. When you understand Swift Concurrency you know what is happening when a TurboModule blocks the main thread. When you have signed a build by hand you know what EAS does for you and what to do when it fails. The senior React Native developers who bring the most value to a team are the ones who can open Xcode, read the crash log and fix the module instead of opening an issue and waiting. The second is commercial. There are projects that need Swift: the app with widgets as its core feature, the one that runs models on the device, the one that lives on watchOS, the one that wants to adopt every new Apple API the day it ships. If you only offer React Native, those projects go to someone else. If you offer both, you are the person who can tell the client "this in React Native, this in Swift, and here is the reasoning", and that conversation is worth more than either skill on its own. > In my experience, the argument that most convinces a client is not "native is better" or "React Native is cheaper", but having the judgment to say which one fits their case and why. That judgment is only built by having shipped with both. None of this means abandoning Expo. It means no longer depending on someone else having written the module you need, and being able to pick the tool per project instead of out of habit. ## How to decide per project: a table and three questions This is the table I use to steer the conversation with a client before writing a single line. It is not a fixed rule; it is a way to make the decision explicit instead of implicit. | Criterion | Leans toward React Native | Leans toward native | |---|---|---| | Platforms | iOS and Android from day one, a single team | iOS only, or iOS first and Android in another cycle | | Change cadence | Daily fixes, OTA as part of the process | Planned releases, App Store review fits in the calendar | | Core feature | Screens, forms, lists, networking | Widgets, Live Activities, local ML, watchOS, new APIs | | Performance | Standard for a content app | Scroll, gestures and startup measured in milliseconds | | Team | JavaScript, web, agency | Swift knowledge already exists, or the project justifies building it | | Sharing with web | Yes, with Expo web or shared logic | No, or the web is a separate product | The three questions that summarize the table: 1. **How many platforms and with what team?** If it is two and the team is one, React Native, unless the second question strongly contradicts it. 2. **Does the feature that sells the product live inside the app or at the edge of the system?** Widgets, extensions, local ML and day-one APIs live at the edge: native. 3. **How much is iterating without App Review worth?** If the business depends on fixing things in hours, OTA outweighs almost everything else. When all three point the same way, the decision is obvious. When they contradict each other, the answer is usually hybrid: a React Native app with native targets for the widgets and extensions, written in Swift. And for that, once again, you need to know Swift. ## What you will miss from React Native This section is the one that cost me the most to write, and it is the one that matters most. If you come from Expo, this is what you will lose when you open Xcode. No softening. **Fast Refresh.** You save a file and the app changes in under a second, keeping its state. In SwiftUI you have Xcode Previews, which are good for designing an isolated view, and an incremental compile that in a medium-sized project takes as long as it takes. Xcode has improved the speed of Previews and incremental builds, but the "save and see" loop is still slower than in Metro, and a change in a shared type can recompile half a module. One of the posts in the series is about how to modularize to bring those times down, because it is a real problem you have to attack with architecture. **OTA updates.** I said it above and I repeat it because it is what you notice most in operation: in native there is no way to fix a bug without going through the store. You can mitigate it with remote feature flags and with configuration downloaded from the server, but the code that runs is the code you signed. **Expo Go and dev clients.** Scan a QR code and have the app on your phone in seconds, with no cable and no provisioning profile. In native, installing on a physical device requires that device to be registered in your developer account and the signing profile to include it. Xcode automates almost all of it with automatic signing, but "almost" is the key word: the first time a profile gets corrupted you will miss the QR code. **The npm ecosystem.** For almost any problem there are three packages on npm with thousands of weekly downloads. Swift Package Manager has a solid ecosystem, but a smaller one, and in several domains (charts, rich text editors, certain third-party SDKs) the mature option is a single one or none. You will write more code of your own. **A single codebase.** Even if the project is iOS-only today, in React Native the door to Android was open at a much lower cost: sharing the codebase does not make the second platform free, but it keeps it far from being a second project. In Swift that door does not exist; Android is another project. **Flexbox.** SwiftUI's layout system is different: each view proposes a size to its children, each child decides its own, and the parent positions them. It is coherent and powerful, but your `flex: 1` and `justifyContent` reflexes do not translate one to one. The SwiftUI post explains the whole system, because it is the biggest mental shift in the entire series. **A `package.json` instead of a `.pbxproj`.** Xcode's project file is a proprietary format that produces merge conflicts every time two people add files. There is a solution (Tuist, or generating the project from a description) and the series covers it, but the fact that you need a tool so the project file does not break the team says a lot. **TanStack Query.** There is no equivalent with the same adoption. You will design your own cache, invalidation and retry layer. There are libraries that help and clear patterns with `AsyncStream` and SwiftData, but the decision and the maintenance are yours. **The Spanish-speaking community.** React Native has a huge community in Latin America: meetups, Discord, content. The Swift one exists and is good, but it is smaller and more concentrated in English. None of this is a reason not to learn native. It is the list of what you will have to make up for with architecture, tooling or patience, and I would rather you have it before you start than discover it in the second week. ## The series map The following posts go in the order in which a senior runs into the problems while building their first serious app in Swift, not in the order of a course: | # | Topic | The React Native pain point it starts from | |---|---|---| | 2 | [Swift for people who already master TypeScript](/blog/swift-for-typescript-developers) | Optionals, enums and Codable instead of `null`, unions and zod | | 3 | [SwiftUI is not React](/blog/swiftui-is-not-react) | `body` vs `render`, view identity, layout without flexbox, hooks vs property wrappers | | 4 | [State and architecture](/blog/state-and-architecture-from-zustand-to-observable-and-tca) | From Zustand and Redux to `@Observable` and TCA | | 5 | [Navigation without file-based routing](/blog/swiftui-navigation-without-file-based-routing) | From Expo Router to `NavigationStack` and a Route enum | | 6 | [Data: what TanStack Query did for you](/blog/data-in-swift-what-tanstack-query-did-for-you) | Cache, invalidation and `URLSession` | | 7 | [Real concurrency](/blog/swift-concurrency-goodbye-event-loop) | From the event loop to actors and Swift 6 | | 8 | [Persistence](/blog/ios-persistence-swiftdata-grdb-keychain) | SwiftData, GRDB, Keychain and sync | | 9 | [From the expo-* ecosystem to Apple frameworks](/blog/from-the-expo-ecosystem-to-apple-frameworks) | The equivalence table by domain | | 10 | [UI, theming and animations](/blog/swiftui-ui-theming-animations-without-nativewind-reanimated) | Without NativeWind or Reanimated | | 11 | [Build, signing and the App Store](/blog/build-signing-app-store-what-eas-hid-from-you) | What EAS did for you | | 12 | [Testing and tooling](/blog/ios-testing-and-tooling-for-seniors) | Swift Testing, snapshots, Instruments, build times | | 13 | [What you can only do in native](/blog/what-you-can-only-do-in-native-ios) | Widgets, Live Activities, App Intents, StoreKit 2, Foundation Models | Each post can be read on its own, but the order matters: the state post assumes the SwiftUI one, the navigation post assumes the state one, and the data post assumes concurrency even though concurrency comes later, because in practice you will run into `async` before you understand it. ## Frequently asked questions ### Is it worth learning Swift if React Native's New Architecture already closed the performance gap? Yes, because performance is not the main argument. The main arguments are the features that live outside the process (widgets, extensions, Live Activities), the APIs that reach Swift first and on-device ML. The New Architecture greatly improved the communication between JavaScript and native, but it does not change where a widget runs or who writes the module for a new API. ### Should I learn UIKit or go straight to SwiftUI? SwiftUI, with one practical exception: you will read UIKit constantly, because many libraries, many examples and some system components are still exposed that way. Learn SwiftUI as your main language and enough UIKit to wrap a `UIViewController` when needed and to understand what is underneath a `List`. ### What about Kotlin? Does the series cover Android? No. The series is about iOS by focus: the mental shift from React Native to SwiftUI and Swift Concurrency is already enough for thirteen posts. Much of what is explained about architecture, navigation and state carries over to Jetpack Compose under other names, but that is another series. ### How long does it take to become productive in Swift coming from TypeScript? It depends on what productive means. Writing a SwiftUI screen that compiles: days. Making correct architecture decisions about state, navigation and concurrency: months, and that is exactly the stretch this series tries to shorten. The language is learned quickly; the slow part is no longer applying React reflexes where they do not belong. ## Conclusion For a senior React Native developer, learning native iOS is not switching tools, it is no longer having half of the job in a black box and being able to choose per project instead of out of habit: knowing when what sells the product lives at the edge of the system and when the business demands two platforms and OTA. And what you will miss is real. If you are going to start, do it in this order: first decide with the table what kind of project justifies Swift in your context, then build a small app that uses at least one capability React Native does not offer (a widget is the most honest choice) and, while you build it, read the series in order. The [next post](/blog/swift-for-typescript-developers) is the only one about the language: the five differences between Swift and TypeScript that do change how you design code, without going over syntax.