-
Notifications
You must be signed in to change notification settings - Fork 198
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
Publish a Mac Catalyst app to the App Store #938
Comments
@davidbritch, I have done the steps outlined here except that in step 5 I am using Transporter. My .pkg file uploads successfully to the AppStore. However, I get an email that says I need to correct issues. Below is one and the others are basically the same. BTW, I am using the Publish/Publish to Folder in VSMac to create the .pkg. So far I have been unable to create and Archive for Publishing that will upload to the AppStore either in VS or XCode. Could you give me a pointer as to what to try next? ITMS-90238: Invalid Signature - The executable at path CacheAll.app/Contents/MonoBundle/libSystem.IO.Compression.Native.dylib has following signing error(s): valid on disk /Volumes/workspace/app_data/SWValidationService/mz_9428053241116182122dir/mz_11292165874503355173dir/com.CacheAll.pkg/Payload/CacheAll.app/Contents/MonoBundle/libSystem.IO.Compression.Native.dylib: satisfies its Designated Requirement test-requirement: code failed to satisfy specified code requirement(s) . Refer to the Code Signing and Application Sandboxing Guide at http://developer.apple.com/library/mac/#documentation/Security/Conceptual/CodeSigningGuide/AboutCS/AboutCS.html and Technical Note 2206 at https://developer.apple.com/library/mac/technotes/tn2206/_index.html for more information. |
Hi @cdavidyoung I'd recommend trying again without using VSMac to do the publish. The whole reason the docs don't use VSMac is that, AFAIK, it hasn't been updated to publish MacCat apps. It's Mac publishing functionality is for Xamarin.Mac/.NET for Mac rather than MacCat. So I'd recommend trying again using the CLI (make sure you start with a clean solution - delete your bin/obj folders). Then see if you get the same outcome. You may well do, but at least we'll know that it's not a problem caused by VSMac doing the publish. |
Hi @davidbritch Thanks for the suggestion. I am getting the same response email from the AppStore. Below is my CLI output. charlesyoung@Mac-mini-M1-CDY jiffyLog2 % dotnet publish -f:net7.0-maccatalyst -c:Release
Detected signing identity:
jiffyLog -> /Users/charlesyoung/Projects/jiffyLog2/bin/Release/net7.0-maccatalyst/maccatalyst-x64/CacheAll.dll
jiffyLog -> /Users/charlesyoung/Projects/jiffyLog2/bin/Release/net7.0-maccatalyst/maccatalyst-arm64/CacheAll.dll Workload updates are available. Run |
Have you tried running the published app locally? Run the .pkg, install the app and launch it. I'd be interested to know if it works. |
@davidbritch, partial success! In looking back at your email I realize that I had forgotten to clean solution - delete bin/obj folders. I did that, increased the bundle number, did the publish command, and delivered it to the store with Transporter. Now the build is sitting in TestFlight Ready to Submit. However, when I install it with TestFlight on my Mac it will not run and instead gives me a crash report log. I try to run the app directly from the release folder and it says it cannot be run. The installation of the .pkg gives the same result. When I go back to the Debug version it runs fine in the debugger. However, when I build with the Release configuration the option to run without debugging does not start the app. So it seems there is something wrong with the Release build that prevents it from running. I think that once we get it to run from VS the actual delivery to the AppStore should result in a successful deployment. Do you think it would make a difference to build it from CLI as well as publish from CLI? |
@cdavidyoung Which linking mode are you using? None, SdkOnly, or Full? |
That shows it for the debug configuration. What about the release config? |
It is exactly the same for Release. Link Framework SDKs Only. |
So just confirming: you have |
No. I assumed this is the default because there is no such line in the .csproj file. If you want me to add it can you give me the context so I can put it in the right place? |
You should have something in your .csproj like: <PropertyGroup Condition="'$(Configuration)|$(TargetFramework)|$(Platform)'=='Release|net7.0-maccatalyst|AnyCPU'">
<MtouchLink>SdkOnly</MtouchLink>
<EnableCodeSigning>True</EnableCodeSigning>
<EnablePackageSigning>true</EnablePackageSigning>
<CreatePackage>true</CreatePackage>
<CodesignKey>Apple Distribution: John Smith (AY2GDE9QM7)</CodesignKey>
<CodesignProvision>MyMauiApp</CodesignProvision>
<CodesignEntitlements>Platforms\MacCatalyst\Entitlements.plist</CodesignEntitlements>
<PackageSigningKey>3rd Party Mac Developer Installer: John Smith (AY2GDE9QM7)</PackageSigningKey>
</PropertyGroup> |
My line was Now my Release configuration is
I did a clean Release build in VSMac and it still won't run when I double click on the app. I did not try to publish it because I assume it will crash in FlightTest as well. |
So just to be clear, when you run your Release build from VSMac or
double-click the app in the Release folder, it runs, right?
On Tue, Mar 28, 2023 at 9:06 AM Charles David Young <
***@***.***> wrote:
… Well, you got me there. I had only done a clean all in VSMac.
So I did the clean all again and this time deleted the bin/obj folders.
Then it won't build until I quit VS and reopen the project so that it can
restore the nugets. Finally, it builds but it still won't run when I
double click on the app in the Release folder, saying "The application
"CacheAll" can't be opened."
On Tue, Mar 28, 2023 at 8:52 AM David Britch ***@***.***>
wrote:
> Clean release build meaning you deleted bin/obj?
>
> —
> Reply to this email directly, view it on GitHub
> <#938 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAHE7KZRFRGKRVSWM24IGSDW6MCLVANCNFSM6AAAAAAQZR4ZUM>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>
|
It is an M1, which I assume is Arm.
…On Tue, Mar 28, 2023 at 9:07 AM David Britch ***@***.***> wrote:
Is your Mac an Intel CPU or an Arm CPU?
—
Reply to this email directly, view it on GitHub
<#938 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAHE7KYXODIZRJEEMA7NCATW6MEEXANCNFSM6AAAAAAQZR4ZUM>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
@davidbritch , just to be clear, you can run the Release version of your app either from the local .pkg or after installing from FlightTest? Or have you yet to overcome this hurdle? |
I completely forgot that you're doing an App Store publish. The issue is that you can't launch an executable that's code-signed with a distribution cert ( |
Yes, I've uploaded an app to App Store Connect, pulled it down via TestFlight and been able to run it. |
@davidbritch, I am really confused. Do you want me to create a cert that is Apple Development that requires that I upload a Certificate Signing Request (CSR) file from my Mac? I would be able to run the resulting .pkg on my Mac? I would then upload it to the App Store/TestFlight, Apple would sign it, and then I could download from TestFlight and run it? |
@cdavidyoung No. You're signing the app correctly, using an Apple Distribution certificate, for Mac App Store deployment. The point is that once you sign the app with that certificate, you won't be able to run it locally. Instead, when you upload it to App Store Connect, Apple will re-sign it to enable local execution. So then when you download it from TestFlight you should be able to run it locally (provided there aren't other issues). |
@davidbritch. Hmm, so you are using an Apple Distribution certificate and after uploading it to the Mac App Store you can download it from TestFlight and it runs? Mine doesn't but runs fine under debug config. So I am uncertain how to discover why it is crashing under release.
|
@davidbritch, that is what I get. I can study the report but should I not get a crash under debug config if there was really something I could fix? I'll post the report if you like. |
@davidbritch Here is the crashed thread. It is some sort of privacy violation. I can't image why this would only happen in the release config. Thread 5 Crashed:: Dispatch queue: com.apple.root.default-qos |
In looking at the app output when I run in debug mode I see something suspicious when thread #5 starts. I wonder if this is what could be causing the "privacy violation" from FlightTest. Thread started: #3 |
Provided the app launches in debug mode, you don't need to worry about debug mode. Looking at the stack trace for release mode, we can see
What's in your Entitlements.plist file? |
@davidbritch Here is my Entitlements.plist. Also, I got rid of the runtime warnings in debug when thread #5 ran. Still, when I build in release and upload to FlightTest and install that on my Mac it now quietly quits. I don't even get the crash report.
|
@davidbritch I have studied https://learn.microsoft.com/en-us/dotnet/maui/ios/entitlements?view=net-maui-7.0 but don't see any additional entitlement that I might need. I am also wondering why I am not getting a crash report, or at least I can't find it. Are you working with others that are having similar problems with the MacCatalyst deployment to the App Store? |
Your entitlements look good. I was just checking you had |
Here's my thinking, so you know where I'm coming from. TCC_CRASHING_DUE_TO_PRIVACY_VIOLATION usually occurs because the app is attempting to access privacy-sensitive data without a usage description for it in Info.plist. So depending on what you're app is actually doing (maps, location, file system, photos, camera etc.) you may well be missing an Info.plist entry. It's often the case that they aren't required for debug builds, but are for release builds. |
Something else to try is to comment out the PropertyGroup in your .csproj for your release config, to stop the code-signing etc. Then run a freshly built release build (having deleted bin/obj first) and see if you get anything that indicates a missing Info.plist key/description. |
@davidbritch Here is my Info.plist file. It has the same list of access that my iOS app has that is currently live on the App Store. Thanks for all your help, BTW! This stuff is so confusing. As far as maps, location, file system, photos, camera, etc, yes I do them all in this app. I also record and play audio. Looking at your last recommendation, after I do the release build do you mean you want me to try and publish it to the App Store?
|
@davidbritch So I commented out the PropertyGroup in my .csproj for my release config and I was able to Start Without Debugging. It would not allow me to Start Debugging. This is an improvement, but it runs perfectly normally with no hint of a a missing Info.plist key/description. I was able to take a photo and record audio without a problem. Of course, the GPS does not work on the Mac but the standard Apple map comes up fine and plots markers of photos that I have recorded with my iPhone. |
@davidbritch Here is the change to the .csproj file with the release commented out. The debug config runs fine in the debugger.
|
@davidbritch So I am still trying to figure out why the FlightTest app is quietly quitting without a crash report. I just want to point out that I think I initially addressed the TCC_CRASHING_DUE_TO_PRIVACY_VIOLATION when I fixed the thread #5 crash which was apparently caused by a xaml problem. As you suggested, commenting out the release configuration allows the app to run fine locally. So it must have something to do with the provisioning, right? Apple is just not signing it in a way that allows it to run from FlightTest. |
The following entries aren't required in your release config:
I noticed you were using the hardened runtime last week, but didn't think it would be necessarily causing a problem. Then I read this: "The Hardened Runtime is a collection of system-enforced restrictions that disable a set of functional capabilities, such as loading third-party frameworks, and prohibit access to restricted resources, such as the device’s built-in camera, to prevent certain classes of exploits from compromising the runtime integrity of your macOS app. If your app relies on something the Hardened Runtime restricts, you remove that specific protection by adding an entitlement to your app’s entitlements file. Xcode’s Hardened Runtime capability provides an easy way to manage those entitlements." - from https://developer.apple.com/documentation/xcode/configuring-the-hardened-runtime So because you've enabled the hardened runtime, you've disabled the ability to access the camera. Your app wants that access which maybe what's causing your privacy violation. |
Also, in your Info.plist:
Should just be:
In fact, the UIDeviceFamily definition in your Info.plist file prevented me from even uploading an app to the App Store with Transporter (at the same time, I don't have the hardened runtime enabled for my app). |
@davidbritch Thanks for the new things to try. I can report a little bit of progress. At least now when it crashes it gives me a crash report! Of course I did a clean all and deleted obj/bin before doing the publish. dotnet publish -f:net7.0-maccatalyst -c:Release It looks like I am missing a library. Here is my config and a snippet from the crash report.
Crashed Thread: 0 Exception Type: EXC_CRASH (SIGABRT) Termination Reason: Namespace DYLD, Code 1 Library missing Thread 0 Crashed: |
@davidbritch xamarin/xamarin-macios#14686 covers this issue. There seems to be a solution but I am a little unsure how to implement it. |
@davidbritch I tried to implement their fix but I am still getting the same error. Perhaps I am not putting the 2 lines in the right place?
|
You need to completely remove:
|
@davidbritch I tried removing those lines and I also tried using the config recommended in the link below but I am still getting the same "security policy does not allow @ path expansion" error. I think I am going to start over at the beginning of this doc and go through the whole process again. Perhaps I made a mistake the first time. |
@davidbritch So I spent all day yesterday following the instructions in your doc but I am still getting the same error. There are some confusing parts to the doc where I may be making the wrong decisions. I'll describe them as a new issue on the doc page. |
At the moment the publish a Mac app doc is CLI only, for unsigned apps.
The story for Mac Catalyst publishing is that it's not possible on Windows, but it is possible on a Mac. However, it's not currently possible as an end-to-end scenario in VSMac. The solution is:
This approach requires an Apple Distribution certificate, and a Mac Installer certificate.
Create a doc that covers distribution to the App Store using this approach.
Note: this distribution channel is only an option for individual Apple accounts.
Associated WorkItem - 66534
The text was updated successfully, but these errors were encountered: