You shape something interesting in Rork, finally pull the project down to your local Mac to open it in Xcode, and the terminal greets you with a wall of red. For a lot of people, this is where progress stops. The frustrating part is that the failure rarely has anything to do with Rork itself — it is your local mix of Ruby, CocoaPods, and Xcode that is out of alignment. Apple Silicon Macs have made this whole layer noticeably more fragile.
I have moved Rork-exported projects between half a dozen Macs at this point, and every time pod install finds a new way to fail. The patterns are limited though, and the fixes are surprisingly mechanical once you recognise the symptom. This guide walks through the five patterns I have hit most often, in the order I now check them.
Why pod install Trips Up Rork Projects So Often
Rork generates React Native + Expo code. To build it locally you typically run npx expo prebuild to generate the native iOS project, and CocoaPods pulls in the dependency tree from there. So Rork itself is fine — it is the moment pod install runs that exposes any drift in your host environment.
Three axes cause most of the trouble: how Ruby is installed (system Ruby vs rbenv vs asdf), the version of CocoaPods you have, and where Xcode's command line tools are pointing. A misalignment in any one of those will make a project that worked yesterday refuse to build today.
Pattern 1: ffi Gem Cannot Load on Apple Silicon
This is by far the most common one I see. The error usually looks like:
LoadError - dlopen(.../ffi_c.bundle, 0x0009):
tried: '.../ffi_c.bundle' (mach-o file, but is an incompatible architecture
(have 'x86_64', need 'arm64'))
The cause is that your Ruby binary was compiled for x86_64 but pod install is trying to run as arm64. Sometimes a previous Rosetta-based install left the wrong binary behind.
There are two ways to fix it. The cleaner one is to stay native arm64:
# Confirm what arch you are actually running
arch
# Should print arm64
# Reinstall ffi as arm64
sudo gem uninstall ffi
sudo arch -arm64 gem install ffi
# Reinstall CocoaPods as arm64 too
sudo arch -arm64 gem install cocoapodsThe other option is to explicitly run everything through Rosetta. This sometimes helps when you inherit an older Podfile that depends on x86_64-only gems:
arch -x86_64 pod installMy rule of thumb: for any new project, stay native arm64. Only reach for the Rosetta fallback when you are dealing with a legacy project that genuinely depends on x86_64 binaries. Mixing the two makes future debugging much harder.
Pattern 2: System Ruby and rbenv/asdf Are Fighting Each Other
macOS ships with a system Ruby at /usr/bin/ruby, but most developers also install Ruby via Homebrew, rbenv, or asdf. The trouble starts when you cannot tell which Ruby gem install cocoapods actually targeted.
A quick diagnostic:
which ruby
which gem
which pod
ruby -vIf you are using rbenv you would expect something like:
/Users/yourname/.rbenv/shims/ruby
/Users/yourname/.rbenv/shims/gem
/Users/yourname/.rbenv/shims/pod
ruby 3.2.2 (2023-03-30 revision e51014f9c0) [arm64-darwin23]
If pod lives at /usr/local/bin/pod or /opt/homebrew/bin/pod while ruby resolves to your rbenv shim, you have a mismatch. The CocoaPods you installed is bound to a different Ruby than the one your shell currently uses.
The fix is to reinstall cocoapods against whichever Ruby your shell actually points at:
# Using rbenv
rbenv local 3.2.2 # pin the version for this project
gem install cocoapods
rbenv rehash
pod --versionMatch the Ruby version to whatever the Rork template expects. Expo SDK 50 and later are stable on Ruby 3.2. Avoid using the system Ruby (currently 2.6.10 on macOS) directly — it produces a flood of deprecation warnings and tends to fail in subtle ways.
Pattern 3: CocoaPods Is Newer Than the Podfile Expects
Run gem install cocoapods today and you get the latest release (1.16.x at the time of writing). Rork-generated Podfile files inherit from the Expo template, which often pins to 1.14 or 1.15. Occasionally you'll see this:
[!] CDN: trunk Repo update failed - 28 error(s):
CDN: trunk URL couldn't be downloaded ...
It looks like a network error, but in practice the CocoaPods Specs repository is the actual culprit. Work through these in order:
# 1. Clear CocoaPods cache
pod cache clean --all
# 2. Update Specs repo
pod repo update
# 3. If still broken, blow away the local Specs and re-fetch
rm -rf ~/.cocoapods/repos/trunk
pod setupIf none of that helps, downgrade CocoaPods to the version Expo recommends:
sudo gem uninstall cocoapods
sudo gem install cocoapods -v 1.15.2
pod --version # confirm 1.15.2It is tempting to assume newer is always better, but the React Native and Expo ecosystems are sometimes a release behind on CocoaPods major versions. Matching the version your template expects saves time in the long run.
Pattern 4: Xcode Command Line Tools Are Pointing at the Wrong Place
If you see something like this during pod install:
xcrun: error: SDK "iphoneos" cannot be located
xcrun: error: unable to lookup item 'PlatformPath' in SDK 'iphoneos'
Your Xcode path setup is wrong. This happens after upgrading Xcode, or when only the standalone Command Line Tools are installed and Xcode itself is missing. Point xcode-select back at the full Xcode app:
# Show current path
xcode-select -p
# If it returns /Library/Developer/CommandLineTools, that's the wrong target
sudo xcode-select -s /Applications/Xcode.app/Contents/Developer
# Verify
xcode-select -p
# Should now read /Applications/Xcode.app/Contents/DeveloperYou also need to have launched Xcode at least once and accepted the license. Otherwise any command that touches Xcode internals will refuse to run:
sudo xcodebuild -license acceptThis whole class of failure tends to resurface whenever you buy a new Mac, upgrade macOS, or switch to an Xcode beta. If a build that worked yesterday breaks today, this is the first place to check.
Pattern 5: Hermes or Folly Fails to Compile in C++
Even when pod install itself completes, the subsequent xcodebuild step can fail while compiling Hermes or RCT-Folly. The error output is enormous, but the root cause almost always comes down to one of two things.
First, the Hermes flag in ios/Podfile and the equivalent setting in app.json / app.config.js are out of sync. If Expo wants the New Architecture enabled but the Podfile is not propagating :hermes_enabled => true, you'll get C++ inconsistencies. Open the app.json Rork generates and check the value of "newArchEnabled".
Second, Xcode 16 and newer combined with older versions of Folly produces C++17 errors. The fix is either to bump React Native to 0.74 or later, or to pin CLANG_CXX_LANGUAGE_STANDARD to c++17 inside a post_install hook in your Podfile.
When all else fails, the most reliable move is to rebuild the iOS project from scratch:
# From the project root
rm -rf ios
rm -rf node_modules
npm install # or yarn / bun install
# Regenerate the iOS project
npx expo prebuild -p ios --clean
cd ios
pod installexpo prebuild --clean is destructive — back up any hand-written changes inside ios/ first. But if you have lost track of what was modified in Podfile, starting fresh is usually faster than detective work.
Lock In a Debugging Order So You Don't Loop
If you respond to errors as they appear, you'll keep getting stuck in the same places. I now follow a fixed order: first verify the environment with arch and which ruby / pod, then check external state with pod --version and xcode-select -p, and only as a last resort regenerate ios/. With that order, most failures get isolated within thirty minutes.
For related troubleshooting, the Rork React Native Build Errors Complete Guide 2026 and the Rork EAS Build CI/CD Pipeline with GitHub Actions are good companions — together they cover both local and cloud build strategies.
Run arch and which pod on your Mac and see which pattern your environment matches. Once you have isolated the cause, the actual fix usually takes about five minutes.