text
\n$ npx react-native run-ios –scheme “FlagshipApp”
\ninfo Found Xcode workspace “FlagshipApp.xcworkspace”
\ninfo Building (fe)
\nerror Failed to build iOS project. We ran “xcodebuild” command but it exited with error code 65. To debug build logs further, consider building your app via Xcode.app directly.<\/p>\n
** BUILD FAILED **<\/p>\n
The following build commands failed:
\n PhaseScriptExecution [CP-User]\\ Generate\\ Specs \/Users\/admin\/Library\/Developer\/Xcode\/DerivedData\/FlagshipApp-abc\/Build\/Intermediates.noindex\/Pods.build\/Debug-iphonesimulator\/FBReactNativeSpec.build\/Script-001.sh (in target ‘FBReactNativeSpec’ from project ‘Pods’)
\n(1 failure)<\/p>\n
\/Users\/admin\/.rvm\/gems\/ruby-3.2.2\/gems\/cocoapods-1.15.2\/lib\/cocoapods\/executable.rb:167:in Error: Failed to install CocoaPods dependencies for iOS project, which is required for this architecture. Forty-two milliseconds. That\u2019s nearly three frames of animation lost. To the user, it\u2019s a “micro-stutter.” To me, it\u2019s a failure of the fundamental architecture. You can\u2019t “optimize” your way out of a garbage collector that doesn’t know about the native UI lifecycle. The JS thread is decoupled from the UI thread, which sounds good on paper until you realize that any synchronization requires crossing the bridge or using the JSI (JavaScript Interface). <\/p>\n If I want to sync a scroll position with an animation, I have to use Table of Contents<\/p>\nexecute_command':
\n\/usr\/local\/bin\/pod: line 2: \/usr\/local\/Cellar\/cocoapods\/1.13.0\/libexec\/bin\/pod: No such file or directory
\n(RuntimeError)
\n from \/Users\/admin\/.rvm\/gems\/ruby-3.2.2\/gems\/cocoapods-1.15.2\/lib\/cocoapods\/executable.rb:52:in<\/code>pod’
\n from \/Users\/admin\/projects\/flagship\/node_modules\/react-native\/scripts\/cocoapods\/utils.rb:291:in get_react_native_path'
\n from \/Users\/admin\/projects\/flagship\/ios\/Podfile:14:in<\/code>block in (root)’<\/p>\n
\n
\nCheck your Ruby version (currently 3.2.2) and ensure it matches the project’s .ruby-version.
\nAlso, check if ‘ffi’ gem is installed for M1\/M2 compatibility.<\/p>\nThe output above is the sound of a $4,000 machine choking on its own vomit. It\u2019s 2:14 AM. The "visionary" CTO is likely asleep in a weighted blanket, dreaming of "write once, run everywhere" efficiencies. Meanwhile, I\u2019m staring at a Ruby stack trace inside a JavaScript project that\u2019s trying to compile C++ code to run on an ARM-based simulator. \n\nThe failure is predictable. We updated a single transitive dependency\u2014a minor bump in a library that handles SVG rendering\u2014and the entire house of cards folded. CocoaPods is looking for a version of itself that was uninstalled three months ago. The `FBReactNativeSpec` script failed because the environment variables exported by the Metro bundler didn't play nice with the shell environment inherited by Xcode. This is the reality of **react native** in a professional environment. It isn't a framework; it\u2019s a collection of shims held together by duct tape and hope.\n\n## 1. The 3 AM Build Failure: A Forensic Analysis\n\nWhen you build a native app in Swift, the compiler is your friend. It\u2019s a strict friend, sure, but it\u2019s honest. In **react native**, the build process is a multi-layered nightmare of abstraction. You aren't just compiling code; you are orchestrating a fragile dance between the Node.js runtime, the Ruby-based CocoaPods dependency manager, the Gradle build system for Android, and the LLVM compiler for iOS.\n\nThe error log above highlights the first great lie of cross-platform development: that you can escape the native platform. To fix that "error code 65," I have to manually clear the DerivedData folder\u2014a ritual as old as time\u2014but then I have to go deeper. I have to check if the `node_modules` resolution for the `FBReactNativeSpec` is pointing to the right path. Because **react native** 0.73.x uses a "New Architecture" (which has been "new" for three years now), it relies on `Codegen`. \n\nCodegen is supposed to generate C++ interfaces from your TypeScript definitions. It\u2019s a noble goal. But when it fails, it doesn't give you a syntax error. It gives you a 400-line dump of Ruby errors because the script that triggers the C++ generation couldn't find the right version of the `ffi` gem. So here I am, a senior engineer, debugging a Ruby environment mismatch so that I can generate C++ code that I didn't write, to support a JavaScript bridge that shouldn't exist.\n\nThe "visionary" CTO thinks this saves time. He sees the "Fast Refresh" feature and thinks we\u2019re moving at light speed. He doesn't see the four hours I spent yesterday trying to figure out why the Android build failed with a `D8: Cannot fit requested classes in a single dex file` error because the **react native** core and its bloated dependency tree pushed us over the 64k method limit. We had to enable multi-dex, which added another 30 seconds to every cold build. The "saved time" is a myth. We just traded stable compile-time checks for runtime volatility and build-time insanity.\n\n## 2. The Hermes Myth and the Reality of Garbage Collection\n\nWe were told Hermes would solve everything. "A JavaScript engine optimized for fast start-up on mobile devices," the documentation says. It pre-compiles JavaScript into bytecode. Great. But let\u2019s talk about what happens when the app actually runs.\n\nIn a native Swift app, I have ARC (Automatic Reference Counting). I know exactly when an object dies. In Kotlin, I have the ART (Android Runtime) which, while it has a GC, is tuned for the hardware it lives on. In **react native**, we have Hermes. \n\nThe problem is the "Stop the World" garbage collection. When you\u2019re scrolling a complex list\u2014say, a feed with high-res images and nested comments\u2014the JS thread is already gasping for air. It\u2019s calculating the virtual DOM diff, it\u2019s handling touch events, and it\u2019s trying to format timestamps. Then, the Hermes GC decides it\u2019s time to clean up the 15,000 small objects created during the last three seconds of scrolling. \n\n```text\n\/\/ Logcat output during a scroll event\n02:16:44.123 D\/Hermes: GC Stats (Non-contiguous):\n - Total Footprint: 142MB\n - Allocated: 98MB\n - Collection Time: 42ms (STOP THE WORLD)\n02:16:44.165 W\/ReactNative: [JSI] Slow block on JS thread: 45ms\n02:16:44.166 I\/Choreographer: Skipped 3 frames! The application may be doing too much work on its main thread.\n<\/code><\/pre>\nreact-native-reanimated<\/code>, which essentially injects C++ code to bypass the JS thread entirely. Think about that. We are using a JavaScript framework, but to make it performant, we have to write code that avoids using JavaScript. It\u2019s architectural insanity.<\/p>\n