addSubview slows down with sibling count, process-wide, once a MapKit location view has been in a window

Filed as FB25405148 with a small sample project. Posting here in case anyone else has hit this or knows a better workaround.

Once a MapKit location view has been in a window, addSubview: anywhere in the process takes time proportional to the number of subviews the parent already has. The parent doesn't have to belong to the map. On iPhone Air with iOS 27.2, in a clean app, adding 8,000 plain UIViews to a plain UIView took 85 ms without a location view and 4,992 ms with one.

You won't see this with a few hundred views. Up to about 1,000 siblings, the whole batch costs less than 100 ms extra. Map apps can hit it because annotation views are siblings under one container. On the same phone, adding 5,000 annotation views in batches took the longest frame from 25 ms to 208 ms.

It happens with the default location view, with an MKUserLocationView returned from mapView(_:viewFor:), and with a bare MKUserLocationView added to a window by hand. A plain MKAnnotationView doesn't cause it. From LLDB on the simulator, it looks like MapKit's first call to _accessibilitySetInterfaceStyleIntent: installs _UIAccessibilityInterfaceStyleVisitor, and that's what slows later adds.

Returning a plain MKAnnotationView for MKUserLocation avoids it, but gives up the system view. Only iOS 27.2 has been tested so far. Has anyone seen this on other versions, or found a way to keep the system location view without the cost?