macOS app not available for testing in TestFlight

[tipa]

Steps to Reproduce

1. Build .NET 6macOS app (dotnet publish -c Release)
2. Upload app package using Apple Transporter app

Expected Behavior

App becomes available for TestFlight.

Actual Behavior

The app is not available for TestFlight.

It is worth noting that the entitlements show up twice, which is likely related to this issue: #15632

My other MacOS (legacy Xamarin) apps (which also support both ARM64 and x68) have the entitlements only shown once in App Store Connect and the TestFlight works perfectly fine for them

Environment

These are my current build settings. Are they wrong? It's trial-and-error to find what out what is necessary to get the app building correctly...

Version information

Visual Studio Community 2022 for Mac
Version 17.3.6 (build 20)
Installation UUID: 80f56338-02fe-4236-b839-2593c8299102

Runtime
.NET 6.0.5 (64-bit)
Architecture: Arm64

Roslyn (Language Service)
4.3.0-3.22312.2+52adfb8b2dc71ed4278debcf13960f2116868608

NuGet
Version: 6.2.1.2

.NET SDK (Arm64)
SDK: /usr/local/share/dotnet/sdk/6.0.401/Sdks
SDK-Version: 6.0.401
MSBuild-SDKs: /Applications/Visual Studio.app/Contents/MonoBundle/MSBuild/Current/bin/Sdks

.NET Runtime (Arm64)
Laufzeit: /usr/local/share/dotnet/dotnet
Laufzeitversionen:
	7.0.0-rc.1.22426.10
	6.0.9

.NET Runtime (x64)
Laufzeit: /usr/local/share/dotnet/x64/dotnet
Laufzeitversion: 6.0.8

Xamarin.Profiler
Version: 1.8.0.19
Speicherort: /Applications/Xamarin Profiler.app/Contents/MacOS/Xamarin Profiler

Updater
Version: 11

Apple Developer Tools
Xcode 14.0.1 (21336)
Build 14A400

Xamarin.Mac
Version: 8.12.0.2 (Visual Studio Community)
Hash: 87f98a75e
Branch: d17-3
Build date: 2022-07-25 20:18:54-0400

Xamarin.iOS
Version: 16.0.0.72 (Visual Studio Community)
Hash: 6756a1146
Branch: release/6.0.4xx-xcode14
Build date: 2022-09-21 08:51:06-0400

Xamarin Designer
Version: 17.3.0.208
Hash: 0de472ea0
Branch: remotes/origin/d17-3
Build date: 2022-09-22 15:21:44 UTC

Xamarin.Android
Nicht installiert

Microsoft Build of OpenJDK
Java SDK: Nicht gefunden

Eclipse Temurin JDK
Java SDK: Nicht gefunden

Android SDK Manager
Version: 17.3.0.23
Hash: 965bf40
Branch: remotes/origin/d17-3
Build date: 2022-09-22 15:21:49 UTC

Android Device Manager
Version: 0.0.0.1169
Hash: fafb1d5
Branch: fafb1d5
Build date: 2022-09-22 15:21:49 UTC

Build Information
Release ID: 1703060020
Git revision: f7a6334599543f127e737d6de1f362bbe36cebca
Build date: 2022-09-22 15:19:46+00
Build branch: release-17.3
Build lane: release-17.3

Operating System
Mac OS X 12.6.0
Darwin 21.6.0 Darwin Kernel Version 21.6.0
    Mon Aug 22 20:20:05 PDT 2022
    root:xnu-8020.140.49~2/RELEASE_ARM64_T8101 arm64

Build Logs

timopartl@Timos-Mac-mini GeoPhoto.macOS % dotnet publish -c Release 
MSBuild version 17.3.1+2badb37d1 for .NET
  Determining projects to restore...
  All projects are up-to-date for restore.
  Detected signing identity:
          
    Code Signing Key: "Apple Distribution: Timo P (P9337B87X7)" (---)
    Provisioning Profile: "GeoPhoto MacOS Store" (2618369f-c239-4254-bbdc-b3f4f0f0eb26)
    Bundle Id: partl.geophoto
    App Id: P9337B87X7.partl.geophoto
  Detected signing identity:
          
    Code Signing Key: "Apple Distribution: Timo P (P9337B87X7)" (---)
    Provisioning Profile: "GeoPhoto MacOS Store" (2618369f-c239-4254-bbdc-b3f4f0f0eb26)
    Bundle Id: partl.geophoto
    App Id: P9337B87X7.partl.geophoto
  GeoPhoto.macOS -> /Users/timopartl/GitHub/geophoto/GeoPhoto.macOS/bin/Release/net6.0-macos/osx-x64/GeoPhoto.macOS.dll
  Optimizing assemblies for size, which may change the behavior of the app. Be sure to test after publishing. See: https://aka.ms/dotnet-illink
  Detected signing identity:
          
    Code Signing Key: "Apple Distribution: Timo P (P9337B87X7)" (---)
    Provisioning Profile: "GeoPhoto MacOS Store" (2618369f-c239-4254-bbdc-b3f4f0f0eb26)
    Bundle Id: partl.geophoto
    App Id: P9337B87X7.partl.geophoto
  GeoPhoto.macOS -> /Users/timopartl/GitHub/geophoto/GeoPhoto.macOS/bin/Release/net6.0-macos/osx-arm64/GeoPhoto.macOS.dll
  Optimizing assemblies for size, which may change the behavior of the app. Be sure to test after publishing. See: https://aka.ms/dotnet-illink
/usr/local/share/dotnet/packs/Microsoft.macOS.Sdk/12.3.447/tools/msbuild/macOS/Xamarin.Shared.targets(2053,3): warning : Code signing has been requested multiple times for 'bin/Release/net6.0-macos/publish/../GeoPhoto.macOS.app/Contents/MonoBundle/createdump', with different metadata. The metadata 'CodesignEntitlements' has different values for each item (once it's 'obj/Release/net6.0-macos/osx-x64/Entitlements.xcent', another time it's 'obj/Release/net6.0-macos/osx-arm64/Entitlements.xcent'). [/Users/timopartl/GitHub/geophoto/GeoPhoto.macOS/GeoPhoto.macOS.csproj]
  Created the package: /Users/timopartl/GitHub/geophoto/GeoPhoto.macOS/bin/Release/net6.0-macos/publish/GeoPhoto.macOS-1.1.12.pkg

Workload updates are available. Run `dotnet workload list` for more information.

[rolfbjarne]

I don't think the duplicated entitlements are the problem (they're not really duplicated, because the come from different executables, and that's an expected difference in .NET).

However, I wonder if it's because you're missing the com.apple.developer.team-identifier entitlement: does your legacy Xamarin app have the com.apple.developer.team-identifier entitlement?

Ref: https://developer.apple.com/forums/thread/689377

[ghost]

Hi @tipa. We have added the "need-info" label to this issue, which indicates that we have an open question for you before we can take further action. This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time.

[tipa]

@rolfbjarne there is indeed a difference with the com.apple.developer.team-identifier entitlement: My legacy apps do not show that entitlement (in the Apple portal) while this .NET6 app does.
In neither my legacy nor my .NET6 app I am specifying this entitlement in my Entitlements.plist file.

[tipa]

I also tried to add the com.apple.developer.team-identifier entitlement explicitly to the Entitlements.plist file and uploaded a new build, but it is as well marked as "Not available for testing".

[rolfbjarne]

I can reproduce this, it seems related to the createdump executable, possibly it shouldn't use the same entitlements as the main executable, but I still need to do some debugging to say for sure.

In any case, you should be able to stop us from adding the createdump executable to the app by adding something like this to the project file:

	<Target Name="RemoveCreateDump" BeforeTargets="_ComputePublishLocation" AfterTargets="ComputeFilesToPublish">
		<ItemGroup>
			<_CreateDump
				Include="@(ResolvedFileToPublish)"
				Condition=" '%(ResolvedFileToPublish.Filename)' == 'createdump' And
				            '%(ResolvedFileToPublish.Extension)' == '' And
				            '%(ResolvedFileToPublish.AssetType)' == 'native'
				            "
				PublishFolderType="Assembly"
			/>
			<ResolvedFileToPublish Remove="@(_CreateDump)" />
		</ItemGroup>
	</Target>

@tipa can you try that and see if it works?

[tipa]

Did that and uploaded a new build, which is now "Processing" since 2 hours. Will update my comment in case this changes.

[rolfbjarne]

Note to self: the problem is that the com.apple.application-identifier entitlement must not be set for the createdump executable.

[tipa]

Does the .NET 8 milestone mean that I should not expect to be able to test my .NET 6 macOS app via TestFlight before end of 2023 and better downgrade to legacy Xamarin?

[rolfbjarne]

@tipa the workaround didn't work for you?

[tipa]

At least for now (5 hours after upload) the app is still stock in the "Processing" status. So that's different from going to "Not available for Testing" but usually the processing doesn't take as long and my apps become available in TestFlight maybe 20 minutes after I uploaded them.
I can wait a bit longer and if nothing changes, do another rebuild and upload

[tipa]

I uploaded another build and this one it works and the app became available to test. Thanks for the workaround!

[charlesroddie]

Note: this issue duplicates dotnet/runtime#83613 but in the right repo

[rolfbjarne]

Note: this issue duplicates dotnet/runtime#83613 but in the right repo

This might be relevant:

Creatdump needs to have the following entitlements: main/eng/pipelines/common/createdump-entitlements.plist

dotnet/runtime#83613 (comment)

[rolfbjarne]

I looked into this, and it seems rather complicated to get createdump to work in a sandboxed environment (i.e. Mac App Store), so I'm instead adding a property to make it opt in:

<PropertyGroup>
    <BundleCreateDump>true</BundleCreateDump>
</PropertyGroup>

For the record, this is more or less what I found out:

• createdump has to be signed with a bundle identifier. It doesn't seem like the same bundle identifier as the main app can be used, although I wasn't able to confirm this (in any case it sounds like a bad idea to re-use the bundle identifier).
• createdump requires a few custom entitlements: https://github.com/dotnet/runtime/blob/main/eng/pipelines/common/createdump-entitlements.plist
• createdump would also need the sandbox entitlement to publish to the App Store (com.apple.security.app-sandbox).
• I'm not entirely sure whether a custom provisioning profile is required. If so, createdump would have to be put inside an app-like directory structure: https://developer.apple.com/documentation/Xcode/signing-a-daemon-with-a-restricted-entitlement. This is inconvenient, because CoreCLR expects createdump next to one of its dylibs. Maybe this can be worked around with a symlink?
• It seems that since a bundle identifier is required, an Info.plist must be embedded inside the executable, which is done when the executable is linked (by passing -sectcreate __TEXT __info_plist path/to/Info.plist to ld)... but we get the executable already linked from the runtime pack.

Also interesting: https://developer.apple.com/documentation/xcode/embedding-a-helper-tool-in-a-sandboxed-app

An alternative approach seems to be to embed the createdump functionality as a static library, and then potentially fork before generating the dump.

Ref: dotnet/runtime#84864
Ref: dotnet/runtime#89203

[tipa]

Has this bug been fixed with .NET8? I just updated to .NET8, removed the workaround, built & uploaded a new package using the "Transporter" app. The package was "delivered with warning":
"Cannot be used with TestFlight because the executable “${executable}” in bundle “${bundle}” is missing a provisioning profile but has an application identifier in its signature. Nested executables are expected to have provisioning profiles with application identifiers matching the identifier in the signature in order to be eligible for TestFlight." (90885)

Or do we now have to set the new BundleCreateDump property to true in order to be able to test apps via TestFlight?

Edit: I just tried to only use the BundleCreateDump property: the same warning after the upload shows and the app also shows as "not available for testing" in App Store Connect. So it appears to me that this problem hasn't been fixed and I still need to use the workaround

[rolfbjarne]

@tipa please try again with .NET 8 RC 2 which was just released.

Don't set BundleCreateDump=true: that's asking for the old (broken) behavior, not the new (fixed) behavior.

[tipa]

Now it works - thanks!!