Meta’s “one supercomputer” line is right about capacity and misleading about speed. That difference matters to anyone considering a second Mac.

On October 15, 2026, Meta released Muse Spark Open, its new open-weight model. What made it news was that a model with 816 billion parameters runs on two Mac Studios. Here is the line from Meta’s blog:

“The result is two Mac Studios behave like one supercomputer with a terabyte of unified memory.”

MacRumors and Engadget repeated the line word for word. The same day, Apple published its own measurements. Apple’s article makes no such claim: it describes a model that will not fit on a single machine, so half of it goes on one Mac and half on the other.

So do two Macs really behave like one computer? The short answer: there is a terabyte of memory, but it isn’t one memory. That distinction explains both why the setup works and what to check before buying a second Mac.

What was announced?

• The model: Muse Spark Open has 816 billion parameters, of which only 42 billion are active for each token. It has a 1-million-token context window and accepts images, audio, and text. The weights can be downloaded under a license that allows limited commercial use (Meta).
• The hardware: Two M5 Ultra Mac Studios with 512 GB of unified memory each, connected over Thunderbolt 5. In its two-machine test, Apple used two cables for the link (Apple).
• The software: Apple’s MLX framework and its jaccl backend, which uses RDMA over Thunderbolt. RDMA support arrived with macOS 26.2.
• Precision: In its native format (BF16), the model is larger than 1.6 TB. The tests used the 4-bit NVFP4 version, which is about 493 GB.

The 512 GB Mac Studio is not on sale yet; Apple says it is coming in late October. Apple had not announced its price as of October 15, but according to MacRumors, even the 256 GB model costs more than $10,000. Engadget puts the alternative, four 256 GB Mac Studios, at about $38,000.

What the line gets right: capacity

Together, the two Mac Studios have 2 × 512 = 1,024 GB of memory: a terabyte. The model’s 4-bit version is about 493 GB. The weights alone fit under 512 GB, but that leaves no room for the operating system, the intermediate data created during computation, or the conversation’s context. 🧐

Apple says so plainly: the model will not fit on a single machine, so the solution is to “store half of the model on one Mac Studio and the other half on another” (Apple).

In terms of capacity, then, two Macs together hold a model that one Mac cannot. The “terabyte” in Meta’s line is accurate in that sense. 👏🏻

What it gets wrong: there is no single memory

Inside a Mac, “unified memory” means the CPU and the graphics processor (GPU) share the same memory. On the M5 Ultra, the GPU reads that memory at 1.2 TB per second (Apple).

Between two Macs, there is a Thunderbolt 5 cable. At best, it carries about 10 GB per second; with two cables, as in Apple’s setup, about 20 GB (MacGeneration). That is 60 to 120 times slower than the Mac’s own memory.

The gap in latency is even larger: according to MacGeneration, memory responds roughly 1,000 times faster than this link. So each Mac’s GPU can read only its own memory quickly. The two machines’ memories are not one pool; they are two separate pools joined by a cable.

What if it were one memory?

A thought experiment makes the difference concrete. What if one Mac’s GPU had to read the half of the model stored on the other Mac over the cable?

The 42 billion parameters active for each token come to about 24 GB, even in the 4-bit version. Half of that, about 12 GB, would have to cross the cable for every token. Even with two cables, that is about 0.6 seconds per token: fewer than 2 tokens per second.

Apple measured 25 tokens per second. In other words, the system works not because it behaves like one memory but because it avoids doing so.

Interestingly, the “supercomputer” comparison is apt. Supercomputers, too, are made of many nodes, each with its own memory, connected by a fast network. The misleading part is “unified memory.”

So how does it work?

Three things come together: the model’s structure, the way it is split, and the latency of the link between the two Macs.

Each token uses a twentieth of the model

Muse Spark Open is a mixture-of-experts (MoE) model. Each layer has 256 “expert” subnetworks, and only 8 of them are chosen for each token (NVIDIA). That is why only 42 billion of the 816 billion parameters, roughly a twentieth, are active for each token.

The sentence just before Meta’s “supercomputer” line makes this point: “the chip’s 1.2 TB/s of memory bandwidth is fast enough to read the small slice each token needs.” That part is accurate. 👏🏻

Each Mac reads its share from its own memory

There are two ways to split a model across two machines (Apple):

• Pipeline (split by layers): The first Mac holds the model’s first layers; the second holds the last ones. Each token passes through one Mac, then the other; while one works, the other waits. Apple notes that generation speed stays “very similar to that of a single machine, since the layers are still evaluated sequentially.”
• Tensor parallel (split within layers): Each Mac holds half of every layer. Both Macs compute each layer at the same time and combine their results. A single conversation gets faster, too; the price is that the machines wait for each other at every layer.

With Muse Spark Open on two Macs, the pipeline split produced 15.7 tokens per second and the tensor-parallel split 25.0 (Apple).

What crosses the cable

In a tensor-parallel split, the weights never move; each Mac reads its half from its own memory. All that crosses the cable is intermediate results, combined twice in every layer. A rough calculation puts this at 2–4 MB per token: 62 layers × 2 combinations × 8,192 values × 2–4 bytes (architecture).

A cable carrying 10 GB per second moves that in 0.2–0.4 milliseconds, while a token takes about 40 milliseconds. Cable capacity is not the problem.

Latency is what matters

In a tensor-parallel split, the two Macs wait for each other about 124 times per token. Over an ordinary network connection (TCP), a message on this link takes about 300 microseconds (Gigazine). That adds about 37 milliseconds of waiting per token; by a rough estimate, it would cut 25 tokens per second to 13–14, below even the pipeline split.

That is why RDMA is critical. With RDMA, added in macOS 26.2, the Thunderbolt controller writes data arriving from the other Mac directly into the application’s memory, without going through the operating system’s network stack (Apple TN3205). Latency drops below 50 microseconds (Gigazine); MacGeneration speaks of a few tens of microseconds (MacGeneration). Total waiting per token falls to at most about 6 milliseconds.

Independent measurements bear this out. In Jeff Geerling’s test with four Mac Studios, llama.cpp, which splits by layers over TCP, got slower as machines were added: Qwen3 235B ran at 20.4 tokens per second on one machine and 15.2 on four. By contrast, exo, which splits within layers and uses RDMA, sped up from 19.5 to 31.9 (AppleInsider).

What the measurements say

Apple measured with an 8,192-token prompt and a single user (Apple).

• Adding machines does not scale linearly. For Muse Spark Open, going from two Macs to four raises speed from 25.0 to 36.7 tokens per second: about 1.47×, not 2×.
• Dense models gain more. Qwen3.8 27B, which uses all of its parameters for every token, produces 19.7 tokens per second on one M5 Ultra, 33.3 on two (1.69×), and 50.9 on four (2.58×). Apple’s claim of “up to 3x faster performance” than a single system (Apple) also holds for a dense model: Mistral Medium 3.5 goes from 7.7 to 23.4 tokens per second on four machines.
• First token: With an 8,192-token prompt, Muse Spark Open’s first token arrives in about 8 seconds on two Macs and 4.8 seconds on four.
• The 1-million-token context was not measured. The model supports 1 million tokens, but Apple’s measurements stop at 65,536. At that length, even four Macs take about 40.6 seconds to produce the first token, or about 50.5 seconds with one cable per link. One million tokens is 16 times longer; even an optimistic linear estimate puts the first token more than 10 minutes away.

What it means for the Macs on your desk

The first question many readers will have: if I buy a second Mac, can I run a model this big, too?

• Not this model. The Mac mini with the most memory (M5 Pro) tops out at 64 GB (Apple); two of them make 128 GB. By default, macOS gives the GPU roughly three-quarters of memory, about 48 GB on a 64 GB Mac (LLM Configurator). That leaves about 96 GB for the model across two Mac minis, while the 4-bit Muse Spark Open is about 493 GB.
• A bigger model that fits is not necessarily a better model. Some models fit on two Mac minis but not on one, such as the 65 GB gpt-oss-120b (LM Studio). It scores 12 on Artificial Analysis’s Intelligence Index (v4.3.2). Qwen3.8 27B, which can run on a single 64 GB Mac mini in its 8-bit version, scores 34, and Muse Spark Open scores 39 (gpt-oss-120b, Qwen3.8 27B, Muse Spark Open). The index is only one measure, but size and quality are less directly linked than many assume.
• The speedup depends on the model. For dense models, a second machine gives a clear boost (Apple: 1.69× for the 27B on two M5 Ultras). For MoE models, the gain is smaller: two M4 Pro Mac minis sped up Qwen3.5-35B-A3B by about 1.3× (SiliconBench). No measurements have been published yet for M5 Pro Mac minis.
• Both Macs need Thunderbolt 5. RDMA works only on Apple Silicon Macs with Thunderbolt 5 (Apple TN3205). The M5 Pro Mac mini has Thunderbolt 5; the M6 Mac mini has Thunderbolt 4 (iGeeksBlog).
• Setup is not plug-and-play. In macOS 27, you can turn on RDMA with a single checkbox in System Settings (MacGeneration). Splitting a model, though, takes MLX’s command-line tools (mlx.launch, mlx_lm.server) or a tool such as exo. LM Studio's October 13 release (0.4.26) cannot split a model across several Macs (LM Studio).
• Two separate models don’t need RDMA. If each Mac runs its own model, the machines don’t talk to each other; an ordinary network is enough.

Five questions to ask when reading news like this

1. Total or active? Of Muse Spark Open’s 816 billion parameters, 42 billion are active for each token. Total parameters set the memory requirement; active parameters largely set the speed.
2. At what precision? In its native format, the model exceeds 1.6 TB; the Macs ran the 4-bit version (about 493 GB).
3. Capacity or access? “1 TB” is the two machines’ combined capacity. Each GPU can read only its own 512 GB quickly.
4. At what context length? The model supports 1 million tokens; the measurements were taken at 8,192 and 65,536.
5. Which hardware, when, and at what price? The 512 GB Mac Studio in the demo is not on sale yet, and Apple had not announced its price as of October 15.

Conclusion

What Apple and Meta showed is real and impressive: an 816-billion-parameter model producing 25 tokens per second on two desktop computers. Three things make it possible: the model’s MoE design, a smart way of splitting it, and RDMA’s low latency.

“One supercomputer with a terabyte of unified memory,” by contrast, is marketing shorthand that squeezes this engineering into a single sentence. There is a terabyte of memory; it just isn’t one memory.

Sources

• Introducing Muse Spark Open, The Most Capable US Open-Weight Model to Date — Meta, October 15, 2026
• Local and Distributed Large LLM Inference with MLX and RDMA on Mac Studio — Apple Machine Learning Research, October 15, 2026
• Meta and Apple Bring Muse Spark Open AI Model to Mac Studio — MacRumors, October 15, 2026
• Meta built a huge open-weight AI model for Macs, but you’ll need 1TB of RAM to run it — Engadget, October 15, 2026
• The new Mac mini and Mac Studio are available today — Apple Newsroom, September 22, 2026
• TN3205: Low-latency communication with RDMA over Thunderbolt — Apple
• macOS 27 simplifie la mise en place d’un cluster de Mac Studio avec le RDMA — MacGeneration (in French), September 24, 2026
• Muse Spark Open — NVIDIA NeMo AutoModel
• This is what happens when you create a 1.5TB VRAM AI cluster with 4 Mac Studios and RDMA over Thunderbolt — Gigazine, December 22, 2025
• AI calculations on Mac cluster get big boosts from new RDMA support on Thunderbolt 5 — AppleInsider, December 20, 2025
• SiliconBench: Speed, Memory, and Fidelity for LLM Serving on Unified-Memory Desktops — arXiv, September 12, 2026
• Artificial Analysis: Muse Spark Open, Qwen3.8 27B, gpt-oss-120b
• gpt-oss — LM Studio and LM Studio Changelog
• Mac mini M6 and M5 Pro: price, specs, release date — iGeeksBlog, August 26, 2026
• Increase the Metal VRAM limit on Apple Silicon — LLM Configurator

This article was written with AI assistance; all figures come from the linked sources.

Moving from React Native back to native may be the right decision for Shopify. The problem is that these decisions are presented to the industry as “the future” and copied by teams without Shopify’s infrastructure.

Shopify’s post “Native is now the future of mobile at Shopify” was published on September 10. I’ve wanted to write about it ever since. Nearly a month later, I’ve finally put my thoughts into words.

Shopify is moving its mobile apps from React Native back to Swift and Kotlin. The reasoning, in short: coding agents have changed the cost of building the same app twice.

If the headline sounds familiar, there’s a reason. In January 2020, the same blog published “React Native is the Future of Mobile at Shopify”. Six years apart, almost the same headline, the exact opposite conclusion.

I’m not going to criticize Shopify for changing its mind. Revisiting a decision when circumstances change is sensible. My concern is how the industry reads these posts. I’ve seen this repeatedly at companies I’ve worked for: startups read large companies’ engineering blogs, adopt their decisions, and more often than not, the result is chaos.

Shopify’s last six years make a useful case study in why this pattern is dangerous.

“The future” changed three times in six years

Read Shopify’s own posts in order, and you’ll find three different “futures” announced over six years: first React Native, then native and React Native together, and now native.

