file uri scheme

Good points — I’d value more control over default apps, better file management, and faster access to system settings. Small tweaks like these would make iOS feel much more flexible.

Yeah, it can be that changes on the framework unintentionally trigger the crash, which will be a regression; it can also be the framework intentionally became stricter, which triggers the crash that should have been triggered in the previous version. Given that you have confirmed your model schema matches the JSON schema, I think it is more like the former, and so would suggest that you file a feedback report. It will be a great help if you can attach a minimal sample that reproduces the issue though to your feedback report, and you can create that by following the steps I mentioned. Best, —— Ziqiao Chen  Worldwide Developer Relations.

I haven't been able to find much in the documentation on whether this behavior is enforced in classificationResponse handlers. Apple's barebones page on SMS and Call Spam Reporting[1] says the system always deletes your extension’s container after your extension terminates, but that doesn't answer whether you can write to an App Group container. No, you cannot. This could have been more directly stated, but this is basically implementing one of the strongest possible restrictions* around your extension. For comparison, the filter data provider extension, which can examine the contents of all network traffic, is allowed to write to its data container but cannot write ANYWHERE else on the system (nor can its container be read). ILClassificationUIExtensionViewController takes that level of protection one step further and doesn't even preserve your app’s own container. *We could have simply blocked writing, but I suspect container writing was allowed to provide a bit more implementation flexibility. For example,

The error references a .o (object) file. Generally speaking, these are intermediate files used during a build and not distributed as part of a final product. If you make a copy of your project (for testing) and remove these .o files from it are you able to successfully sign your app?

Thanks for bringing up the potential policy problem. I indeed can't speak for the App Review team, and so would suggest that you contact App Review(login required). I don't see an API that allows you to tell if an Apple Watch is impacted. I agree that a separate syncing system is far from ideal, and yes, filing a feedback report is the way to go in this situation. Best, —— Ziqiao Chen  Worldwide Developer Relations.

The UILabel text and task's progress is updated once every 1 billion nanoseconds (1 second). I'm afraid Friday was a very busy day, and yes, I did misread that. (notably you're manipulating UIKit from a background thread) I don't believe that's the case. Setting breakpoints before the while block, in it, and after indicates it's on com.apple.main-thread. Hmm... I guess Task is keeping you on the main thread based on your entry point. I'm not a huge fan of that implicit behavior, but you're right that this should work. Moving to the original problem: The indeterminate progress bar is visible (from the get-go and throughout the operation) even when the app stays in the foreground the whole time on iPad. I would try: Set totalUnitCount before you set completedUnitCount. I'm not sure why this would matter, but both operations kick off a KVO cycle, and setting completedUnitCount first means you're sending 0/0-> indeterminate while totalUnitCount first means you’re sending 0/100-> a valid start point. Directl

Indeed, I used test numbers that I called previously. Can you update the doc? Please file a bug asking the documentation to be updated and post the bug number back here. Having said that: I did not see this information anywhere. ...while the behavior above is new in iOS 26, there have ALWAYS been exceptions that would cause us to bypass a call directory entry. Notably, the user direct contact takes precedence over CXCallDirectory. This has always been the case but has never been formally documented as such. __ Kevin Elliott DTS Engineer, CoreOS/Hardware

Has any one come across file corruption issues with tvOS 26? This is the first time I've heard of this. Can you provide more details about what's actually going on (file type, how you're accessing it, what damage has occurred in the file, etc.)? __ Kevin Elliott DTS Engineer, CoreOS/Hardware

Glad to here that's working! Note if you have a case where you get the same failure even with the workaround I suggested, please: File a separate bug on it. Start a new forum thread on it (this one is getting long). Include links to both this forum thread and the new thread in that bug. __ Kevin Elliott DTS Engineer, CoreOS/Hardware

Sorry, I am not sure what happened with my original submission. There is now a file called MacToolbarIssue.zip attached the the submission that you can use to reproduce the issue. Just be sure to set your system appearance to Dark before building and running the app.