I've been testing out some migrations using code from @Fat Xu's blog (thank you for that!), and I've run into the "Duplicate version checksums across stages detected" error a few times. By using only NSCustomMigrationStage and not NSLightweightMigrationStage, it seems to work. My observations start with the following setup: My Model has four versions: v1, v2, v3, v4. V1ToV2 and V3ToV4 can use lightweight migrations. V2ToV3 requires a custom stage What I found was that if I created the NSStagedMigrationManager like this: let myCustomMigrationStageV2toV3 = NSCustomMigrationStage( migratingFrom: v2, to: v3) myCustomMigrationStageV2toV3.willMigrateHandler = /* do custom migration stuff */ let migrationManager = NSStagedMigrationManager([ NSLightweightMigrationStage([v1.checksum]), myCustomMigrationStageV2toV3, NSLightweightMigrationStage([v3.checksum]) ]) I would get the "Duplicate version checksums" error, probably because the custom stage and the third stage both included v3. If I change the final stage to v4.checksum, the migration succeeds. I find this somewhat confusing because in two NSLightweightMigrationStages with the same initializer, the provided version checksum is the source version in one, and the destination version in the other. A more reliable option for me was to use NSCustomMigrationStage even where NSLightweightMigrationStage would work. For example... let migrationManager = NSStagedMigrationManager([ NSCustomMigrationStage(migratingFrom: v1, to: v2), myCustomMigrationStageV2toV3, NSCustomMigrationStage(migratingFrom: v3 to: v4) ]) This works fine, and I get to be certain of each stage along the way having the source and destination versions that I specify. It seems a NSCustomMigrationStage with no willMigrateHandler and no didMigrateHandler is just the same as a NSLightweightMigrationStage, but with an initializer that makes more sense.

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?

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: 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 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. 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. I tried replacing the custom MKPolylineRenderers with MapKit's standard MKPolylineRenderer, with no effect. I removed all calls to overlay.setNeedsDisplay() and related functions, also no effect. Added a button to the MapView that causes all overlay renderers in the MapView to call setNeedsDisplay(). No effect there either. Changed the button to instead remove all overlays and re-add them to the MapView. Still no effect. Tried not adding any of the MKPolylines in the first place. The MKTileOverlay still disappeared/reappeared during the pan/zoom. 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?

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. :-/