The Crash
You pull down a fresh React Native repo, or you upgrade your Expo project, navigate to your /ios directory, and run your standard installation command:
pod install
Instead of a clean build, your terminal drops a wall of text pointing to a compilation or architecture conflict:
LoadError - dylib library not found for ffi_c - /Library/Ruby/Gems/2.6.0/gems/ffi-1.15.5/lib/ffi_c.bundle
Or you are hit with an explicit architecture clash during compilation:
Ignoring ffi-1.15.5 because its extensions are not built.
Arch mismatch: x86_64 vs arm64
Why the Common Internet Advice is a Trap
If you search for this error on Stack Overflow or Reddit, the top answers almost always tell you to run your terminal in Rosetta mode or force compilation with an architecture flag:
sudo arch -x86_64 gem install ffi
arch -x86_64 pod install
Do not do this.
While this might bypass the error temporarily, it introduces a highly unstable configuration to your machine. It forces an Apple Silicon Mac to use Intel x86 emulation for specific Ruby gems while running an underlying system interpreter that expects native ARM (arm64) code.
This mixed-architecture setup will inevitably break your bundler, conflict with Node native modules, and cause random, hard-to-diagnose failures during local builds.
The real problem isn't your hardware; it's that your environment is attempting to load global, system-level Intel configurations inside a modern ARM environment.
The Fix: Resolving the Conflict Natively
To resolve the issue permanently, you need to purge the conflicting configurations and ensure your dependency manager runs natively on Apple Silicon.
Step 1: Purge the Broken System Gems
First, clear out any global, system-level gems that were compiled incorrectly under mixed architectures.
Run the following command from your root directory to remove CocoaPods configurations managed by the system Ruby installation:
gem list --local | grep cocoapods | awk '{print $1}' | xargs sudo gem uninstall
```
---
### Step 2: Install the Native ARM Version of CocoaPods via Homebrew
Instead of relying on the default macOS system Ruby interpreter to manage your gems, install CocoaPods through Homebrew.
Homebrew automatically detects your M-series architecture and fetches the dedicated, optimized native `arm64` binary.
```bash
brew install cocoapods
```
---
### Step 3: Isolate Your Ruby Environment (Optional but Highly Recommended)
Using the default pre-installed macOS system Ruby (`/usr/bin/ruby`) frequently causes permissions and architecture locks.
For a stable environment, switch to a local Ruby version manager like `rbenv` or `chruby` to handle your project dependencies cleanly.
```bash
# Install rbenv via Homebrew
brew install rbenv ruby-build
# Initialize rbenv in your shell configuration (~/.zshrc or ~/.bash_profile)
echo 'eval "$(rbenv init -)"' >> ~/.zshrc
source ~/.zshrc
# Install and set a modern native Ruby version
rbenv install 3.2.2
rbenv global 3.2.2
Step 4: Clear the Local State and Install Natively
Now that your environment relies on native binaries, clear your project's cached build configurations to ensure no stale artifacts remain:
cd ios
pod deintegrate
rm -rf Podfile.lock
Finally, run your installation command normally.
It will complete natively without requiring any arch -x86_64 prefixes or Rosetta terminal wrappers:
pod install
Wrestling with local environment drift, corrupted build paths, and conflicting architectures can pull you out of the development loop for hours.
If you are tired of decoding cryptic terminal logs and tracking down configuration bugs by hand, take a look at FixMyError. It is a clean diagnostic workspace built to parse your build outputs instantly, giving you clear solutions so you can get right back to building your app.