“offloading”

And another found is that on the home Wifi network(which has PPPoE router provided by carrier) with an iOS 14 iPhone the message will be like udp_validate_cksum_internal * udp incorrect IPv4-UDP non-offload checksum * ulen 1506 And the pppoe header length is 6. Compared with previous network with Vlan the error message showed ulen is 1502. I believe there most probably a bug exists somewhere in iOS 14 kernel or in network extension. Since I didn't found such issue under the same condition on iOS 12, this issue may only exists in iOS 14. The reproduce condition is with NEPacketTunnelProvider set the MTU of the UTUN to be a value bigger or equal than 1480(Theoretically we should be able to set this value to a very big size like 65535 and without any problem) or overhead size to be 0, and run it on an iOS 14 iPhone, on a Wifi network which has a Vlan setting or PPPoE, on inbound packets there will be such problem.

Reusing one big buffer instead of many seems like a great idea. Less moving parts the better here. Why the vertices are expensive to compute is mostly a question of scale. For instance, with indirect draw calls I can handle 4000+ chunks of terrain and 25 million+ vertices at 60 fps. With much lower terrain distances the meshing on the CPU can keep up fine, but when I push it there is a lot of frame dropping when moving over the terrain and generating meshes for dozens or hundreds of chunks. Part of this is that my meshing is single-threaded on the CPU, but my experience with Swift multi-threading is so far hit and miss for this kind of thing. As such, parallelism is the entire point of trying to offload this to a compute shader. The process of vertex generation is pretty standard for block/Minecraft-style terrain. We loop through all the blocks in a chunk, and if a block is solid, we check if any of its neighbours are air, and therefore if we should put a quad opposite it. Roughly: for y in i..

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

There could be several reasons why quick replies are not being saved on WhatsApp for Business on iOS 16.3.1. Here are some troubleshooting steps you can try: 1.Check if you have the latest version of WhatsApp for Business installed on your device. If not, update it from the App Store. 2.Make sure that you have enabled the Quick Replies feature in the Business Settings of your WhatsApp account. To do this, go to Settings > Business Settings > Quick Replies and toggle the switch to ON. 3.Ensure that you have granted WhatsApp permission to access your device's microphone and camera. Quick Replies require access to these features to work properly. 4.Try clearing the cache of WhatsApp. Go to Settings > General > iPhone Storage, find WhatsApp in the list of apps, and tap on it. Then, tap Offload App or Delete App to remove it from your device. After that, reinstall WhatsApp and try setting up Quick Replies again. 5.If none of the above solutions work, contact WhatsApp support for further assist

Yes, we have a similar problem: We have two installer plugins, and they have worked fine for 12 years (well, every few years, Apple makes a silent change and we have to adjust). Starting in OSX 10.14 or 10.15, the Installer is not working right for us: does not totally hang, but the GUI is non-responsive. Fortunately, in our design, the installation more-or-less finishes.It definitely looks like Apple changed the Installer app to offload any plugin software into other processes: the com.Apple.InstallerRemotePluginService ... it gets its own PID. In our case, a single Installer has three processes are running: Installer and two InstallerRemotePluginService processes.Our issue is that the plugins are not able to dynamically update controls/widgets on the installer GUI. They are updating a progress bar: but the main/GUI thread in the Installer process is not responding. I guess that software in the InstallerRemotePluginService cannot update widgets drawn by the main Installer process??Have not figured o

