Why does my Rork app fail with 'Error initializing Firebase' on iOS 18?

When a Rork-generated iOS app crashes at launch with 'Error initializing Firebase' on iOS 18, the cause sits at the boundary between what the Rork AI editor wrote and what the native Firebase iOS SDK expects to find at build time. The iOS 18 part of the error rarely matters. The missing or misconfigured GoogleService-Info.plist file does.

Short answer

The crash is almost always a configuration gap, not an iOS 18 regression. The native Firebase iOS SDK reads GoogleService-Info.plist from the app bundle at startup. Per the Firebase iOS setup guide, the file must be downloaded from the Firebase console for the exact bundle identifier and placed where Xcode can include it in the build. In an Expo or Rork project, that means setting ios.googleServicesFile in app.json and adding useFrameworks: "static" via expo-build-properties, per the React Native Firebase documentation.

What you should know

• Rork generates Expo and React Native apps. Any rule that applies to Expo Firebase setup applies to a Rork export.
• The native Firebase iOS SDK requires GoogleService-Info.plist. Without it, FirebaseApp.configure() throws at startup.
• Bundle identifier match is strict. The Firebase console registers each iOS app to a specific bundle ID, and the plist is tied to that registration.
• The Firebase JS SDK and @react-native-firebase are different libraries. Only the second one needs the plist on iOS.
• useFrameworks: "static" is mandatory for iOS Firebase under Expo. Skipping it breaks the CocoaPods install long before the app reaches iOS 18.
• iOS 18 itself rarely causes a new init failure. A fresh EAS Build often surfaces a pre-existing config gap that the previous build silently tolerated.

Why does Rork generate apps that fail Firebase init on iOS 18?

In practice, the Rork AI editor produces JavaScript code that imports Firebase, but the iOS build pipeline still expects the native GoogleService-Info.plist to be present whenever a project includes any package from the @react-native-firebase family. The Firebase iOS setup documentation is explicit: 'The Firebase config file contains unique, but non-secret identifiers for your project and app,' and FirebaseApp.configure() looks for it at startup. The AI editor does not have access to your Firebase console, cannot download the plist on your behalf, and does not always add the matching field in app.json.

The iOS 18 version in the error string usually shows up because the developer ran a clean EAS Build for the first time after upgrading their device or the Xcode toolchain. The init failure was latent in the earlier build, but cached native modules or a prior Expo Go session masked it. The new build forces the SDK to read the plist on a real device or simulator that no longer has the cached state. That is why the error feels iOS 18 specific even when iOS 18 plays no causal role.

How do I confirm GoogleService-Info.plist is actually missing?

Start at the source of truth, the EAS Build log. When the file path declared in app.json cannot be resolved, the Xcode step fails with Build input file cannot be found: GoogleService-Info.plist, per the public EAS CLI issue tracker. When the build succeeds but the app crashes at startup, the more useful signal is the native Firebase log line that prints during FirebaseApp.configure() and says it could not locate the configuration file.

Three quick checks confirm the cause:

• Open app.json and search for googleServicesFile. If it is missing under expo.ios, the build never copies the plist.
• Inspect the file referenced by that path. The plist must contain a BUNDLE_ID value matching expo.ios.bundleIdentifier exactly. Bundle ID is case-sensitive, per the Firebase documentation.
• Open the Firebase console and check that the iOS app under your Firebase project has the same bundle ID. A mismatch means the downloaded plist will never satisfy initialization.

If any of the three checks fails, the diagnosis is settled before the next build.

How do I add GoogleService-Info.plist to a Rork project the right way?

The fix has three moving parts: downloading the file, referencing it from app.json, and configuring CocoaPods to use static frameworks. The table below maps each step to the documentation and to the failure mode it prevents.

For public Rork repositories, the plist can be uploaded as an EAS secret file instead of being committed. The build references it through the same googleServicesFile path, but EAS injects it at build time. This is the workflow the Expo EAS Build documentation describes for any iOS config file that the team prefers to keep out of source control.

Why does Firebase on iOS need useFrameworks set to static?

The Firebase iOS SDK ships as static frameworks and depends on use_frameworks! in the underlying CocoaPods configuration. Per the React Native Firebase documentation, this is enforced by firebase-ios-sdk and propagates up to any project that links a Firebase pod. In a stock Expo project, the default Podfile does not use frameworks. Without the expo-build-properties plugin, the pod install step fails with linker errors well before the app launches on iOS 18.

The practical consequence is that a Rork project where the AI editor adds @react-native-firebase/app and @react-native-firebase/auth but does not add the build-properties plugin will fail at pod install. The error surface looks like a native build error rather than an init error, but the same configuration gap is upstream of both failure modes. Fixing it once removes both classes of crash.

What if Firebase still fails after adding the plist?

Three residual causes account for most of the remaining init failures.

The first is a stale build. The Metro bundler caches transformed JavaScript, but the iOS native binary is built once per EAS Build run. A change to app.json does not propagate until a fresh native build is triggered, per the Expo EAS Build documentation. Running expo start against an existing iOS development build will not pick up the new plist path.

The second is a duplicate or renamed plist file. Some Rork exports include GoogleService-Info (1).plist or GoogleService-Info-Dev.plist. Xcode looks for the exact filename declared in the build phase. A renamed copy means the SDK reads the wrong file at runtime, and the init call returns the 'Configuration fails' error documented in the public React Native Firebase issue tracker when the GOOGLE_APP_ID does not match.

The third is a mismatch between the GoogleService plist and the Firebase JS SDK config object. When a Rork screen calls initializeApp with a hardcoded config object whose appId differs from the plist value, the native module and the JS module register two different FirebaseApp instances. The init call then fails on one of them depending on which import order Metro emits. Removing the hardcoded JS config and letting the native plist drive both layers is the cleaner fix.

What to watch out for

Four patterns lead to repeat regressions in Rork plus Firebase projects.

The first is treating the plist as a secret. It contains identifiers, not credentials. Security comes from Firebase Security Rules and App Check, both documented in the Firebase security rules guide. Hiding the plist does not protect a misconfigured Firestore collection.

The second is editing app.json without rebuilding. Rork's preview runs in a development client that holds the previous build's native config. A change to googleServicesFile requires a fresh EAS Build to take effect, not a JavaScript reload.

The third is missing the iOS 18 specific App Transport Security defaults. While ATS does not affect Firebase init directly, a Rork project that fails Firebase init on iOS 18 often also fails ATS rules added in recent iOS releases, per the Apple App Transport Security documentation. Both failures look similar in the device console, so checking ATS is useful when the plist diagnosis seems clean.

The fourth is shipping GoogleService-Info.plist without scanning the compiled IPA for other leaked secrets. The plist is fine, but the same Rork export often inlines a Supabase service_role key, an OpenAI key, or other credentials that would fail OWASP MASVS-STORAGE-2 checks. For builders who want an external automated read of a compiled IPA before submission to App Store Connect, PTKD.com (https://ptkd.com) is one of the platforms focused specifically on pre-submission OWASP MASVS scanning for AI-coded apps including those generated by Rork.

Key takeaways

• The iOS 18 version in the error message is rarely the cause. A missing or misreferenced GoogleService-Info.plist is the cause in the majority of Rork projects that hit this crash.
• Wire the plist through app.json, not by dropping it in ios/. Expo and Rork need the expo.ios.googleServicesFile field to copy the file into the native build at compile time.
• Set useFrameworks: "static" through expo-build-properties. The iOS Firebase SDK requires this, and the pod install fails without it before the app ever runs.
• Bundle identifier match is strict and case-sensitive. The plist is tied to a specific iOS app registration in the Firebase console.
• Some teams outsource the pre-submission scan. Platforms like PTKD.com run automated OWASP MASVS checks on the compiled IPA, which is one way to catch leaked keys alongside the Firebase config before App Review sees the build.