Hello I am implementing an NFC Reader session in my app, and presenting the bottom sheet works completely fine. However, I am facing an issue with screen rotation. If I rotate the device while the NFC bottom sheet is active, the sheet does not adapt or resize according to the new screen orientation. Is there a way to force the NFC bottom sheet to update its layout or fix this rotation issue?Any help or workarounds would be greatly appreciated. Thanks!

Hello I am experiencing a layout issue where UI components overlap in a bottom sheet during screen rotation while an NFC Reader session is active. The NFC Reader session initializes and displays the bottom sheet properly. However, if the device is rotated while this sheet is on screen, the layout breaks, and elements appear overlapped. I have attached a sample image demonstrating this rendering issue. Is there a known workaround to fix this layout distortion or force a proper layout update during an active NFC session?Any insights or suggestions would be greatly appreciated. Thanks!

I developed an app that uses the Core NFC framework to read tags. The feature works correctly on iOS 18 and earlier versions, but after upgrading to iOS 26, it stopped working. Details: Entitlement Near Field Communication Tag Reader Session Formats D2760000850101 D2760000850101 Info.Plist com.apple.developer.nfc.readersession.iso7816.select-identifiers D2760000850101 com.apple.developer.nfc.readersession.felica.systemcodes 12FC Privacy - NFC Scan Usage Description Signing and Capabilities: Near Field Communicating Tag Reading [Eanbled] My Sample Code Is: class NFCManager: NSObject, NFCTagReaderSessionDelegate { private var nfcSession: NFCTagReaderSession? let isConnectionNeeded = false func startNFCSession() { guard NFCTagReaderSession.readingAvailable else { // NFC is not available on this device. return } nfcSession = NFCTagReaderSession(pollingOption: [.iso14443, .iso15693, .iso18092], delegate: self) nfcSession?.begin() } func stopNFCSession() { nfcSession?.invalidate() } // MARK: - NFCTagReaderSessionDelegate Methods func tagReaderSessionDidBecomeActive(_ session: NFCTagReaderSession) { print("tagReaderSessionDidBecomeActive") } func tagReaderSession(_ session: NFCTagReaderSession, didInvalidateWithError error: Error) { print("didInvalidateWithError --\(error)") } func tagReaderSession(_ session: NFCTagReaderSession, didDetect tags: [NFCTag]) { print("didDetect: Tag Detected --\(tags)") } } The above code works fine on iOS 18 and earlier versions for detecting tags. Please let me know if I’m missing anything. Please help me to resolve the issue in iOS 26

We are developing a non-custodial cryptocurrency wallet app with the following characteristics: Architecture: Users hold their own private keys at all times (we never custody any assets). The app includes identity credential verification: KYC-verified identity data (Verifiable Credentials / DID-based) is exchanged between the payer's iPhone and a counterparty device for identity verification purposes. NFCTagReaderSession is used only to exchange identity credential data via our proprietary, non-payment ISO 7816 AID with the counterparty device. Cryptocurrency transactions are submitted entirely over the internet (blockchain RPC), completely independent of the NFC session. NFC is NOT used to: Transmit cryptocurrency or payment instructions. Interact with any EMV payment AID or Secure Element. Replace or emulate Apple Pay or any payment card. Jurisdiction & licensing context: The app is being developed by a Japanese company for initial launch in Japan. While this question is posted from an individual Developer account for inquiry purposes, the app itself will be submitted under an appropriate Organization Developer account of the operating company, in compliance with Guideline 3.1.5(a)(ii). We are working with Japanese legal counsel to obtain any applicable Japanese financial-services license (e.g., 電子決済手段・暗号資産サービス仲介業 / Electronic Payment Instruments and Crypto-Asset Service Intermediary Business under the 2023-amended 資金決済法 / Payment Services Act) prior to App Store submission, and a written legal opinion will accompany the submission. We are not seeking to qualify as a 暗号資産交換業 (crypto-asset exchange) or 資金移動業 (funds transfer service operator), as our non-custodial design is intended to fall outside those categories under Japanese law. Question: Under Guideline 3.1.5, does a non-custodial wallet that uses NFCTagReaderSession solely for identity credential data exchange (not for transmitting cryptocurrency or payment instructions over NFC) fall under the "Wallets" sub-category — requiring an Organization Developer account only — or does NFC involvement for identity verification shift it toward a sub-category requiring additional licensing, entitlements, or financial institution credentials?

Hi, I am trying to build a very simple iOS app in Xcode that starts an NFCNDEFReaderSession when I press a button. My goal right now is only to verify that the NFC reading process starts correctly on a real iPhone. I am not trying to publish the app on the App Store. When I try to start the session, I get this error in the console: -[NFCHardwareManager areFeaturesSupported:outError:]:435 XPC Error: Error Domain=NSCocoaErrorDomain Code=4099 "The connection to service named com.apple.nfcd.service.corenfc was invalidated: Connection init failed at lookup with error 159 - Sandbox restriction." UserInfo={NSDebugDescription=The connection to service named com.apple.nfcd.service.corenfc was invalidated: Connection init failed at lookup with error 159 - Sandbox restriction.} and then my app reports that NFC is not available on this device. Important details: I added Near Field Communication Tag Reading in Signing & Capabilities. I added the NFC privacy usage description in the target settings. I am using automatic signing. I am not using an Apple Developer Program paid account. I am using a Personal Team / free account. I should also mention that I am not experienced with Swift/iOS development, so I may be missing something basic in the setup. My question is: Is this expected when using a Personal Team / free account, or is there some configuration issue I should still check? I am happy to provide any additional information needed

I've added NFC support for my app. So, my UIRequiredDeviceCapabilities were extended from "armv7" to "armv7 nfc". This means I've prevented this application from running on devices supported by previous versions. Now I've received a message from Apple: ITMS-90109: This bundle is invalid - The key UIRequiredDeviceCapabilities in the Info.plist may not contain values that would prevent this application from running on devices that were supported by previous versions. What is the right way to add new functions?

We have enabled the Host Card Emulation (HCE) capability for our app and successfully implemented and tested the functionality during development. When running the app directly from Xcode, HCE-related flows work as expected. However, we are observing different behavior in the distributed build. In particular, the following check consistently evaluates to false: guard await CardSession.isEligible else { return } After distributing the app via TestFlight, HCE functionality is not available for external testers. The CardSession.isEligible property always returns false, even when tested on supported devices and in supported regions. We are using the same bundle identifier for both development and distribution builds, and the provisioning profiles include the required capability. Could you please clarify the following: Are there any additional entitlements, approvals, or configuration steps required for HCE to function in TestFlight or distribution builds? Are there known region, device, or account-related restrictions that could cause CardSession.isEligible to return false outside the development environment? Is there any difference in behavior between development-signed and distribution-signed builds for this capability?

Hi everyone, I'm looking for clarity on the NFC HCE entitlement process for third-party apps in the EEA. I've built an alternative client for Milan's public transport app (ATM Milano) on Android by reverse engineering the original app. It offers the same core functionality(users still need a valid transit subscription) just with a different UI and better UX. I'd now like to port it to iOS. According to Apple's documentation, NFC HCE was opened to third parties in the EEA starting with iOS 17.4. However, the API requires an entitlement from Apple. I have a few questions: Is the entitlement required regardless of distribution method? Even if I distribute through a third-party marketplace like AltStore PAL rather than the App Store, do I still need Apple to grant the HCE entitlement? Are third-party/alternative clients eligible for the entitlement? My app isn't a competing transit provider, it's an alternative frontend for an existing service. Users must hold a valid subscription with the official provider. Is there anything in the entitlement criteria that would disqualify this kind of app? What's the correct process to apply?Developer Support directed me here, so I'm hoping someone from Apple engineering or someone who has gone through the process can share the steps. Thanks!

Is it possible to read a custom, non-payment, ISO7816 AID on a multi-application smartcard that also has an active payment AID? I guess Apple Wallet may auto-detect the payment scheme and open, but this could be prevented if my app was already running in the foreground and scanning for the custom AID?

Hello, I would like to discuss the behavior of the expiration of NFCPresentmentIntentAssertion (test in iOS 18.5). In the documentation we have : The intent assertion expires if any of the following occur: The intent assertion object deinitializes Your app goes into the background 15 seconds elapse BUT; in fact ; only the 1st rule is applied. The expiration seems to be random after the usage of CardSession and that's difficult to give to the user a good experience. Has someone faced the same kind of issue; or can give an explanation? Regards, François

Hi, I’m implementing ePassport reading in an iOS app using a third-party KYC identity verification SDK (the SDK handles the NFC logic internally). Before adding any specific AID, the NFC session would start normally and iOS showed the system popup asking the user to hold the passport near the device. However, the passport was never read , the session just stayed there with no progress or data returned. I then tried enabling the ICAO ePassport AID: A0000002471001 After adding this, the build failed with the following signing error: Provisioning profile "iOS Team Provisioning Profile: com.sandrotbilisi.DigitalCurrency" doesn't include the com.apple.developer.nfc.readersession.iso7816.select-identifiers entitlement. Has anyone encountered this behavior when working with ePassports? Do I need special entitlement approval from Apple for this AID? Thank you.

We have NFC capabilties enabled for our app ID - com.uob.mightyvn but our minimum deployment target is 15.0. We do not have an option deselect PACE from provisioning profile. Hence, the validation is failed for IPA. Invalid entitlement for core nfc framework. The sdk version '18.2' and min OS version '15.0' are not compatible for the entitlement 'com.apple.developer.nfc.readersession.formats' because 'NDEF is disallowed'

We are developing an iOS application that requires NFC-based communication using ISO 7816 / ISO 14443 standards for secure element interaction as part of a card provisioning workflow. We would like clarification on the following points: Is it possible to provision a payment card or securely add a card to an NFC-enabled device using direct ISO 7816 APDU communication via NFCTagReaderSession? If not, is Apple Pay In-App Provisioning (PassKit framework) the only supported approach for enabling contactless payment functionality on iPhone? What specific entitlements are required if the use case involves secure element communication for token provisioning (not bypassing Apple Pay)? We have already requested the relevant NFC entitlements through our Apple Developer account and are awaiting a response. Any guidance on the correct architecture and approval requirements would be greatly appreciated. Thank you in advance for your support.

Provisioning profile doesn't match the entitlements file's value for the com.apple.developer.nfc.hce.iso7816.select-identifier-prefixes entitlement. Although when we created the request, we added a list of AIDs which is the same as the list registered in Inof.plist <key>com.apple.developer.nfc.hce.iso7816.select-identifier-prefixes</key> <array> <string>XXXXXX</string> <string>XXXXXX</string> <string>XXXXXX</string> </array> How can we get a better message of diffs between them?

G'day. At my office the doors are locked with an NFC reader. We carry around a little NFC tag on our key chains which will read out a number and this then will open the door if the number matches a number in the database. I am tired of carrying around the tag, people keep loosing it, forgetting it and it would be nice to open the door using a Phone - which we tend to always have on us. So I used a credit card which is NFC enabled to readout the NFC information, added this number to the database and can now open doors using my credit card. This is pretty cool. If I forget my keys (most likely they will be on the desk but silly me left the desk without them), I may have my wallet with me. Then I tried Wallet.app on my iPhone and select the same credit card. However the door doesn't open. When looking in the door software I noticed that the tags will always transmit the same number. So does my credit card. However Wallet.app will read out 4 readings (or maybe just one very long one) and they are always different. So I can not make them match with the door database. Any ideas how to make this work? Can I give somehow wallet.app an NFC number which I can then add to my door database? Or how come the credit card and the very same one in wallet.app don't match? Thanks for your help! Would be neat if I could make this work out. This will make a lot of people happy at my office! Cheers!

Dear Apple Engineers, I am using NFCNDEFReaderSession to read information from NFC tags. When calling the begin method of the session, a system dialog/popover appears at the bottom of the screen. Is it possible to suppress or disable this dialog? Thank you for your assistance. Here is my demo code： @IBAction func beginScanning(_ sender: Any) { guard NFCNDEFReaderSession.readingAvailable else { let alertController = UIAlertController( title: "Scanning Not Supported", message: "This device doesn't support tag scanning.", preferredStyle: .alert ) alertController.addAction(UIAlertAction(title: "OK", style: .default, handler: nil)) self.present(alertController, animated: true, completion: nil) return } session = NFCNDEFReaderSession(delegate: self, queue: nil, invalidateAfterFirstRead: true) session?.alertMessage = "Hold your iPhone near the item to learn more about it. session?.begin() }

Dear Apple Engineers： My app utilizes the App Clip experience. I would like to prevent the App Clip card from appearing when the host app is running in the foreground. How can this be achieved? I have observed that Alipay (in China) does not display an App Clip card when the device is tapped against a tag while the app is in the foreground, which indicates that this behavior is possible. Thank you for your assistance.

Background: We are developing a cross-platform mobile application that communicates with a custom NFC-enabled hardware device. The hardware expects ISO7816-style APDU commands for data exchange and functions correctly with Android using the IsoDep protocol. Observed Issue on iOS: On iOS, the tag is only detectable via NFCNdefReaderSession, which provides access to INFCNdefTag. Attempting to use NFCTagReaderSession with NFCPollingOption.Iso14443 (which is required for APDU communication) results in no tag detection. As a result, the tag is inaccessible for APDU-based communication on iOS. Since NFCNdefReaderSession does not support APDU, we are unable to establish the required command channel. Constraints: The hardware firmware cannot be changed to support NDEF-based command interpretation. The device expects raw ISO-DEP APDU commands (i.e., Class-Instruction-Param1-Param2-Data-Le). Impact: The lack of ISO7816 tag detection on iOS prevents the app from sending APDU commands, resulting in a platform-specific feature limitation. Functionality that relies on secure, structured APDU communication is unavailable to iOS users, even though it works seamlessly on Android.

Hello, I would like to seek clarification regarding the availability of the NFC Secure Element (SE) / ISO7816 entitlement by region, specifically for Indonesia. I recently contacted Apple Developer Support regarding the use of NFC for reading ISO7816-compatible cards. I was informed that, at this time, the NFC & Secure Element entitlement is not available in Indonesia. For technical planning and compliance purposes, I would like to confirm the following: Is the NFC Secure Element / ISO7816 entitlement currently restricted by region, and is Indonesia officially unsupported at this time? For apps distributed on the App Store in Indonesia, is Core NFC limited to NDEF and non–Secure Element tag reading only? Are there any publicly supported alternatives or recommended architectural approaches for NFC-based workflows in regions where the Secure Element entitlement is unavailable? Is there any public documentation or guidance that outlines regional availability for NFC Secure Element features? I understand that entitlement approvals and availability may vary by region and are handled on a case-by-case basis. Any clarification from Apple engineers or developers with experience in this area would be greatly appreciated. Thank you for your time and assistance. Best regards.

Hello. I am attempting to wrap the C library libnfc as a Swift library. This is not for use on macOS - it's mainly for use on Linux (Raspberry Pi). I have a USB reader and my code appears to work so far, however the code/test/debug cycle is suboptimal if I'm running the code on the Pi. As I use a Mac for day-to-day coding, I'd prefer to use Xcode and my Mac for development. MacOS appears to capture the NFC hardware for its own frameworks and attempting to open a connection to the USB device gives a Unable to claim USB interface (Permission denied) error. ioreg shows that the hardware is claimed by an Apple framework: "UsbExclusiveOwner" = "pid 10946, com.apple.ifdbun" Is there a way to temporarily over-ride that system and use the hardware myself? I've tried Googling but most of the replies are out of date and Claude's advice launchctl unload /System/Library/LaunchDaemons/com.apple.ifdreader.plist doesn't appear to work... I'm wary of disabling SIP - is there a simple way to have access to the hardware myself? Thanks.