ITMS-90078: Missing Push Notification Entitlement when building with iOS SDK 17.5.8018

[velocitysystems]

trafficstars

Steps to Reproduce

CI/CD builds from Azure Pipelines for our MAUI application have begun producing .ipa's with the following warning:

ITMS-90078: Missing Push Notification Entitlement - Your app appears to register with the Apple Push Notification service, but the app signature's entitlements do not include the 'aps-environment' entitlement. If your app uses the Apple Push Notification service, make sure your App ID is enabled for Push Notification in the Provisioning Portal, and resubmit after signing your app with a Distribution provisioning profile that includes the 'aps-environment' entitlement. Xcode does not automatically copy the aps-environment entitlement from provisioning profiles at build time. This behavior is intentional. To use this entitlement, either enable Push Notifications in the project editor's Capabilities pane, or manually add the entitlement to your entitlements file. For more information, see https://developer.apple.com/library/content/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/HandlingRemoteNotifications.html#//apple_ref/doc/uid/TP40008194-CH6-SW1.

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:

macOS 13
Current image version: 20240728.2
Microsoft.iOS.Sdk version 17.2.8078
Microsoft.Maui.Sdk version 8.0.61

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

[rolfbjarne]

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?

[velocitysystems]

Thanks @rolfbjarne. How can I securely provide these to you?

[rolfbjarne]

@velocitysystems the easiest is probably to use a file sharing service like Dropbox and then you can send the sharing link to me ([email protected]).

[velocitysystems]

Thanks @rolfbjarne. Emailed you just now.

[rolfbjarne]

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?

[velocitysystems]

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?

[rolfbjarne]

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.

[rolfbjarne]

I've identified a change which may be the cause of this problem, and a fix is in progress.

[velocitysystems]

Thanks @rolfbjarne. We also notice this warning in the log output:

You've implemented -[<UIApplicationDelegate> application:performFetchWithCompletionHandler:], but you still need to add "fetch" to the list of your supported UIBackgroundModes in your Info.plist.

[rolfbjarne]

Thanks @rolfbjarne. We also notice this warning in the log output:

You've implemented -[<UIApplicationDelegate> application:performFetchWithCompletionHandler:], but you still need to add "fetch" to the list of your supported UIBackgroundModes in your Info.plist.

Yes, that might have the same underlying cause.

[enclave-marc-barry]

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 dotnet build output).

[LSMartijn]

Same problem here, not able to upload to apple store

[rolfbjarne]

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?

[velocitysystems]

@rolfbjarne I can confirm this is only a warning for us when submitting an update to our app.

[LSMartijn]

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?

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

[FranRDev]

I've identified a change which may be the cause of this problem, and a fix is in progress.

Hello, when will the fix be available? @rolfbjarne

[janusw]

For us, the ITMS-90078 warning started appearing when we moved to .NET SDK 8.0.400 (from 8.0.303) AFAICS.

[rolfbjarne]

I've identified a change which may be the cause of this problem, and a fix is in progress.

Hello, when will the fix be available? @rolfbjarne

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.

[enclave-marc-barry]

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?

[DDHSchmidt]

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.

[janusw]

For us, the ITMS-90078 warning started appearing when we moved to .NET SDK 8.0.400 (from 8.0.303) AFAICS.

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 ...

[rolfbjarne]

For us, the ITMS-90078 warning started appearing when we moved to .NET SDK 8.0.400 (from 8.0.303) AFAICS.

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.

[enclave-marc-barry]

@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.

[janusw]

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.

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!

[rolfbjarne]

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:

1. Download https://gist.github.com/rolfbjarne/74b27a48abcf1812618e8e63909a74dd and save to rollback.json

2. Run in a terminal:

   $ sudo dotnet workload install ios --from-rollback-file rollback.json
   

[janusw]

Try this:

1. Download https://gist.github.com/rolfbjarne/74b27a48abcf1812618e8e63909a74dd and save to rollback.json

Awesome, thank you. Since the file is rather compact, I'll just paste it here for persistence:

{
  "microsoft.net.sdk.android": "34.0.113/8.0.100",
  "microsoft.net.sdk.ios": "17.2.8022/8.0.100",
  "microsoft.net.sdk.maccatalyst": "17.2.8022/8.0.100",
  "microsoft.net.sdk.macos": "14.2.8022/8.0.100",
  "microsoft.net.sdk.maui": "8.0.72/8.0.100",
  "microsoft.net.sdk.tvos": "17.2.8022/8.0.100",
  "microsoft.net.workload.mono.toolchain.net7": "8.0.0/8.0.100",
  "microsoft.net.workload.mono.toolchain.current": "8.0.0/8.0.100",
  "microsoft.net.workload.emscripten.net7": "8.0.0/8.0.100",
  "microsoft.net.workload.emscripten.current": "8.0.0/8.0.100"
}

2. Run in a terminal:
   ```shell
   $ sudo dotnet workload install ios --from-rollback-file rollback.json
   ```

This command only seems to install/downgrade the ios workload, so I assume the above json file is a bit overblown for the purpse here and could actually be reduced to:

{
  "microsoft.net.sdk.ios": "17.2.8022/8.0.100"
}

Is that correct?

[rolfbjarne]

This command only seems to install/downgrade the ios workload, so I assume the above json file is a bit overblown for the purpse here and could actually be reduced to:

{
  "microsoft.net.sdk.ios": "17.2.8022/8.0.100"
}

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).

[enclave-marc-barry]

Thanks @rolfbjarne - just to ask, what would be the recommended way to roll back out of this once a fix is released?

[rolfbjarne]

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.

[last-Programmer]

we have this issue with .net 9 rc also. will there be a fix in .net 9 rc also?