file uri scheme

[quote='867165022, pabugeater2, /thread/806641?answerId=867165022#867165022, /profile/pabugeater2'] because I was not changing the icon, and it had been previously cached. [/quote] OK. But you can test this by setting up a new macOS 15 machine and trying it there. I usually use a VM for this sort of thing, because it lets me quickly get back to a ‘fresh’ state by restoring a snapshot. [quote='867165022, pabugeater2, /thread/806641?answerId=867165022#867165022, /profile/pabugeater2'] it seems I learned to include two thumbnail files [/quote] Ah, that explains my confusion. Given that this isn’t documented as part of the screen saver API, it’s basically an implementation detail that you can’t rely on. Oh, and I’d be remiss if I didn’t repeat my standard spiel: The current screen saver API is based on legacy in-process plug-in technology. This results in a wide range of performance and compatibility problems. If you’re interested in having a better screen saver API, one based on app extensions, I encour

Same problem here with 26.1 I have complete wild guess: The issue may originate from iCloud-Apple-whatever-enforced constraints within the local filesystem sandbox or from misconfigurations in the iCloud container provisioning layer or failures in the underlying iCloud service endpoints responsible for file coordination and metadata synchronization. Alternatively, the root cause could be an incomplete or corrupted code-signing pipeline within Xcode or the like. In addition, a failed or skipped notarization step, an unprocessed staple operation, or an artifact that was signed outside the expected keychain context can prevent the resulting binary from passing Apple’s runtime validation, ultimately blocking proper initialization. It has perhaps its root cause in the new (ugly and power lavishing 2007ish Windows Vista Aero designed) OS. Perhaps it's so complicated to fix, that this app is beyond (costly) repair. Best regards, S.

Inno Setup was a sweet app. I used to use that when I made Windows software. I don't know anything about Filemaker. A quick search says that runtimes were deprecated and removed years ago. Apparently Filemaker 18 was the last version to support them. There is some kind of iOS App SDK that may still be supported. It doesn't sound like this would be a quick and/or easy solution, but that seems to be all there is. After Hypercard, there was never the same kind of custom database app community (Clipper, Access, Paradox, etc.) as on PCs. I don't know what you mean by inherited icons. A DMG is just a disk image. Its use in installing software is problematic. Why use a zip files or pkg installer when you can use DMGs that make it 3 times more difficult? Look at the pkgutil tool. All you need is a folder with the app you want to install. Create a directory tree of all the locations where you want to install files. Then use pkgutil to create an installer for that. Forget everything I said about the M

Hi Kevin, Regarding your previous analysis of the KEXT configuration, specifically where you pointed out the IOMaximumByteCount is actually 0x80000 (512KB) in this post. We observed the runtime logs of the legacy KEXT, and the results align perfectly with your observation. Even when copying a 2GB file, the KEXT actually splits the request into 512KB (0x80000) chunks per transfer. [ProcessParallelTask] [KEXT_CHECK] WRITE (0x2a) | T:0 L:0 | Size: 524288 bytes (512 KB) This confirms that our current 1MB limit in the DEXT actually exceeds the behavior of the legacy driver. Since the current setting has passed all data integrity verifications, we consider the transfer size issue resolved and will not pursue larger transfer sizes at this stage. As per your recommendation, we are currently implementing the UserProcessBundledParallelTasks architecture to strictly follow DriverKit best practices and optimize performance (it is currently causing the DEXT to crash, so we are in the middle of debugging it). Than

I have a working walkie-talkie app based on the PushToTalk framework. Everything works fine except for an intermittent bug that I face from time to time on different devices with different iOS versions, from iOS 18 to iOS 26.2 Beta. The next time this occurs, please capture a sysdiagnose, file a bug on this, then post the bug number back here. What you're describing sounds similar to a CallKit issue (r.157725305). A fix is being investigated for the CallKit issue, but if it's happening to the PTT system, then that's something we'd need to address. Once I leave the channel and rejoin it again, the issue is fixed and I start to receive non silent buffers of varying size, as expected. Assuming this is similar to the CallKit issue, this works because it's updating the audio session ID that callservicesd uses to activate your audio session. Unfortunately, that also means that it's basically the only thing that WILL work. __ Kevin Elliott DTS Engineer, CoreOS/Hardware

Once again I get rejected. I removed all references to dating. They just come back and hit me with a 4.3 rating and give me no guidance on what I need to do. I am filing a second appeal, but I haven't received a response from anyone. Here's my new appeal message: My app is not a dating app. It’s a real-world social discovery tool designed to help people meet others while they are out in public spaces. Users can create events, connect with others nearby, and explore Hot Zones, which show where activity is happening in a specific area. I have removed all references to dating to make that distinction clear. I continue to receive Guideline 4.3 rejections, but I have not been given any specific feedback or direction on what changes are required. Without actionable guidance, it is impossible to understand what the review team believes is duplicative or how I can bring the app into compliance. I respectfully request that someone contact me or provide more detailed clarification. I have invested significant

So I guess I'm wondering: is it... fine to now use fdatasync on APFS? Because if it is now fine (as per sqlite's understanding via the Hacker News comment...), then I think there's a bunch of software might be relying on outdated documentation/advice, since: So, the first thing to understand is that what led to F_FULLFSYNC wasn't really the kernel itself's handling of data. The basic issue was that the kernel itself would send the data all the way to disk... and which point the drive itself would stick the data in a write cache and leave it there for an indeterminate but long time. Even worse: Some of these drives were intentionally ignoring the existing commands (and more performant) that were supposed to flush the specific data. These issue were widespread enough across product and vendors that blaming hardware wasn't really feasible. The only solution we found viable was what F_FULLFSYNC does, which is to flush the data and the force the drive to commit the data. I'll also note that issue above was never s