Hi all,
I'm working on a use case where a customer checks in at a point of service (e.g., a cafeteria or restaurant) using their Apple Wallet pass (e.g., a digital employee badge).
In this scenario, we would like to use an iPhone (with a custom iOS app) as the NFC terminal to read the pass directly from the customer's iPhone over NFC.
I’m aware that "Tap to Pay on iPhone" allows NFC-based payment acceptance, but it’s unclear if similar functionality is available or permitted for reading access-type passes from another iPhone via NFC.
Key questions:
Is it technically possible for an iPhone to act as an NFC reader for a Wallet pass on another iPhone?
If not, is this restricted due to Secure Element isolation or protocol limitations?
Is there any Apple-supported path for building such a solution — or is certified external hardware (e.g., HID, Wavelynx) the only option?
I’ve reviewed the Core NFC and PassKit documentation but couldn't find a definitive answer.
Thanks in advance for your clarification!
Wallet
RSS for tagDiscuss how to manage tickets, boarding passes, payment cards and other passes in the Wallet app.
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
We requested the com.apple.developer.passkit.pass-presentation-suppression entitlement in our app to suppress the Apple Pay popup when our app is near a reader. This entitlement was approved by Apple and successfully suppresses Apple Pay popups when approaching readers.
Currently, we have another use case in the same app: presenting a PKPass (our door key pass) by calling the Wallet from our code using passLibrary.present(pass.secureElementPass!). This should take us to the Wallet and display our pass. This functionality works perfectly in other environments where this entitlement is not in place.
We now understand that this entitlement suppresses all passes from our app.
Our questions are:
How can we suppress the Apple Pay popup while displaying our app key against a reader and also present the pass in the Wallet?
Both requirements are essentially the same but implemented in two different ways, and we need both functionalities. Presenting the pass through a URL is not a viable option for us according to our standards.
(https://developer.apple.com/forums/content/attachment/c2542a51-fd2c-42ce-88a2-207689b31159)
I have implemented the functionality to open my app when double-tapping the side button on an iPhone. However, whenever I double-tap the side button, my app always opens on the login screen. Instead of this default behavior, I want my app to navigate directly to a specific view when launched through the side button action.
I am using SwiftUI and have already integrated HCE (Host Card Emulation) entitlements and also configured with contactless payment. How can I achieve this behaviour so that my app opens a specific screen instead of always showing the login page?
Any guidance on handling this within SwiftUI would be greatly appreciated. Thank you!
Topic:
App & System Services
SubTopic:
Wallet
Hi!
I have set up an APNS API that sends push notifications to update my Apple Wallet pass. I am using the APN library and a .p8 key for APNS push notifications. I keep getting 200 responses and "sent successfully" logs, but Apple Wallet is not receiving the notification.
Which configuration or payload should I check to make it work?
Thanks
We are currently developing a wallet solution that uses the iOS EEA HCE API. During the development of our solution we have been unable to identify how we can opt out of using the native HCE payment modal screen or biometric authentication UI so that we can customise the experience to align with our overall customer experience. The only available customisation is a label below the title of the screen which does not meet our needs.
Please can you advise how we can opt out of using the native HCE payment modal screen.
If it is not possible to opt out of using the native HCE payment modal screen, please can you provide the rationale for this given
the Digital Marketing Act interoperability guidelines and EU Commitments in case AT.40452.
Topic:
App & System Services
SubTopic:
Wallet
We are currently developing a wallet solution that uses the iOS EEA HCE API. During the development of our solution we have been unable to identify an API that allows us to evaluate the default contactless wallet state on the device.
Please can you advise how we can source this information that enables customers to be provided with accurate details of their default wallet state whilst they are using our wallet solution.
If this is not possible please can you provide the rationale for this given the Digital Marketing Act interoperability guidelines and EU Commitments in case AT.40452.
We are currently developing a wallet solution that uses the iOS EEA HCE API’s, during the testing of enabling our wallet as the system default wallet, we are being presented with an iOS system alert that states:
“Change the default contactless app? You can double-click to use cards in your default app. If Apple Wallet is not your default wallet app, you’ll need to open Wallet to use its cards, keys and tickets. Express Mode will continue to work when iphone is held near a compatible reader”
Please can you advise how we can prevent Apple Pay’s express mode from intercepting the customers preferred wallet actions including transit payments.
If this is not possible please can you provide the rationale for this not being possible given the Digital Marketing Act interoperability guidelines and EU Commitments in case AT.40452.
on a span of 4 months we sent 2 for nfc entitlement requests and refused , no reason nothing . i mean all we want is the ability to use nfc on passes nothing else , no idea why this is so complex . with google you don’t even need a developer account and it’s for free , here we pay and we can’t even get the full functionality the passes offer , we got the hardware and the solution but we find out we need an nfc entitlement to allow passes to have nfc ? i mean our use case is very simple instead of having barcode on the passes we want them to be via nfc and we already got the nfc hardware but we find out we need nfc entitlement which we tried requesting but getting refused with no reason at all. at least tell u what is the problem what how to fix it not outright refuse without any reason at all. if anyone got any solution please provide.
I am fallowing the steps mention here
https://developer.apple.com/wallet/get-started-with-verify-with-wallet/
and https://developer.apple.com/documentation/passkit/requesting-identity-data-from-a-wallet-pass
to run a POC in simulator but I am getting a crash
DigitalPresentmentSession requestDocument fatal error from xpc: This app has crashed because it called an API it is not entitled to use.
:0: Fatal error: This app has crashed because it called an API it is not entitled to use.
Hello,
I am facing a problem when trying to start the Wallet Extension Flow. It seems that even though the
override func status(completion: @escaping (PKIssuerProvisioningExtensionStatus) -> Void)
of the PKIssuerProvisioningExtensionHandler is called, the
override func passEntries(completion: @escaping ([PKIssuerProvisioningExtensionPassEntry]) -> Void)
is not called.
Note that this issue is reproduced in a device with iOS 18.1 whereas it is working correctly in a device with iOS 17.4.
Has something changed regarding the Wallet Extension in iOS 18.1 and above?
I am currently working on creating a digital wallet for Apple. While I am able to successfully generate the .pkpass file and verify its contents by changing the extension to .zip, I encounter an issue when attempting to open the .pkpass file on an iPhone—it displays the error "File format is not supported."
I validated the .pkpass file using https://pkpassvalidator.azurewebsites.net/, and the validation results indicate that everything is correct. Additionally, I manually verified the contents by extracting the zip file, and all the information appears to be in order.
I am unable to identify the root cause of this issue. Could you please provide guidance on what might be going wrong?
Topic:
App & System Services
SubTopic:
Wallet
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.
Hi,
To ensure the issue is not caused by an error within your app or web service request, please review the following documentation:
Wallet Passes
Wallet Developer Guide
If the resources above don’t help identify the cause of the error, please provide more information about your app or web services to get started. To prevent sending sensitive credentials in plain text, create a report in Feedback Assistant to share the details requested below. Additionally, if the error is something we need to investigate further, the appropriate engineering teams also have access to the same information and can communicate with you directly within Feedback Assistant for more information, as needed. Please follow the instructions below to submit your report.
For issues occurring with your native app or web service, perform the following steps:
Install the Wallet profile on your iOS or watchOS device.
Reproduce the issue and make a note of the timestamp when the issue occurred, while optionally capturing screenshots or video.
Gather a sysdiagnose on the same iOS or watchOS device.
Create a Feedback Assistant report with the following information:
The serial number of the device.
Open Settings > General > About > Serial Number (tap and hold to copy).
The SEID (Secure Element Identifier) of the device, represented as a HEX encoded string.
Open Settings > General > About > SEID (tap and hold to copy).
The sysdiagnose gathered after reproducing the issue.
The .pkpass file(s), pass signing certificate(s) and pass type identiifier(s) (optional).
The timestamp of when the issue was reproduced.
Screenshots or videos of errors and unexpected behaviors (optional).
Important: From the logs gathered above, you should be able to determine the cause of the failure from PassbookUIService, PassKit or PassKitCore, and by filtering for your SEID or pass type identifier in the Safari Web Inspector. See Inspecting Safari on macOS to learn more.
Submitting your feedback
Before you submit to Feedback Assistant, please confirm the requested information above is included in your feedback. Failure to provide the requested information will only delay my investigation into the reported issue within your Wallet pass implementation.
After your submission to Feedback Assistant is complete, please respond in your existing Developer Forums post with the Feedback ID. Once received, I can begin my investigation and determine if this issue is caused by an error within your web implementation, a configuration issue within your developer account, or an underlying system bug.
Cheers,
Paris X Pinkney | WWDR | DTS Engineer