file uri scheme

Our engineering teams need to investigate this issue, as resolution may involve changes to Apple's software. Please file a bug report, include a small Xcode project and some directions that can be used to reproduce the problem, and post the Feedback number here once you do. If you post the Feedback number here I'll check the status next time I do a sweep of forums posts where I've suggested bug reports. Bug Reporting: How and Why? has tips on creating your bug report.

It turns out the situation is worse than I thought: it's not the OS update that triggers the bug, but merely restarting the device! If I schedule an alarm with the above code and then restart my device, the alarm triggers at the correct time, but the UI shows the localization keys instead of the strings. I just installed the iOS 26.1 beta (23B5044I) and it's still broken, so I've filed a bug report: FB20472264 As a temporary workaround, I will set my localization keys to English language strings.

Our engineering teams need to investigate this issue, as resolution may involve changes to Apple's software. Please file a bug report, include a small Xcode project and some directions that can be used to reproduce the problem, and post the Feedback number here once you do. If you post the Feedback number here I'll check the status next time I do a sweep of forums posts where I've suggested bug reports. Bug Reporting: How and Why? has tips on creating your bug report.

Thanks for the details regarding this. I tried import Metal in the swift test, as well as the following Objective C test code: #import ViewController.h #import Metal/Metal.h @interface ViewController () @property id commandBuffer; @property id commandQueue; @end @implementation ViewController - (void)viewDidLoad { [super viewDidLoad]; // Do any additional setup after loading the view. } @end No dice with this either. I'll file the bug, thanks for looking into this!

This smells like a Safari-side change/regression in the capability probe, not in the payment sheet itself. Treat applePayCapabilities() as advisory only for now. Implement a graceful fallback: always show the button when Apple Pay is supported, then try to launch a session. Use canMakePayments() (and optionally canMakePaymentsWithActiveCard) only to influence prominence, not eligibility. This is consistent with Apple’s guidance and long-standing WebKit advice. File a bug with reproducibles via Feedback Assistant. Assume this is a Safari capability-probe issue (and possibly anti-fingerprinting collateral) rather than your integration. Don’t block Apple Pay on the probe; keep the button visible and let the session tell you the truth. This both fixes your users today and aligns you with Apple/WebKit’s recommended UX.

Please test this again with iOS 26.1 betas and file a bug report if the issue still persists. Bug Reporting: How and Why? has tips on creating a successful bug report.

Just file a bug report for the new symbols you would like to see in SF 8.

With card present environments, what's happening there is Apple Pay is sending the DPAN and cryptogram to the terminal, and terminal completes the charge. However, in card not present environments, from a payment processing UX perspective, the user has to see the amount they are confirming for pre-authorization. Otherwise it could lead to fraud cases. You could consider talking to your gateway or bank for Credential On File (COF) if you want to implement something similar to card present environments: You can save the card with a symbolic amount (or zero if the banks allow it) and then use the card you saved for the actual charge. But please beware that Credential On File brings its own set of rules and implementation requirements.

That could be a little problematic to have all gateways in the same domain because as far as I understand, Apple provides the domain verification files per platform integrator, so the gateway that provided you with the verification file is your integrator. And I am not sure how Apple treats multi-integrator platforms. Is it possible for you to register as a merchant, decrypt the payload as a merchant and then send the transaction to gateways for authorization? That might be a better solution.

Thanks. I added a link to this post to the feedback. NSDocument.fileURL is nil for a new document that hasn't been saved – In that case, when you try to terminate your app or close the document window, AppKit shows an alert asking if you'd save the document, and so you should be fine. Yes, but only assuming that the document has been marked as dirty... which is what we're trying to work around. I noticed that there is another issue now: Create a new document. Type a letter. Switch to another app and back again. Type another letter. Quit and restart the app. The document is correctly restored, but when selecting File > Close (or hitting Command-W), it is closed without asking whether I want to save or discard it, and so it probably stays in its autosave directory without the user knowing where it is. This is my current implementation: class Document: NSDocument { private var textStorage: NSTextStorage! private(set) var savedText: String? override func data(ofType typeName: String) throws -> Data