Placemark Deprecated

Question

SirBengt OP

Created Jun ’25

Replies 2

Boosts 1

Participants 3

"Use location, address and addressRepresentations instead"

Is it possible to know what kind of "Address" a MapItem is representing (State, County, Neighborhood etc) after a MKGeocodingRequest?
Is it possible to find out the CLRegion or similar of an map item. (Now when we cannot read it from the Placemark)

Answered by soapbox in 857931022

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?

Boost

Answer 1

DTS Engineer OP

Apple

Jun ’25

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

0

Answer 2

soapbox OP

Sep ’25

Accepted Answer

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?

3