John, my project is the same, like 9 years old, objective-c project (not even using ARC!). If you find out anything, I'd be very happy if you'd let me know. We're a small shop with one developer across all technologies and in the given situation, right now it's hard to find time to spare to look at things. I also hope Apple will notice this.

Hi, little bit late to the game, but i just got this in my app after compiling with xcode 13. I followed the advice from @Rincewind and got it working, with one exception: When you change the appearances, the navigation text, is then black, not white. The back arrow is still white though. I managed to sort this out by doing the "largeTextAttributes"-dance : coloredAppearance.titleTextAttributes = [.foregroundColor: UIColor.white] coloredAppearance.largeTitleTextAttributes = [.foregroundColor: UIColor.white] However, i am surprised that this is not mentioned by anyone in this thread. Howcome i am the only one having this color issue? Am i missing something? Pointers appreciated.

@cblaze22 asked for an Objective-C version. Here: UINavigationBarAppearance *navBarAppearance = [[UINavigationBarAppearance alloc] init]; [navBarAppearance configureWithOpaqueBackground]; navBarAppearance.backgroundColor = [UIColor blueColor]; [navBarAppearance setTitleTextAttributes: @{NSForegroundColorAttributeName:[UIColor whiteColor]}]; navBar.standardAppearance = navBarAppearance; navBar.scrollEdgeAppearance = navBarAppearance; [navBarAppearance release];` ```

I came in here to look for exactly this. We have an app with a Geofence function, and since IOS15, it happens that the app just stops getting geofence triggers after a couple of days without opening the app. if you just open and shut the app down, the geofences start coming in again.

Hey, thanks for responding. Ok, that was clarifying, however I must as a follow-up question. If it is created twice, once for light, and once for dark, why am i seeing it being redrawn on-screen? My widget should be displaying the "dark mode version", so it should not be visibly reloaded (i.e. the number changes twice) just because light mode is created? EDIT: Also, as a side note i just came to think of - If my widget does not support dark/light mode, i.e. it always returns the same, as in this case, wouldn't make sense that i could config that? If my widget takes a lot of resources to create itself (like heavy network calls, calculations etc), it seems like a waste to create the same thing twice, or more, times.

Hey Quinn, super sorry for late response, but thank you for responding :) (i missed it) The tip about shortcuts is good however i worry, i'm sorry, that getting our regular users to go in to Shortcuts and fiddle in the app will be hard. Many are not very tech savvy. Ah well, too bad.

Same here, what gives? Would be great with some direction from @Apple

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

OK, thanks

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?

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.

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

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?

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];

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