Enable codesigning by default in the simulator #18469
Comments
|
Didn't work for Xamarin Forms adding the above in property Group .. Also, I signed the App with a Distribution Certificate and with an AdHoc Profile and distributed it through AppCenter ... It still has the black splash screen blackScreen.mp4 |
|
@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 dotnet#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 dotnet#18469. Fixes dotnet#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. |
|
FYI: Despite years of developing in .Net for iOS (at first via Xamarin Native / iOS), I had trouble recently getting Splash Screen to work. Posted a StackOverflow Q & A with the steps that I went through: Using .Net 8 for iOS [NOT MAUI], add a LaunchScreen with logo image and background color. There is a reference in that, back to this issue, which solved one of the problems. |
|
@ToolmakerSteve Hey, you got this working somehow? |
Yes. Added answer: https://stackoverflow.com/a/79565661/199364 BOTTOM LINE: Rofl's lines to "fake" code-sign work, to show on simulator. To get the storyboard file correct, I used Xcode to create a tiny native app (Swift app, specifying "storyboard" for LaunchScreen). Used Xcode's UI to modify LaunchScreen.storyboard. (There's an auto-constraint button somewhere at bottom, that sets the constraints to fill the screen minus "safe" margins.) Copied LaunchScreen.storyboard from that, into my project's Troubleshooting: Sometimes simulator fails to show updated launch screen. (Including not showing the change from "black screen" to "now I have the needed files - works on device".) I list various steps that might be needed. Launch screen is tricky, because device or simulator seems to cache for each app that has been run. Power off/on helps. CAVEAT: the "fake" code-signing (for Debug build) may not work on a physical device. CAVEAT # 2: I Seem to need certificate on both mac and pc. (Might be related to how this Apple team was originally set up.) Still trying to get a good "recipe" for the certificate+provisioning process. However, once it works for a device attached via USB to the Mac (Building on PC via Pair to Mac), then getting it to work on simulator now seems to be easy, by changing to those "fake" code-sign lines. |
When building for the simulator: * Signing is enabled by default. * Any entitlements the app requests will be embedded in the native executable in an `__ents_der` Mach-O section. * The actual app signature only demands the "com.apple.security.get-task-allow" entitlement. * No provisioning profiles are used. Also: * Unify the code to detect signing identity, so that it's as equal as possible between our platforms. Fixes #18469.
Enable signing by default for all platforms, because that's what Xcode does. This fixes an issue for simulator builds, where certain features don't work unless the app is signed (#18469). It also simplifies and unifies our code to detect signing identities, so that it's much more shared/equal beteween platforms. However, simulator builds have a few peculiarities: * The placeholder code signing certificate ("-", or what Xcode calls "Sign to Run Locally") is always used. * Any entitlements the app requests will be embedded in the native executable in a Mach-O section named `__ents_der`. * The actual app signature only demands the "com.apple.security.get-task-allow" entitlement (which seems to be allowed without a provisioning profile when using the placeholder code signing certificate). * No provisioning profiles are used. In order to provide a fairly decent way of restoring old behavior (not signing simulator builds), I created a public property to determine whether we're building for the simulator (SdkIsSimulator), and added documentation on how to use this new property to disable code signing. Fixes #18469.
Enable signing by default for all platforms, because that's what Xcode does. This fixes an issue for simulator builds, where certain features don't work unless the app is signed (#18469). It also simplifies and unifies our code to detect signing identities, so that it's much more shared/equal beteween platforms. However, simulator builds have a few peculiarities: * The placeholder code signing certificate ("-", or what Xcode calls "Sign to Run Locally") is always used. * Any entitlements the app requests will be embedded in the native executable in a Mach-O section named `__ents_der`. * The actual app signature only demands the "com.apple.security.get-task-allow" entitlement (which seems to be allowed without a provisioning profile when using the placeholder code signing certificate). * No provisioning profiles are used. In order to provide a fairly decent way of restoring old behavior (not signing simulator builds), I created a public property to determine whether we're building for the simulator (SdkIsSimulator), and added documentation on how to use this new property to disable code signing. Fixes #18469.
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=truedoesn'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:
EnableCodeSigningdefaults to true for device, so nothing changes.CodesignRequireProvisioningProfilealso 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: