offloading

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

I'm having the exact same issue. The OTA updates don't work well because of limited space. Even when I do clear enough space by offloading apps, the required space goes up and it always tells me I need more. Tried updating today via IPSW and getting the same error.

[quote='757385021, xiazhvera, /thread/757385, /profile/xiazhvera'] I'm working on an MQTT client for Apple platforms (macOS, iOS, and possibly tvOS and watchOS). [/quote] The story here varies by platform: For macOS, it’s possible to run indefinitely in the background. watchOS has significantly more restrictions than iOS. See TN3135 Low-level networking on watchOS for the details. tvOS generally follows iOS, except that one of the common workarounds, push notifications, is not available there. The rest of my response focuses on iOS (including iPadOS). [quote='757385021, xiazhvera, /thread/757385, /profile/xiazhvera'] it seems that my best bet is to use a long-running background process with BGProcessingTaskRequest while setting up the connection. Does that sound like the right approach? [/quote] No. Quoting iOS Background Execution Limits: To request extended background execution time, typically delivered overnight when the user is asleep, use BGProcessingTaskRequest. So, unless you just happen to want to run

Is Core Telephony APIs (CTGetSignalStrength class) appropriate in this case That class isn’t part of the public iOS SDK. If you have questions about it, you’ll need to raise them with your carrier contact at Apple. Honestly, I think that’s a good way forward here in general. One expected use case for the hotspot helper subsystem is to help carriers offload traffic to Wi-Fi. There are carrier-specific aspects to this that I’m not really up-to-speed with (because they involve stuff that’s not in the iOS SDK). Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

You're not alone. Here's why it happens and what to do: Cause: System files, caches & incomplete iCloud sync can eat up space. Fix: Restart, offload apps, check iCloud settings, update iOS (if needed). Last Resort: Backup & restore as new (erase all content first!).