offloading

Update: Refining the Architecture with LLMs (Gloss-to-Text) I've been refining the concept to make development faster and less data-dependent. Instead of trying to solve Continuous Sign Language Recognition purely through computer vision (which is extremely hard), we can split the workload. The Hybrid Pipeline Proposal: Vision Layer (ARKit): Focus strictly on Isolated Sign Recognition. The CoreML model only needs to identify individual signs (Glosses) based on the skeleton data. It treats gestures as Tokens. Input: Skeleton movement. Output: Raw tokens like [I], [WANT], [WATER], [PLEASE]. Logic Layer (LLM): We feed these raw tokens into an On-Device LLM (or API). Since LLMs excel at context and syntax, the model reconstructs the sentence based on the tokens. Input: [I] [WANT] [WATER] [PLEASE] Output: I would like some water, please. Why this is faster to build: We don't need a dataset of millions of complex sentences to train the Vision Model. We only need a dictionary of isolated signs. The grammar part is offloaded

Volume does not implement both maxFileSizeInBits and maxFileSize, while one of them must be implemented. Implementing this didn't seem to change the result. But I definitely do need to fix the sample FSKit project I've been copying as a base for all of these bug reports, then! Have you looked at what the actual block size of that device is and what FSBlockDeviceResource.blockSize is? Both physicalBlockSize and FSBlockDeviceResource.blockSize are 512 on the disk image. However, there are other issues. Your testing with a disk image, but the disk image block size is 0x200/512, NOT 0x1000/4096. If you’re looking at those values from the volume side, you may get 4096, but that's because the volume changed what stat returned, not because it's actually true. ... In your particular case, this also means that the stat value you're returning is 4x larger than the underlying FSResource size. That isn't necessarily wrong, but that's because the VFS layer will basically believe anything you tell it, not because that's wh

I've also been seeing some other issues related to certain things I set in the FSKit API not showing up in statfs (mainly the volumeStatistics's blockSize and ioSize, FB21106711). Actually, I think the size problem might be on your side. So, first off, your test implementation is incomplete. This is the last message logged by your extension: 2025-11-20 12:56:06.891883-0800 FSKitSampleFilesystem: (FSKit) [com.apple.FSKit:default] -[FSModuleVolume(Project) getMaxFileSizeInBits]: Volume does not implement both maxFileSizeInBits and maxFileSize, while one of them must be implemented. Shortly after which, lifs (the kernel support KEXT for FSKit) logs: 2025-11-20 12:56:06.891917-0800 kernel: (lifs) lmp max_filesize 0x7fffffffffffffff 2025-11-20 12:56:06.891927-0800 kernel: (lifs) lifs_io_strategy_thread: thread starting for mount 2025-11-20 12:56:06.891936-0800 kernel: (lifs) Failed to open block device /dev/disk7, err: 16 2025-11-20 12:56:06.891937-0800 kernel: (lifs) unknown: isssd 0 devblksize 512 devreadsize

Thanks so much, @tbartelmess1—this is super helpful, and really appreciated a bit more context from our app: App context (what we store) The blobs we persist will be user-generated cruise photos, we would downsize those to more manageable size as iphone format photos can be quite big, but they would still be in the 1-3 mb after downsizing Realistic volume per active user: a few hundred images/year; heavy users could reach low thousands over time. Decision: use Core Data Binary Data + “Allows External Storage” We’ll keep originals as Binary Data (Allows External Storage) so Core Data handles externalization transparently, my philosophy has always been to offload as much work to the system services as possible. We’ll keep thumbnails as well inline in coredata (let coredata decide but likely will be inline (blob)). CloudKit mirroring We’ll rely on NSPersistentCloudKitContainer mirroring; we understand CloudKit decides when an attribute becomes a CKAsset independently of Core Data’s externalization thres

You're welcome. We're here to help. Seems like you're flying with insight w.r.t. limitations of ANE on iPhone. Challenge question: are you certain image resizing is too resource intensive, particularly if offloaded to GPU?

