@tipa do we have any workaround of it?

@tipa i think we must need the feature to have multiple entitlements for different build configuration.

@qasimmajeed my .csproj looks something like this:

  <ItemGroup>
    <AdditionalAppExtensions Include="../native">
      <Name>ShareExtension</Name>
      <BuildOutput Condition="'$(ComputedPlatform)' == 'iPhone'">build/$(Configuration)-iphoneos</BuildOutput>
      <BuildOutput Condition="'$(ComputedPlatform)' == 'iPhoneSimulator'">build/$(Configuration)-iphonesimulator</BuildOutput>
    </AdditionalAppExtensions>
  </ItemGroup>

The native folder is where I have my xcodeproj. My .entitlements files are placed directly in that folder (not in subfolders of it, where it is placed by default when creating a new project in XCode).

@tipa Thanks i have done the same thing from my side and its working as expected. I am just wondering if we have the build configuration different for staging or dev environment how the entitlement will work for the same because they could have different key chain group, so is there any way that we can define the different entitlements here to pick it from the root directory basis on the build configuration?

I'm struggling with this again today. It would be great if we could manually specify the entitlements path manually. In my case I have a widget extension that I want to share between iOS and macOS, but since it requires two different entitlement files (e.g. macOS needs sandbox entitlement while iOS doesn't), I also need to maintain two different extension projects in Xcode, in order to get two different "product names" (.appex files), one for iOS and one for macOS

@tipa can you try changing your local version of Xamarin.Shared.targets like this:

https://gist.github.com/rolfbjarne/cfe67a2735339725330549824023ddbf

This should make it possible to set the CodesignEntitlements property on your AdditionalAppExtensions item to the path of the entitlements file for that app extension.

@rolfbjarne where is that file located? Is it possible to "overwrite" the target in just my project folder (e.g. in my csproj) without having to edit files from the toolchain that might change again as I update .NET workloads?

Adding this to the csproj might work (by overriding the existing target we ship):

https://gist.github.com/rolfbjarne/637575e393f78e08a28869aa464a9361

I added that snippet into my csproj (as direct child of Project) but it seems to be ignored completely, unless I am doing something wrong. E.g. I renamed my appex file on the file system and made the same name change to the snippet, when building it still tries to copy the original appex file (from %(AdditionalAppExtensions.Name).appex) and errors out

Can you upload a binlog of your build?

In case someone else faces the same problem, I was able to workaround it. Instead of forcing the .NET toolchain to pick another .appex or entitlements file, I provide a PRODUCT_NAME when building it in the command line - this will create WidgetExtensionMac.appex in my case:

xcodebuild -project ../native/myswiftapp.xcodeproj -configuration Release PRODUCT_NAME=WidgetExtensionMac -target WidgetExtension -sdk macosx

@tipa thank you, how do you get it signed from .xcodeproj config? I've been trying to add a simple sticker extension via xcodebuild but then spctl -a -vv iOS.app/iOS invalidates the whole bundle no matter if I re-sign it or not (and this is the check the App Store uses on uploads)

@ivmirx I have set the Entitlement in Xcode but you could probably also do that in the call to xcodebuild

But then .NET re-signs your package when building your app (if it finds your Entitlements file!)

A fix is in progress, which:

• Documents the AdditionalAppExtensions item group a little bit better + all the supported metadata.
• Adds support for a CodesignEntitlements metadata, so you can choose your own location for the entitlements for an app extension.
• Warns if no entitlements are set for an app extension.