Mr. Eskimo, huge thanks for a great response. Not 100% about "mode to the networking layer", do you mean basically add Thread.sleep on the server when testing? I will take your suggestions to heart. It's great since i'm also rewriting my objc networkhandler in Swift. Just a final belt/suspenders-question: If i understand you correctly, most applications should just perform the request regardless, wait for the API response/timeout and not bother at all with NWPathMonitor ?

I am not sure what that has to do with anything? I am reporting a bug in UIKit, a pretty popular framework that you support, while noting that i've found several apps, being sold on the app store, that show similar behavior. I have taken time off a busy schedule to report a bug, discuss and even put together a full project to display the issue. It would then be useful to hear someone say "yes it does look like something is off here, we'll look at it." To Instead being rewarded with critique on the quality of my app, of which you've basically only seen one line of code does not encourage further bug reporting. FURTHERMORE, while the code line above is Objc, my entire test project that i submitted is Swift, showing the same behavior. But i guess that confirms that you didn't look at it. I am aware that parts of my app is objective C and that Swift exists, but thank you for reminding me.

It would have been nice with an acknowledgment from someone, anywhere, that "Yes your eyes do not deceive you, we also can see the issue."

Yeah, my process is basically when i get a trigger: check network status (the old, lame way :) ) if network down or other issue, create local notification failure user explanation and exit if all good, get a background task id and start working It was a long time since we initially evaluated this, but back then we had issues with being killed off mid-flight sometimes. As you can perhaps guess, i didn't document everything, and it's totally possible that we did something wrong or that whatever wasn't working 100% right now. So, what you are saying is that i should not bother with NWPathMonitor (or the one i'm using right now) at all? just fire off the request blindly and wait to see what happens?

When we made this, like back in 2013, we (thought we) had situations where the system killed the geofence trigger before it had a chance to complete its network request. The thought was that if we checked the network status before we do the actual http request, we reduced the risk of the trigger being killed before we had a chance to put up a notification explaining to the user that we failed and why. We do the whole UIBackgroundTaskIdentifier but back then the documentation (we thought at the time) made it a bit uncertain if we could be sure that we'd always get a chance to finish and clean up properly.

FB21298709

In addition to my comment to your post: i tried the demo project on 26.2 and it's still there.

Yeah, i've seen that tech talk, and i know it's deprecated. I know the limitations and agree, but i mean, it wasn't deprecated before :) None of the texts refer to situations where you only have a short time to do your thing, such as a network request in response to user interaction from a live activity or a geofence trigger like we do a lot. For our geofence triggers for example: It's crucial for us that if a network request fails in the trigger, we can end it by posting a local notification to the user "the thing failed because of X". This won't happen if the system kills the trigger in the middle of the request waiting for network connectivity. In that case, it's better with a false positive for us, than nothing at all, because then we can be certain that the user is informed.

Please find attached a small demo view controller i made that shows the bug. It looks as expected prior to 26.1 but is bugged in 26.1 and onwards. (i tried attaching a zip of the entire project but alas not allowed here) Demo view controller

I guess not :)

i am using xcode 26.0. If i deploy it from there on my phone running 26.1 or 26.2 i get the strange flip. but if i instead deploy it on one running 18.5 (all iphone pros) , the animation is wrong.

Hello, in addition to here and a support ticket, I now also went ahead and created a bug report, FB15909487. I would also really appreciate further discussion in this thread.

Hey huge thanks for responding and sorry for being late I missed it! OK. A couple of comments: 1 - Your last comment, it's not accurate. In our app, we have Lock Screen widgets. They are visible at the same time and it looks very strange that they do not get updated when the live activity does. If you do it from the Dynamic Island and have a widget below on the Home Screen, you can see it there too. This is a big reason to why we think it's so bad. 2 - It's not really an issue if the widget being updated 5-10 seconds, or perhaps even 30 at times. However if you run my example app you quickly see that often the widget isn't updated at all, even hours later. 3 - This happens a lot. We have been running this for weeks, and we quickly get in to situations where the widgets aren't updating for hours or for the rest of the day even though the live activity has been updated over 50 times. Again, always works in Xcode. To me, it's clear that this is not a battery or prioritization issue because it happens consistently after a while. This is why I mentioned the "budget" thing possibly being an issue despite the documentation saying otherwise. 4 - I've seen this behavior in other apps that have both Lock Screen widgets and live activities. To summarize: To me, this is an obvious flaw. It provides a bad user experience. If you tested my simple project, surely you saw this? So, my final 2 questions are these: 1 - I am not doing anything wrong as in the code has errors that can be fixed? The inconsistent or skipped updates is working as intended? 2 - Should I create a bug report? Would be great with a confirmation/response so that we can think about whether to actually go live with this. Again, thanks for your time, appreciated.

Hi there, any chance of an update here? As I mentioned I tried to use up one of my 2 code-level support tickets, no response there either.

Hey, I already have a case-id, 9879068 is that good or do you need me to file something separate? (I have included my test project in that ticket)