offloading

AFAIK, offloading expects the app to be in the store.Perhaps an MDM vendor would be able to provide a replicated process that works w/internally distributed apps that reside on your own servers.

We recently solved a similar issue by removing one of our contexts. We had our a main queue context writing into a private queue context which would then write to the persistent store coordinator (Same as your root context). This was done to offload saving to disk to a background queue. On iOS 12 beta 5, this seemed to be causing the deadlock. We pointed our main queue context to the store coordinator directly, and removed the final private queue context, which resolved it. Write now happen on the main thread, but the app runs.

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

I've observed the same behaviour with one of our Apps - if the App is offloaded, the device will continue to recieve push notifications. Since the App is (effectively) uninstalled, it seems that there's not delegate to call-back to, and touching the notification banner does nothing, doesn't even show a message that the app has been offloaded that you would see when you touch the App icon. This behaviour persisted for me for a couple of days, although I haven't tested longer than that to know if it the APNs token remains valid indefinitely. I likewise was unable to find any definitive developer documentation about how offloaded apps effect push notifications (or technical documentation on offloaded apps in general). Were you able to find any information Sumanth?

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

Same here. What worked for me was deleting the ‘prepared’ install bits, from the iPhone Storage settings after the install failed a couple of times, then re-downloading. The subsequent attempt to download completed, “prepared”, and “verified”, and successfully updated the phone (iPhone 7). [For the curious, I have a 128GB iPhone 7, which has about 60GB free. Ample space for the OS to download the update bits, expand them, and do what it needed to do to effect an install without offloading apps or other data to introduce confounding variables to the process.]

You're right Scott. Offload unused apps somehow was enabled. It did an awful job of determining inactivity. For example it removed 1Password which I use seveeral times a day. It also blew apart most folders and couldn't bring apps back as advertised.Thanks,Tom

Have you checked to see if your Offload Unused Apps is enabled? Is it possible that these are apps that you have not used in a while and the new OS has removed them from your device due to inactivity in order to free up space on your phone?

From what I have been reading, APFS changes how Fusion works. It's now just a cache repository for meta data, readback cache and writeback cache. It will assist in directory listing. App Nap, Prelinking and directory lookups would likely be the most impacted.I do not know if it will offload files to the SSD that are frequently used like in days past. I'm not saying this is fact but supposition based on what little information I've found so far. The nature of APFS means it is always optimizing content in order to reduce fragmentation so logically it makes sense that it would work off of the HDD and use the Fusion as a cache - such as that for app nap. Anyone else have insight on APFS and Fusion topology? Has it changed Fusion fundamentally?

I understand that UIKit is not designed to be thread safe, and that generally long running tasks need to be offloaded to other threads to avoid blocking the main thread.I'm just currently making UIKit do a lot of work - animations, autolayout etc. Which cannot be offloaded to another thread - therefore being a prime candidate for the creation of another UI thread and everything that goes along with that.So what I want is sounding to be unlikely.I want to be able to duplicate my application into another window and have the second window not interfere with performance of the main window.Without significant rewriting effort.Another UI thread working on the separate window would solve my problem immediately and gracefully.I do appreciate all of the comments though.So, thank you.