macOS: Xcode 15.3 build process makes Sentry.framework not universal when copying to the bundle

[grzegorzkrukowski]

Platform

macOS

Environment

Production, Develop

Installed

Swift Package Manager

Version

8.24.0

Did it work on previous versions?

It works with Xcode 15.2 using the same Sentry version

Steps to Reproduce

1. Set up a universal macOS application (or download my sample project)
2. Include the Sentry dependency through the SPM
3. After building the app, check in the Products that Contents/Frameworks/Sentry.framework/Versions/A/Sentry contains only single architecture x86_64, instead of being universal (lipo -info)

In the previous Xcode version (we were using 15.2) Sentry was not producing the Framework that would be copied to /Contents/Frameworks with the same project configuration. Now with Xcode 15.3, we get a Framework file that is copied in this step:

Copy ---/Contents/Frameworks/Sentry.framework ---/SourcePackages/artifacts/sentry-cocoa/Sentry/Sentry.xcframework/macos-arm64_x86_64/Sentry.framework

builtin-copy -exclude .DS_Store -exclude CVS -exclude .svn -exclude .git -exclude .hg -exclude Headers -exclude PrivateHeaders -exclude Modules -exclude \*.tbd -resolve-src-symlinks -remove-static-executable ---/SourcePackages/artifacts/sentry-cocoa/Sentry/Sentry.xcframework/macos-arm64_x86_64/Sentry.framework ---/Build/Products/Internal/MyApp.app/Contents/Frameworks

The source is properly a universal binary with a size of 8.4MB, but after copying it to the destination folder it is stripped to x86_64 only and it's just 24KB.

Interestingly enough - even after removing the framework everything works properly, so the framework that is being copied is just a few KB. It looks like a side effect of some Xcode 15.3 changes and something that should not happen.

Expected Result

I would expect the copied framework to support both architectures: arm64 and x86_64 or the framework should not be copied.

Actual Result

The copied binary is stripped to x86_64 for universal builds.

Are you willing to submit a PR?

No response

[grzegorzkrukowski]

Here are build logs from 2 Xcodes 15.2 and 15.3: xcode15.2.txt xcode15.3.txt

You can see that 15.2 is not copying the framework file to the bundle.

Also here is the project file I tested with. SentryTest.zip

[philipphofmann]

Interestingly enough - even after removing the framework everything works properly, so the framework that is being copied is just a few KB. It looks like a side effect of some Xcode 15.3 changes and something that should not happen.

@grzegorzkrukowski, it seems like it's working though. Have you tried archiving your app and running it on x86_64 and arm64? If everything works correctly, what is the problem? Maybe Xcode optimizes your build to reduce framework sizes.

[grzegorzkrukowski]

It is kinda working for single architecture builds - but for universal builds the binary that is being copied to Contents/Frameworks is x86_64 instead of universal.

And more interestingly this file is not being used as Sentry is statically embedded into our application binary as in Xcode 15.2. Whatever this file is - I dont think it should be there in the first place or it should be universal containing both arm64 and x86_64.

And optimization from 8MB to 24KB seems a bit off.

[philipphofmann]

@grzegorzkrukowski, as this changed from Xcode versions, why do you think it's a problem caused by the Sentry SDK? Do you see any problems with Sentry at runtime for universal builds?

[grzegorzkrukowski]

@grzegorzkrukowski, as this changed from Xcode versions, why do you think it's a problem caused by the Sentry SDK? Do you see any problems with Sentry at runtime for universal builds?

I tried that with 6 different dependencies and it's only Sentry having this weird artifact being generated in the process of changing the Xcode version - so I assumed that it may be related to some settings in the Sentry framework itself.

Universal builds in theory should be running properly as this framework is not being used as I said earlier. But our script validates if all frameworks in a Bundle are signed and have required architectures for each build and it fails there. In theory, we could delete the framework that is generated - but it feels hacky approach. It would be better if this project would not generate invalid files in a process - as I said I have more dependencies and none of them behaves like that - results are consistent for all of them across Xcode versions - only Sentry changes its output.

[philipphofmann]

Thanks for the update, @grzegorzkrukowski, and for answering all my questions. Now it makes sense to me. We have to investigate this.

[grzegorzkrukowski]

Thanks for the update, @grzegorzkrukowski, and for answering all my questions. Now it makes sense to me. We have to investigate this.

No problem - let me know if I can help any further - the attached project is already setup for universal so it should be really easy to reproduce the problem - but feel free to contact me directly in case there will be any further doubts / questions

[brustolin]

Hello @grzegorzkrukowski. Its seems to me that this is a side effect of using the static framework, and as far I have investigated this is why Sentry framework binary its so small.

When using Sentry-Dynamic

this is lipo output:

[HHuckebein]

I'm not sure whether this is related to the problem described above, but using Xcode 15.4 instead of 15.3 yields this error after a clean build for the simulator. Under Xcode 15.3 everything is fine.

Copy /Users/yx06488/Library/Developer/Xcode/DerivedData/XXXXX-bprvotukrdhscecjrbaqsrnlzssx/Build/Products/Debug_Development-iphonesimulator/meine-AOK.app/Frameworks/Sentry.framework /Users/XXXXX/Library/Developer/Xcode/DerivedData/XXXXX-bprvotukrdhscecjrbaqsrnlzssx/SourcePackages/artifacts/sentry-cocoa/Sentry/Sentry.xcframework/ios-arm64_x86_64-simulator/Sentry.framework (in target 'XXXXX' from project 'XXXXX') cd /Users/yx06488/Developer/Apps/XXXXX builtin-copy -exclude .DS_Store -exclude CVS -exclude .svn -exclude .git -exclude .hg -exclude Headers -exclude PrivateHeaders -exclude Modules -exclude *.tbd -resolve-src-symlinks -remove-static-executable /Users/XXXXX/Library/Developer/Xcode/DerivedData/XXXXX-bprvotukrdhscecjrbaqsrnlzssx/SourcePackages/artifacts/sentry-cocoa/Sentry/Sentry.xcframework/ios-arm64_x86_64-simulator/Sentry.framework /Users/yx06488/Library/Developer/Xcode/DerivedData/XXXXX-bprvotukrdhscecjrbaqsrnlzssx/Build/Products/Debug_Development-iphonesimulator/XXXXX.app/Frameworks

note: Injecting stub binary into codeless framework (in target 'XXXXX' from project 'XXXXX') /Applications/Xcode-15.4.0-Release.Candidate.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -isysroot /Applications/Xcode-15.4.0-Release.Candidate.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator17.5.sdk -dynamiclib -Xlinker -adhoc_codesign -x c /dev/null -o /Users/yx06488/Library/Developer/Xcode/DerivedData/XXXXX-bprvotukrdhscecjrbaqsrnlzssx/Build/Products/Debug_Development-iphonesimulator/meine-XXXXX/Frameworks/Sentry.framework/Sentry -target arm64-apple-ios9999-simulator clang: error: invalid version number in '-target arm64-apple-ios9999-simulator'

[brustolin]

@HHuckebein, your Xcode 14 problem was solved with https://github.com/getsentry/sentry-cocoa/pull/3958 and will be available in the next release.

[brustolin]

This issue may be closed cause it was explained in this comment.

[HHuckebein]

Thank you.