Ran pod install on a project I hadn’t touched in a few months, on a Mac I’d just migrated to Apple Silicon, and got hit with a wall of Ruby stack trace ending in something about ffi_c.bundle and an incompatible architecture. Not the friendliest error message CocoaPods has ever produced. If you’re seeing the same wall of text, this is one of the most common CocoaPods problems on M1/M2/M3 Macs, and it’s almost always about which CPU architecture your Ruby gems were actually built for.
Quick Answer
- This error means the
ffigem’s native extension was compiled for a different CPU architecture (x86_64 vs arm64) than the Ruby interpreter currently running. - Reinstalling CocoaPods through Homebrew, using Homebrew’s own native arm64 Ruby, is the cleanest long-term fix.
- If you need to stick with system Ruby, forcing a consistent architecture with
arch -x86_64orarch -arm64on both the gem install and the terminal session fixes it in most cases. - Mixing Rosetta-based terminal sessions with native ones is the single most common cause of this error reappearing after you thought you’d fixed it.
- A clean uninstall of
ffiandcocoapods, followed by a fresh install in a consistent architecture context, resolves it for the vast majority of people.
Why It Happens
So the root of this is architecture mismatch, plain and simple — but the ways you can end up with mismatched architectures on Apple Silicon are more varied than people expect.
The ffi gem’s native extension was compiled for the wrong architecture. ffi includes a compiled binary component (ffi_c.bundle), and gems with native extensions get built for whatever architecture was active at install time. If you installed it while running under Rosetta (x86_64 emulation) but you’re now running Ruby natively as arm64 — or the reverse — the compiled binary won’t load, and Ruby throws a LoadError about incompatible architecture.
Terminal running under Rosetta without you realizing it. This is genuinely easy to do on Apple Silicon. If you ever launched Terminal (or iTerm2) with “Open using Rosetta” checked, or inherited that setting from a duplicated terminal profile, every command you run in that window — including gem install — happens in x86_64 emulation mode, even though your Mac is arm64 natively.
System Ruby versus Homebrew Ruby confusion. macOS ships with a system Ruby that Apple has been trying to discourage developers from using for exactly this kind of headache. If some of your gems got installed against system Ruby and others against a Homebrew-installed Ruby (which is genuinely arm64-native on Apple Silicon), you end up with a mixed environment where architecture mismatches are almost guaranteed sooner or later.
CocoaPods itself installed via sudo gem install without considering architecture. The most common install method still floating around in older tutorials — sudo gem install cocoapods — doesn’t inherently account for which architecture you want, it just uses whatever’s active in that terminal session at that moment.
An overlooked cause worth mentioning: switching Xcode Command Line Tools versions. So if you updated Xcode or its command line tools between when you originally installed your gems and now, the native extension compiler toolchain can shift under you, and gems with native components sometimes need to be rebuilt after a significant Xcode Command Line Tools update, even without touching architecture settings directly.
Step-by-Step Fixes
Step 1: Check whether your terminal is running under Rosetta
Open Activity Monitor, find your Terminal (or iTerm) process, and check the Kind column — it’ll say either “Apple” (native) or “Intel” (running under Rosetta). Alternatively, from the terminal itself:
uname -mThis should return arm64 on native Apple Silicon. If it returns x86_64, your terminal session is running under Rosetta.
Step 2: Uninstall the conflicting gems
sudo gem uninstall cocoapods
sudo gem uninstall cocoapods-core
sudo gem uninstall ffiAnd if any of these say they’re not installed or give you permission errors, that’s fine — the goal here is just to clear out anything potentially built for the wrong architecture before reinstalling clean.
Step 3: Reinstall via Homebrew (recommended path)
brew install cocoapodsThis is genuinely the cleanest fix for most people, because Homebrew on Apple Silicon defaults to installing native arm64 packages, and it manages the Ruby dependency chain more predictably than a manual gem install does. If you don’t have Homebrew yet, install it from brew.sh first — the installer itself detects your architecture correctly.
Step 4: If you need to stick with gem install, force a consistent architecture
sudo arch -arm64 gem install ffi
sudo arch -arm64 gem install cocoapodsThe arch -arm64 prefix forces that specific command to run natively rather than under whatever Rosetta state your terminal happens to be in. Use arch -x86_64 instead if your project specifically needs an x86_64 toolchain for other reasons — just make sure you’re consistent across every related gem, not mixing arm64 for one and x86_64 for another.
Step 5: Verify Ruby itself is running the architecture you expect
ruby -e "puts RUBY_PLATFORM"This should return something containing arm64-darwin if you’re running native. If it says x86_64-darwin and you expected arm64, that’s your actual Ruby interpreter running under Rosetta, not just an individual gem being mismatched — and reinstalling gems alone won’t fix that; you’d need to address which Ruby install you’re pointing at (system Ruby, Homebrew Ruby, rbenv, or rvm).
Step 6: Rebuild native extensions after Xcode Command Line Tools changes
sudo gem pristine ffiThis rebuilds the gem’s native extension using your currently active toolchain, which resolves cases where the mismatch is coming from a stale build rather than a straightforward architecture swap.
What Actually Worked For Me
My first guess was that I just needed to reinstall CocoaPods, so I ran sudo gem uninstall cocoapods and reinstalled with the same sudo gem install cocoapods command I’d always used. Same error, immediately. Which should’ve been my clue that the terminal session itself was the actual problem, not the gem.
Checked Activity Monitor and, sure enough, that particular Terminal window had been duplicated from an old profile months earlier that had Rosetta mode enabled — I’d genuinely forgotten that setting existed. Opened a completely fresh terminal window, confirmed uname -m returned arm64, reinstalled through Homebrew from that clean session, and it worked immediately. The gem itself was never really the issue, it was the environment it was being installed into.
Advanced Fixes and Edge Cases
Multiple Ruby versions managed through rbenv or rvm. If you’re using a Ruby version manager, confirm which Ruby is actually active with rbenv version or rvm current, and make sure that specific Ruby build itself is arm64-native — a Ruby version installed months ago under an old Rosetta session can persist as x86_64 even after you’ve otherwise cleaned everything else up.
Check for duplicate gem installs across Ruby paths. Run which gem and which pod to confirm you’re not accidentally running a gem or pod binary installed under a completely different Ruby path than the one your terminal thinks is active — this happens more than you’d expect when Homebrew, rbenv, and system Ruby are all present on the same machine.
Flutter and React Native projects specifically. If you hit this error through a Flutter or React Native project’s pod install step rather than directly, the same fixes apply, but you’ll also want to run flutter clean or clear your node_modules/Pods directory afterward, since cached build artifacts from the broken architecture state can cause follow-up errors even after CocoaPods itself is fixed.
Prevention Tips
- Avoid enabling “Open using Rosetta” on any terminal profile unless you specifically need x86_64 emulation for a particular tool.
- Prefer Homebrew for installing CocoaPods and Ruby-adjacent tooling on Apple Silicon rather than raw
gem install, since Homebrew handles architecture consistently by default. - After any major macOS or Xcode Command Line Tools update, run
pod installonce early to catch native extension issues before they pile up on a deadline. - If you manage multiple Ruby versions, periodically confirm your active Ruby is genuinely arm64-native with
ruby -e "puts RUBY_PLATFORM", rather than assuming it still is.
FAQ
Do I need Rosetta installed at all on Apple Silicon for iOS development? Not specifically for CocoaPods or Ruby — Xcode and its build tools run natively on Apple Silicon. Rosetta is more relevant for older tools or dependencies that haven’t shipped arm64 builds yet.
Will switching to Homebrew’s Ruby break my existing gems? It can, since gems are tied to a specific Ruby installation. You’ll likely need to reinstall CocoaPods and any other project-specific gems after switching, but that’s usually a quick step compared to the mismatch headache itself.
Does this happen on Intel Macs too? No, this specific architecture mismatch is unique to the Apple Silicon transition — Intel Macs don’t have the arm64/x86_64 duality that creates this particular failure mode.
Is it safe to just keep using arch -x86_64 for everything instead of fixing the root cause? It works as a workaround, but you’re running everything under Rosetta emulation at that point, which is slower than necessary — worth fixing properly if this is a machine you’ll be developing on regularly.
Editor’s Opinion
the terminal rosetta setting getting forgotten about is way more common than people admit, myself included apparently. if reinstalling the gem doesn’t fix it on the first try, stop reinstalling gems and go check uname -m instead, that’s usually where the real answer is hiding.
