Native Swift vs Flutter vs React Native: RAM, CPU and Real Efficiency

The short version

• On the only iPhone test that measures all three the same way, Swift used the least memory by a wide margin. One scroll through a list added 9.74 MB in Swift, 25.33 MB in Flutter and 45.13 MB in React Native — about 62% and 78% less
• That gap is built in, not a bug. Flutter and React Native each carry their own engine in memory. A Swift app uses what the phone already has
• Memory matters because iPhones do not slow down — they shut apps down, heaviest first. Your customer sees an empty basket, not a crash. It never shows up in your crash reports
• Widgets settle the argument on their own. Home-screen widgets and Live Activities run under a limit too small for a bundled engine, so that part is written in Swift whatever you choose for the main app
• Most users will never notice the difference. On a recent phone, all three feel the same. It becomes decisive on older handsets, on long sessions, and anywhere the app does sustained work
• Native wins the measurements and costs more once you need Android too, because there is no second platform in the price. That is the real trade — not Swift against Flutter, but one app against two
• Be sceptical of the numbers you are shown. On three of the four questions buyers ask most — processor use, download size, opening speed — nobody has published an iPhone test that includes Swift at all. Most figures in circulation are from 2020 and describe software nobody ships

We build in all three: native Swift, Flutter and React Native. So this is a comparison of trade-offs we live with, not a pitch for one of them.

How much more RAM and CPU does Flutter or React Native use than native Swift?

Memory growth over an automated 100-item scroll. SynergyBoat, iPhone 16 Plus, N=3, August 2025. This is a growth delta, not a total footprint. Full conditions and limits are in the table below.

Two things that number does not tell you, and both matter.

It is memory, not CPU. No published benchmark measures CPU for all three on iOS against a Swift baseline. We looked hard and it does not exist. Everything below with a CPU figure either ran on Android or had no native arm at all, and we say so each time.

Most users will never feel it. On ordinary screens all three hold 60 fps on modern hardware, and a 35 MB difference is invisible on a phone with 8 GB of RAM. The gap becomes decisive in three specific places: memory-capped app extensions, sustained compute, and older or low-RAM devices. Those are the cases this article is really about.

The rest of the article gives you every figure we could verify. Each one is labelled with the device, framework version, and tool it came from. We label them for a reason. Most numbers on this topic carry no labels at all, and about half are out of date.

One definition first, since it gets blurred constantly. By "native Swift" we mean Swift with UIKit or SwiftUI. Those two differ from each other on footprint too. But both run under ARC, and neither loads a second runtime. That is the distinction this whole comparison rests on.

What does that memory number actually cost you?

An iPhone does not slow an app down when memory runs short — it shuts the app down, heaviest app first. Your customer does not see a crash. They switch to another app for twenty seconds, come back, and find an empty basket and a login screen. It is the least understood cost of a heavier app, and it never appears in your crash reports.

We wrote that up separately, with the widget ceiling that stops some features being buildable at all: Why iPhones shut down heavy apps first.

Every number we could verify, in one table

Four things people ask about — memory, processor use, download size, and how fast the app opens. The numbers are below. The conditions each was measured under are numbered underneath, so you can scan the table first and check the small print only where it matters.

One flashcard app, built four ways and run on an iPhone, is the only public test that puts native Swift beside both Flutter and React Native. It covers memory. For the other three questions, no such test has been published.

What was measured	Native Swift	Flutter	React Native
Memory — the one question with a real answer
Extra memory used while scrolling a long list 1	9.74 MB	25.33 MB	45.13 MB
The same figure, next to Swift 1	the baseline	2.6× more	4.6× more
How much the result moved between runs 1	± 0.18	± 0.47	± 10.94
Memory against a native app, on Android 2	no Swift on Android	middle of the field	highest of any framework tested
Older iPhone figures still quoted today 3	48 MB	117 MB	135 MB
Processor use — no iPhone test includes Swift
iPhone, same app, all three 4	nobody has published this	nobody has published this	nobody has published this
Scrolling a list, on Android 5	no Swift on Android	43.4%	52.9%
Running the camera, on Android 5	no Swift on Android	81.6%	49.1%
Download size — what your customer waits for
A bare-bones app, downloaded on iPhone 6	nobody has published this	10.9 MB	nobody has published this
Machinery carried just to run 7	none — uses what is on the phone	~4 MB engine	a JavaScript engine, ~2.4 MB
How fast the app opens — nothing comparable exists
Cold start on iPhone, same app 8	nobody has published this	nobody has published this	nobody has published this

