MKReverseGeocodingRequest and CNPostalAddress from MKMapItem

I then enumerate its attributes to pull out specific elements like just the street or state or zip etc.

What do you do with this information? Parsing the structured information is not always the right thing to do.

— Ed Ford,  DTS Engineer

Hi Ed! The use case in my app is to get the address for where a photo was taken. The user selects which address component(s) they want included. So I look at each attribute from the full attributed address to see if the CNPostalAddressPropertyAttribute is a component the user selected if so I add it to an array. Once enumeration is complete I join the array with commas to separate the components. For examples, if they selected zip it would be just 92101, or if they selected street and city and state it’d be 3835 N Harbor Dr, San Diego, CA. (The selected attributes aren’t guaranteed to be in the final string and that is acknowledged.)

I have your code-level support request, and from that I have your Feedback Assistant report FB19363454 (thank you for that!) that has a bit more info on what you're doing.

Since you're using the address for display purposes, I would try to see if you can make MKAddressRepresentations work for your needs, and if you could present the customization options to your customers based that line up with what that class offers. I realize the options are not as granular as you would like, and I can intuit that for certain customers, the API options may not be enough, so expressing your requests for even more API in FB19363454 is the right thing to do.

Once enumeration is complete I join the array with commas to separate the components

I want to call this out as an issue. Techniques like this are understandably common, and unfortunately, it is very easy to naively construct geographically incorrect place descriptions as a result. Geographic data and place identity has regional complexity and subtleties that are easy to over look! Thus, we want to discourage folks from doing these string concatenation techniques, and instead rely on the framework to provide you with the correctly formatted information through MKAddressRepresentations — you can specify a description of how much address detail for the place is needed, and delegate the correctness of how to represent the place with different levels of detail onto MapKit.

— Ed Ford,  DTS Engineer

I would try to see if you can make MKAddressRepresentations work for your needs, and if you could present the customization options to your customers based that line up with what that class offers

I'll pursue this route, thanks! Existing customers will need to change their settings to choose one of the predetermined formats that most closely matches their use case. As folks reach out to report what they can't achieve anymore, I can file feedback reports requesting more formats be added to MKAddressRepresentations.

The only thing I'm struggling to come up with is a friendly name to show in the UI for selecting the predetermined format of "city with context" both the short and full variants. Best I have is City, City and State, or City and State and Region - the word "state" is probably not appropriate everywhere. 🤔

it is very easy to naively construct geographically incorrect place descriptions ... we want to discourage folks from doing these string concatenation techniques, and instead rely on the framework to provide you with the correctly formatted information through MKAddressRepresentations

Makes sense! With the approach to select specific date components, I took inspiration from DateFormatter.setLocalizedDateFormatFromTemplate(_:) where you specify which components you want and you'll get an appropriately formatted localized string. I thought I achieved that fairly well by preserving the order of components in the postal address just filtering out undesired ones, but can certainly imagine there could be scenarios where the resulting string doesn't really work for different locations around the world. I did file FB8648023 (Template API desired to format addresses with different components, similar to DateFormatter.setLocalizedDateFormatFromTemplate) hoping to replace my solution with a native API, but maybe that's infeasible given address complexity?

I did file FB8648023 (Template API desired to format addresses with different components, similar to DateFormatter.setLocalizedDateFormatFromTemplate) hoping to replace my solution with a native API, but maybe that's infeasible given address complexity?

Thanks again for the input through these requests. I can't comment on if this is totally infeasible or not, and so that's why we value the request for consideration. I have a small working set of examples where I know its easy and common to misrepresent a place by "simply" extracting values from a structured postal address and combining them back together in a way appears to work for some regions but is incorrect for other regions, and I'm sure our folks who are more deeply attuned to worldwide geographic subtleties than I will have many more examples and counter examples and ideas of how to approach the problem space.

— Ed Ford,  DTS Engineer