Background Modes Capability Missing in App ID Configuration

Background modes aren’t gated by an entitlement, they configured via the UIBackgroundModes property in your Info.plist.

the com.apple.developer.location.always and com.apple.developer.location.background entitlements.

These are not real entitlements. I suspect you’ve been mislead by an LLM hallucination )-:

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

UIBackgroundModes was already configured in info.plist:

Entitlement provisioning is not an LLM hallucination it's part of the error message:

Automatic signing failed

Xcode failed to provision this target. Please file a bug report at <https://feedbackassistant.apple.com> and include the Update Signing report from the Report navigator.

Provisioning profile "iOS Team Provisioning Profile: [app id]" doesn't include the com.apple.developer.location.always and com.apple.developer.location.background entitlements.

As far as I understand there should be a capability for background modes in the App ID Configuration.

UIBackgroundModes was already configured in info.plist:

Great! That's all you need to do.

Entitlement provisioning is not an LLM hallucination it's part of the error message:

Yes, I'm afraid it is. Let me start with the error message here:

Automatic signing failed

Xcode failed to provision this target. Please file a bug report at <https://feedbackassistant.apple.com> and include the Update Signing report from the Report navigator.

Provisioning profile "iOS Team Provisioning Profile: [app id]" doesn't include the com.apple.developer.location.always and com.apple.developer.location.background entitlements.

Structurally, code signing entitlements involve comparing a list of keys/values from two different sources:

1. The entitlements embedded in your app code signature, which come from your entitlements plist.

2. The entitlements in the embedded provisioning profile, which came from our developer portal.

Critically, that also means that failures can accurately be described in two different ways:

1. The entitlement file defines a key which is not in the provisioning profile.

2. The provisioning profile does not include a key which the entitlement file defines.

Note that BOTH of those descriptions are completely accurate, however, Xcode generally prefers the second description over that first. That's because, for most errors, the solution is to modify the portal configuration to include what ever is "missing".

However...

As far as I understand there should be a capability for background modes in the App ID Configuration.

No, that's not true.

The ONLY thing you need to do to enable background location updates is include "location" in your "Background Modes" Info.plist key. More specifically:

• The "location" background mode was introduced in iOS 4, dating from a kinder, simpler time. At that point we made VERY limited use of code signing entitlements, certainly nothing like we do today. It does not require any specific entitlement and never has.

• The specific entitlements "com.apple.developer.location.always" and "com.apple.developer.location.background" simply do not exist and NEVER have.

One clarification that might help explain this:

When I go to Apple Developer Portal > Identifiers > [select App ID] > Edit, the option for “Background Modes” is missing from the list of capabilities.

The term "Capabilities" is a term that was invented after the fact by Xcode when it's interface consolidated a number of totally unrelated technical mechanisms like:

1. Entitlements

2. Specific Info.plist keys (notably, "Background Modes")

3. Non-entitlement based build and code signing configuration (like App Sandbox and the hardened runtime).

None of those technologies have any real relationship with each other. Xcode lumps them together as "Capabilities" because they're somewhat conceptually similar ("allow/make may app do <insert description>") and because that's how it chose to make it's interface work. However, ONLY #1 involves the developer portal.

Finally, completing the circle, our documentation and the portal have now started referring to "Entitlements" as "Capabilities". This was done so that the portal and Xcode are using the same vocabulary. It's also correct in the sense that "All Entitlements are Capabilities". However the reverse, "All Capabilities are Entitlements", is NOT correct, which is what makes this confusing.

Finally:

These are not real entitlements. I suspect you’ve been mislead by an LLM hallucination )-:

As Quinn said, this was almost certainly caused by an LLM hallucination, as those values simply do not exist in our system. Indeed,the first value doesn't even makes sense in terms of how CoreLocation actually works.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Thank you for your detailed response!

The issue was indeed caused by a redundant backup location entry in the entitlement file.

After removing it and keeping the definition only in the info.plist, everything worked.

In my case, i specified all these but then the VOIP notification doesnt come when the device is in the background mode or terminated mode. The callkit service is not called when the app is in the background mode or terminated mode.

First off, let me quickly expand on what I said here:

The ONLY thing you need to do to enable background location updates is include "location" in your "Background Modes" Info.plist key.

That statement is also true of voip apps, except that they should include the "voip" and "audio" Background Modes. Note that failing to include "audio" doesn't cause an immediate failure, but can cause weird/unpredictable behavior, particularly across the broader range of iOS version. Critically the word "ONLY" here is important, as voip app signing is identical to any other standard iOS app.

Moving to your push failure, are you receiving voip pushes through PushKit when your app is in the foreground? If you are, then issues like this:

In my case, i specified all these but then the VOIP notification doesnt come when the device is in the background mode or terminated mode.

...are caused by logic problem in your app. The details of what that might actually be vary but some examples I've seen are:

• Assuming the user will always "login" manually before the service becomes active. That won't happen if an app launches into the background.

• Tying the PushKit initialization process to the details of view initialization sequence (which may not happen the same way in a background launch).

• Tying PushKit initialization to things like "network checkin" which may not always succeed.

Note that these issues will eventually cause PushKit delivery to stop entirely, due to the iOS 13 CallKit requirements.

Finally one point to understand here:

The callkit service is not called when the app is in the background mode or terminated mode.

One point that sometimes trips up new voip developers is that CallKit UI makes it look like the system is FAR more involved with voip calls than it actually is. Fundamentally, CallKit is best understood as very specialized user interface framework. EVERYTHING it does, it does because YOUR app told it to do that. It doesn't "make calls", it presents the system call screen because that what YOUR app told it to do.

Expanding on that last point, our CallKit sample effectively implements a "full" voip implementation (including PKPushRegistry)... except that it doesn't do ANY networking or actually allow the user to "talk" to anyone. It's basically using CallKit to implement a fake call app, which neatly illustrates my point that the system doesn't really have any idea what your app is actually "doing". In any case, if its helpful you can use that to validate that your push infrastructure works and sort out signing issues.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware