Log Entry: 03:42 AM. The build failed again, and if I see one more ‘Invariant Violation,’ I’m throwing this MacBook Pro into the Hudson River.
--- FATAL EXCEPTION: mqt_js ---
Process: com.enterprise.monolith, PID: 28492
java.lang.RuntimeException: Error: Exception in HostFunction: Failed to create JS object from C++ pointer.
at com.facebook.react.bridge.CatalystInstanceImpl.jniCallJSFunction(Native Method)
at com.facebook.react.bridge.CatalystInstanceImpl.callFunction(CatalystInstanceImpl.java:272)
at com.facebook.react.bridge.AppRegistry.runApplication(AppRegistry.java:35)
at com.facebook.react.HostHolder.lambda$resume$0(HostHolder.java:12)
at android.os.Handler.handleCallback(Handler.java:942)
at android.os.Looper.loopOnce(Looper.java:201)
at android.os.Looper.loop(Looper.java:288)
at android.app.ActivityThread.main(ActivityThread.java:7872)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:548)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1003)
Caused by: com.facebook.jni.CppException: std::bad_alloc
at com.facebook.hermes.unicode.Unicode.convertToUTF8(Unicode.cpp:142)
at com.facebook.hermes.inspector.RuntimeAdapter.getPages(RuntimeAdapter.cpp:210)
... 42 more lines of garbage
---------------------------------------------------------
BUILD FAILED in 7m 22s
248 actionable tasks: 122 executed, 126 up-to-date
Error: /Users/jaded_lead/dev/monolith/node_modules/react-native-reanimated/android/build.gradle:82:
A problem occurred evaluating project ':react-native-reanimated'.
> Could not find method compileOnly() for arguments [com.facebook.react:react-native:0.74.1]
Table of Contents
Incident Report: The 72-Hour Descent
I’ve been awake so long that the syntax highlighting in VS Code is starting to look like a Rorschach test. I see my failures in the red squiggly lines. This isn’t a “development cycle.” It’s a war of attrition against an abstraction layer that hates me. We’re running react native 0.74, trying to be “modern.” We’ve got Ruby 3.2.2 screaming about Gemfile locks and Gradle 8.0 throwing tantrums because some library written by a teenager in 2019 hasn’t updated its namespace.
The app is an enterprise beast. Thousands of components. Deeply nested navigation. A “state management solution” that is basically just a global object we pray doesn’t mutate into a black hole. And now, the OOM (Out of Memory) crashes. The users are reporting that the app just… vanishes. No error. No “Oops.” Just back to the home screen.
The culprit? A memory leak so deep in the JSI (JavaScript Interface) that I had to learn more about C++ smart pointers than I ever wanted to know. We’re supposed to be “web developers on mobile,” right? That’s the lie. The reality is that when react native breaks, you aren’t a web developer anymore. You’re a forensic engineer digging through layers of C++, Java, and Objective-C, trying to figure out why a garbage collector in one language isn’t talking to the garbage collector in another.
Ticket #882: The Bridge is a Bottleneck, Not a Feature
For years, we were told the Bridge was the heart of react native. It was the glorious asynchronous pipe that kept the UI thread smooth while the JS thread did the heavy lifting. That was a lie. The Bridge is a toll booth on a highway where every car has to be disassembled, turned into JSON, moved across the road, and reassembled on the other side.
In our enterprise app, we have a list of 5,000 inventory items. Every time the user scrolls, the Bridge chokes. We tried to move to the New Architecture. We enabled Fabric. We enabled TurboModules. We thought the direct C++ communication via JSI would save us.
It didn’t. It just changed the shape of the bottleneck. Now, instead of JSON serialization overhead, we have “Host Object” overhead. We’re passing pointers back and forth, and if one of those pointers points to a dead object because the JS garbage collector decided to be aggressive, the whole app goes down with a SIGSEGV.
The Fabric renderer was supposed to make UI updates synchronous. Great. Now, instead of a slightly laggy UI, we have a UI that deadlocks because the JS thread is waiting for a synchronous layout pass from the Yoga engine, while the Main thread is waiting for a lock on a native module. It’s a Mexican standoff in the CPU.
Ticket #666: Dependency Hell and the Ruby 3.2.2 Nightmare
Every morning starts the same way. git pull. npm install. cd ios && pod install. And then, the screaming starts.
CocoaPods is a relic of a darker age. In a react native project, it becomes a sentient entity that feeds on your productivity. We updated to Ruby 3.2.2 because of a security patch. Suddenly, half the pods won’t install because of a FFI (Foreign Function Interface) mismatch.
Then there’s the package.json. Look at this crime scene:
{
"name": "enterprise-monolith-mobile",
"version": "4.2.0",
"dependencies": {
"react": "18.2.0",
"react-native": "0.74.1",
"react-native-reanimated": "3.10.0",
"react-native-screens": "3.31.1",
"react-native-svg": "15.3.0",
"react-native-vector-icons": "10.1.0",
"some-legacy-chart-library": "git+https://github.com/dead-repo/charts.git#v0.1.2",
"react-native-gesture-handler": "2.16.1"
},
"devDependencies": {
"@react-native/babel-preset": "0.74.83",
"@react-native/metro-config": "0.74.83",
"typescript": "5.0.4"
},
"overrides": {
"react-native-reanimated": "3.10.0",
"react-native-svg": "15.3.0"
}
}
The overrides section is a confession of guilt. It’s where we admit that our dependencies are so broken we have to force the package manager to ignore the peer dependency warnings. If I run npx react-native-clean-project, it wipes everything. It takes 20 minutes to rebuild. 20 minutes of staring at the wall, wondering why I didn’t just go into carpentry.
The react-native-reanimated library is a marvel of engineering, but it’s also a house of cards. If your Babel config is off by one character, or if you forget to add the plugin to the very end of the list, the app crashes on startup with a cryptic “Worklet not found” error.
// babel.config.js - The place where dreams go to die
module.exports = {
presets: ['module:@react-native/babel-preset'],
plugins: [
// This MUST be last. If you put it anywhere else,
// Reanimated will silently fail and your animations
// will run at 2 FPS on the JS thread.
'react-native-reanimated/plugin',
],
};
Ticket #772: TurboModules and the Myth of Shared Logic
The promise of react native was “Write Once, Run Anywhere.” The reality is “Write Once, Debug Everywhere, and then Write Native Code Anyway.”
We needed a high-performance encryption module for our enterprise data. Doing it in JS was too slow. So, we had to write a TurboModule. This involves writing a spec in TypeScript, running a codegen script that generates a mountain of C++ glue code, and then implementing the actual logic in Swift for iOS and Kotlin for Android.
Here is the “simple” Swift implementation for the bridge. Look at the boilerplate. Look at the manual memory management.
@objc(EncryptionModule)
class EncryptionModule: NSObject {
@objc
func encryptData(_ data: String, resolver: @escaping RCTPromiseResolveBlock, rejecter: @escaping RCTPromiseRejectBlock) {
do {
let encrypted = try MyCryptoLibrary.encrypt(data)
// We have to manually bridge types.
// If this string is too large, the bridge might
// just drop it or OOM the JS heap.
resolver(encrypted)
} catch {
rejecter("E_ENCRYPT_FAIL", "Encryption failed", error)
}
}
@objc
static func requiresMainQueueSetup() -> Bool {
return false // Because we don't want to block the UI thread... yet.
}
}
By the time you’ve written the TypeScript spec, the C++ header, the Swift implementation, and the Kotlin implementation, you’ve written four times as much code as you would have if you’d just built two separate native apps. And you still have to deal with the fact that the RCTPromiseResolveBlock might be called after the JS context has been destroyed, leading to a “Heisenbug” that only happens on Friday afternoons.
Ticket #112: The Yoga Layout Engine and the 60FPS Lie
react native uses Yoga, a C++ implementation of Flexbox. It’s impressive, but it’s a black box. In a native iOS app, the Auto Layout engine is optimized for the hardware. In react native, every time a component state changes, Yoga has to recalculate the entire layout tree.
In our “Dashboard” screen, we have nested views—containers inside containers inside containers. Each one of those is a “Shadow Node” in the C++ layer. When the user toggles a single switch, the following happens:
1. JS thread triggers a state change.
2. React does a virtual DOM diff.
3. The diff is sent across the JSI to the Shadow Tree.
4. Yoga performs a layout pass on the entire screen.
5. The results are sent to the Main thread.
6. The Main thread updates the native views (UIViews or Android Views).
If you have a complex layout, this process takes longer than 16.6ms. Congratulations, you just dropped a frame. The “60FPS” promise is only true if your app is a glorified Todo list. For an enterprise app with real data, real charts, and real complexity, you’re constantly fighting the “Jank.”
We tried to optimize. We used memo, useCallback, useMemo. We turned our code into a minefield of optimization hooks. It made the code unreadable and barely improved the performance. The overhead isn’t in the JS; it’s in the communication between the worlds.
Ticket #505: The Hermes Garbage Collector and the Silent Death
We switched to the Hermes engine because it’s supposed to be faster for mobile. And it is. Startup time improved. But the garbage collector is… temperamental.
In our 72-hour debug session, we found that Hermes was holding onto references of deleted components because of a closure in a useEffect hook that was captured by a native event listener. Because it was a “Host Object” (a JS object backed by a C++ object), the memory wasn’t being freed.
We watched the memory profiler in Android Studio. 400MB. 600MB. 1.2GB. Then, the kernel kills the process.
The fix? We had to manually nullify every reference in the cleanup function of the effect. We’re writing JavaScript like it’s 1998 and we’re worried about Internet Explorer 6 memory leaks. This is the “modern” mobile development experience.
Ticket #911: The Upgrade Path to Nowhere
Upgrading react native is like performing open-heart surgery on yourself while running a marathon. We went from 0.71 to 0.74.
The changelog said it would be “straightforward.” It wasn’t.
– The AppDelegate.mm had to be completely rewritten to support the new RCTAppDelegate class.
– The Podfile required a specific version of hermes-engine that wasn’t yet on the public CDN.
– Android’s build.gradle needed to be updated to Gradle 8.0, which broke our obfuscation rules in ProGuard.
– Three of our core community libraries (which haven’t been updated in 18 months) used a deprecated internal API that was finally removed.
We spent two weeks just getting the app to compile. Two weeks of zero feature development. Two weeks of explaining to stakeholders why “doing nothing” takes so much effort.
When you are native, an OS update might break a few things, but the core architecture remains stable. In react native, the architecture is a moving target. You are building on shifting sands.
The Final Tally
I’m looking at the sun coming up over the skyline. The memory leak is “mitigated”—which is a professional way of saying I put a band-aid on a gunshot wound. I’ve nullified the pointers, I’ve added some defensive checks in the C++ layer, and I’ve prayed to the gods of the heap.
Was it worth it?
The Case for React Native:
– We have one codebase for the business logic.
– Our web developers can contribute to the mobile app (mostly).
– Hot Reloading is great when it doesn’t break the state and force a full rebuild anyway.
The Case Against React Native:
– The “Shared Logic” is a fraction of the total effort. The rest is spent fighting the bridge, the environment, and the dependencies.
– Performance is a constant uphill battle. You are always one nested View away from a frame drop.
– The toolchain is incredibly fragile. One Ruby version change can bring an entire 50-person engineering team to a halt.
– You need “Senior” developers who actually know Native code to fix anything meaningful. The “Web Dev on Mobile” dream ends the moment you need to access a file system or a hardware sensor efficiently.
The Bitter End
If I were starting this project today, with the knowledge of the last 72 hours burned into my retinas, I would have gone native.
The technical debt we’ve accumulated isn’t just “debt.” It’s a high-interest payday loan from a shark. We’re paying for the “speed” of initial development with the “misery” of long-term maintenance. Every time we want to add a feature, we have to check if the Bridge can handle it, if Yoga can layout it, and if Hermes will leak it.
react native is a powerful tool, but it is not a shortcut. It is a trade-off. You trade the predictability of native APIs for the flexibility of JS. But in an enterprise environment, predictability is worth its weight in gold. Flexibility just gives you enough rope to hang yourself—and your entire production environment.
I’m going to save this log, push the “mitigation” branch, and sleep for a thousand years. If the build fails again, the MacBook is going in the water. I’m not joking.
Status: Resolved (Incomplete)
Time Spent: 72h 14m
Caffeine Consumed: Lethal
Sanity: Depleted
Related Articles
Explore more insights and best practices: