“offloading”

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

Discussed this more with cross-functional teams and not using keys a no-go. This will not work if you want to share localization efforts across platforms beyond Apple which is more of a real-world scenario especially in enterprise settings. For example, Android requires localization keys to not have dots and other kinds of characters, also we found many 3rd party localization services had a character limit on key length. And when looking at very long localization entries, using the value as the key just doesn't make sense. I think sticking with my first intuition in using localization keys is the right way despite all the Apple sessions and samples showing otherwise. Also, just to share I was able to achieve isolating localization configurations by extending Text views to initialize from other Text views. This way, I can offload the localization configurations off the view by creating a bunch of static Text views and let the rest of the app pick them off the shelf. First I create the simple but awkwa

[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

Volume does not implement both maxFileSizeInBits and maxFileSize, while one of them must be implemented. Implementing this didn't seem to change the result. But I definitely do need to fix the sample FSKit project I've been copying as a base for all of these bug reports, then! Have you looked at what the actual block size of that device is and what FSBlockDeviceResource.blockSize is? Both physicalBlockSize and FSBlockDeviceResource.blockSize are 512 on the disk image. However, there are other issues. Your testing with a disk image, but the disk image block size is 0x200/512, NOT 0x1000/4096. If you’re looking at those values from the volume side, you may get 4096, but that's because the volume changed what stat returned, not because it's actually true. ... In your particular case, this also means that the stat value you're returning is 4x larger than the underlying FSResource size. That isn't necessarily wrong, but that's because the VFS layer will basically believe anything you tell it, not because that's wh

Thanks so much, @tbartelmess1—this is super helpful, and really appreciated a bit more context from our app: App context (what we store) The blobs we persist will be user-generated cruise photos, we would downsize those to more manageable size as iphone format photos can be quite big, but they would still be in the 1-3 mb after downsizing Realistic volume per active user: a few hundred images/year; heavy users could reach low thousands over time. Decision: use Core Data Binary Data + “Allows External Storage” We’ll keep originals as Binary Data (Allows External Storage) so Core Data handles externalization transparently, my philosophy has always been to offload as much work to the system services as possible. We’ll keep thumbnails as well inline in coredata (let coredata decide but likely will be inline (blob)). CloudKit mirroring We’ll rely on NSPersistentCloudKitContainer mirroring; we understand CloudKit decides when an attribute becomes a CKAsset independently of Core Data’s externalization thres

Oh, there are so many pitfalls here )-: The System keychain is a filed-based keychain. To modify it you must have file system permissions to change the file. That means running as root. Using sudo for this is tricky because of execution context issues. There are two relavent bits of execution context here: BSD and security. The sudo command changes the first but not the second. That can result in a lot of ‘fun’ edge cases. In this specific situation I think the only relevant edge case is the default keychain, which is easy to work around. However, keep an eye out for this in other situations where you use the security-related APIs from sudo. Note TN2083 Daemons and Agents talks about execution contexts in some detail. File-based keychains use an access control system based on ACLs. If program A adds a keychain item and program B tries to access it, one of two things happens by default: If B is in a GUI context, the user gets a dialog asking whether to allow this. If not, the access fails. Your -T argument is