offloading

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

This answer is for home routers. Much of the bufferbloat on the internet is on the home router and ISP head ends. There is only so much you can do end-to-end - and the advice in the video is primarily targeted at LTE <-> server interactions. Definitely take a hard look at your server behaviors as I wrote above! I've written a lot and given many presentations on the bufferbloat problems in the typical home or office network, one of the more amusing is here: https://blog.apnic.net/2020/01/22/bufferbloat-may-be-solved-but-its-not-over-yet/ To improve the ISP link... encourage your customers to get better home routers with Smart Queue Management (SQM), and fq-codel for the wifi. It's universally available from third party router firmwares like openwrt, dd-wrt, merlin, and tomato. It's also available for most gamer routers (netduma calls it anti-bufferbloat), it's the premier feature of the evenroute (eero also), ubnt's edgerouter products and the udm pro also have sqm. IP fire, tangledOS also, it's a really