Google's Places API for Android and iOS lets app developers use place names instead of coordinates
Jen Kovnats Harrington / Google Geo Developers Blog :
Context & Ripple Effects
Through early-to-mid 2015, Google has been steadily opening its location stack to app makers: the Places API for iOS exited beta in May, desktop users gained the ability to push places straight to an iPhone in June, and Search began answering place-aware questions like restaurant hours via geolocation on both mobile platforms.
This update is the developer-side piece of that push: by accepting place names instead of raw latitude-longitude pairs, the Places API removes the coordinate-resolution work that used to sit between an app and usable location data. It matters because place identity — not GPS math — is what most app builders actually want to program against.
First-order effects
- Android and iOS developers building with the Places API can now pass human-readable place names directly, cutting out the geocoding step they previously had to handle themselves before calling Google's endpoints.
Second-order effects
- Name-based lookups make it practical for non-mapping apps — food, travel, social — to bolt on location features cheaply, deepening their dependence on Google's place database as the canonical source of what a 'place' even is.
Third-order effects
- If the pattern holds, Google's map data keeps evolving from a consumer app into a programmable infrastructure layer — a direction the corpus confirms with the Awareness API's context signals in 2016 and the 2018 Maps platform for games with Unity SDK support.
The trend: Google Maps is shifting from a product into a developer platform, with each API release lowering the cost of embedding Google's place data inside third-party software.