Placemark Deprecated

Is it possible to know what kind of "Address" a MapItem is representing (State, County, Neighborhood etc) after a MKGeocodingRequest?

It vends back a MKMapItem which contains geographic location and any interesting data that might apply to that location, such as the address at that location and the name of a business at that address. It also contains a unique identifier for a place which You can persist an identifier and use it later to recall information about place. See Interacting with nearby points of interest

I agree that the loss of individual fields is a major downside of MKPlacemark and CLPlacemark being deprecated. Now they are embedded in MKMapItem as additional opaque "context" with no information as to what they are. Here's what's lost:

• CLPlacemark's postalAddress.street is now only available as part of the strings in MKMapItem's fullAddress (in address or addressRepresentations)
  • Example: "Street Rd & Avenue Rd" in "Street Rd & Avenue Rd, Cupertino, CA 95014, United States"
• Similarly, CLPlacemark's administrativeArea (the "state" in the US) is only available as part of the strings in MKMapItem's cityWithContext or fullAddress. It's also not clear if this context will always be the "state", it may be something else per the documentation ("The city name along with the country name, to provide additional disambiguating context.")
  • Example cityWithContext: "Cupertino, CA"
• There are no equivalents to CLPlacemark's subAdministrativeArea (typically a "county" in the US) or subLocality (typically a neighborhood or named area of a city). These values are not embedded in any of the "WithContext" strings that I have seen.

This is a major step back in the data we get back from Apple's geocoding systems, and much of the data is still there, just embedded in strings without indication of what is used.

Any chance we could get additional individual fields added to MKMapItem to maintain parity with MKPlacemark/CLPlacemark? In addition to the "WithContext" fields that are already there?

Agreed. Major regression. Forced us to Switch to Google Maps api.

Send your feedback. Here are mine. I too make heavy use of the properties on the placemark.

FB20007974 - Core Location: No found replacement API for obtaining the region of a CLPlacemark via MapKit or GeoToolbox APIs - killing the feature? (August 2025)

FB20008112 - MapKit: No replacement API for accessing MKAnnotation properties on MKMapItem previously available on MKPlacemark/CLPlacemark (August 2025)

FB16064707 - MapKit / Core Location: CLPlacemark's region returns CLRegion type that is a deprecated aka CLCircularRegion (deprecated 18.2), was this deprecated by mistake? (December 2024)

I make heavy use of the CLPlacemark properties in my apps.

They're used for search tokens and comparisons in my visit timeline app: https://apps.apple.com/us/app/location-feedback/id6478832551

I had planned on using them for advanced 'body of water' workouts in my workout app: https://apps.apple.com/us/app/cardio-active/id1488124050

They're used in my craft brewery app similar to my location timeline app: https://apps.apple.com/us/app/the-craft-experience/id1504349960

Here is to hoping that WWDC26 brings a replacement API because it was certainly a miss and the CLPlacemark properties power many third party developer app features.