“offloading”

[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!).

My desired result was to monitor my pool filler That’s not really feasible to do directly from iOS. The best way to solve this problem is to stand up some separate hardware that connects to the accessory with MQTT and, when the state changes, sends a push notification to your app. That hardware would be mains-powered, which offloads the energy impact of this task from your battery-powered iPhone. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Yes there is an issue with app storage in iOS 17, The cache data is somehow not getting erased from the app resulting in apps taking too much storage space. As off now only way is to offload the app or reinstall it, but the issue keeps on occurring. Waiting a soultion from Apple in the next update ASAP.

I tested 20 times, on simulator, both in Portrait and landscape. onAppear always called. Please explain exactly how you get the error, and which versions you use. On simulator or device ? For the meaning: offloaded means the view is offloaded from view hierarchy and will be reloaded after.

I tested with Xcode 14.2, iPad simulator (iOS 16.2) and it works as expected. on appear on topic Topic1 on appear on topic Topic2 on appear on topic Topic3 on appear on topic Topic1 on appear on topic Topic2 on appear on topic Topic3 Take care that onAppear is only called when view is loaded. May be in your case, view is not offloaded and reloaded ?

Clearing the cache can potentially resolve the issue if it is corrupted. To clear Cash App's cache on your iPhone, open the Settings app, go to General, Scroll down and tap on “iPhone Storage”, locate the Cash App and tap on it, Tap on “Offload App.” Confirm the action when prompted.

Are all flows funneled through a single serial queue that calls into my subclass? Yes. Should I offload flow processing onto a concurrent queue and then pause the flow and return from my callback? Or just do all processing in the callbacks? It’s kinda up to you. Certainly, I wouldn’t use a concurrent queue for this because I wouldn’t use a concurrent queue for anything (-: See Avoid Dispatch Global Concurrent Queues. However, handing work out to your own code that has its own concurrency model is perfectly reasonable. Now, as to whether that’ll actually improve the performance, that’s a very different question, one that doesn’t have an easy answer. My experience is that most networking code is I/O bound, so getting more CPUs to work on the problem doesn’t help. However, the only way to know for sure is to measure and test. And once I return an allow/deny verdict for the flow … do I no longer see that flow's traffic in my content filter? Correct. What if multiple content filters are present? Are they

Reusing one big buffer instead of many seems like a great idea. Less moving parts the better here. Why the vertices are expensive to compute is mostly a question of scale. For instance, with indirect draw calls I can handle 4000+ chunks of terrain and 25 million+ vertices at 60 fps. With much lower terrain distances the meshing on the CPU can keep up fine, but when I push it there is a lot of frame dropping when moving over the terrain and generating meshes for dozens or hundreds of chunks. Part of this is that my meshing is single-threaded on the CPU, but my experience with Swift multi-threading is so far hit and miss for this kind of thing. As such, parallelism is the entire point of trying to offload this to a compute shader. The process of vertex generation is pretty standard for block/Minecraft-style terrain. We loop through all the blocks in a chunk, and if a block is solid, we check if any of its neighbours are air, and therefore if we should put a quad opposite it. Roughly: for y in i..