chore: Add manually configured entitlement files and configurations

[armcknight]

These were added in #5208 but the entitlement files aren't actually needed for the test to pass.

#skip-changelog

[philprime]

To answer your questions in this PR comment.

• was something broken that this fixes? In the original fix(profiling): Change path of non-sandboxed macOS app launch profile configuration #5143 that introduced the mac app variants, i actually removed the entitlements file altogether and only set ENABLE_APP_SANDBOX = YES in the project's build settings and confirmed that was able to reproduce the issue, which I moved to the xcconfig files in the xcodegen refactor (ci: macos swift xcodegen #5170) so nothing was accidentally lost, you can see no entitlements file appears in that diff at all.

I was looking at sandbox settings due to the discovery of sentry-wizard#988, where we realized that the SentrySDK can not be used when sandbox is enabled without checking "Outgoing Connections (Client)".

That's when I realized that the Entitlements file where absent and that the App Sandbox settings where also not there where I expected to find them in Xcode:

So basically when checking out this PR, I am not able to use macOS-Swift-Sandboxed to perform tests with data being send to Sentry.

I was not aware that ENABLE_APP_SANDBOX exists as I am used to manage Info.plist and Entitlements as actual files instead of letting Xcode generate them from build settings. Thanks for that, will keep it in mind when fixing the wizard 👍

But to be able to use the Sentry SDK and have it actually send envelopes in a sandboxed macOS app, we will have to check the "Outgoing Connections (Client)" in the App Sandbox settings. Can we do that from the build settings as well, when using ENABLE_APP_SANDBOX?

• why does the entitlements file for macOS-Swift also have com.apple.security.app-sandbox set to ? actually, looking again, i think macOS-Swift.entitlements is simply unused, removing in

Ah yes, that file was a left-over from local testing and accidentally committed by me and missed in PR review. Thanks for pointing this out, that one should be removed as it isn't used.

why do we provide the entitlement files with the settings, but then also specify the setting again in the xcodegen spec?

see answers above

ETA: Ah I see what happened here, you checked in the generated files. Please don't commit multiple sources of truth to the repository as it can cause confusion and drift, as I mentioned in #5106 (comment)

That's why I reached out on Slack, as I wanted to circle back to you that it doesn't lead to a misunderstanding or perceives as undermining of the previous discussion. It wasn't entirely clear which files are checked in and which ones not:

File	Can be generated?	Is being generated?	Is ignored?
.xcodeproj	YES	YES	YES
Info.plist	YES	NO	NO
.entitlements	YES	NO	YES

[armcknight]

@philprime Thanks for the detailed response. I'm totally fine using entitlements for sandboxing and the outgoing client connection thing as I didn't know about the work being done around that.

My preference would be to check in an entitlements file and reference it with CODE_SIGN_ENTITLEMENTS in an xcconfig, instead of declaring the settings in the XcodeGen spec to have it generate an entitlements file, but I don't feel too strongly about this.

The one thing I will continue to request is, if we go the XcodeGen-managed route, that we don't check in the generated entitlements files.

Would you be ok with me modifying this PR as such, with checked in entitlements files with all the needed settings, and referencing them from the projects?

[philprime]

In that case let's treat it the same way as we do with Info.plist and will not generate the file using xcodegen and directly configure it using CODE_SIGN_ENTITLEMENTS.

Would you be ok with me modifying this PR as such, with checked in entitlements files with all the needed settings, and referencing them from the projects?

Yes, I can do that. I'll create an entitlements file for each, even if empty, and reference it accordingly.

[philprime]

@armcknight I went through all the configs and manually tested if I can configure capabilities from the Xcode UI

[github-actions]

Performance metrics 🚀

	Plain	With Sentry	Diff
Startup time	1233.92 ms	1246.45 ms	12.53 ms
Size	23.76 KiB	865.92 KiB	842.16 KiB

Baseline results on branch: main

Startup times

Revision	Plain	With Sentry	Diff
01a28a9	1225.55 ms	1249.96 ms	24.41 ms
8f212af	1246.41 ms	1270.98 ms	24.57 ms
c6a8035	1236.80 ms	1253.04 ms	16.24 ms
24e0744	1241.98 ms	1262.44 ms	20.46 ms
0f4071f	1212.80 ms	1239.22 ms	26.43 ms
bfe863d	1223.19 ms	1236.23 ms	13.04 ms
5bcb070	1223.38 ms	1246.45 ms	23.07 ms
4f848d0	1233.79 ms	1258.49 ms	24.70 ms
26530fe	1233.98 ms	1250.06 ms	16.08 ms
c0ff306	1218.92 ms	1240.64 ms	21.72 ms

App size

Revision	Plain	With Sentry	Diff
01a28a9	22.85 KiB	405.39 KiB	382.55 KiB
8f212af	22.84 KiB	403.14 KiB	380.29 KiB
c6a8035	22.31 KiB	780.90 KiB	758.58 KiB
24e0744	21.58 KiB	709.06 KiB	687.48 KiB
0f4071f	21.58 KiB	681.72 KiB	660.14 KiB
bfe863d	21.58 KiB	414.57 KiB	392.99 KiB
5bcb070	21.58 KiB	699.29 KiB	677.71 KiB
4f848d0	21.58 KiB	713.91 KiB	692.33 KiB
26530fe	21.58 KiB	714.93 KiB	693.35 KiB
c0ff306	20.76 KiB	434.65 KiB	413.89 KiB

[philprime]

As we @armcknight switched roles I take your enabling of the auto-merge as an "approval" for the changes, and actually approve this PR to get it merged.