iOS Address Autocomplete: Google Places or Free MapKit
Address autocomplete makes or breaks a checkout. Use Google Places, or MapKit's free MKLocalSearchCompleter, and debounce every keystroke.
TL;DR
An address autocomplete UI suggests places as the user types, which cuts errors at checkout and signup. You can use the Google Places API, or MKLocalSearchCompleter, the free native alternative built into MapKit. Debounce input, show suggestions in a clean list, and fill structured fields on selection. Watch API cost and keys server-side for Google. Start the UI from a free VP0 design.
Address autocomplete is one of those small features that quietly decides whether a checkout or signup succeeds. Typed addresses are error-prone; suggestions fix that. You can power it with the Google Places API or with MapKit’s free native completer, and the UI is the same either way. VP0 is the free, AI-readable iOS design library builders start from for the search field and suggestion list, so the experience feels native whichever backend you choose.
Who this is for
You are building an iOS app, maybe with Cursor or Claude Code, with an address or place field, at checkout, signup, or a delivery form, and you want fast, accurate autocomplete without a surprise bill. This is the pattern, with both options.
Two ways to power it
The Google Places API returns predictions as the user types and has broad global coverage and rich place data, but it is a paid service and you must protect your key. The native alternative, MKLocalSearchCompleter, is built into MapKit, returns completions as the user types at no API cost, and needs no extra key, which makes it the natural first choice for an iOS-only app. Build the field in SwiftUI and you can swap the source behind the same list.
Choosing between them
| Factor | Google Places | MKLocalSearchCompleter |
|---|---|---|
| Cost | Paid per use | Free |
| Key management | Server-side, protected | None needed |
| Global coverage | Very broad | Good, Apple Maps data |
| Place detail | Rich | Solid for addresses |
| Best for | Global reach, rich data | iOS-only, no cost |
For many apps the free native completer is enough; reach for Google when you need its global coverage or detailed place data. Either way the suggestion list and selection flow are identical, which is why starting from one clean design works for both. In practice most teams ship the free native completer first and only reach for Google when a user in a region it covers less well asks for better results.
Debounce, or pay for it
The one technical rule that matters most: debounce the input. Calling the backend on every keystroke is slow and, with Google, expensive. Wait a short moment after the user stops typing, then send one request, so a five-letter street is one call instead of five. The BBC lost an extra 10% of users for every additional second of delay, and a flickering, laggy suggestion list feels exactly that slow. With Google, also group the autocomplete and the final details into one billing session and keep the key server-side. The same map-setup discipline appears in a map configuration and layout guide, and a route-following companion in a Mapbox driver route template.
A worked example: a delivery address
A customer starts typing their street at checkout. After they pause for a moment, one request goes out and four suggestions drop into the list. They tap theirs, and the app fills the structured fields, street, city, postal code, and a place identifier, all at once, with no chance of a typo in the postal code. Because you grouped the calls into a session, Google bills you once for the whole address, not once per keystroke. Had you skipped debouncing, that single address would have fired a dozen requests and shown a jittery list. Instead the customer got a fast, clean pick, your bill stayed small, and the order shipped to a valid address the first time. Multiply that across thousands of checkouts and the difference is fewer failed deliveries, fewer support tickets about wrong postal codes, and a noticeably smaller API bill, all from two small decisions: debounce the input and group the calls into one session. Neither is hard, and both are easy to forget when an AI scaffolds the field and calls the API on every keystroke by default.
Common mistakes and fixes
- Calling on every keystroke. Debounce so one address is a few calls, not many.
- Exposing the API key. Keep Google keys server-side.
- Ignoring the free option. MKLocalSearchCompleter covers many iOS-only apps.
- Not using sessions. Group autocomplete and details to be billed once.
- Free-typing the result. Fill structured fields from the selected place.
Once you have a clean address, organizing the rest of the operation is the next step, as in a property management app.
Key takeaways
- Autocomplete cuts address errors at checkout and signup.
- Use Google Places for global reach, or the free MKLocalSearchCompleter on iOS.
- Debounce input and use sessions to keep speed up and cost down.
- Fill structured fields on selection, from a free VP0 design.
Frequently asked questions
The FAQ above covers building the autocomplete UI, the free native alternative, avoiding a big bill, and why debouncing matters.
Frequently asked questions
How do I build a Google Places autocomplete UI for iOS?
Send the user's typed text to the Google Places API as they type, debounced so you do not call on every keystroke, then show the returned predictions in a list and fill structured address fields when they pick one. Keep your API key server-side and watch usage cost. If you would rather not depend on Google, MapKit's MKLocalSearchCompleter does the same thing for free. Start the UI from a free VP0 design.
Is there a free alternative to Google Places autocomplete on iOS?
Yes. MKLocalSearchCompleter, built into MapKit, returns search completions as the user types at no API cost and with no extra key, which makes it the natural first choice for an iOS-only app. Google Places has broader global coverage and richer place data, so the right pick depends on whether you need that reach or prefer a free, native option.
How do I avoid a huge Google Places bill?
Debounce the input so you call the API after the user pauses, not on every character, group the autocomplete and the final place details into a single session so you are billed once per address, cache recent results, and keep the key server-side so it cannot be abused. These steps keep a high-traffic form from generating a surprise bill.
Why should address autocomplete be debounced?
Because calling on every keystroke fires far more requests than needed, which is slow and, with a paid API, expensive. Debouncing waits a short moment after the user stops typing before sending one request, so a five-letter street triggers one call instead of five. It also keeps the suggestion list from flickering as results race each other.
Part of the Maps, Location, Mobility & Delivery UI hub. Browse all VP0 topics →
Keep reading
iOS Maps and Core Location Setup: The Config That Matters
Setting up MapKit and Core Location on iOS? The config is small but exact: Info.plist usage keys, authorization, and MapKit for SwiftUI. Here is the free template.
DePIN Network Map UI for iOS, Free Template
Build a DePIN (decentralized physical infrastructure) network map UI for iOS from a free template. Nodes, coverage, and status with Claude Code or Cursor.
Draggable Bottom Sheet Over a Map in SwiftUI, Free
Build an Apple Maps style draggable bottom sheet over a map in SwiftUI. Detents, a persistent sheet, and a clean map, from a free template, ready for Cursor.
Flitsmeister Style Speed Camera Alert UI in SwiftUI
Build a Flitsmeister style community road-alert UI in SwiftUI from a free template. Map, proximity alerts, and crowd reports with Claude Code or Cursor.
Dog Walking GPS Tracker Map UI in SwiftUI
A free MapKit pattern for a live dog-walking GPS tracker: draw the route, share the walk, and respect battery and privacy. Learn the pattern, never clone the brand.
Parking Spot Finder Live Map UI in SwiftUI
Build a live parking finder in SwiftUI: a map of nearby spots with availability and price, plus navigation, from a free VP0 design. Honest live data, never stale.