Improve the entitlements debug/release experience

[Redth]

Looking at recent changes to our MAUI templates:

https://github.com/dotnet/maui/blob/main/src/Templates/src/templates/maui-mobile/MauiApp.1.csproj#L64-L73

This is a bit verbose and would be preferable to not include in the templates by default.

How can we improve the implicit behaviour here?

Entitlements.Debug.plist

• com.apple.security.get-task-allow

I'm not sure exactly why this one was added... perhaps for debugging the webview, or maybe for secure storage API's in debug mode

Entitlements.Release.plist

• com.apple.security.app-sandbox
• com.apple.security.network.client

These are required for publishing catalyst apps to the store.

Proposal

1. Seems like a good time to introduce an item group of something like PartialEntitlementsPlist that allows multiple entitlements files to be added to the build to be merged together.
2. Is there a good reason not to implicitly merge the release plist items into a release maccatalyst build? It could always be conditioned on a flag that someone could override if they needed to.
3. Same goes for debug mode - can we implicitly merge the debug plist item, add a condition to not include them if it is explicitly set.

[rolfbjarne]

You can add custom entitlements without a plist using the CustomEntitlements item group.

So this:

https://github.com/dotnet/maui/blob/main/src/Templates/src/templates/maui-mobile/Platforms/MacCatalyst/Entitlements.Debug.plist

could be replaced with:

<ItemGroup Condition="$(TargetFramework.Contains('-maccatalyst')) and '$(Configuration)' == 'Debug'">
    <CustomEntitlements Include="com.apple.security.get-task-allow" Type="boolean" Value="true" />
</ItemGroup>

2. Is there a good reason not to implicitly merge the release plist items into a release maccatalyst build?

If the app is published through other means than the App Store, then those entitlements aren't needed (and maybe even just plain wrong).

One idea could be to introduce a helper property to indicate the app developer's intentions:

<PropertyGroup>
    <AppPublishingIntention>AppStore</AppPublishingIntention> <!-- we set defaults to make release work for the app store -->
    <AppPublishingIntention>AdHoc</AppPublishingIntention> <!-- we set defaults to make release work for adhoc publishing -->
    <!-- if not set, we'll guess something (which may or may not change in the future) -->
</PropertyGroup>

There's also the question of identifying a debug or a release or a publish build: it's been a point of friction for customers that we pivot on the Configuration, but nobody has come up with a better solution (dotnet/sdk#31918).

[aritchie]

@rolfbjarne Is this CustomEntitlements node documented anywhere? How do I set multiple values like the StringArray?

[rolfbjarne]

@aritchie no, it's not documented yet, but you can set a string array like this:

<ItemGroup>
    <CustomEntitlements Include="com.apple.security.get-task-allow" Type="stringarray" Value="a;b;c" />
</ItemGroup>

More details can be found here:

xamarin-macios/msbuild/Xamarin.MacDev.Tasks/Tasks/CompileEntitlementsTaskBase.cs

Lines 256 to 263 in 112318f

	// Possible values:
	// <ItemGroup>
	// <CustomEntitlements Include="name.of.entitlement" Type="Boolean" Value="true" /> <!-- value can be 'false' too (case doesn't matter) -->
	// <CustomEntitlements Include="name.of.entitlement" Type="String" Value="stringvalue" />
	// <CustomEntitlements Include="name.of.entitlement" Type="StringArray" Value="a;b" /> <!-- array of strings, separated by semicolon -->
	// <CustomEntitlements Include="name.of.entitlement" Type="StringArray" Value="a😁b" ArraySeparator="😁" /> <!-- array of strings, separated by 😁 -->
	// <CustomEntitlements Include="name.of.entitlement" Type="Remove" /> <!-- This will remove the corresponding entitlement -->
	// </ItemGroup>

[aritchie]

@rolfbjarne Much appreciated! This works better than docs anyhow

[zippo227]

<ItemGroup>
    <CustomEntitlements Include="com.apple.security.get-task-allow" Type="stringarray" Value="a;b;c" />
</ItemGroup>

@rolfbjarne Thank you. This helped me work through an issue where I had to use multiple entitlement files to support push notifications on iOS. Now I'm using the ItemGroup version here, and it works within my Github Action to build the maui app.

@aritchie There does seem to be some documentation of this feature here for maui blazor, though I'm using traditional maui. Add domain association entitlements to the app: https://learn.microsoft.com/en-us/aspnet/core/blazor/hybrid/routing?view=aspnetcore-8.0&pivots=maui#add-domain-association-entitlements-to-the-app

[aritchie]

@rolfbjarne one last issue I'm seeing -

<CustomEntitlements Include="keychain-access-groups" Type="StringArray" Value="$(AppIdentifierPrefix)com.mydomain" />

Obviously, $(AppIdentifierPrefix) is replaced to "" by msbuild. I tried an escape of %24(AppIdentifierPrefix) which did set the entitlement, but the teamID is never set. Manually entering the teamID here does work obviously, but isn't ideal. Thoughts?

Also - this customentitlement doesn't seem to be put on the simulator and causes crashes for MSAL based setups.