• January 2020: React Native is declared the future. The team rewriting Arrive feels twice as productive as it did with native development; code sharing between iOS and Android reaches 95% in Arrive and 99% in Compass. Shopify establishes React Native tooling and foundations for teams.
• December 2022: Shopify Mobile, its largest app with 300 screens per platform, is being migrated to React Native. The goal is to move all native apps to React Native.
• January 2025: The five-year retrospective is glowing: feature parity is no longer a problem, screens open in under 500 ms at P75, more than 99.9% of sessions are crash-free, and all apps are on React Native. The conclusion is clear: don’t think in terms of native versus React Native. Think of them together.
• September 2025: Shopify Mobile and POS are migrated to React Native’s New Architecture. The weekly release cadence is maintained throughout.
• September 2026: The direction reverses. The Shop app is rewritten in Swift and Kotlin and shipped to the app stores in 12 weeks; the rewrite of the Shopify app, with its 300-plus screens, is still underway.

That’s three major transitions: native to React Native, React Native to the New Architecture, and then back to native. The most striking detail: Shopify Mobile’s New Architecture migration was completed in September 2025. A year later, the same app is being rewritten from scratch.

Shopify addresses this criticism upfront in its post: it doesn’t stick with a decision simply because it once worked, and LLMs have changed one of the fundamental assumptions behind its 2020 decision. For Shopify, this is an internal decision. For the rest of the industry, each post is a signal. And that signal has changed three times in six years.

What happened to the teams that took the advice?

The January 2025 retrospective didn’t just describe Shopify’s experience. It offered readers direct advice. React Native had come a long way in five years, it said, and most of the limitations that had kept people away were gone. Its recommendation: “now would be a good time to revisit it.”

Imagine a team that took that advice. It moved to React Native in 2025, adopted Shopify’s libraries, and built its architecture around the model Shopify described. Twenty months later, the company that offered the advice is leaving that same stack.

That isn’t Shopify’s fault. The company is making decisions based on its own circumstances. But this is exactly the price of treating a company’s blog post as the industry’s roadmap. When the author’s circumstances change, everyone who tied themselves to that decision is left stranded.

The followers foot the bill

The clearest example of that cost is in open source. Shopify made substantial contributions to the React Native ecosystem for years, and some of its libraries became standards in their categories. With the return to native:

• FlashList: Downloaded roughly two million times a week and widely considered the default way to render high-performance lists in React Native. Shopify will now only address critical compatibility-breaking bugs and is looking for a company to take over long-term maintenance.
• React Native Skia: Shopify’s sponsorship ends at the close of 2026. The library’s creator will fork the project under a new name and continue developing it; the original repository will be archived. Shopify recommends that teams whose apps depend on the library consider sponsoring it.
• Restyle: It will remain functional through the end of 2026, after which maintenance will stop.

Shopify is trying to manage the transition responsibly. Sponsorships, handover plans, and advance announcements are in place. Still, every team that chose these libraries because “Shopify is behind them” now has to plan its own migration. On Hacker News, sergiotapia described this as a major loss for the React Native community.

Following a large company’s technology choices means relying on its maintenance budget. When that budget disappears, the followers are left with the bill.

The headline gets copied. The infrastructure doesn’t.

A section in Shopify’s post matters far more than the headline but will get far less attention. Shopify explicitly says that feeding React Native code to an LLM and asking it to rewrite features in native in one shot did not work. That approach produced a pile of code too unmaintainable to ship.

Here’s the infrastructure they describe instead:

• Helix: A loop used in the Shopify app rewrite that breaks each screen into small, sequential checkpoints. Each checkpoint must prove its behavior through tests, visually match the running app, pass two adversarial code reviewers, and receive human approval.
• Tardis: A debugging tool from the Shop app team that gives agents structured access to the running app’s events, logs, and state, and can also send commands to the app.
• Headless architecture: Business logic is completely separated from the UI and runs headlessly on a desktop. Agents can iterate through a CLI in milliseconds rather than minutes, without touching a simulator.

A core team of six built the Shop app’s foundation and main user flows. Behind them, hundreds of engineers contributed to the migration to React Native.

What a startup reading this post will copy is the headline: “Coding agents have made native cheaper. Let’s leave React Native.” It won’t copy Helix, Tardis, the headless architecture, or the review discipline. They take up a few paragraphs in the post, but building them takes a serious engineering investment. The result will be exactly what Shopify warns about in its own post: a pile of code that cannot be shipped or maintained. This time, on two platforms at once.

Watching the effect in real time

We don’t have to wait until next year to see this effect. The post’s Hacker News discussion has 957 comments, and the pattern was visible within the first few hours.

robofanatic says the post motivated them to rewrite their Flutter app in Swift. lackoftactics predicts this will become an industry-wide trend, while tzone expects even small teams to go fully native. Vishal_Max asks the question that matters: if the apps already work, why is every company suddenly saying it’s going native?

The comment that stands out most to me is madrox’s. A year earlier, when they proposed moving to native at their former company, most of the mobile engineers pushed back. But because that company practically worshipped Shopify’s engineering blog, they expect those same people to now call it “the future.”

In other words, the same decision is rejected when it comes with an engineer’s reasoning and accepted when it appears on Shopify’s blog. The source determines the decision, not the reasoning.

There are dissenting voices in the discussion, and I think they’re the healthiest ones. SV_BubbleTime writes that, for a small team, the choice isn’t between Flutter and native. It’s between Flutter and not shipping an app at all. afavour also points out that a decision can make sense at Shopify’s or Airbnb’s scale without making sense for a ten-person startup.

It may be right for Shopify. Not for you.

To be fair, Shopify’s own numbers show that the React Native years were not a failure, and the return to native has brought measurable gains. In the new version of the Shop app, launch time is down 23% on iOS and 50% on Android. The Android app is 109 MB smaller, crashes have dropped by a factor of ten, and Android build time is down 75%.

The timing also makes sense. The Shop app’s next major React Native investment, the New Architecture migration, was approaching. Shopify tested the alternative before committing to that investment. This isn’t a story of incompetence. It’s a context-specific decision. And that’s precisely the problem: the context doesn’t get copied along with the blog post.

There are costs the post doesn’t show that will hit small teams much harder:

• The cost of divergence. hermitwriter, who wrote the strongest critique on Hacker News, sums it up in one sentence: “Feature parity isn’t an implementation cost. It’s a divergence cost.” Two codebases may look identical today. The real question is whether they’ll stay that way as experiments, accessibility fixes, and platform changes accumulate over the years.
• The organizational burden of staying in sync. According to nfw2, the real cost isn’t an extra engineer. It’s the product and organizational overhead of keeping two products in sync when they have to remain identical.
• Losing OTA updates. In React Native, bugs in the JavaScript layer could be fixed through OTA updates without waiting for app store review. In native, every hotfix enters Apple’s and Google’s queues. joshstrange writes that their last three updates spent 40, 67, and 98 hours in review. Shopify’s main post doesn’t address this at all.
• Agent and token costs. Maintaining two implementations with agents isn’t free, and the main post doesn’t provide a single figure for that spending.

The numbers Shopify has shared are today’s numbers: rewrite speed, launch time, app size. Maintenance costs accumulate over years, and no one has measured those yet.

Here’s my takeaway from this discussion: if cross-platform’s biggest advantage is the cost of writing code, coding agents reduce the economic value of that advantage. But they don’t eliminate the costs of shared semantics, parity, testing, and maintenance. Shopify is shifting those costs from shared code to shared specifications, tests, and review checkpoints. It has the infrastructure to make that bet. Most teams don’t.

Five questions before turning an engineering post into a decision

The chaos I’ve seen at startups came from following large companies without questioning their choices. Before turning an engineering post into your own decision, ask these five questions:

1. Is this company operating at a scale similar to mine? Team size, budget, user count. Shopify’s optimal architecture isn’t everyone’s optimal architecture.
2. Does the post describe the result, or the infrastructure that made it possible? Which one can I actually replicate? Shopify’s 12 weeks won’t be 12 weeks for a team without the same infrastructure.
3. What is being measured? Rewrite speed and two years of maintenance costs are not the same thing.
4. What will it cost me if this company announces the opposite a year from now? Which libraries, tools, and processes am I tying myself to?
5. Is the problem they’re solving actually my problem? Shopify is dealing with an app that has more than 300 screens, widgets, an Apple Watch app, and Siri Shortcuts. What am I dealing with?

For teams that want native interfaces but can’t support two separate codebases, there’s also a middle ground frequently suggested on Hacker News: keep business logic in a shared core using something like Kotlin Multiplatform or Rust, and write only the UI natively. Shopify’s post doesn’t mention this option at all.

Let’s talk again in a year

Shopify’s bet may pay off. Coding agents may genuinely be changing the economics of mobile architecture. But the proof won’t be the time it took to rewrite an app in 2026. It will be the numbers from 2027 and 2028: parity bugs, engineering hours per feature, accessibility regressions, review overhead, model spending, and the human effort required to keep two implementations equivalent. That’s exactly what hermitwriter is asking Shopify to report.