Oh, interesting. This actually came up when I filed a different bug where kernel offloaded IO wasn't working (FB17773100). At first, it was closed because I didn't include that key (since it wasn't documented or in the template), but it still didn't work after adding that key until macOS 15.6 beta 3, where it's now fixed. Adding some background context, the reason the key exists is that because kernel memory is involved, we wanted to make sure it would only occur in clients that explicitly asked for it. The metadata I/O APIs also involve kernel memory, which is why it ended up being limited by the same plist key. For anyone else who finds this thread, FB18614667 is fixed in macOS 15.6 RC (24G84). Yep. It's always tricky to talk about future stuff, but it's often the case that the bug fix is already on its way to shipping when I'm writing about them. __ Kevin Elliott DTS Engineer, CoreOS/Hardware

FSSupportsKernelOffloadedIO Oh, interesting. This actually came up when I filed a different bug where kernel offloaded IO wasn't working (FB17773100). At first it was closed because I didn't include that key (since it wasn't documented or in the template), but it still didn't work after adding that key until macOS 15.6 beta 3, where it's now fixed. Interesting to see that metadata{Read,Write} is linked to that at the moment. It was indeed the case that adding that key made it work. the FSKit team is working very hard to ship as many fixes as possible in macOS 15 (not just macOS 26) Yeah, I have noticed that the FSKit team has generally been quite responsive and good at updating the statuses of feedbacks I've filed recently. Highly appreciated, by the way! No, or at least not exactly... Interesting insight! I mostly come from a background (or lack thereof) where I kinda just started working with filesystem code first with FUSE as a small thing (for a school project) and found it interesting, then FSKi

So, let me get the bug out of the way first: I reported this as a bug (FB18614667), but also wanted to ask here in case this is actually just me doing There are actually two bugs here: FSSupportsKernelOffloadedIO is the Info.pist key that marks whether or not to use FSVolumeKernelOffloadedIOOperations to shift file I/O into the kernel. We haven't actually documented that key, but there's actually a more general bug on that (r.156162068), which is to consolidate and document all the FSKit's Info.plist keys. That Info.plist key is currently restricting the metadataRead/Write APIs, which it really shouldn't (r.155070316). That is, you should be able to use metadataRead/Write, even if you don't offload I/O. I can't comment on our release schedule, but the fix is straightforward and the FSKit team is working very hard to ship as many fixes as possible in macOS 15 (not just macOS 26). In terms of what you do now: Once #2 is fixed, I believe your code will “just work”. I think it's perfectly reasonable to a

and someone tried removing all cards, removing apple wallet, restarting and reinstalling it ? if I understand well, the problem comes from the wallet notification not coming at the good time so resetting maybe can make the trick . BTW got the same problem, when I pay with apple wallet, dont got the wallet notification, so the shortcut return failed . tried resetting, rewritting the shortcut, offloading shortcut etc nothing work, so maybe the problem is wallet ? ps: how did you founded the shortcut trace ?

These are the Developer Forums, where developers of apps for Apple's platforms ask each other for hints and tips on coding. Your question is more of a product support one, so I'd suggest you ask it over at the Apple Support Forums. Thanks. System data is the System, i.e. iOS plus necessary files such as logs and cache files. That number will stay pretty static. There's not really a lot you can do to reduce that. Try and offload some of your data to iCloud. Enable iCloud Photos and turn on Optimise iPhone Storage in Settings > Apps > Photos. Regardless, you have a 64GB iPhone, which isn't that big these days. It might've been fine five years ago, but not really now.

I’m still not entirely sure I understand where you’re going with this, but let’s start with some basic info. First, this header is defined by the virtio spec: https://docs.oasis-open.org/virtio/virtio/v1.1/virtio-v1.1.html Next, my general advice is: On the transmit path (packets from the VM), the virtio header can be used to indicate whether checksum offload is requested or not, and also whether they are transmitting a TCP large segment (TSO). On the receive path (packets going to the VM), the virtio header communicates whether the checksum has already been validated and doesn’t need to be checked. It can also indicate a large receive offload packet and the number of segments that were aggregated. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com