we are currently using the requestAutomaticPassPresentationSuppression API in my app. to prevent the Wallet interface from appearing when an NFC/RF reader is detected during active app usage.
Recently, a new transit card supporting Express Mode (T-money Transit Card) was released in Korea, and we are seeing an increasing number of users enabling Express Mode.
However, this has introduced an issue where users are unable to use the BLE-based functionality we provide via our widget. Specifically, when the user taps our widget, it triggers a BLE signal broadcast for approximately 10 seconds. In this scenario, when the user brings their iPhone close to our reader, Express Mode is activated before the BLE interaction can be established. This prevents the BLE signal from being successfully received and processed.
We would like to ask:
-
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?
We would appreciate any guidance or best practices you can share regarding this scenario.
Thank you.
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 requirements).
That said, even if suppression were possible, widgets introduce additional limitations:
- WidgetKit extensions run in a restricted sandbox with no access to PKPassLibrary suppression APIs.
- Widget taps trigger either a URL launch (widgetURL / Link) or an App Intent, both of which transition to the app, but there is a latency window before the app is fully foregrounded.
- During that transition window, Express Mode has already engaged if the device is near an NFC reader.
I'd suggest for you to submit a Feedback Assistant report explaining your use case and technical conflicts—your business need is legitimate and should be reviewed. Once submitted, please reply with the Feedback ID so I may escalate to the Wallet and Core NFC engineering teams directly.
As a workaround, you should guide your users to hold the phone near the reader after the BLE handshake is established, rather than simultaneously:
- Add a visual indicator in your widget/app showing "Connecting via BLE..." followed by "Ready — tap now" or similar.
- This separates the BLE establishment phase from the NFC proximity phase.
However, if you control the reader hardware:
- Delay NFC field activation until after the BLE connection is established.
- Use BLE as the primary communication channel and only active the NFC reader once BLE confirms readiness.
- This way the NFC field is not present when the user first approaches.
Lastly, instead of broadcasting BLE directly from the widget tap, consider using the widget to launch your full app, stable the BLE connection, and then prompt the user to tap. This doesn't suppress Express Mode, but it ensures BLE is established before the user brings the phone near the NFC field.
Cheers,
Paris X Pinkney | WWDR | DTS Engineer
