file uri scheme

Thank you for your response and for taking the time to read the Technical Note. I believe you have now realized that Universal Links function consistently well, but there could be several reasons for their behavior deviating from expectations: When encountering issues related to Apple-app-site-association files and associated domains, particularly when they function correctly on the first attempt but fail on subsequent attempts within the same tab, several potential security and configuration factors could be at play: JavaScript Logic Errors: Although you mentioned that the code execution is identical, race conditions or state mismanagement within your JavaScript could lead to differing outcomes on successive runs. Please verify for such possibilities. Error Handling and Logs: Enhance error handling surrounding the associated domain validation logic and ensure comprehensive logging to capture any discrepancies during the second invocation. By systematically examining these areas, you should be able t

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.

In iOS 26.1, after my app answers a VoIP call on the lock screen, tapping the bottom-left More button doesn't bring up the app icon to jump to the app. The same scenario works normally on iOS 26. Please file a bug on this and post the bug number back here. How can I resolve this issue? I'm not sure what's caused the change, but I don't think there's anything your app can do to change the behavior. The system is what controls the call UI and your app has very little control over it. __ Kevin Elliott DTS Engineer, CoreOS/Hardware

Thanks for the post and thank you for bringing this issue to our attention. Indeed, this is a known problem where SwiftUI control will need to resize a window with a NavigationSplitView generates Invalid view geometry warnings in Xcode. The issue is currently being investigated. If you would like to be notified when the fix is implemented and Xcode ceases to issue these warnings, we recommend filing a bug report. The warning looks something like this: Unable to simultaneously satisfy constraints. Probably at least one of the constraints in the following list is one you don't want. Try this: (1) look at each constraint and try to figure out which you don't expect; (2) find the code that added the unwanted constraint or constraints and fix it. (Note: If you're seeing NSAutoresizingMaskLayoutConstraints that you don't understand, refer to.. In the meantime, please be advised that the engineering team is actively addressing the warning issue. If you want to file a bug please post the FB number h

Thanks for the post. Are you using Flutter? Have you addressed by the support channel for Flutter - the third-party resource you are using. Unless another developer in the forums has experience with the third-party and can provide assistance. However I am sure the 3rd party tool could be aware of the issue if you provide them with crash files. Have you been able to reproduce on your environment? The objective-c code you posted seems ok, is that the part of the code is crashing? Have you use Xcode to reproduce it? Thanks Albert Pascual
  Worldwide Developer Relations.

@viktor_runcoach thanks for letting me know, I didn't see the issue when I use Xcode 26.2 beta and the simulator for iPhone Air, but it means I need to get a real device and start trying to reproduce it. However is very important if you can file a bug using a focus sample showing the issue. Once you open the bug report, please post the FB number here for my reference. If you have any questions about filing a bug report, take a look at Bug Reporting: How and Why? Above all, thanks for providing all this. Looking forward your bug to get to the bottom of the issue. Albert Pascual
  Worldwide Developer Relations.

@Mathias_ Thanks for filing the bug and providing the focus sample FlipTest project. Its being routed to the correct team and lets give them sometime to look over the issue. The status appears beside the label Resolution. We're unable to share any updates on specific reports on the forums. For more details on when you'll see updates to your report, please see What to expect after submission. Thanks again for doing all that work, hopefully will be a resolution of the issue soon. Albert Pascual
  Worldwide Developer Relations.

Excatly the same issue with the same code used for years. Tested on macOS 26.0, 26.1 and 26.2 RC. My app is sandboxed, and access to the files is made through the NSOpenPanel first (Macintosh HD folder). Same log message and behavior: takes a long time. Can a DTS engineer tell us what's going wrong?

Hi Albert, Thank you for the links. After reviewing both documentation pages, I've implemented a complete test following the specifications, but password autofill is not working. Test Implementation AASA File (accessible at http://localhost:8080/.well-known/apple-app-site-association): { webcredentials: { apps: [ZW962TGA3F.com.test.PasswordAutofillTest] } } ✅ Served with Content-Type: application/json ✅ Verified accessible via curl ✅ Team ID matches Apple Developer account Associated Domains Entitlement: webcredentials:localhost:8080 ✅ Configured in both Debug and Release entitlements ✅ Bundle ID: com.test.PasswordAutofillTest SwiftUI Implementation: TextField(Email, text: $email) .textContentType(.username) SecureField(Password, text: $password) .textContentType(.password) Authentication Flow: App sends POST to http://localhost:8080/login with credentials Server returns 200 OK App displays Login successful Server logs confirm request received and processed Result ❌ No Save Password prompt appears ❌

It’s better to reply as a reply, rather than in the comments; see Quinn’s Top Ten DevForums Tips for this and other titbits. The screenshot above is the iOS system's crash log Just clarify what we’re talking about here, this is an Apple crash report from iOS 26.1: Exception Type: EXC_BAD_ACCESS (SIGKILL) Exception Subtype: KERN_PROTECTION_FAILURE at 0x0000000000000000 … Thread 0 name: Dispatch queue: com.apple.main-thread Thread 0 Crashed: 0 ??? 0x0 ??? 1 Test808813 0x10058c128 -[MainViewController tableView:didSelectRowAtIndexPath:] + 100 2 UIKitCore 0x1a563bc98 -[UITableView _selectRowAtIndexPath:animated:scrollPosition:notifyDelegate:isCellMult… 3 UIKitCore 0x1a563bfbc -[UITableView _userSelectRowAtPendingSelectionIndexPath:animatedSelection:] + 255 4 UIKitCore 0x1a563c0c8 -[UITableView _userSelectRowAtPendingSelectionIndexPath:] + 215 5 UIKitCore 0x1a407d878 -[_UIAfterCACommitBlock run] + 71 … You’re concern is with that SIGKILL, where prior to iOS 18 this was a SIGSEGV. That doesn’t strike me as a proble

[quote='868752022, DMSAS, /thread/794045?answerId=868752022#868752022, /profile/DMSAS'] However, some Macs still have issues with malicious software [/quote] My advice is that you test your notarised software on a ‘clean’ machine. I generally use a VM for this. See Testing a Notarised Product. If that test fails, there’s definitely something wrong with your product and you should investigate that. I have lots of advice on that topic in Resolving Trusted Execution Problems. If that test succeeds but you receive sporadic reports of Gatekeeper problems from your users, that’s a trickier issue. It’s possible that you have a Gatekeeper problem with a specific OS release. You can investigate that by re-running the above-mentioned test process with that release. However, it’s more likely that there’s something borked on that user’s machine. That puts you in a bit of a bind: You want to help the user with their problem. But debugging their machine configuration problems isn’t really your core business. This is a bala