offloading

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

@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

Thanks again @meaton for all the helpful replies!As I said I would do, I tried to reproduce it a lot of times, including uploading big files (3GB, 5GB) and it didn't reproduce on my Mac.However, at the customer, it reproduced easily, even with small files - she tries to upload 3 files of ~10mb each, and it happens.I checked again her Console logs, and no sign for utun_output or ctl_enqueuembuf, but those line seems related:default 17:27:22.110479 -0400 symptomsd NWPath: kNetworkPrimary NWPathStatusSatisfied interface en1 index 6 default 17:27:22.110535 -0400 symptomsd primary interface change to en1, type 1 default 17:27:22.110692 -0400 symptomsd Primary change default 17:27:22.110754 -0400 symptomsd noi: NOI: v:0 type:Wifi, isAny:yes, isBuiltin:no, loi:-1, flags:0, event: kNotificationNewPrimaryInterface, oldLoadedLqm: 100, rawLoadedLqm: 100, newLoadedLqm: 100, not posting default 17:27:22.118243 -0400 apsd Looking up connection on peer: d573aec0 found default 17:27:22.118320 -0400 apsd Looking up connection

I was struggling with having over 500gb used of 1TB with over 300gb dedicated to Other Initially, I had 200gb worth of videos that I offloaded, then removed from the deleted folder. Seems that the needle didn't move much and for nearly a day, it stated I had 85gb worth of videos left. After seeing the alarm comment with 35gb of data, it hit me. I was using FilmIC Pro to record some of my videos because it has a pause feature which is really nice. I do have it set to save to my photos album, but FilmIc uses a system folder (maybe because it is hidden) to record the video before it transfers over to Photos. FilmIC can also be setup to not sent anything to the photos album. It has its own camera roll. So, it is a matter of choice. I choose for it to go to the photos folder so that I can see it immediately. So why didn't FilmIc clear the cache I wondered. I rebooted the phone earlier and it didn't work. So then, I opened up the photos app, looked to ensure nothing was in deleted folder, then swiped up to