Thanks Ziqiao, I'm not talking about the Remove Downloaded feature, but it's definitely something very similar. In the problem scenario, the files are stored in ~/Documents/x and if the users' hard drives get too full, macOS is moving those documents to iCloud automatically, thereby triggering the FileWatcher* to say they've been removed. I believe that behind-the-scenes Optimise Mac Storage almost certainly uses the same mechanism as the Remove Downloaded feature you mentioned (ie 'dataless files) which I'd never heard of till now. Your tech note link gave me some good keywords for further research. If it's true I'm dealing with a dataless file issue, when FileWatcher says a file was deleted can I simply ask fileExists(atPath:) to see if it's actually still there or not? I think a dataless file will still return true for a fileExists call, despite being offloaded? * FileWatcher is just using FSEvents, I believe. Pertinent code is here.

Why? What are you actually trying to do here? More specifically, what do you expect to actually be interacting with your user space component? If you go down this route, then you're telling the system here is a network interface you should use and the system is absolutely going to try and use it. At that point you're going to be forced to try and find ways to keep the system away from the interface you just created... since the point of an network interface is to provide an generic endpoint the system can interact with. Maybe there's a reason you want to do this, but if your ultimate goal is just to communicate with your device, then this seems like an awful lot of work to avoid using IOUserClient. Keep in mind that IOUserClient is sufficiently fast and powerful that there's always a way to do basically ANYTHING you want. Sorry for the confusion. The goal is not just to communicate with the device from our app. We want to expose a network accelerator to macOS — a device that handles the full network stack fro

Hi Kevin, this is extremely helpful — thank you for the depth here. Two takeaways reshape our design: (1) using DiskArb as the primary volume API with ES as a backstop, and (2) treating copy as an inference rather than an observable operation. For an audit product, that pushes us toward separating observed facts (rename, clone, open — things ES reports as true) from inferred semantics (copy, asset movement) that a correlation layer derives. We'll record and preserve the raw events and treat high-level interpretation as a distinct, clearly-labeled layer. One follow-up on running ES in production at scale. Given the message volume you describe on the notify path, is there a recommended approach for keeping an ES client responsive without dropping events — for example, using es_mute_path or related APIs, early filtering of event types, or offloading correlation from the ES callback thread? I want to make sure we don't design ourselves into a position where the client falls behind and events are lost; fo

If there is a way to achieve, then How can I upload/download data after 30 minutes of app went backgrond?.Two things:iOS provides no general mechanism for an app to schedule itself to be resumed at a specific time.If an app is running, it has full access to the network, regardless of whether it’s in the foreground or background. The only gotcha is that devices with WWAN will typically shut down Wi-Fi when the device is locked.I’m confused about your upload requirement. If you’re suspended in the background there should be no need to upload data because you can’t possibly have generated new data that warrants uploading.As far as downloads are concerned, my standard recommendation in this space is to have your app offload the decision about what data needs to be dowloaded to a server. When the server decides that the app needs some data it can send it a silent push notification to the app, in response to which the app can kick off the download.IMPORTANT You can use silent push notifications as a mechan

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

Are all flows funneled through a single serial queue that calls into my subclass? Yes. Should I offload flow processing onto a concurrent queue and then pause the flow and return from my callback? Or just do all processing in the callbacks? It’s kinda up to you. Certainly, I wouldn’t use a concurrent queue for this because I wouldn’t use a concurrent queue for anything (-: See Avoid Dispatch Global Concurrent Queues. However, handing work out to your own code that has its own concurrency model is perfectly reasonable. Now, as to whether that’ll actually improve the performance, that’s a very different question, one that doesn’t have an easy answer. My experience is that most networking code is I/O bound, so getting more CPUs to work on the problem doesn’t help. However, the only way to know for sure is to measure and test. And once I return an allow/deny verdict for the flow … do I no longer see that flow's traffic in my content filter? Correct. What if multiple content filters are present? Are they

No, atomicity doesn't change anything. The value of the property is a pointer (to a mutable array), so atomicity would protect only the accessing of the pointer, not the data structures pointed to.It's a complete waste of time looking for a generic solution, such as encasing random blocks of code in a synchronizing construct. You'll either leave hard-to-find bugs in the edge cases, or hard-to-find deadlocks.In this case, we can't even speculate on a real solution, because we don't know what's going on. We don't even know if scanQueue is serial or concurrent. We don't know what the point of using NSOperation is: is it to get parallel processing, to offload long tasks from the main thread, etc? Maybe NSOperation isn't the best API to use for this, perhaps direct use of GCD is easier. The code you showed has each NSOperation using, or not using, the resulting array of the previous operation, according to the timing of the block placed back on the main thread. We don't know the consequences of this sort

It is November 2020, and my Iphone 6s has just been reset to factory settings because of this. So, no, we cannot assume that Apple has fixed anything in the new updates, nor will they. I've been experience a slow decay of storage space on my, already too compact, 16gb phone. 6gb taken by the storage, so this phone is actually a 9gb phone, sold as a 16gb phone. Over the past 2 months my phone went from the occasional offloading of an app, to having almost 0gb of space. I was so confused, as apple does little to nothing to explain to their customers how to handle the defuncts in the system. I started using icloud, uploading everything possible to it. It did absolutely nothing, nothing at all. You have to go through absurd hoops and hurdles to export your iphone photo library into your computer and separate them from icloud, so that they won't disappear when you delete them off your phone. Learned that lesson before, should out to apple iCloud for losing 500-1000 of my pictures to iCloud in 2018. So, ev

With respect, herein lies the issue. If you were to handle all touch detection only in the SKScene class, that would make it easier to determine which node should receive the touch. However, in any complex system, you would (at least in my opinion) distribute touch handling to objects themselves.For example, I have a Button class that I use in all my projects, which is subclassed from SKNode. Button receives and handles its own touches, so that such logic doesn't have to be repeated multiple times in each SKScene, in each project. Buttons tend to be important elements, so you're likely to find one in each SKScene in your project, making it highly efficient to offload this particular logic to the object class. So when I want to use a button, I instantiate Button in an SKScene, feed it the functionality I want it to perform upon touching and it works out of the box.Since touch handling is distributed, you can't really loop through and consider touch fallthrough per node. Consider a custom scroll view c

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