IssueTracker

Thank you for reporting this issue. We have been able to reproduce it internally and we will be working on a fix. We will update the issue with any related news.

This is working as intended and is documented here:
https://developers.google.com/places/ios-sdk/place-details

"GMSPlaceFieldPhoneNumber, GMSPlaceFieldWebsite, GMSPlaceFieldOpeningHours, and GMSPlaceFieldAddressComponents are not supported for GMSPlaceLikelihoodList place objects."

We are working on adding it here to the list of unsupported fields:
https://developers.google.com/places/ios-sdk/client-migration#find-place-likelihoods

I will keep this issue open until we fix this documentation bug. Again thank you for flagging this.

I you are interested in having this feature that returns all address components, please explain your use case.

This seems like a pretty standard use case from the previous iterations of this API. I need to pull the user's current location and get the address for display but often do not need to display the complete address. The user generally knows the city and state they are in so displaying a partial address allows for a much cleaner UI/UX. While it appears that I can achieve the same effect by making two API calls one to get the likelihood list and another to get the place details, that seems like a drain on user resources and could negatively affect performance, especially in rural and semi-rural markets where mobile data is often slow. Based on the fact that the deprecated version of the API returned all of the standard details for a place, this seems less like a feature add than a regression.