Until those numbers arrive, Shopify’s post isn’t a conclusion. It’s a bet. Shopify is betting its own money. You’re betting yours.

Six years of headlines sum it up: React Native is the Future of Mobile at Shopify → Five years of React Native at Shopify → Native is now the future of mobile at Shopify. The next time you read a post about “the future of mobile,” ask whose future it’s talking about first.

Sources

• React Native is the Future of Mobile at Shopify, Shopify Engineering, January 2020
• Migrating our Largest Mobile App to React Native, Shopify Engineering, December 2022
• Five years of React Native at Shopify, Shopify Engineering, January 2025
• Migrating to React Native’s New Architecture, Shopify Engineering, September 2025
• Native is now the future of mobile at Shopify, Shopify Engineering, September 2026
• Migrating Shop app from React Native to native, Shopify Engineering, September 2026
• Shopify is moving from React Native back to Swift and Kotlin, Hacker News discussion, 957 comments

Apple ships no source code with iOS or macOS, but the binaries it does ship record which toolchains produced them. This census reads that record across two corpora: the iOS 27 simulator runtime and macOS 27.

Swift signals appear in 48.7% of the iOS simulator binaries examined and 34.5% of the macOS binaries. SwiftUI links appear in roughly a third of the binaries that link the UI frameworks measured here.

Those are presence measurements. They describe the compiled artifacts in these two corpora, not the fraction of Apple’s source code written in Swift or the amount of UI rendered by SwiftUI.

This census follows the compilation-artifact approach described in Timac’s Apple’s use of Swift and SwiftUI in iOS 18. The measurements were taken on 20 September 2026, using:

• iOS 27.0, build 24A434: simulator runtime.
• macOS 27.0, build 26A428.
• Xcode 27.0, build 27A266a.

What was counted

The iOS corpus contains 5,705 Mach-O binaries: 3,879 on disk and 1,826 in the dyld simulator shared cache.

The macOS corpus contains 9,395 binaries: 5,311 on disk and 4,084 additional cache images after deduplication. The cache’s full image table contains 4,088 entries; four also exist on disk. The counting details are below.

The iOS total is from a simulator runtime, not a device image. Its composition differs from the device corpus behind Timac’s 6,800-binary iOS 18 count. These totals are not a like-for-like time series. Percentages describe each measured corpus; they should not be treated as device-wide estimates.

Swift appears in nearly half of the iOS simulator binaries examined

A Swift signal means a __swift5_* section or a link against libswiftCore.dylib. That test identifies 2,780 of 5,705 iOS simulator binaries (48.7%) and 3,238 of 9,395 macOS binaries (34.5%).

A binary with one Swift file counts exactly like a binary written entirely in Swift. This does not measure the fraction of Apple’s source code that is Swift; how much of each binary is Swift is a separate measurement, covered below. Nothing here supports the stronger claim that half of iOS is written in Swift.

Objective-C metadata remains widespread: 5,329 binaries (93.4%) on iOS and 7,126 (75.8%) on macOS. C++ library links appear in 722 (12.7%) and 1,627 (17.3%), respectively.

Separating the Swift and Objective-C signals shows how often they coexist:

• iOS simulator: 2,552 Objective-C without Swift (44.7%); 2,777 with both (48.7%); 3 Swift without Objective-C (0.1%); 373 with neither (6.5%).
• macOS: 3,945 Objective-C without Swift (42.0%); 3,181 with both (33.9%); 57 Swift without Objective-C (0.6%); 2,212 with neither (23.5%).

“Without Objective-C” means no detected Objective-C metadata, not proof that the binary is exclusively Swift. The result is clear at the binary level: Swift signals usually coexist with Objective-C signals.

How much of each binary is Swift

The counts above answer a yes-or-no question: does a binary carry any Swift at all? How much of a binary is Swift needs a magnitude instead, and one is available: the byte sizes of the __swift5_* and __objc_* sections. Both runtimes read their own metadata, so unlike a symbol table it survives stripping. The section sizes come from a rescan of the same builds on 21 September 2026.

Swift’s share of each binary’s language metadata, across the binaries that carry a Swift signal:

• iOS simulator (2,780 binaries): no Swift metadata at all, 30 (1.1%); under 1%, 197 (7.1%); 1–10%, 497 (17.9%); 10–50%, 990 (35.6%); 50–90%, 802 (28.8%); 90% and over, 264 (9.5%).
• macOS (3,238 binaries): no Swift metadata at all, 88 (2.7%); under 1%, 174 (5.4%); 1–10%, 434 (13.4%); 10–50%, 1,011 (31.2%); 50–90%, 1,166 (36.0%); 90% and over, 365 (11.3%).

