MKOverlays vanish in Airplane Mode iOS 16

Since iOS 16.3, our app users have reported that while their devices are in Airplane Mode, all MKOverlays on our MapView will simply vanish from the view. The overlays are rendered using locally stored data, so network connection isn't an issue. Also, if the users turn off Airplane Mode and still have no internet connection, the overlays will reappear as normal (although the phone will be searching for a cellular network when the user prefers otherwise).

We had hoped the update to 16.4 would solve the problem, since it mentioned fixes for MKOverlays, but so far it has persisted. We've sent a report through Feedback Assistant and a TSI request, but both have gone unanswered by Apple. Anyone have other ideas?

Post not yet marked as solved Up vote post of dirtybrew Down vote post of dirtybrew
1.2k views

Replies

We are experiencing the same issue, also since 16.3. This has been tested on 16.4 and 16.5 Beta 1 with no luck. Beta feedback has gone unanswered and our TSI request was almost immediately credited back with no response. Not sure what's going on there..

Made me test overlays in my apps in airplane mode.

I have MKTileOverlay, the bottom one. TailOverlay : NSObject <MKOverlay>, for the track line. CourseLine : NSObject <MKOverlay>, 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.

Thanks Stan. I should have mentioned that it doesn't happen consistently every time I try it. Maybe one time out of ten when in airplane mode. And it shows up after panning and zooming for a little while-- like 30 seconds or a minute, but again, it's not really consistent.

What I've got for overlays are at MKTileOverlay with a standard MKTileOverlayRenderer, and 20 to 60 MKPolylines with custom drawing MKOverlayRenderers. I haven't tested on smaller sets with only a few polylines, so maybe I'll try that next.

I guess it's somewhat reassuring to know I'm not the only one not getting responses on Feedback & TSI's. :-/

My users are still reporting this bug, and more frequently, so I did a bunch more testing to see what I can find. I am now able to reproduce the issue a little more reliably. Since I still haven't heard any responses to the Feedback & TSI tickets, I feel like this is the only place to try finding anything.

To test the issue, I run the app from Xcode on my iPhone. The iPhone has Airplane Mode on, and Network Link Conditioner (Developer Settings) enabled with 100% loss. I pan and zoom around the map until the overlays disappear -- annotations are unaffected. This seems related to the MapView's cache of Apple Maps running out and at a specific location on the map, because if I find the exact spot where the overlays disappear, I can pan/zoom just a tiny bit back to where I was before, and the overlays reappear. Pan/zoom back to where they disappeared, and they disappear again. I can do this over and over, and it even persists between app launches as long as I keep Airplane Mode and Network Link Conditioner enabled (the app persists the visible map rect between launches as well). When the overlays disappear, it always happens exactly when the Apple Maps disappear and are replaced with the empty grid.

Some more things I tested or observed:

  1. At the moment the overlays disappear, I get a stream of logs like this (which I gather are sent by MapKit because the Apple Maps cache and network requests are failing):
[ResourceLoading] TiledGEOResourceFetcher received failed Resource: 623.735.11.255 t:27 kt:0, 334
[ResourceLoading] Failed to load key: 623.735.11.255 t:27 kt:0 type: 27, -1009: NSURLErrorDomain
  1. Added log statements at the beginning of the custom MKTileOverlay's loadTile(at:) function, and found that as soon as the overlays disappear, no function calls are sent. When the overlays reappear, the function calls resume as before.
  2. Likewise, added log statements to the beginning of the custom MKPolylineRenderer's draw(_:zoomScale:in:). As soon as the overlays disappeared, the function stopped being called. When they reappeared, the calls resumed as before.
  3. I tried replacing the custom MKPolylineRenderers with MapKit's standard MKPolylineRenderer, with no effect.
  4. I removed all calls to overlay.setNeedsDisplay() and related functions, also no effect.
  5. Added a button to the MapView that causes all overlay renderers in the MapView to call setNeedsDisplay(). No effect there either.
  6. Changed the button to instead remove all overlays and re-add them to the MapView. Still no effect.
  7. Tried not adding any of the MKPolylines in the first place. The MKTileOverlay still disappeared/reappeared during the pan/zoom.
  8. Tried re-adding the MKPolylines and not adding the MKTileOverlay. The MKPolylines still disappeared/reappeared during pan/zoom.

I'm pretty much at my wits end with this. Anyone else have any ideas?

Latest update, I've found the culprit:

When the MKMapView's mapType property (or the newer preferredConfiguration) is set to Satellite/Imagery, the bug does not occur. When it's set to hybrid, no overlays ever display. When it's set to standard, the reported bug occurs (overlays disappear after some use with no internet connection).

Seems like a bug in MapKit, no?

  • Hello @dirtybrew , have you found the solution for this issue? I was also working on a bug and observed this exact same thing (hybrid map type breaks overlays while offline).

Add a Comment

I'm also impacted by this issue, I discovered it the hard way when testing my offline map application in the mountains without network connexion, the purpose of this application :-(