-
Notifications
You must be signed in to change notification settings - Fork 514
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Enable codesigning by default in the simulator #18469
Comments
@ithiredguns if the problem occurs on device, then it's a different problem (because device builds are always signed, there's no way to install unsigned builds on device), so please open a new issue and attach a test project we can use to reproduce the problem. |
@rolfbjarne I am still having issues on the simulator ( as well as device) I am using pdf files ( for background and logo ) for my launch screen .... I have uploaded a test project for you to verify... Please help :) I have a deployment soon ... If pdf is the issue, can you give me a different workaround ? *** update**** |
If you look at the console log when you install the app, this shows up:
|
Wow ! Thanks for the feedback @rolfbjarne . What worked was changing the pdf images to png, shrinking the images and also, moving the images away from Assets.xcassets to Resources folder and updating the LaunchScreen.storyboard to reflect the new png files (instead of pdf) , delete the app & restarting the simulator, cleaning the iOS folder by deleting the bin & obj ... Looks like Apple restricts the size of LaunchScreen images to be less than 25 MB ... |
When I do this in Maui it forces me to use a developer certificate even when I just want to run on a simulator... Which I don't have right now... |
AFAIK there's no way around this right now if you want the launch screen to show up. When we fix this issue, we'll investigate and see if there's a way to implement code signing without requiring a developer account. |
Damn that sucks, anyways can you please update here once there is a solution for this or even a workaround i guess |
If I try to validate the signature of an app built for the simulator by Xcode it doesn't pass our code signing verification either, so it seems ignoring the verification step in this case is the right thing to do. |
I've experimented a bit with Xcode, and found the following:
|
We'll soon start signing simulator builds by default, and simulator apps aren't verifiable (with the default signing configuration), which means we'd need some new logic to determine when to verify the code signature and when not to. Ref #18469. Xcode doesn't do any signature verification during/after the build as far as I can see. And lastly, the verification doesn't really contribute anything important. For device builds, the app installation will fail anyway if the signature is incorrect (and if the signature is correct, and the verification is wrong, we failed the build for no good reason). For App Store builds, the app store will also complain if the signature isn't correct. So just remove the whole signature verification. Another bonus is that this will speed up the build. There's nothing faster than doing nothing at all! Partial fix for #18469. Fixes #10641.
We'll soon start signing simulator builds by default, and simulator apps aren't verifiable (with the default signing configuration), which means we'd need some new logic to determine when to verify the code signature and when not to. Ref xamarin#18469. Xcode doesn't do any signature verification during/after the build as far as I can see. And lastly, the verification doesn't really contribute anything important. For device builds, the app installation will fail anyway if the signature is incorrect (and if the signature is correct, and the verification is wrong, we failed the build for no good reason). For App Store builds, the app store will also complain if the signature isn't correct. So just remove the whole signature verification. Another bonus is that this will speed up the build. There's nothing faster than doing nothing at all! Partial fix for xamarin#18469. Fixes xamarin#10641.
I have tested on real iPad of browserstack, 11, 12 and 13 are OK with: <ItemGroup>
<MauiSplashScreen Include="Resources\storyboard1536x2048.svg" />
</ItemGroup> , but 14 and above give me black screen . on real iPhone, the same. Therefore, it is a problem in 14, 15 and 16, while the latest xcode supports only minimum 15. |
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:OK, let's try giving the build a code signing key:
No change!
what gets us passed that error is actually setting CodesignRequireProvisioningProfile=true, although it runs into another one:
So what actually makes the app build successfully is passing DisableCodesignVerification=true as well:
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:
Setting CodesignRequireProvisioningProfile=true got us passed these two issues, but there's a third:
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 deviceDisableCodesignVerification
: 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).The text was updated successfully, but these errors were encountered: