Solidean on ARM64: macOS, iOS, and Android

What's working today

Solidean's core boolean engine now compiles and runs on ARM64. That covers Apple Silicon Macs (M1 and later), iOS devices, and Android phones and tablets. The same exact predicates, the same geometry, the same results, and surprisingly good performance.

Performance on mobile

The short version: it is better than you would expect.

The iterate demo runs consistently below 10 ms per iteration on a budget Android tablet, maybe an average of 3-5 ms. Our desktop numbers are around 1 ms per iteration, maybe a bit less.

In other words: the same exact boolean pipeline remains interactive even on mobile hardware.

The reason comes down to what Solidean actually uses. Our hot paths are pure integer arithmetic. No floating point, no GPU compute, and actually not that heavy memory bandwidth use. The integer execution units on modern SoCs are fast and available. The GPU is not involved, which means it stays free for your rendering code. Mobile GPUs are often the bottleneck in graphics applications, which Solidean does not compete for at all.

Integer throughput tends to scale more uniformly across devices than GPU performance or memory bandwidth. A budget tablet has slower cores than a high-end workstation, but the integer pipeline gap is much smaller than the GPU or memory bandwidth gap. For our exact mesh booleans, that turns out to be an advantage.

Challenge 1: SIMD abstraction

While the core mesh cutting logic is integer-heavy, a couple of support systems are written in floating point (in a careful manner that does not violate exactness guarantees).

As such, we had a handful of SIMD-accelerated code paths that were written directly against AVX2 intrinsics. AVX2 is x86-only, so those paths simply did not compile on ARM.

The fix was to build a thin SIMD abstraction layer. Each operation maps to AVX2 on x86-64 and to NEON on ARM64, with the selection happening at compile time. The abstraction is relatively narrow (we only expose the operations we actually use) so it stayed manageable.

We plan to flesh this out and open source the library separately. It does a few different tradeoffs compared to the C++26 std::simd, in particular around the resulting codegen and the ability to make it easy to write runtime dispatched code regions.

Challenge 2: Portable exact integer arithmetic

This was the more interesting problem.

Our exact predicates and constructions are built on fixed-width integers that go well beyond 64 bits. The previous post on building a u128 in C++ describes the x86-64 side of this: using _addcarry_u64, _subborrow_u64, and _mulx_u64 to get carry-correct arithmetic that maps to adc, sbb, and mulx.

ARM64 has equivalent instructions. Addition with carry uses adds / adcs, subtraction with borrow uses subs / sbcs, and wide multiplication is split into mul (low half) and umulh (high half). The patterns are the same, just different intrinsics. Concretely, this means __builtin_addcll and __builtin_subcll for add/sub. The multiplications don't have intrinsics per se, so we use __uint128_t and __int128_t to access these instructions.

We now have a portable u128/i128 and larger types (up to i832 for some weird corner cases) that compile cleanly on both x86-64 and ARM64, and produce equally tight assembly on both. We are also working toward a standalone guide covering the multi-platform picture. The x64 post is the foundation, and the ARM64 half is coming (together with how to go beyond 128 bits).

Platform busywork

The engineering above was the interesting part. The rest was mostly integration work.

Getting everything to build cleanly across toolchains (Clang, Apple toolchains, Android NDK), sorting out packaging, and making sure the SDK behaves predictably in each environment.

Since we're shipping libraries rather than apps, we didn't go through full App Store or Play Store submission pipelines. But we still had to set up and understand the same signing, provisioning, and toolchain requirements to make the SDKs integrate cleanly into real apps.

As part of this, we now have native APIs for Kotlin (Android) and Swift (Apple platforms), alongside the existing bindings. We've also been working on a few additional APIs that we'll share more about soon.

What comes next

We plan to bring the free Solidean demos to the app stores. That is a distribution question more than a technical one, the hard parts are already done.

Consoles are a natural next question. We do not have dev kits yet, but given where we stand now, this looks like incremental work rather than a new port.

The fact that budget mobile devices already run the pipeline comfortably gives us a good lower bound. Console CPUs are not weaker than that class of hardware, so performance should translate well.

Availability

ARM64 support across macOS, iOS, and Android is not yet in an official release. We are still working through exhaustive platform testing before we stamp it.

That said, it is available as a preview right now. If you want to evaluate Solidean on Apple Silicon or mobile, get in touch.