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)

Hey thanks for responding. What's puzzling is that widgets updating from app have basically zero problems. It's only when the live activity is the one updating. To me, it would make sense that since the docs say that button presses from widgets are not subject to the budget, neither should live activity button presses be subject to the budget restrictions for updating the widgets, but it seems not. Is it possible to confirm that live activities ARE restricted by the update budget? In that case, I can at least know that I don't have a bug in my app.

Rico, thanks for response. That's a great hack :) It feels strange though to go through all those hoops and unnecessary server traffic for a local-only need, when it could be solved by letting the user give the app permission or something. It could be a dialog like it is for live activities now, but for background initializations?

Thank you so much, Frameworks Engineer! :)

Hey thanks for responding. Yeah sure I know what to do to try and fix it, my question was more about why it looks so different :)

Hey, thanks for responding so quickly. Yeah we only have png images. They're defined as a resource in the widget target. I have found one resource that works that I was using in the "minimal" view, but other images that are in the same resource collection don't work. Could it be a size issue?

But it's not semantics or 'my opinions' - I'ts wrong. Xcode highlights the line locationServicesEnabled() and suggests I should instead wait for locationManagerDidChangeAuthorization which does not do the same thing. Your answer "locationServicesEnabled() has everything to do with authorization" is simply incorrect and it's unfortunate that it becomes a highlighted answer next to my original post. I want the warning to go away, but the remedy suggested by Xcode will not solve the problem. I suppose I do agree that it's fruitless to argue any more. :) I'll try and file a support ticket.

Hey there, I think that maybe there's a way if you took a look at the new Location API's Apple released last year, CLLocationUpdate.LiveUpdates I think this might work even if app is force killed, but check the docs and wwdc videos, I'm not sure

..and in case anyone is looking at this, it's not fixed in beta 8 either.

Hmm. It feels very scary to argue with an Apple engineer, but I have to make sure I'm not being unclear. From Apple's doc: CLLocationManager.LocationServicesEnabled(): Returns a Boolean value indicating whether location services are enabled on the device. CLLocationManager.authorizationStatus The current authorization status for the app From the documentation, it seems pretty clear. Please consider my short code snippet at the bottom. If I go into settings/privacy and turn the "location services" global checkbox back and forth, the locationServicesEnabled method returns true/false My authorisation status does not change, and when I turn the global setting back I still have the authorisation status I had before. This is why the error message seems strange to me. Saying that I should look at the authorizationstatus-callback to know whether the user has enabled location services globally is to me confusing two different things? EDIT: To be super clear, I have the didChangeAuthorizationStatus implemented since a long time. It is called when you click around on the "always"; "in use" etc. options for my app. It is not called when I turn location services on and off, which is the call that Xcode is warning me about. Snippet: CLLocationManager *man = [[CLLocationManager alloc] init]; //Returns a Boolean value indicating whether location services are enabled on the device. BOOL enabled = man.locationServicesEnabled; //The current authorization status for the app. CLAuthorizationStatus stat = man.authorizationStatus; [DialogUtils showBannerWithHeader:@"CHECK" message:[NSString stringWithFormat:@"Enabled? %i AuthStatus: %i", enabled, stat] type:MessageTypeINFO];

Hey thanks for great responses! I am currently looking at extensions. this way, I can have the MyLoggingClass contain the code that works everywhere, and then in an extension to MyLoggingClass, that I put inside the App only, I override the "doNotification"method to contain the logic to see if the app is running. This way, in the extension the "regular" method will be called, and in the app the overridden method will be called. This would work right?

Just checked beta 7 that was released just now, it wasn't fixed there.

Hey Argun, thanks for responding. I'm using it on an iPhone running the beta, yes, but not beta Xcode. Would that be affected? EDIT: Thanks, I tried myself and can verify that it's a bug on ios18. Tried on my wife's phone and it's only called once there.