Skip to content

ios: Add workaround for package:firebase_messaging when building with Xcode 16 #958

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Sep 24, 2024

Conversation

rajveermalviya
Copy link
Member

Without this workaround iOS build currently fails with the following error:

Lexical or Preprocessor Issue (Xcode): Include of non-modular header inside framework module 'firebase_messaging FLTFirebaseMessagingPlugin':
'/Users/rajveer/Projects/zulip-flutter/ios/Pods/Headers/Public/Firebase/Firebase.h'
/Users/rajveer/.pub-cache/hosted/pub.dev/firebase_messaging-15.0.4/ios/Classes/FLTFirebaseMessagingPlugin.h:11:8

Upstream issue and the workaround comment:
firebase/flutterfire#13323
firebase/flutterfire#13323 (comment)

Docs: https://developer.apple.com/documentation/xcode/build-settings-reference#Allow-Non-modular-Includes-In-Framework-Modules

The documentation states that enabling this setting may result in issues later on, which is why this workaround should only be temporary until firebase_messaging is patched with the correct fix.

@rajveermalviya rajveermalviya added maintainer review PR ready for review by Zulip maintainers integration review Added by maintainers when PR may be ready for integration labels Sep 19, 2024
@chrisbobbe
Copy link
Collaborator

chrisbobbe commented Sep 19, 2024

LGTM, and I've tested on Xcode Version 15.4 (15F31d) and it works there too.

An alternative that should also work, and didn't break the build in my testing on Xcode 15, is to add a line

CLANG_ALLOW_NON_MODULAR_INCLUDES_IN_FRAMEWORK_MODULES = YES

in ios/Flutter/Debug.xcconfig and ios/Flutter/Release.xcconfig, and leave project.pbxproj untouched. This might be nicer, because the project.pbxproj is hard to read, and there's a lot in there. Putting this setting in an uncrowded file, with a helpful comment saying it's a temporary workaround for a specific issue, seems helpful.

The Xcode GUI lets you see how the final value for this setting is resolved.

Here's with the PR as-is, with the additions in project.pbxproj:

image

And with my proposal:

image

In my proposal, the prevailing "YES" value comes from the config-file column, instead of the target ("Runner") column.

