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.

Hey man thanks for responding. I did think about that, but I am inside the perform() method for a while, so how do I set the boolean state on the Live Activity view from within perform?

OK, thanks

Thanks Quinn for the great explanation. If I really need it I'll file a bug report. Have a great day.