Post not yet marked as solved
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.
Post not yet marked as solved
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.
Post not yet marked as solved
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.
Post not yet marked as solved
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?).
Post not yet marked as solved
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.
Post marked as Apple Recommended
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.
Post not yet marked as solved
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.
Post marked as Apple Recommended
@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 :).
Post marked as Apple Recommended
I tried now on my iPad with iOS 16.4 RC and there is no problem with the app staying in the background. I switched off significant location updates as well as part of the experiment, the app still stays in the background with no problem. ~20 minutes now.
If you can test this on iPad with iOS 16.4 then we can see if this is iPad vs iPhone that makes a difference or something in your vs mine configuration of a LocationManager.
Post not yet marked as solved
I've been testing iOS 16.4 on iPad since day 1 and it runs in background location 24x7, I specifically and continuously test for this use case.
Are you sure this is not some kind of crash that would be happening after these 10 minutes that might be bringing the app down?
There might be differences between location services on iPad and iPhone though.
Post not yet marked as solved
Looks like iOS 16.4 Beta 1 solved the performance issue with drawing on MKTileOverlay. Looks like a few performance issues might have been solved. Hopefully is stays this way.
Post not yet marked as solved
I might have a related FB to this issue, or more related to iOS 16 MKMapKit performance degradation when it comes to overlays that need to draw. It's "iOS 16 regression - MKMapView flicker with MKTileOverlay and MKOverlayRenderer with draw().".
I have FB FB11805267 with the sample project that reproduces the issue.
I used "Ask Apple" and I got confirmed that issue is known and is assigned a high priority. Then I used a DTS to ask if there is a workaround (e.g. I hoped I could only provide the overlay path and will not draw) and that returned back unused.
Going to add a link to this thread to my FB.
Post not yet marked as solved
I'm trying now in iOS 16 and setting Background Refresh as OFF for the app doesn't affect regular background location updates. Looks like documentation for this permission has been significantly changed to only relate to the Background Refresh Tasks:
https://developer.apple.com/documentation/uikit/uiapplication/1622994-backgroundrefreshstatus
