“nfc”

Every App Store Connect upload I sign with my Cloud Managed Apple Distribution certificate is rejected with ITMS-90035 (Code failed to satisfy specified code requirement(s)) for the app binary and its widget extension. It happens from Xcode Cloud and from a manual Organizer upload alike. I think I have found the cause, and it looks like a Unicode normalization bug in cloud-managed signing. The certificate holder's name contains an umlaut: Apple Distribution: Jonathan Thorsten Müller (…). In the certificate the ü is precomposed (NFC, UTF-8 c3 bc). In the designated requirement that the export writes into the signature it is decomposed (NFD, u + U+0308, UTF-8 75 cc 88): certificate subject CN ... 4d c3 bc 6c 6c 65 72 ... (Müller, NFC) designated requirement leaf CN ... 4d 75 cc 88 6c 6c 65 72 ... (Müller, NFD) The bytes differ, so the signature can never satisfy its own designated requirement. It reproduces with Xcode 27.0's App template, unmodified, and without uploading anything: Archive for

I'm building an accessibility feature where a user walks around and taps NFC tags to trigger updates in the app (e.g., wayfinding/context info). I want a Live Mode toggle that keeps the app listening for NFC reads continuously while it's on, processing each tag as it's scanned, rather than one-shot read-and-dismiss. Is there a Core NFC API or session configuration that supports this kind of continuous/persistent listening, or does every read still require invalidating and restarting the session afterward? Currently: I have high-performant reads working reliably with passive NDEF/tag detection. What I'm trying to figure out: Recommended approach — should I keep a single long-lived NFCReaderSession alive and handle repeated reads within it, or restart a new session immediately after each read? VoiceOver / accessibility — how does the system NFC sheet interact with VoiceOver, especially if the session is restarting frequently while the user is mid-walk? Session timeout and res

I am currently having issues getting tap to pay to work locally for development. I have: the tap to pay development entitlement a verified test device a test sandbox user tap to pay / NFC / app apptest capabilities the correct provisioning profile We are currently working a payment service provider NMI to support tap to pay. Part of that process has been getting entitlements, and we now have the developer entitlement for tap to pay. We are having an issue with an account not linked error. We have been told by NMI this is an issue on Apple's side since we have the correct provisioning profile, capabilities, and entitlements set up for our company. This issue is when using a sandbox account. When I use a developer account I get an invalid apple account issue. Any combination of user / provisioning profile / and capabilities that I have tried have not produced better results. Versions: IOS version is 26.6 and xcode is also 26.6. I have followed these steps: https://developer.apple.com/forums/thread/7757

I am developing an iOS app that uses Core NFC to communicate with an ISO 14443 / ISO 7816 smart card. For security reasons, I would like to minimize or temporarily prevent other external communications while an NFC read/write session is active. My questions are: Is there any supported iOS API or entitlement that allows an app to temporarily disable or block Wi-Fi, cellular, or Bluetooth communication while a Core NFC session is active? If device-wide communication cannot be controlled by a third-party app, is there a supported way to guarantee that the app’s own process performs no network communication during that NFC session? Does Apple recommend any architecture or security practice for implementing an offline-only Core NFC read/write operation? The NFC communication itself must remain available during the operation. Thank you.

Hi, We're implementing a HCE contactless app on iOS. The intention of this app is to only support contactless payments. Next to the com.apple.developer.nfc.hce and com.apple.developer.nfc.hce.default-contactless-app entitlements, we've listed the identifiers that we're interested in through the com.apple.developer.nfc.hce.iso7816.select-identifier-prefixes in the Info.plist. (325041592E5359532E4444463031 & A0000000041010 f.e.) When the app is configured as the Default Contactless App, we start receiving NFCWindowSceneEvents through our NFCWindowSceneDelegate. However we notice that also non-payment related NFC events are being received, such as when the device is close to a NFC reader for Access cards for example. This experience results in launches of our app when it's not intended. Is there a way to allow the app to only receive NFC events related to ISO 7816 identifiers when the when the app is configured as the Default Contactless App? Thanks in advance for any guidance! Kin

Does anyone know how to implement Apple Account Binding for Wallet Pass function like https://www.ticketswest.com/customer-service/nfc-apple-account-binding/apple-account-bin

Does anyone know how to implement Apple Account Binding for Wallet Pass function like https://www.ticketswest.com/customer-service/nfc-apple-account-binding/apple-account-bin

Hello Apple App Review Team, I am requesting assistance with the review of my app, which has now been pending without an update. I submitted an Expedited App Review request on 25 August 2026, but I have received no response or acknowledgement regarding the expedited request, and there has been no progress on the app review. I have also previously attempted to contact App Review regarding the submission but have not received an update. Could you please investigate the current status of the submission and escalate the case to the appropriate App Review team? I am not requesting that the review process be bypassed; I am simply trying to obtain an update and have the submission reviewed, as there has now been an unusually long period without communication. App name: Boost NFC Apple ID: 6801883761 Version: 1 Current status: Waiting for review Expedited review requested: 25 August 2026 Existing support case number: 20000147579048 Thank you for your assistance.

We are developing UTipping, a digital tipping application, and are seeking technical guidance before implementation. Our intended experience is: The recipient opens the app and activates “Receive Tip”. The sender selects a tip amount and “Send Tip”. Both authenticated apps are unlocked, online, and in the foreground. The two iPhones are brought into very close physical proximity. The proximity interaction exchanges or resolves only a short-lived, opaque session identifier. No funds, card credentials, cryptograms, or payment-authorization data are exchanged through NFC. The sender confirms the resolved recipient and amount. Payment is processed separately through the backend and licensed payment infrastructure. Standard Core NFC appears to provide reader functionality for supported tags/protocols, but not a general application-controlled iPhone-to-iPhone peer/tag-emulation channel. We would appreciate guidance on: whether this interaction can be implemented using Core NFC; whether NFC

We ship an App Clip with our iOS app and want the App Clip card to appear when users share our website's links in Messages. Instead, recipients only get a plain link preview. The App Clip was approved and has been live on the App Store for over a week. We've verified every requirement from the docs (Associating your App Clip with your website and the Messages invocation requirements): The invocation page's server-rendered HTML (no JS needed) contains the meta tag: apple-itunes-app with app-id and app-clip-bundle-id set correctly. /.well-known/apple-app-site-association has an appclips section listing the clip's app ID, and Apple's AASA CDN (app-site-association.cdn-apple.com/a/v1/) serves the same content. The App Clip's entitlements include appclips: and the correct parent application identifier. Via the App Store Connect API, the currently live build contains the APP_CLIP build bundle, and the live version has a default App Clip experience (action OPEN, with localizations). The default experience link https