-
Notifications
You must be signed in to change notification settings - Fork 510
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
ITMS-90078: Missing Push Notification Entitlement when building with iOS SDK 17.5.8018 #21002
Comments
Would you be able to provide the before and after .ipa files so that we can try to compare to see what triggers this change? |
Thanks @rolfbjarne. How can I securely provide these to you? |
@velocitysystems the easiest is probably to use a file sharing service like Dropbox and then you can send the sharing link to me (Rolf.Kvinge@microsoft.com). |
Thanks @rolfbjarne. Emailed you just now. |
I can confirm I got the email and was able to download the .ipas. I believe this is not preventing you from publishing the app (since it's a warning), is that correct? |
Thanks @rolfbjarne. That is correct but we would ideally like to resolve the issue as soon as possible. Will it be fixed in an upcoming service release? |
I don't know yet, once I've figured out what's causing this I'll be able to say more. |
…ces if we're registering protocols in the static registrar. Pending: * Update docs * Tests * Stats for size improvements This might be the fix for #21002.
I've identified a change which may be the cause of this problem, and a fix is in progress. |
Thanks @rolfbjarne. We also notice this warning in the log output:
|
Yes, that might have the same underlying cause. |
Thanks @rolfbjarne - just to flag we've noticed the same two warnings flagged by our maui ios build of enclave.io (ITMS-90078 email from Apple after upload to testflight, and the add "fetch" to .plist from |
Same problem here, not able to upload to apple store |
According to the original issue description, this particular issue is a warning, and shouldn't block the App Store submission. Can you post your entire rejection message? |
@rolfbjarne I can confirm this is only a warning for us when submitting an update to our app. |
I'm sorry, it is indeed a warning, it shows in the store with a warning: Missing Compliance And I get an email with the message as shown above. ITMS-90078: Missing Push Notification Entitlement - Your app appear..... etc |
Hello, when will the fix be available? @rolfbjarne |
For us, the |
Not in the next/upcoming service release (too late for that), but hopefully in the next one. Unfortunately I can't be much more specific at this point. |
Thanks for the update @rolfbjarne. Open question to everyone watching this thread- has anyone pushed to the appstore with this warning, has it generated any back pressure or app review activity from Apple for you? |
Just published a new app version on the store today despite the warning and no, no noticeable repercussions yet. Keeping my fingers crossed and following this issue very closely. |
…ces if we're registering protocols in the static registrar. Pending: * Update docs * Tests * Stats for size improvements This might be the fix for #21002.
…tructor for protocol interfaces if we're registering protocols in the static registrar. (#21162) When we implemented support for using default interface members for binding protocols, we also unintentionally introduced a size regression. This happened because we now tell the linker to keep all methods in a protocol interface, thus all the corresponding types end up marked as well, etc. This had an additional side effect: depending on the types that weren't linked away anymore, the App Store could flag an app, saying that additional entitlements is needed. This is what's happening in #21002: the App Store detects that the app references the `application:didRegisterForRemoteNotificationsWithDeviceToken:` selector [1] (from the method `RegisteredForRemoteNotifications` on `IUIApplicationDelegate`) and tells the developer they probably need the push notification entitlement. The good news is that we don't need these protocol interface methods at runtime if the optimization to register protocols with the static registrar is enabled (which it is by default). In this PR I teach the optimizer to remove the DynamicDependency attributes keeping these protocol interface methods from being trimmed out. ## Size improvements * monotouch-test build for Release/ios-arm64 shrinks by [2.9mb (-2.6%)](https://gist.github.com/rolfbjarne/5e8ca6ea6854dc4a46f8e838dff11e6b) * A very simple app (tests/dotnet/MySimpleApp) shrinks by [176kb (-0.3%)](https://gist.github.com/rolfbjarne/f0e062900528eb499fd96d124d18376f) [1]: This is somewhat speculative, but it's probably not far from what the App Store actually does. Fixes #21002. Backport of #21012
Can anyone confirm that this issue only affects .NET SDK versions 8.0.4xx, but not 8.0.3xx? If this is indeed the case, then reverting to 3xx might be a viable workaround until a proper fix is available ... |
No, it won't, because the culprit here is the latest version of the iOS workload, which is the same for both 8.0.4xx and 8.0.3xx (and 8.0.2xx and 8.0.1xx for that matter). That said, we can provide a workload rollback file, which can be used to downgrade your workloads if need be. Please let us know if this is what you need. |
@rolfbjarne I think it depends on what action Apple are likely to take, if any. If they do start rejecting updates, and the fix is going to be a few months coming then a rollback file might be helpful. However, from the activity on this thread it doesn't look like there's been any back pressure from Apple yet over the warning. That said, we've not tried a release since this issue surfaced, so for us this remains a bit of an unknown. |
If this is the only workaround, then yes, I'd be interested in having a short rollback-file snippet with the correct workload versions that are needed to fix it. Thank you, @rolfbjarne! |
Try this:
|
Awesome, thank you. Since the file is rather compact, I'll just paste it here for persistence:
This command only seems to install/downgrade the
Is that correct? |
Potentially, if you only use the iOS workload. If your project uses Mac Catalyst, Android, MAUI, etc. then you might need the other workloads too (not necessarily because they're broken, but because the specific mix of workload versions you might end up having on your machine are not working well together. The rollback file contains a set of well-known versions that are supposed to work well together). |
Thanks @rolfbjarne - just to ask, what would be the recommended way to roll back out of this once a fix is released? |
I believe "sudo dotnet workload update" should work. Note that the fix isn't in the service release that came out yesterday, but it should be in the next one. |
we have this issue with .net 9 rc also. will there be a fix in .net 9 rc also? |
Yes, the next RC (RC 2), will have the fix. |
Steps to Reproduce
CI/CD builds from Azure Pipelines for our MAUI application have begun producing .ipa's with the following warning:
The application does not have a "Push Notification Entitlement".
No changes have been made to entitlements, profile etc.
No code changes have been made.
Began happening on 7 August 2024 when we bumped to macOS 14 / Xcode 15.4 and
dotnet workload install
began installing the latest SDK version. Builds from the day before did not generate any warnings with the following configuration:Expected Behavior
An ITMS-90078 warning should not be produced.
Actual Behavior
An ITMS-90078 warning is produced with Microsoft.iOS.Sdk 17.5.8018.
Environment
Azure Pipelines:
macOS-14
(20240804.1)Xcode 15.4
Microsoft.iOS.Sdk 17.5.8018
Microsoft.Maui.Sdk 8.0.71
The text was updated successfully, but these errors were encountered: