Skip to content

Conversation

@Shahroz16
Copy link
Contributor

summary:

  • Refactors withGoogleServicesJsonFile.ts to detect and handle GoogleService-Info.plist files across multiple locations
  • Prevents duplicate file additions by checking Xcode project references
  • Improves error handling and logging

changes:

  • Systematically checks multiple locations where GoogleService-Info.plist might exist Prioritizes existing files added by React Native Firebase

This PR attempts to resolve build errors caused by both our plugin and React Native Firebase trying to add the same GoogleService-Info.plist file.

@Shahroz16 Shahroz16 requested a review from a team as a code owner March 12, 2025 16:37
@Shahroz16 Shahroz16 removed the request for review from a team March 12, 2025 16:40
function isFileReferencedInXcodeProject(project: any, fileName: string): boolean {
try {
// Get all file references
const fileReferences = project.pbxFileReferenceSection();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have considered this option initially but I was hesitant to do that route since I don't know how reliable it is to be parsing Xcode project file and if this might fail with Xcode upgrades or things like that? Specially since there are no Expo plugins or mods that allow us to access those details in a structured way.

Or maybe even this file looks different for complicated project structures, at the end of the day, the vast majority of iOS development depend on Xcode updating this file when files are added to the project and it's not done manually

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have found the xdode package to be very reliable, the approach is actually the most common way to programmatically interact with Xcode projects in the React Native ecosystem. Most tools (including React Native itself in the CLI), fastlane, expo config use similar methods.

While Apple does change the Xcode project format in xcode upgrades, they generally maintain backward compatibility, especially for core features like file references.

And lets say there is a case with very complicated structure out of ordinary, and this check fails, the consequences would be we get a duplicated reference which we were going to get anyway? and if someone has this issue we can suggest the solution of not adding the googleservices file in our config?

Copy link
Contributor

@uros-mil uros-mil Mar 27, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've recently updated our Xcode project file for APN UIKit to the newest version (available with Xcode 16.x), and our existing project file parsing (in .github workflow/actions) failed.
I would advise testing this with both Xcode 15.x and 16.x project-file versions before merging.

Reference:

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I actually think we should re-think this change, because a similar logic was problematic with Expo warnings for version conflicts. I believe this is could even be more problematic.

Like @uros-mil mentions, seems like Xcode 16 added/changed this file format and we don't wanna keep testing and supporting multiple Xcode project files format

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't analyze this in depth, but my logic is:

  • We'll need a solution that is not error-prone
  • If we need to look inside the project file (and there is no other way), let's check if anyone has found an approach that is working well with both newer and older versions of the format

expect(existsInAnyLocation).toBe(true);
});

test("GoogleService-Info.plist file is not duplicated", () => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think those tests will never fail since our test project doesn't have any Firebase SDKs setup for it, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes thats correct, created them so when we run these on the branch where you added react native firebase, we can verify it via unit test too.

also, might help even in future when we want to quickly test any other rn-firebase feature while making sure nothing else breaks. But it can be removed if deemed unnecessary.

Base automatically changed from google-services-plist-file-conflict to feature/fcm-support March 13, 2025 10:08
Base automatically changed from feature/fcm-support to beta March 13, 2025 10:46
Copy link
Contributor

@mahmoud-elmorabea mahmoud-elmorabea left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I actually think we should re-think this change, because a similar logic was problematic with Expo warnings for version conflicts. I believe this is could even be more problematic.

Like @uros-mil mentions, seems like Xcode 16 added/changed this file format and we don't wanna keep testing and supporting multiple Xcode project files format

@Shahroz16
Copy link
Contributor Author

Putting this back to draft, so when we plan to bring the expo improvements project again, we can restart the conversation.

@Shahroz16 Shahroz16 marked this pull request as draft April 28, 2025 10:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants