Enable codesigning by default in the simulator · Issue #18469 · dotnet/macios (original) (raw)

It seems the simulator won't load launch screens unless the app is signed.

Ref: https://dev.azure.com/devdiv/DevDiv/_workitems/edit/1834468

Since most apps have launch screens, it might make sense to enable code signing in the simulator by default.

Note: we should look into what Xcode does if you don't have a Developer Account.

However, some additional testing might be required, because simply setting EnableCodeSigning=true doesn't work as expected:

$ dotnet build /p:EnableCodeSigning=true [...] error : The "Codesign" task was not given a value for the required parameter "SigningKey", nor was there a "CodesignSigningKey" metadata on the resource [...]

OK, let's try giving the build a code signing key:

$ dotnet build /p:EnableCodeSigning=true /p:CodesignKey='Apple Development: Rolf Kvinge (CZ9YXM2X9A)' [...] error : The "Codesign" task was not given a value for the required parameter "SigningKey", nor was there a "CodesignSigningKey" metadata on the resource [...]

No change!

what gets us passed that error is actually setting CodesignRequireProvisioningProfile=true, although it runs into another one:

$ dotnet build /p:EnableCodeSigning=true /p:CodesignRequireProvisioningProfile=true [...] _CodesignVerify: /usr/bin/codesign --verify -vvvv "-R=anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.1] exists and (certificate leaf[field.1.2.840.113635.100.6.1.2] exists or certificate leaf[field.1.2.840.113635.100.6.1.4] exists)" bin/iPhoneSimulator/Debug/TestLaunchScreen.iOS.app bin/iPhoneSimulator/Debug/TestLaunchScreen.iOS.app: valid on disk bin/iPhoneSimulator/Debug/TestLaunchScreen.iOS.app: satisfies its Designated Requirement test-requirement: code failed to satisfy specified code requirement(s) error MSB6006: "codesign" exited with code 3.

So what actually makes the app build successfully is passing DisableCodesignVerification=true as well:

$ dotnet build /p:EnableCodeSigning=true /p:CodesignRequireProvisioningProfile=true /p:DisableCodesignVerification=true [...]

From looking at the source code, this is what happens (don't take this as truth, it needs verification when implementing any fixes) for the simulator in the DetectSigningIdentity task:

• If a provisioning profile is needed, then the task will report '-' as the signing identity.
  • Bug A: Even if a specific signing identity was specified. I'm not sure if's ever a valid thing to pass a specific signing identity on the simulator though, testing would be needed in XCode
• If a provisioning profile is not needed, then the task will not return anything as the signing identity.
  • Bug B: Even if a specific signing identity was specified. This is rather odd behavior no matter how you look at it - if a signing identity is always wrong for the simulator, then at least a warning should be reported, otherwise the signing identity should be used.

Setting CodesignRequireProvisioningProfile=true got us passed these two issues, but there's a third:

• Bug C: the signing process does not produce a verifiable app bundle when using '-' as the signing identity, so we should probably skip the CodesignVerify task in that case (or adjust what's verified).

TLDR;

Add the following to the csproj to work around this:

This should work on device as well:

• EnableCodeSigning defaults to true for device, so nothing changes.
• CodesignRequireProvisioningProfile also defaults to true for device
• DisableCodesignVerification: assuming the code signing configuration in the project is correct, it shouldn't matter that the verification is skipped (and if it's broken, the app will fail to install on device anyways).