The presence figure holds up under this check. On iOS, 227 of the 2,780 Swift-signal binaries (8.2%) carry less than 1% Swift metadata, 30 of them none at all. Excluding them lowers this from 48.7% to 44.8%; on macOS, it drops from 34.5% to 31.7%. At the other end, 1,066 of the iOS Swift-signal binaries (38.3%) are more than half Swift by this measure.

This is not a source-line ratio. Swift and Objective-C do not emit comparable amounts of metadata per declaration: Swift’s reflection sections are verbose, while Objective-C’s method lists are compact. The shares compare binaries with each other, not the two languages in absolute terms.

Two shortcuts give the wrong answer. Counting Swift-mangled symbols with nm measures whether a binary kept its local symbol table, not what language it is in: Freeform reads as 100% Swift that way and Music as 0%, while by section bytes they are 17.6% and 8.8%. Freeform is stripped; Music is not. And __objc_classlist is not an Objective-C class count, because Swift classes are emitted into it too: otool -ov labels all 507 of Weather’s entries “Swift class”.

Object files cannot be counted either. Apple ships linked, stripped Mach-O rather than .o files. The only structure that preserves object-file boundaries is the debug map, the N_OSO stabs, and stripping removes it. A per-object-file language split is not available from a shipped system.

SwiftUI links appear in roughly a third of UI-linking binaries

Comparing SwiftUI against every binary includes command-line tools and services with no UI framework link. Restricting the denominator to binaries that link AppKit, UIKit or SwiftUI — whichever the platform has — gives a more relevant comparison.

UIKit is a macOS UI framework too: 578 Mac binaries link it, 464 of them under /System/iOSSupport — Mac Catalyst. An AppKit-only denominator drops the 283 binaries that link UIKit and neither AppKit nor SwiftUI, and files the 106 Catalyst binaries that link both UIKit and SwiftUI under “SwiftUI without a native framework”.

SwiftUI appears in 749 of 2,504 UI-linking binaries on iOS (29.9%) and 767 of 2,426 on macOS (31.6%).

Composition of the UI-linking corpus. “SwiftUI only” means no detected link to AppKit or UIKit. It does not rule out indirect dependencies.

• iOS simulator: 1,755 link UIKit without SwiftUI (70.1%); 746 link both (29.8%); 3 link SwiftUI without UIKit (0.1%).
• macOS: 1,659 link AppKit or UIKit without SwiftUI (68.4%); 622 link a native framework and SwiftUI (25.6%); 145 link SwiftUI with no direct AppKit or UIKit dependency (6.0%).

The two platforms are closer than a per-platform denominator suggests, but these are dependency patterns. They do not establish how much of an app’s interface uses SwiftUI, which code runs, or whether an entire app has replaced UIKit or AppKit.

AppKit and the Dock link SwiftUICore

Timac documented the introduction of SwiftUICore in iOS 18 and its link from UIKitCore. In this census, the direct links include AppKit and the Dock on macOS.

The complete detected lists are short:

• iOS: UIKitCore, SwiftUI, DesignLibrary, AnimationKit, and TextAnimationSupport.
• macOS: AppKit, Dock, SwiftUI, UIKitCore, DesignLibrary, AnimationKit, SwiftUITracingSupport, and TextAnimationSupport.

These links place SwiftUICore as a dependency of both UI frameworks and system components. They do not, on their own, identify which visible features use it or when each dependency was introduced.

FoundationModels links extend across system components

38 iOS binaries and 36 macOS binaries link FoundationModels. The iOS list includes HomeKit, ActionKit, Shortcuts, SafariCore, PasswordManagerUI, PassKitUI, HealthExperience, CalendarUIKitInternal, and CoreSpotlightAgenticCore.

Other examples include CallIntelligenceRuntime, TextUnderstandingRuntime, IntelligenceFlowPlannerRuntime, and the fm executable. The dependencies span multiple parts of the system; a link alone doesn’t demonstrate an active model call or a user-facing feature.

For context, SwiftData links appear in 30 iOS binaries and 42 macOS binaries. Those counts are in a similar order of magnitude. A single snapshot cannot establish which framework is being adopted faster.

Swift signals are more common in apps and frameworks

The iOS simulator’s directory breakdown shows a gradient:

