I have been seeing a lot of undesirable behavior with MKOverlayRenderer in iOS 13, including double calls to canDrawMapRect and inconsistent mapRect sizes going between setNeedsDisplayInMapRect, canDrawMapRect, and drawMapRect.
Perhaps the biggest problem is that canDrawMapRect seems hardwired to use giant 1536x1536 (point) mapRects no matter what size mapRect needs to be drawn or is invalidated. We used to have very fine control over our map overlay content, being able to surgically redraw 256x256 or 512x512 regions of the map, but now canDrawMapRect is upsizing all mapRects to 1536x1536. That is larger than the short screen dimension on many devices!
I have come up with a workaround that involves abandoning canDrawMapRect and doing tile management inside drawMapRect, however this brings on some other headaches and isn't a long term solution.
Anybody else seen this? I have filed a bug report, FB7442855. Among other things, I am proposing Apple let developers define the size mapRect they want to use, such that we can have consistent behavior between setNeedsDisplayInMapRect, canDrawMapRect, and drawMapRect. Most maps probably want to use a power of 2 multiple of 256 for their mapRect size in points. 1536? Not so much!
Your information might explain why there is such a performance regression with custom tiles in iOS 13. I reported under FB7451880 (performance regression) and FB7455392 (tiles cache not working in iOS 13?).