1. SynergyBoat, August 2025 — the same flashcard app built four ways, iPhone 16 Plus, three runs each. Swift used about 62% less memory than Flutter and 78% less than React Native. React Native did not just use more, it was the least predictable — swinging by about a quarter of its own average, so read it as “roughly four to five times”, not exactly 4.6.
2. Oliveira and colleagues, 2023 — the one study here that passed academic peer review. Android phone, and the native app it compared against was written in Java, not Swift. A direction of travel, not an iPhone number.
3. inVerita, June 2020, on an iPhone 6s. Measured before three of the biggest performance changes these frameworks ever shipped. Listed so you recognise it when someone quotes it at you as current — it is not.
4. No public iPhone benchmark measures processor use with a native Swift app in it. Flutter publishes live iPhone figures, but only for Flutter, and counted in a way that will not line up against anything you measure yourself.
5. Tollin and Lidekrans, Linköping University, 2023. Android only, no Swift version built. Note the order reverses between the two workloads — which is exactly why a single processor percentage for a framework is worth very little.
6. Flutter's own FAQ, measured March 2021 on an empty app. Apple publishes no matching Swift figure and we found no matching React Native one, so this number has nothing fair to sit beside.
7. Flutter's FAQ for the engine size; Callstack's measurements for React Native's. This is the structural difference: a cross-platform app ships a second runtime and keeps it in memory. A Swift app borrows what the phone already has.
8. Flutter's team runs a Swift-versus-Flutter opening-speed test in its own build system but publishes no figures from it. One open-source project does publish opening speed against a real Swift app — but has no React Native version.

The rows saying nobody has published this are the finding, not a gap we failed to fill. On three of the four questions buyers ask most, there is no published iPhone test that includes a native Swift app.

Numbers that look like comparisons but are not

These four come up in almost every framework argument. Each one measures a framework against an older version of itself. None of them involves Swift. If someone quotes one of these to you as a reason to skip native, they have answered a different question.

What gets said	What was actually compared	The detail that gets left out
“React Native starts about 40% faster”	Two JavaScript engines, against each other	Callstack, on iPhone, back at React Native 0.64. Memory dropped about 18%, and the app got 2.4 MB bigger
“The New Architecture made it faster”	React Native 0.76 against React Native 0.75	Its own release notes, on Android: the app got about 3.8 MB smaller and opened about 15 milliseconds quicker. No memory figure was published at all
“Shopify proved React Native is production-ready”	Shopify's apps before and after their own upgrade	Shopify, September 2025: opening got ~10% faster on Android and ~3% on iPhone — and some screens got up to 20% slower, freezes went up on both platforms, and crash-free sessions sat below their own target for a couple of weeks
“Flutter fixed its performance problems”	Flutter 3.22 against earlier Flutter	Flutter's own announcement, on an iPhone 11: blur effects roughly halved in cost. Real, and worth having — but it says nothing about how Flutter compares to Swift

Flutter's DeviceLab publishes live, per-commit RAM and CPU from real iPhones. Here is the scrolling benchmark on 6 September 2026: an iPhone 16 Pro at 84.70 MB and an iPhone 11 at 80.91 MB. It is not in the table above, and that is deliberate — it measures Flutter against Flutter, with no Swift app anywhere in it.

Two unit warnings, though. The CPU figures alongside them are 9.33% and 13.72%. Both are measured on an all-core basis. That is not the convention Xcode Instruments uses. So they cannot be lined up against the Android CPU percentages above, or against any Swift number you measure yourself. The memory series is the engine’s own dirty_memory_usage sample. It is not Apple’s dirty-plus-compressed footprint, and GPU memory is reported separately. So it is not directly comparable to an Instruments footprint reading either.

That lab also has no Swift or React Native arm. It compares Flutter to earlier Flutter. This is the best-instrumented data in the entire article, and it still cannot settle the comparison.

Read that table honestly and four things jump out.

• Nobody has published a controlled iOS benchmark of the same app written three ways on current runtimes. No such study exists. Anyone presenting one is extrapolating
• The rigorous academic work is Android with a Java baseline, so it cannot speak to Swift. It also measured Flutter 3.0.3 on Skia and React Native 0.68.2 on JavaScriptCore. Both frameworks have since replaced those exact components. Its method is the best in the field. Its runtimes are two generations old
• The result flips with the workload. In the Linköping data, Flutter wins list-scrolling. It then loses the camera test by 32 points
• iOS and Android memory numbers are not comparable at all — see below

Why you cannot put iOS and Android memory in the same column

This trips up nearly every comparison article, including ones that are otherwise careful. In WWDC18's "iOS Memory Deep Dive", Apple defines an app's memory footprint as its dirty and compressed pages ("clean memory doesn't really count"), counted in 16 KB pages. Android's meminfo reports PSS/RSS on an entirely different model. A 90 MB iOS figure and a 90 MB Android figure are not the same measurement. Averaging or ranking across them produces nonsense.

Two more things from that session are worth carrying. Apple never publishes the numeric footprint limit. It depends on the device, and going over it raises EXC_RESOURCE.

Apple's own jetsam event report documentation works through a sample case. A process is using 92,802 pages × 16,384 bytes = 1.52 GB when it is killed for per-process-limit. But that is what the app was using. It is not a published ceiling. Anyone quoting a specific "iOS kills apps at X GB" figure is inventing a spec.

So what should you actually pick?

Efficiency is one input, and it is rarely the one that decides. The honest trade-off is this: native Swift wins every measurement above, and native costs more the moment you need Android too — because there is no second platform included in the price.

That is the real comparison. Not Swift against Flutter, but one native app against two native apps against one shared app that is heavier on both. Find your situation below.

What to build, and what each answer costs you. The last column is the one people skip.

If this is your situation	Build this	Why	What it costs you
iPhone only, no Android on the roadmap	Native Swift	Lowest memory of anything measured, every Apple feature available the day it ships, and nothing extra bundled into the download	Nothing extra. This is the case where native is also the cheapest option — one platform, one codebase, and no cross-platform layer to debug when something breaks
Both platforms, and efficiency is the product — background audio, camera, maps, on-device AI, long sessions, or customers on older phones	Native on both	This is where the memory gap stops being a statistic and starts shutting your app down mid-session	The expensive answer, honestly. Two codebases: every screen gets built twice. Your design, backend, product and testing work is not duplicated — so it is well short of paying twice — but the app layer genuinely is
Both platforms, ordinary content or booking or shop app, and budget is the binding constraint	Flutter or React Native	One team and one codebase covering both platforms is a real saving, and for an app that mostly shows lists and forms the memory gap may never surface for your customers	You accept a heavier app. Budget for testing on the oldest phone you intend to support, not the newest — that is where the difference shows up
Widgets, Live Activities or extensions matter to how people use your product	Swift, whatever else you choose	These run under a memory ceiling low enough that React Native's own documentation says it may not fit	Not really a choice. Even a Flutter or React Native app ships this part in Swift — so plan for that skill on the team from the start rather than discovering it late
You already employ a React and TypeScript team	React Native	The team you have is a bigger asset than a benchmark. Shipping this quarter beats being 4× lighter next year	The heaviest and least predictable of the three in the only iPhone test that includes Swift. Worth revisiting if your app becomes performance-sensitive
One custom design system, identical on both platforms, animation-heavy	Flutter	Flutter draws every pixel itself, so a bespoke design looks the same everywhere instead of fighting two sets of native components	About 2.6× Swift's memory growth in that same test — the price of bringing your own renderer

If your situation spans two rows, the deciding question is usually not efficiency. It is whether widgets and extensions are core to the product, and whether your customers are on old phones. Both of those push toward native regardless of budget.

Here is the honest summary. For the overwhelming majority of apps, users will never perceive the memory or CPU difference. They will perceive a badly built app in any of the three. Choose on team, platform strategy, and the specific system frameworks you depend on. Then measure your own build against a real device before you commit.

For the head-to-head versions of this comparison, with the framework-specific evidence in full: Swift vs Flutter and Swift vs React Native.

Sources

Every figure above comes from one of these. Each entry states the conditions that make it citable: device, versions, tool, sample size. A number without them is not evidence.

The measurements

1. SynergyBoat — “Flutter vs React Native vs Native: 2025 Performance Benchmark” (31 August 2025)The ΔMemory figures. iPhone 16 Plus, N=3, RSS growth over a 100-item scroll. Vendor-published. We use its memory arm only; its frame-time comparison measures different quantities against one budget.
2. Oliveira, Moraes, Castor & Fernandes — “Analyzing the Resource Usage Overhead of Mobile App Development Frameworks” (EASE 2023)Peer-reviewed. Samsung Galaxy S20 FE, Android 12, adb batterystats + meminfo, 45 runs per benchmark with the first 15 discarded. Flutter 3.0.3 (Skia), React Native 0.68.2 (Hermes disabled), against native Java. No iOS, no Swift. Open-access PDF via Utrecht University; DOI 10.1145/3593434.3593487.
3. Tollin & Lidekrans — “React Native vs. Flutter: A performance comparison” (Linköping University, 2023)Android only. Flutter 3.10.0 vs React Native 0.71.6, adb shell top, five 30-second runs. No Swift arm. Its discussion section explains the camera-test gap that most citations of it omit.
4. Shopify Engineering — “Migrating to React Native’s New Architecture” (5 September 2025)Production data from Shopify Mobile and Point of Sale. Reports its regressions as well as its wins, which is why we use it.
5. Flutter DeviceLab performance dashboardLive, per-commit RAM and CPU from real iPhone 11 and iPhone 16 Pro hardware. Flutter only. CPU is an all-core percentage, not the Xcode Instruments convention. Linked from Flutter’s performance metrics docs.
6. React Native — “Toward Hermes being the default”Carries the Callstack/Mattermost iOS numbers: startup ~40% faster, memory ~18% lower, app +2.4 MiB, at React Native 0.64.
7. Callstack — “Hermes performance on iOS”The original Mattermost measurements behind those figures.