• /Applications: 195 of 294 binaries carry Swift signals (66.3%).
• /System/Library/PrivateFrameworks: 1,711 of 2,938 (58.2%).
• /System/Library/Frameworks: 248 of 466 (53.2%).
• /usr/libexec: 53 of 125 (42.4%).
• /usr/lib: 54 of 263 (20.5%).

Across the framework binaries counted, the Swift-positive share is 57.5% on iOS and 47.6% on macOS. These selected directory groups describe where the signals occur; they do not exhaustively partition either corpus.

58 executables across the two corpora carry the SwiftUI App protocol signal

A more specific signal than a framework link is the mangled 7SwiftUI3AppP marker in an app’s main executable. The census uses it to identify the SwiftUI App lifecycle and finds 26 apps in the iOS simulator runtime and 32 on macOS.

The iOS examples include Passwords, Preferences, Preview, Image Playground, Batteries, MusicRecognition, and ShortcutsActions. On macOS, the list includes System Settings, Calculator, Passwords, Weather, Print Center, Font Book, Games, and iPhone Mirroring.

This is still a static binary heuristic, not a runtime trace of each app’s entry point. Timac reported 19 SwiftUI-lifecycle apps in iOS 18, but the device-versus-simulator difference prevents reading 19 to 26 as a clean measure of growth.

How the numbers were produced

Mach-O magic values identify the binaries. Load commands provide linked dylibs, segments provide section names, and LC_BUILD_VERSION provides platform and SDK information.

The classification rules are:

• Swift: a __TEXT,__swift5_* section or a link to libswiftCore.dylib.
• Objective-C: an __objc_* section.
• C++: a link to libc++ or libstdc++.

Framework identities are matched on the dylib basename, so Foo.framework/Versions/A/Foo and Foo.framework/Foo resolve to the same framework.

System frameworks also live inside the dyld shared cache. The parser walks cache mapping tables to translate virtual addresses into file offsets, then reads Mach-O headers in place. The iOS cache examined here spans two files totaling about 3.8 GB; the macOS cache spans 80 files.

Five implementation problems were found and corrected:

• Framework path matching. Looking only for SwiftUI.framework/SwiftUI missed the versioned macOS path. The contradiction became visible when 32 app executables carried the lifecycle marker while the framework-link count read zero.
• Simulator runtime discovery. In this setup, Xcode 27 mounted the runtime under /private/var/run/com.apple.security.cryptexd/mnt/, with a changing suffix. Discovery used simctl’s Bundle Path output instead of a hardcoded mount path.
• Subcache filenames. Probing only sequential numeric suffixes missed names such as .25.dylddata, .26.dyldreadonly, and .79.dyldlinkedit. That had truncated macOS cache coverage to 1,133 of 4,088 images.
• Lazy dylib load commands. The dependency scan did not read LC_LAZY_LOAD_DYLIB (0x20), so a binary that linked libswiftCore.dylib only lazily was classified as not Swift. Adding that load command to the scan corrected the Swift counts reported here.
• Volume ratio. The first version of the volume measurement compared __swift5_types entries with __objc_classlist entries. Because Swift classes are also listed in __objc_classlist, that ratio was meaningless. The measurement now uses section byte sizes.

Validation and the four-image overlap

I compared the macOS cache using Apple’s dyld_info and the Python parser. Both found 4,088 images and agreed on Objective-C, C++, SwiftUI, UIKit, and AppKit classifications.

There was one observed Swift-classification discrepancy. dyld_info reports a lazy dependency from libobjc.A.dylib to libswiftCore.dylib that the header-based parser does not detect; that edge is not expressed as a load command, so reading LC_LAZY_LOAD_DYLIB does not surface it. This is a known limitation of the comparison, not a global error bound on the census. Agreement between tools does not prove that every heuristic correctly captures source-language or runtime behavior.

The cache’s 4,088 images include four that also exist on disk: /usr/lib/dyld and the libsystem_kernel, libsystem_platform, and libsystem_pthread stubs. Deduplicating that overlap gives:

4,088 − 4 = 4,084 additional cache images.

5,311 on-disk binaries + 4,084 additional cache images = 9,395 unique binaries.

The comparison uses the full cache image table; the system total uses the deduplicated contribution. Both figures describe the same scan at different counting stages.

Source and scope

Methodological reference: Timac, Apple’s use of Swift and SwiftUI in iOS 18, 8 December 2024. The iOS 27 and macOS 27 figures above are from this census, measured on 20 September 2026. Timac’s article provides historical context, not independent verification of these measurements.