nfc

It is probably too early for documentation and sample release. I think they will come out soon, maybe with beta 2. By the way, for what I've been able to understand, the new eventTicket format is an NFC only, so I think you'll need to provide NFC data for it to show up.

We have added CoreNFC as a weak_framework in our podspec s.weak_frameworks = [CoreNFC] Few clients don't use the NFC feature and few clients use it. People who use don't have any issue with it. People who don't use it, will they have an issue when their app is submitted for review ? They have not added the NFC permission in their Info.plist and have not added the capability as well. Will it still be an issue for such clients?

If I understand correctly, you are the third party supplying a library that includes NFC functionality your clients are not using. Not knowing what these apps are, how they are built, and what the actual rejection causes are etc., I can't make any comments or promises about the success of this solution, but the answer to your question about making CoreNFC optional is this: (things might look/work differently depending on which Xcode version or possibly 3rd party build tools your clients are using, but this is the general gist) In the Xcode project Build Phases, the Link Binary With Libraries” section, add the CoreNFC.framework, and then mark it as Optional This will weak link CoreNFC, and unless there is code that is referencing it, CoreNFC will not be included in the build. For that, you could make use of a custom Info.plist entry to check if the app is supposed to be using CoreNFC and not engage any features of your app that would require the use of those features. Again, a lot of the specifics wil

It is not possible to query which app is selected by the user as default, as that is their private choice. But, if your app has indeed been set as the default, you can determine whether it is being launched as the default app. You will need to implement NFCWindowSceneDelegate (https://developer.apple.com/documentation/corenfc/nfcwindowscenedelegate) There is a NFCWindowSceneEvent event your app will receive when it is launched due to double press or an NFC field (with payment intent) https://developer.apple.com/documentation/corenfc/nfcwindowsceneevent If your app has been set as the default, double-pressing the power button will send the presentation event. Detecting an eligible RF field (with payment intent) will send the readerDetected event If you encounter these events then you can assume your app has been set as the default payment app for the time being. Of course the user might change this at a later time without you knowing. Note: If the app is already launched, if it has startEmulation() al

Confirm that your App Clip follows guidelines from Choosing the right functionality for your App Clip, then follow the instructions in Verify the configuration of your released App Clip to diagnose issues with your App Clip. From Choosing the right functionality for your App Clip: To ensure a fast launch experience, App Clips must be small: If you make your App Clip available on devices running iOS 15 and earlier, the uncompressed App Clip binary can be up to 10 MB in size. If you make your App Clip available on devices running iOS 16 and later, the uncompressed App Clip binary can be up to 15 MB in size. If you make your App Clip available on devices running iOS 17 and later, the uncompressed App Clip binary can be up to 50 MB in size if it meets the following conditions: The App Clip only supports digital invocations — for example, from your website or Spotlight search — and not from physical invocations like App Clip Codes, QR codes, or NFC tags People use your App Clip in situations where a relia

For my case, i am using it with NFC and somehow the security key is not detected or there are some NFC hardware issues. The callback is not triggered until timeout. Any idea on NFC troubleshooting?

How about NFC readable store discount cards? A bit of a privacy issue maybe, but no money really changes hands with those, so no harm if they're static.

That looks like decomposed (NFD) unicode form, where an ä is a combination of an a and the two dots, encoded in separate unicode chars. And somehow Xcode(?) is unable to compose them as they should be. Weird. You might be able to fix this by running the strings thru code that re-composes into NFC format, but I guess you have already fixed them all by hand.

It's all very well to open up the HCE for banks, but what about other ways of using the HCE. There are companies in the Americas and Asia leveraging Apple's NFC HCE for access control, integrating access badges/cards into Apple Wallet. Is this functionality available in Europe? If not, what's the reason? Can this be accomplished using Apple's Secure Element? I haven't come across any information addressing this.