No, I din't implement intentUI. The code I posted has worked since iOS 12 until iOS 14.2 with no modifications. I do not see anything in the docs or WWDC sessions which suggest that in iOS 14.3 you should do more to show up as an action in the Shortcuts app...

Thanks for confirming it won't work in an Objective-C app and that the user interface won't update with the wrist down. It is a pity some new features are only being brought to SwiftUI. This app has been available since WatchOS 2.0 and the work to port it to get this feature is not currently worthwhile. Maybe in the future, when more new features are cut out from Objective-C.

Same here. My app is written in Objective-C (most of it), has location updates and audio background mode. When testing in iOS 16 beta 7, I can reproduce the issue. The app plays a warning when approaching some locations while driving. In a long trip I did today while I was testing the app on the road, I could reproduce the issue all the time. Audio is working on the foreground, but as soon as I lock the device, audio does not work. I have just tested in the simulator, and in the simulator it is working fine. Background audio has worked in my app in the last releases of iOS with no issue. It is the same code I am using with iOS 16 beta 7. Any idea? Thank you.

Well after more testing, background audio is working for me. What seems different between iOS 15 and 16 is: [AVAudioSession sharedInstance].currentRoute.outputs In iOS 15, it seemed to work in the background and with not activation of the audio session, so I could check if the device was connected to CarPlay. It seems that in iOS 16 it doesn't work that way, so I have changed my code to compensate. This is what caused for me that audio did not seem to work, I was sending the audio to a route different from CarPlay, when the device was connected to CarPlay. Regarding the original question, do you have an active Audio Session when you are in the background?

I also do have the same question. When Standard Widgets are configurable, it seems really weird to provide a mechanism in the app to configure just Lock Screen Widgets. I have tried all kind of long presses everywhere, but no luck so far.

Thank you very much. Indeed I had not figured it out yet. I had tried a number of combinations, including this one, but most of them with long press. It is strange you edit other widgets with long press and lock screen widgets with a single tap...

It turns out the audio session was active when changing the category, and this worked in foreground, but in background failed, although this had worked in several iOS releases before. This is the Stack Over Flow thread which gave me the clue: https://stackoverflow.com/questions/73349619/ios-16-beta-5-avaudiosession-setcategory-produces-strange-error-what

I filed the feedback request: FB11928291 I hope a policy update will reconsider this use case. Thank you.

Do "available" and "installed" still mean the same in iOS 17? When I use "speechVoices" I get voices such as "grandpa" and "grandma" and others which do not produce any sound. When I check the available voices in Settings > Accessibility > Spoken Content > Voices, these voices are not even listed there or are inside the voice "Eloquence" I was thinking about letting the user choose the voice for TTS, but it seems unfeasible now, I would have to warn the user to test the voice first to see if it works... Is there something I am missing? Is there another way to know if a voice returned in "speechVoices" is really available for TTS?

It seems that my code was not ready to work with the voices which have a sample rate of 16000. This caused the issue with the sound, it was not related to voices returned by AVSpeechSynthesisVoice.speechVoices not being available. Everything is working fine in iOS 17.

If I do the following: buttonConf.titleLineBreakMode = NSLineBreakByClipping; ... button.titleLabel.adjustsFontSizeToFitWidth = YES; adjustsFontSizeToFitWidth seems to work. Is this the intended behaviour? Or could this break in future releases? Thank you.

No, I never got a response. I filed a DTS, and the engineer who helped me wrote to the CarPlay team, or so he said. They also ignored him. I kept replying to the DTS for a while, until I was also ignored here. I also tried the contacting Developer Support. They replay to my e-mail, assign a case ID, they say they are escalating my request, and they they ignore me. When I replay a few days later, same history. I have also reapplied to get the entitlement every time I have added a big update to my apps which implement navigation. Also ignored. So I made a big investment to add navigation to my apps, I am not granted the entitlement when my use case is similar to other apps which have it, and now I am holding off on some marketing campings, what's the point to try to get more users if this will lead to bad reviews because "they cannot see the map in CarPlay". Worst experience ever. I am quite desperate.

Thank you very much for your answer. I already filed the bug report: https://feedbackassistant.apple.com/feedback/19734715

I forgot to mention that I have tried setting overrideUserInterfaceStyle to light mode in the UITabBarController, on the UIViewController, on the tabBar itself and on the GMSMapView with no effect. I have also tried other beta properties but I have not found a workaround that works. It seems that the tabBar refuses to obey these properties. And in the CPMapButtons, these properties do not exist as public properties. Setting them on the UIViewController behind the CPMapTemplate does not help either.