“nfc”

Thank you — that's helpful, and we want to confirm we understand the NFC & SE Platform correctly before pursuing it, because our data flow may differ from what NFC & SE states in the documentation: Users of eligible iOS apps can initiate NFC transactions from within the app with compatible NFC terminals. To be precise about our use case: in our app, the iPhone is the reader. The end user taps their own physical contactless payment card to their iPhone, and our app reads the card's EMV response data (e.g. the application cryptogram and related ICC data) for account verification. This is not a payment, and the iPhone is not presenting a credential to a terminal. Outstanding question: Does the NFC & SE Platform provide any capability for an iPhone to act as the reader — i.e. to read EMV data from a physical card tapped to the iPhone — or is the platform limited to the iPhone presenting a provisioned Secure Element credential to an external terminal? If NFC

An alternative solution for interacting with payment cards if you are not eligible for NFCPaymentTagReaderSession is the NFC & SE Platform for secure contactless transactions which has a broader regional availability, but may have other kinds of restrictions. You can find out whether you would be eligible or that solution is feasible for your use case at the link above.

Hi @Gijunius, You wrote: [...] Is it possible to suppress Express Mode behavior (similar to requestAutomaticPassPresentationSuppression) even when the app is launched via a widget interaction [...] Alternatively, is there any way to delay or defer Express Mode activation temporarily when launching from a widget or during BLE communication? [...] No, Express Mode can't be suppressed programmatically, regardless of whether the app is launched from a widget or directly. This is a fundamental distribution from the Automatic Pass Presentation Suppression behavior. The requestAutomaticPassPresentationSuppression(reason:) API only suppresses the Wallet UI from appearing when an NFC field is detected. It doesn't suppress Express Mode transactions because: Express Mode operates at the Secure Element/NFC controller live, below the operating system. The transaction completes in hardware without any OS or app involvement. This is by design for reliability (transit gates have sub-second timing requiremen

Hi @JakeHess, You wrote: [...] Sometimes ATQB response also comes from the iPhone or iWatch instead of the ATQA response, and then it causes the transit reader to report as collision error in the polling. [...] When the ECP 2.0 frame is received, the iPhone/Apple Watch NFC controller begins activating the Express Transit card emulation profile. During this transient activation window (typically a few milliseconds), the NFC controller's card emulation layer is not yet fully configured to the target technology type (Type A for EMV). As a result: The NFC controller may briefly respond to both WUPA and WUPB solicitations The spurious ATQB is emitted during this intermediate state On the next polling cycle the controller has settled, and only ATQA is returned The reader's anti-collision logic then sees responses on both Type A and Type B in the same discovery loop, interprets this as multiple targets or a collision, and flags an error. Important: First confirm the ATQB is truly originati

HI @bandejapaisa, @marosoaie88, Do you both still need help with this? The page below was updated with the test AIDs and configuration values some time ago: HCE-based contactless NFC transactions for apps in the European Economic Area (EEA) https://developer.apple.com/support/hce-transactions-in-apps/ However, it is expected for you to provide your own proprietary AIDs, not payment network AIDS in your .entitlements file. Cheers, Paris X Pinkney |  WWDR | DTS Engineer

Hi @Pekovic, You wrote: [...] Is it possible for our app to coexist with Apple Wallet as the default contactless app, so that: [...] Yes—full coexistence is expected. Your app and Apple Wallet are on completely independent routing paths. Setting your app as the Default Contactless App has no effect on Apple Pay. To avoid the behavior you've observed in Wallet passes, you need to start your NFC session before the iPhone gets close to the reader. Pass suppression won’t work, because it will suppress your app too. To learn more, please see my answer on the post below: HCE issues https://developer.apple.com/forums/thread/789477?answerId=893671022#893671022 Then, you wrote: [...] Will the system still need to launch our app into the foreground to complete a transaction (e.g., to emulate the NFC card)? [...] Or is there a way to trigger HCE responses in the background (e.g., using a background process or service extension)? No, background HCE is possible on iOS — but requires the Default Contactle

Thanks for the post. Very interesting and also will be good to know exactly what you are trying to accomplish so I’ll know how to reply in detail of what you need to but I’m guessing you already look at this documentation https://developer.apple.com/help/app-store-connect/offer-app-clip-experiences/offer-an-advanced-app-clip-experience/ There are many engineers here that can help answer all your questions in better detail than my answers here. Advanced App Clip Experiences are specifically designed for physical and location-based invocations: NFC tags, visual codes like QR codes,, Maps, and Siri location-based suggestions. They are not used to populate rich links in Messages. Messages intercepts the URL, recognizes the domain is associated with an App Clip, and queries App Store Connect directly for the App Clip's experience metadata to render the special App Clip link bubble. It ignores Advanced Experience routing tables for this visual rendering. When Safari presents an App Clip card or Smart App B

Hi @Valdemar01, You wrote: We have a working solution but there is one issue - if our application is not selected as default NFC application our users may see Wallet popup when there's no active presentment intent in our application. I didn't find in documentation any information how to stop Wallet from activating. I found there's requestAutomaticPassPresentationSuppression method in PassKit, it requires special permission, however I am not sure if it can be used in this situation, as there's no information how it will impact HCE communication in our application. [...] The pass presentation suppression managed entitlement and its API family does not interact with HCE communication at all as they are on completely separate layers of the system. The NFC routing logic is completely independent of the PassKit UI layer. Suppressing Wallet's pass presentation does not clear or modify the AID routing table, nor affect background NFC emulation, and does not impact whether your app is foregr

Hi @Arasuvel, @Pannir_selvam38, You wrote: In most cases, this works as expected and the Wallet popup does not appear. However, in some cases — particularly when the app is running in the foreground — the Wallet still appears for users. [...] Could you please help us understand under what conditions this behavior might still occur, or if any additional configuration is required? The most common reason for this reported behavior is the app process not retaining the memory of the PKSuppressionRequestToken returned by PKPassLibrary.requestAutomaticPassPresentationSuppression(responseHandler:) For example: // ❌ WRONG — token is released and deallocated when this function returns func activate() { PKPassLibrary.requestAutomaticPassPresentationSuppression { token, result in // token is scoped to this closure and lost after } } // ✅ CORRECT — token lives as long as the manager object class MyNFCCoordinator { private var suppressionToken: PKSuppressionRequestToken = 0 func activate() { suppressionToken = PKPassLibrar