I wasn't sure which of Debug.xcconfig and Release.xcconfig would control the "Profile" configuration, or if neither of them would, and I found experimentally that it's Release.xcconfig. I'm not finding the place in the Xcode GUI that tells me that, but this looks like the spot in project.pbxproj:

		249021D4217E4FDB00AE95B9 /* Profile */ = {
			isa = XCBuildConfiguration;
			baseConfigurationReference = 7AFA3C8E1D35360C0083082E /* Release.xcconfig */;

@gnprice
Copy link
Member

gnprice commented Sep 20, 2024

ios/Flutter/Debug.xcconfig and ios/Flutter/Release.xcconfig, and leave project.pbxproj untouched.

Neat, I like that option. @rajveermalviya would you try that and confirm that it works for you?

It looks like those files also accept comments, with //. (See Generated.xcconfig in the same directory for an example.) That'd be good for mentioning that it's a workaround which should be temporary, and linking to the chat thread and that upstream issue firebase/flutterfire#13323 .

@rajveermalviya rajveermalviya force-pushed the pr-fix-xcode-16 branch 2 times, most recently from 8aab93a to 7607989 Compare September 23, 2024 16:22
@rajveermalviya
Copy link
Member Author

Thanks for the reviews @chrisbobbe and @gnprice!

Yes, adding the flag to ios/Flutter/{Debug.xcconfig, Release.xcconfig} does result in a successfull build as well.
I've pushed a new revision which does that via Zulip.xcconfig (new file) and #include-ing that in both Debug.xcconfig and Release.xcconfig.

// This flag is added to workaround the iOS build failing
// on Xcode 16, remove it when `package:firebase_messaging`
// is patched with a fix to build successfully on Xcode 16.
//
Copy link
Member

Choose a reason for hiding this comment

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

nit: extra empty line

@PIG208
Copy link
Member

PIG208 commented Sep 23, 2024

I don't have an Xcode installation at the moment to test this. But the change looks clean to me.

@rajveermalviya rajveermalviya force-pushed the pr-fix-xcode-16 branch 2 times, most recently from b996f21 to 2394754 Compare September 23, 2024 20:57
@rajveermalviya
Copy link
Member Author

Thanks for the review @PIG208, pushed a new revision.

Additionally, added references for Zulip.xcconfig so that it becomes visible in XCode (without them it's not).

Copy link
Member

@gnprice gnprice left a comment

Choose a reason for hiding this comment

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

Thanks! I like this structure. Small comment tweaks below.

Then this is otherwise ready for merge, so please update the commit message to a final/mergeable version.

Comment on lines +1 to +2
// Configuration settings file format documentation can be found at:
// https://help.apple.com/xcode/#/dev745c5c974
Copy link
Member

Choose a reason for hiding this comment

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

Helpful, thanks for including this link.

// Configuration settings file format documentation can be found at:
// https://help.apple.com/xcode/#/dev745c5c974

// TODO(firebase/flutterfire#13323): remove this flag
Copy link
Member

Choose a reason for hiding this comment

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

I guess we've talked about having a tool to scan for TODO comments that point to closed issues, and when we do it could potentially understand this syntax for external issues. So it's fine to include it.

But let's also include an actual link. That will make it nice and easy for someone who happens across this a month from now or a year from now to quickly check on the state of the upstream issue, even if we haven't built that potential tool by then.


// TODO(firebase/flutterfire#13323): remove this flag
//
// This flag is added to workaround the iOS build failing
Copy link
Member

Choose a reason for hiding this comment

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

nit: the verb is "work around", and "workaround" is its noun form:

Suggested change
// This flag is added to workaround the iOS build failing
// This flag is added to work around the iOS build failing

Just like other verb phrases made of a verb plus preposition, where they're run together to make a noun:
"to log in" / "this login"
"to set up" / "this setup"
"to clean up" / "this cleanup"

(In each case the two versions are pronounced differently, too — the stress moves from the end in the verb form to the beginning in the noun form. That probably contributes to making the difference salient for me.)

Comment on lines 6 to 8
// This flag is added to workaround the iOS build failing
// on Xcode 16, remove it when `package:firebase_messaging`
// is patched with a fix to build successfully on Xcode 16.
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
// This flag is added to workaround the iOS build failing
// on Xcode 16, remove it when `package:firebase_messaging`
// is patched with a fix to build successfully on Xcode 16.
// This flag is added to work around the iOS build failing
// on Xcode 16. Remove it when `package:firebase_messaging`
// is patched with a fix to build successfully on Xcode 16:
// https://github.com/firebase/flutterfire/issues/13323

@rajveermalviya
Copy link
Member Author

Thanks for the review @gnprice! Pushed a new revision, PTAL.

… Xcode 16

Without this workaround iOS build currently fails with
the following error:

  Lexical or Preprocessor Issue (Xcode): Include of non-modular header inside framework module 'firebase_messaging FLTFirebaseMessagingPlugin':
  '/Users/rajveer/Projects/zulip-flutter/ios/Pods/Headers/Public/Firebase/Firebase.h'
  /Users/rajveer/.pub-cache/hosted/pub.dev/firebase_messaging-15.0.4/ios/Classes/FLTFirebaseMessagingPlugin.h:11:8

Upstream issue and the workaround comment:
  firebase/flutterfire#13323
  firebase/flutterfire#13323 (comment)

Docs:
  https://developer.apple.com/documentation/xcode/build-settings-reference#Allow-Non-modular-Includes-In-Framework-Modules

The documentation states that enabling this setting may
result in issues later on, which is why this workaround
should only be temporary until firebase_messaging is
patched with the correct fix.
@gnprice
Copy link
Member

gnprice commented Sep 24, 2024

Thanks! Looks good — merging.

@gnprice gnprice merged commit a9b2016 into zulip:main Sep 24, 2024
1 check passed
@rajveermalviya rajveermalviya deleted the pr-fix-xcode-16 branch September 27, 2024 15:30
gnprice pushed a commit to rajveermalviya/zulip-flutter that referenced this pull request Mar 20, 2025
This reverts part of commit a9b2016 (zulip#958),
keeping the `Zulip.xcconfig` file and its references.

The fix was released in version `3.6.0` of `package:firebase_core`
and version `15.1.3` of `package:firebase_messaging`:
  firebase/flutterfire@d7d2d4b

We have since then updated Firebase dependencies 3 times:
  zulip@24215f6
  zulip@1abb0a0
  zulip@3ba9985
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
integration review Added by maintainers when PR may be ready for integration maintainer review PR ready for review by Zulip maintainers
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants