UPDATE 3. Siri just does what it wants to do. There is a period it goes by your "Prefer spoken response" and it speaks out your IntentDialog response, then 30 minutes later it only says "That's ok". I guess this is just by "design", it is not meant to be reproducible :):).

UPDATE 1. It started to work as expected after the iPhone restart. UPDATE 2. After changing Siri responses to "Automatic" or "Silent" and then changing back "Prefer Spoken Responses" - Siri never speaks the result's IntentDialog text again, until the iPhone restart. This lady got a character!

Same warning happens to me for the app that uses SumUp SDK when using Xcode 16 beta 6. Same static framework shows no warnings in Xcode 15. Created an issue for SumUp on github, but can it be Xcode 16 beta issue? https://github.com/sumup/sumup-ios-sdk/issues/150

Per here: https://developer.apple.com/documentation/corelocation/cllocationupdate/liveconfiguration/automotivenavigation CLLocationUpdate.LiveConfiguration.automotiveNavigation The value that configures positioning for an automobile following a road network. It is about accuracy and distance filter requirements for the location module? Also about "glueing" you to the automotive roads or not. Do you believe this should also discriminate for the .automotive activity only? I watched this WWDC session a long time ago though. From the experience with how the current location/motion works, I'd say my apps would miss a lot of driving distance if they rely on discriminating automotive activity solely by Apple's categorisation.

I'm using startRelativeAltitudeUpdates with a barometric reference for altitude and subjectively (tested with iOS 17.5 today) the frequency of updates is the same as it used to be in iOS 16 or 15. I wonder if you have location accuracy at max and distance filter at min, as you mention slower updates and location based altitude. What if Apple linked startAbsoluteAltitudeUpdates totally to a location data and you have low frequency filter/accuracy on you CLLocationManager?

Try DSA registration after erasing the browser History/Cash.

Looks like that for the companies, address and phone will be published. For my company, Apple already shows address, DUNS and phone/email in the Provider section in the AppStore. They called me from the Czech Telecommunication office as told that it is up to a online platform to publish it online or not. I don't know if this will be published for the individual account as well, my individual DSA information is still under review as they required to scan and attach business/court documents. If they publish that in the App Store, you are welcome to visit me!

I'm a small entrepreneur from the Czech Republic and I also don't know if I'm a trader or not. I'm inclined to think that I'm a trader, per definition of DSA, but I'm not sure that my private address should be published in the App Store, available to everyone. We had a story with the digital postal mail boxes here where they started to publish every digital mail box owner address, but they had a privacy related pushback. Now you can select if you want or don't want to have your address published online if you have a digital mail box. I called to our National office of telecommunication that is established as a National Digital Services Act coordinator for Czechia and they promised to be back to me tomorrow with explanations/statement.

Same problem here when seeing crashes from production on iOS 17.0 - 17.1. Added a feedback to Apple as well. I actually went through crash reports and the issue is happening on the current iOS 17.2 beta as well, no fix there.

I think the reviewer has a point here. The current "Enable" looks like the only option to progress to the next step. I'd agree that anything permission related should not be non-skippable or be enforced. You can later highlight the limitation in the app itself or use an alert. The way it is now - give a permission or close and remove the app.

Hi Scott, I created a unit test now as well, like this: /// https://feedbackassistant.apple.com/feedback/13181573 - (void)testTypes { NSDictionary<NSNumber*, WaypointType*> *types = @{ [NSNumber numberWithInt:-2]:[[CircleWaypointType alloc] init], [NSNumber numberWithInt:-1]:[[PolygonPointWaypointType alloc] init], @0:[[OtherWaypointType alloc] init], @1: [[FixedCameraWaypointType alloc] init], }; NSLog(@"Types: %@", [types description]); for (NSNumber *key in [types allKeys]) { NSLog(@"1. Key: %@", key); } types = @{ //https://feedbackassistant.apple.com/feedback/13181573 @-2:[[CircleWaypointType alloc] init], @-1:[[PolygonPointWaypointType alloc] init], @0:[[OtherWaypointType alloc] init], @1: [[FixedCameraWaypointType alloc] init], }; for (NSNumber *key in [types allKeys]) { NSLog(@"2. Key : %@", key); } } And output for @-1 and [NSNumber numberWithInt:-1] is the same in the unit test: 2023-09-18 17:16:48.788685+0200 speedometer[84584:1342510] 1. Key: -1 2023-09-18 17:16:48.789099+0200 speedometer[84584:1342510] 2. Key : -1 I tried then to run the app itself in the simulator (was running on a iOS 16 and 17 devices before). When ran as the app in iOS 17 simulator @-1 and @(-1) turns into 18446744073709551615 in the dictionary, same as it is doing it on iOS 16-17 devices. Xcode is Version 15.0 (15A240d) Looks like that unit test doesn't reveal the issue, compiling/running as the app does. Either on simulator or the real device. Thank you for the suggestions! Stan. P.S. Here it is in the debugger preview while running the app in the simulator (same on the real device): It doesn't match -1 for the objectForKey when NSNumber is -1, so it should be turning into this value 18446744073709551615, I think this is not just a debugger misrepresentation. P.P.S. Also strange how @1 is of (int) type, but @6 is (long), why it would be like this? Looks like some unexpected type random conversion liberty by a compiler (or debugger in this case?).

We probably have to wait. I think the same issue applied to the previous version of Xcode 15 beta as well. It took some time until App Connect started to accept its builds.

My users on iOS 13 are reporting crash on start as well. iOS 13.6 so far. Hope that Apple comes with more than suggesting them upgrading to iOS 15/16.

Made me test overlays in my apps in airplane mode. I have MKTileOverlay, the bottom one. TailOverlay : NSObject , for the track line. CourseLine : NSObject , for the top course line. They have drawing renderers (except for the MKTileOverlay) and Apple fixed, with that mentioned MKOverlays fix in iOS 16.4, the performance and reliability of drawing on top of MKTileOverlay among other things. All shown in the airplane mode. Am I missing something else to make it fail? If you want to run any "what is different in our code", let me know. Similar experience with Apple for the FBs/TSI. I used "Ask Apple" in December (I think) and a nice guy checked the status for that "performance and reliability of drawing on top of MKTileOverlay" and at least I knew it's being fixed. No updates to related FBs, ever. --Stan.

@nickradar. Went for a drive now with iOS 16.4 public and for me it all works 100% unless I'm severely overlooking something. I do have showsBackgroundLocationIndicator = true on the location manager that records a track. I don't have it on the location manager that listens for regions (iBeacons), but I do call startUpdatingLocation() on a region location manager before handing it over to the track location manager with showsBackgroundLocationIndicator = true, otherwise my track recording location manager would not start/stay recording in the background, I thought it was iOS specific - it might be iOS 16.4 specific then. I have competitor apps installed for the automatic mileage tracking, and 2 of 5 (all that really track) recorded now something like: That would correspond to points in the significant location updates, maybe. No recording in between. That's going to be interesting. One more thing, on significant location events I do ask for the background time extension. Not sure that plays any role, I ask due to other things, but also start a probing location manager that has showsBackgroundLocationIndicator = false and it works. Hope this will not give Apple any wrong ideas :).