file uri scheme

I am unsure if there has been any progress in this area. But I needed to resolve a recent Tahoe panic, so chatgpt cobbled together this: https://gist.github.com/lundman/54e633a850e7623aae5adab38a39f464 If we are allowed to share? Either way, output was: ./symbolicate_panic.py -p ~/ZFS.2.3.1rc1.kernel.panic.-.Tahoe.M4.Pro.Mac.Mini.txt -k /Library/Extensions/zfs.kext/Contents/MacOS/zfs --kernel --kdk-nearest --accept-mismatch === KEXT mapping === bundle: org.openzfsonosx.zfs arch: arm64e base@: 0xfffffe004400d840 file __TEXT vmaddr: 0x0 file __TEXT_EXEC vmaddr: 0x70000 delta=0x70000 chosen TEXT_LOAD: 0xfffffe0043f9d840 === Kernel mapping (via KDK) === checking for KDK build 25A354 ... nearest: /Library/Developer/KDKs/KDK_26.0_25A353.kdk build: 25A354 SoC: t6041 kernel: /Library/Developer/KDKs/KDK_26.0_25A353.kdk/System/Library/Kernels/kernel.release.t6041 panic Kernel UUID: E67CAF31-8F84-389C-BB27-7FAEC762FA14 KDK Kernel UUID: E67CAF31-8F84-389C-BB27-7FAEC762FA14 file __TEXT vmaddr: 0

I have a few resources to share with you: Placing content in a bundle explains how bundles should be structured. Creating distribution-signed code for macOS and Packaging Mac software for distribution explain how to manually sign code. Embedding nonstandard code structures in a bundle offers advice on how to deal with non-Apple code structures, like the ones used by Python. You have a couple of choices here: You can strictly follow the rules in Placing content in a bundle, which is a bunch of extra work right now but will likely work better in the long term. You can bend those rules by simply signing your code as it’s currently structured. Based on the script you included, it looks like you’re attempting the second approach. It’s likely you’ll be able to make that work, but that script will need significant enhancement. For example, Creating distribution-signed code for macOS explains that you need to sign code from the inside out from a dependency perspective, and your script is doing it from a file

[quote='860350022, Michael8619, /thread/802183?answerId=860350022#860350022, /profile/Michael8619'] after 3.5 days of waiting. [/quote] Blergh. Lemme know if you see such a long delay in your subsequent notarisation requests. Normally I see follow-up requests go through quickly, but that’s after a successful notarisation. I’m curious to see if your unsuccessful notarisation still allowed the system to ‘learn’. [quote='860350022, Michael8619, /thread/802183?answerId=860350022#860350022, /profile/Michael8619'] I must have missed some files in mine as I just received invalid on all my files [/quote] OK. If you’re unable to resolve this, I’d be happy to take a look. My only ask is that you start a new thread with the details, so we can leave this thread focused on the “in-depth analysis” issue. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

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