“offloading”

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

All I need is to check the data on the network every three hours and issue a warning when checking.This isn’t really the intended use case for background fetch. The idea behind background fetch is that the system learns when the user is using the app and, if the user is regularly using it at specific times, the system sends the app a background fetch event before that time so that it can refresh. For example:The user might run a social media app regularly throughout the day, so the system would send that app regular background fetch events.The user might run their news app at breakfast time, so the system would send that app a background fetch event early in the morning.The user might have a second news app on their device but never run it, in which case that app would never get any background fetch events.Background fetch does not guarantee regular background fetch events. Indeed, there is no mechanism on iOS that guarantees regular execution in the background.Once your app has checked the data on the networ

hi, one correction to my last reply: point number (3) wasn't quite right (i had it backwards; sorry, it was the last thing i wrote before heading off to bed). it should have been: (3) instead, if you write something like ExerciceHistoryRow(name: exerciceHistory.name!) and you use var name: String for the View, that will be updated properly. be sure to NOT define this variable using @State, because that gives ownership of the View to SwiftUI. and in general, you'll obviously want to pass along more than just date for a single field in the object ... my conclusions about this whole display not updating situation, especially with Core Data objects (one i've been struggling with for some time): passing a reference to an object to a RowView works fine if it is an @ObservedObject -- and if the RowView makes any changes to the object, you'll know about it. however, deleting that object will crash if the RowView is still held onto by SwiftUI when the deletion occurs. (i think the situation is even more murky when usi

Running large models like Qwen3 1.7B on devices with limited resources, such as the iPhone SE 3 with 4 GB of RAM, is indeed challenging. Let's address your questions and explore potential approaches to mitigate the issues you're facing: Observations and Possible Causes Memory Spike During Load: Dynamic Shape Usage: While dynamic shapes can help manage memory allocation during inference by not preallocating for the full context length, the initial loading process often requires more fixed memory to parse the model, set up internal structures, and potentially convert certain operations to formats supported by the hardware. Intermediate Conversion: Core ML might internally convert some operations from INT4 to INT8 or FP16 if the underlying hardware (BNNS/ANE) doesn't natively support INT4 operations. This can cause temporary spikes in memory usage during loading. Memory Limitations: The iPhone SE 3's 4 GB RAM is quite limited for large models, especially if additional overhead from the operating system and other

@somewhereInTime oh wow, I would've expected the built-in hardware of the Mac Mini to actually work with the shipped OS. Thanks for sharing! I specifically bought a OWC TB3 to 10GbE adapter, as it uses the Aquantia AQC107 chipset. According to the previously shared link to the guide on Github: With the above 5 drivers, currently Apple only uses 2 of them in their products: Aquantia is used on all Macs with 10Gbe ie. 2017 iMac Pro, 2019 Mac Pro, 2018 Mac mini Broadcom is used on all 2011+ Macs with 1Gbe ie. 2011-2020 iMacs, 2010-2020 Mac minis, 2013 Mac Pro However - no luck. Offloading seems to work, the used driver is Driver: com.apple.driver.AppleEthernetAquantiaAqtion. But using ifconfig ether still fails silently :( Upgrading to the latest macOS Sonoma Developer beta seems to have solved my other issue regarding WiFi 6E (6GHz), it now detects my AP correctly and actually connects. But regarding wired network adapters I didn't see any changes. As this is my daily driver I will downgrade to macOS V

Hi again,Thanks for the reply. This makes me aware of a number of risks we did not appreciate.Could I just follow up to be sure I understand them right? Specifically, even after we‘ve switched to CA-signed server certificates, you point out two major reasons we should still avoid performing our own server trust challenge evaluation (or indeed handling any authentication challenge) with background sessions:The first reason is we might be penalized by the iOS resume rate limiter:For background sessions specifically, the resumes necessary to handle this authentication challenge counter against the resume rate limiter.Note This applies to all authentication challenges, not just server trust challenges.My question is, is this an issue even if I'm doing something computationally cheap like checking the certificate's common name? In other words, do you mean that any URLSessionDelegate object which implements urlSession(_ session: didReceive: completionHandler:) is a handicap for background execution, because simply