First-party documentation

1. Apple — “iOS Memory Deep Dive”, WWDC18 session 416Defines an app’s memory footprint as dirty + compressed pages, counted in 16 KB pages. States the footprint limit is device-dependent and never publishes a number.
2. Apple — “Profile and optimize your game’s memory”, WWDC22 session 10106Source for the claim that on Apple silicon, accessed Metal resources count as dirty memory because CPU and GPU share one pool.
3. Apple — “Identifying high-memory use with jetsam event reports”The worked example we quote: 92,802 pages × 16,384 bytes = 1.52 GB in use at a per-process-limit termination. That is usage at death, not a published ceiling.
4. Apple Developer Forums — EXC_RESOURCE RESOURCE_TYPE_MEMORY (limit=30 MB)Developer-reported WidgetKit crash logs, not an Apple specification. The source for the ~30 MB widget ceiling.
5. Flutter FAQ — “How big is the Flutter engine?”The minimal-app sizes: ~4.8 MB ARM64 Android download, 10.9 MB iOS download, ~4 MB of it engine. Measured March 2021, no Material Components, --split-per-abi.
6. Flutter — Impeller rendering engineConfirms Impeller is the only renderer on iOS and precompiles shaders at build time.
7. Flutter — “Don’t Fear the Garbage Collector” (Matt Sullivan, 2019)The generational GC description: young-space scavenger, parallel mark-sweep, engine idle hooks.
8. Meta Engineering — “Hermes: An open source JavaScript engine optimized for mobile apps” (2019)Why Hermes ships no JIT: warm-up hurts time-to-interactive, and a JIT costs code size and memory.
9. facebook/hermes issue #1829 — memory consumption in Hermes V1A Meta maintainer explaining that HV32 uses ~40% less memory but needs memory-mapping unavailable on iOS, so Hermes V1 ships HV64 there. Applies from React Native 0.84 (February 2026).
10. React Native 0.70 release notes (5 September 2022)Hermes becomes the default engine.
11. React Native — “The New Architecture is Here” (23 October 2024)Fabric, TurboModules and bridgeless by default. Also the source for the fact that the legacy bridge remains in 0.76 for compatibility.
12. React Native 0.76 release notesThe only official figures: Android APK ~3.8 MB smaller (20%), median startup ~15 ms (~8%) faster. No memory figure was published.
13. React Native — app extensions documentationReact Native’s own warning that its memory use “tends to be too high” for the tightest extension budgets. Note the page still discusses the 16 MB Today widget, which Apple removed in iOS 18.

Open source you can run yourself

1. SynergyBoat benchmark sourceAll four implementations — Swift, Flutter, React Native, Kotlin — with the instrumentation. Clone and re-run it.
2. EASE 2023 replication packageEvery raw adb dump behind the paper. Re-runnable.
3. jacobras/flutter-vs-native-vs-kmpOne app in four stacks including a native Swift/SwiftUI baseline. Publishes app size and startup only — no RAM or CPU. Archived August 2026.
4. flutter/flutter — imitation_game_swiftui and imitation_game_flutterFlutter’s own SwiftUI-versus-Flutter comparison, running in iOS CI. Measures compile time, size and time-to-first-frame. No RAM or CPU, and it publishes no figures.

Sources we checked and did not use

1. inVerita — “Deep Performance Comparison” (June 2020)The origin of the “48 MB / 117 MB / 135 MB” figures. iPhone 6s and a 2014 iPad Mini 3, before Hermes, Impeller and the New Architecture. Linked so the claim is checkable, not as a recommendation.
2. inVerita — “Examining Performance” (March 2020)The pi-digit microbenchmarks behind “Flutter is 15% faster than Swift”. Measures arithmetic in a loop, on an iPhone 6s.

If you would like a second opinion on that decision for a specific product, talk to us. We ship in all three and have no stake in which one you pick.