Bug: Architectures aren't stripped from fat frameworks

[brentleyjones]

Describe the bug

When using fat frameworks with apple_dynamic_framework_import Bazel will strip unneeded architectures from the framework during bundling. rules_xcodeproj currently doesn't do this, resulting in the warning:

Building for iOS simulator, but the linked and embedded framework 'X.framework' was build for iOS + iOS Simulator.

Expected behavior

Similar to how Carthage handles this, we should strip unneeded architectures.

[pennig]

@brentleyjones Am I right to presume that since "Code Sign On Copy" is enabled, that the script phase which will strip unused architectures should happen before the existing "Embed Frameworks" phase?

[brentleyjones]

Yes.

Though maybe it should also do the embed as well? You can't strip in place, and the embed phase references files in the Project navigator.

[pennig]

I'd like to rely on the code signing that happens in the the copy files phase used currently rather than manually script it. So, seems like the approach should be:

1. A run script phase strips the unused architectures from the frameworks fed into the existing copy files phase, and save them in some staging location (tmp? DerivedData?)
2. Modify the existing copy files phase to reference the stripped frameworks wherever they lie, instead of the project locations.

[brentleyjones]

I'm not sure you will be able to do #2, at least without putting these new files in the Project navigator, which is really tricky, especially with our custom Derived Data layout.

Carthage seems to be fine with doing code signing itself in its embed script, so I feel we should be okay as well? Maybe it will make you feel better to know that this process will only happen for Build with Xcode, as Build with Bazel won't have any embedding phases (it will all be handled by the bazel copy logic).

[brentleyjones]

@erikkerber @pennig Us changing the validation build setting fixed this for local development, right? I think the main issue remaining is if someone tries to create an xcarchive and submit to the app store, though I don't think that should be a high priority for us right now.

[erikkerber]

That's a flashback from the past, and I remember tinkering with it but we don't have any apple_dynamic_framework_import in our codebase anymore (though we do have apple_dynamic_xcframework_import, which would also repro this)

I don't recall seeing this error in any recent memory.