“offloading”

Moving the files to the iCloud folder will still occupy space on your hard drive unless they are automatically offload when not in use. I would recommend to read this documentation how to manage storage in iCloud :https://support.apple.com/en-us/108922 Albert Pascual
  Worldwide Developer Relations.

Hi, Could you elaborate on When overloaded, stale metal render passes need to be 'aborted', which results in metal callbacks not being called.? This approach seems like dynamic load balancing to maximize throughput. It's unclear how well this could work with current Metal API and seems unlikely to be successful with OS watchdogs. Instead we recommend reducing and optimizing workload. Guidance on that can be found in Improving your game’s graphics performance and settings (even though your app may not be a game). You may also want to consider offloading some rendering work to compute to improve efficiency. See Compute Passes.

Can you clarify the circumstances in which mach ports are leaked? Well, the unhelpful (and slightly flippant) answer is basically anytime they're not properly deallocated when they're no longer useful. More practically, the whole reason mach ports create issues IS that it's often quite difficult to connect any given mach port with the specific component responsible for managing that unit. In terms of run loop semantics specifically, I think you'd (potentially) generate a leak anytime you destroy an thread without removing/stopping all of it's input sources*. *Strictly speaking, that isn't necessarily a guaranteed leak. For example, some of our frameworks register thread destruction handlers so to handle clean up. However, at that point you're relying on the details of our own implementation, which is never ideal. Also, keep in mind that this isn't just about mach port leakage, but could involve any other resource who's management happened to be tied to that thread. The while loop in the original post is in a

Has anyone found ways to improve compatibility with other system extensions? That is a really, really hard problem which doesn't really have any easy answer. The first thing to understand here is what the problem actually is. Architecturally, an ES client has two primary concerns to deal with: Process individual events quickly. Minimize activities that generate additional events. In the basic case, the second concern is easy to overlook. It's easy enough for a client to mute its own helper processes (direct workers) and the work being done by other processes like Apple's daemons are (typically) relatively small. As long as the client has certain amount of parallelism, number two can often be relatively hidden. That breaks down once you hit this scenario: Some users are experiencing performance problems when running our extension alongside other system extensions At that point, what you basically have is a pipeline of ES clients which are both generating AND approving auth events for each other. Performance pr

Hi all, I'm looking for the specifications for the accelerometers used in current iPhone and iPad devices, including the sensitivity and the update rates possible. We've never published any formal documentation about what the exact capabilities of the hardware were. However, I have a word of caution around this: Despite the documentation saying it's 100Hz, I've not yet found it to be better than 50Hz on any of iPhone SE, 8 or 11, nor iPad mini or Pros. Having worked with many developers using CoreMotion, I've seen the same pattern happen MANY times: A basic motion analysis engine is implemented, typically using the real time API and the with a target queue. The main thread or other busy thread are entangled with that algorithm, either because the code is running directly on that thread or because of implicit relationships which aren't as visible. Testing begins and the results are somewhat positive, however, there are issues with random data glitches or other oddities in the data. The assumption is made that

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.

Despite the possible implication with this message, this action does not actually remove the apps and reinstall them. The apps are actually only offloaded, which will free up storage used by the app but keep its existence on the device. This will not result in things like identifierForVendor, push tokens, etc. changing, any app data like documents, and app settings being lost. Argun Tekant /  DTS Engineer / Core Technologies