We are implementing a feature that uses PKPassLibrary.requestAutomaticPassPresentationSuppression to prevent the Wallet from appearing when unlocking a lock. We have already completed the approval process for the entitlement to enable Pass Presentation Suppression.
In most cases, our code snippet works as expected, and the result is .success. However, we are also encountering other results, such as .denied, .alreadyPresenting, and .cancelled or .notSupported, which cause the Wallet to appear for users.
Here's the code snippet we're using:
PKPassLibrary.requestAutomaticPassPresentationSuppression { result in
logger.log(
.info,
"PKPassLibrary suppression result: \(result.description)",
LogContext.homeFeature
)
}
I would appreciate clarification on the following points:
-
What's the meaning of each result type (.denied, .alreadyPresenting, .cancelled, .notSupported) beyond what is mentioned in the documentation? The documentation here does not provide additional details.
-
What is the recommended handling for these specific result states? Should we be taking different actions or retries based on each case?
Thank you very much for your help. Best, Ramiro.
You wrote:
In most cases, our code snippet works as expected, and the result is .success. However, we are also encountering other results, such as .denied, .alreadyPresenting, and .cancelled or .notSupported, which cause the Wallet to appear for users. [...]
As @EtienneVTS mentioned, the API is intended to be used while an approved app is in the foreground. However, this requirement is indeed documented below:
Use this method only in apps that must stay in the foreground when operating near NFC or other RF readers. This method prevents the device from automatically displaying the Apple Pay passes when it detects a compatible reader. This suppression occurs only while the app is in the foreground. The system automatically reenables the Apple Pay interface when the app goes to the background. If the app resumes, the system automatically suppresses the Apple Pay interface again.
requestAutomaticPassPresentationSuppression(responseHandler:)
Next, you wrote:
[...] 1. What's the meaning of each result type (.denied, .alreadyPresenting, .cancelled, .notSupported) beyond what is mentioned in the documentation? The documentation here does not provide additional details.
Understood. I've filed an internal bug (r. 159316709) to get these updated. Please see the following for more info about the intended behaviors:
- The
.deniedresult may be returned as the result of a missing entitlement or misconfigured provisioning profile, or when the app has performed the request in the background. - The
.alreadyPresentingresult may be returned if passes are already presented from the user's library and cannot be suppressed. - The
.cancelledresult may be returned if pass suppression was cancelled by the user before the response handler was invoked. - The
.notSupportedresult may be returned if pass suppression is not supported for the requesting device.
Then, you wrote:
[...] 2. What is the recommended handling for these specific result states? Should we be taking different actions or retries based on each case?
Please see the code snippet below as a guide:
func handleApplicationDidBecomeActiveOrDidEnterForeground() {
// 1. App is in the foreground.
// 2. Confirm pass library exists.
if PKPassLibrary.isPassLibraryAvailable() {
// 3. Store suppression request token.
self.pkSuppressionRequestToken = PKPassLibrary.requestAutomaticPassPresentationSuppression { result in
// 4. Handle suppression results
if result == .success {
// …
} else {
// …
}
}
} else {
// 5. Pass library and pass suppression unavailable.
}
}
func handleApplicationDidEnterBackground() {
// 6. End pass suppression of NFC detection.
if let token = self.pkSuppressionRequestToken {
PKPassLibrary.endAutomaticPassPresentationSuppression(withRequestToken: token)
}
}
There are no other actions or retries to attempt if Automatic Pass Presentation Suppression is implemented correctly. However, if you have any other issues or questions, please let me know.
Cheers,
Paris X Pinkney | WWDR | DTS Engineer
