It's happening all over in Xcode 16. It broke first in Xcode 13, when Swift 5.5 introduced async/await based on coroutines in LLVM. It was broken for almost two years until Xcode 15 shipped with a combination of lldb that worked. It broke again in Xcode 16. That bugs like this have no #1 priority in Apple's development team speaks volumes.
Same here. CarPlay kills established WiFi connections which are in use. This is completely unacceptable API behavior and a critical bug in my opinion.
Since not being a CarPlay app, we can't even find out whether we are connected to CarPlay or not (thus being able to warn the user).
I have opened a feedback item. Please do so as well.
The answer in this case is plist keys. Here's the deal: While the old location APIs with CLLocationManager had runtime assertions for checking the required NSLocation{xyz}UsageDescription keys – thus crashing, if they were not present – the new APIs just silently ignore missing usage descriptions.
Please consider the case closed – other than considering better diagnostics for this case as a feature request.
The problem was a corrupted empty project created by Xcode. It did NOT include the necessary iOS stub target (which seems to be important for deployment, even for a watch-only watchOS app).
With another Xcode version this worked.
It's happening all over in Xcode 16. It broke first in Xcode 13, when Swift 5.5 introduced async/await based on coroutines in LLVM. It was broken for almost two years until Xcode 15 shipped with a combination of lldb that worked. It broke again in Xcode 16. That bugs like this have no #1 priority in Apple's development team speaks volumes.
Same here. CarPlay kills established WiFi connections which are in use. This is completely unacceptable API behavior and a critical bug in my opinion.
Since not being a CarPlay app, we can't even find out whether we are connected to CarPlay or not (thus being able to warn the user).
I have opened a feedback item. Please do so as well.
The answer in this case is plist keys. Here's the deal: While the old location APIs with CLLocationManager had runtime assertions for checking the required NSLocation{xyz}UsageDescription keys – thus crashing, if they were not present – the new APIs just silently ignore missing usage descriptions.
Please consider the case closed – other than considering better diagnostics for this case as a feature request.
The problem was a corrupted empty project created by Xcode. It did NOT include the necessary iOS stub target (which seems to be important for deployment, even for a watch-only watchOS app).
With another Xcode version this worked.