A store locator app for Shopify is a data problem long before it is a map.

What Shopify already stores about each location

Start by reading what you have. In the Admin API a location carries a name, an address, an isActive flag, a fulfillsOnlineOrders flag and local pickup settings. The address is its own object, and it holds address1, address2, city, province and provinceCode, country and countryCode, zip, phone, a formatted version, and latitude and longitude as floating point numbers.

Latitude and longitude are the two worth pausing on. Both are nullable, so a location can exist without them, but where they are filled in you do not need a geocoder for your own shops at all. You geocode what the shopper types, not what you already store. That single fact removes most of the cost people plan for in a shopify store locator.

The gap is hours. There is no opening hours field on a location and no holiday calendar either. A location does support metafields, so hours can be attached there as structured data and stay editable in the Shopify admin. The alternative is your own table keyed by location id. Either works. What does not work is a hard coded list inside the app, because the first time a branch changes its Saturday closing you are shipping a new build to fix it.

Shopify Admin API, the LocationAddress object

Free maps, free geocoding, and where free ends

Yes, there is a free geocoding option with a documented API and no card. It is Nominatim, the geocoder the OpenStreetMap Foundation runs on OpenStreetMap data. No account, no key, no billing details. The published terms are strict, and they are worth reading before you design anything around them.

The usage policy sets an absolute maximum of one request per second, requires a valid HTTP Referer or User-Agent that identifies your application, requires visible attribution, and states that results must be cached on your side. The data is under the ODbL licence, which carries a share alike requirement. Bulk work is limited to a single thread on one machine, and scripts that run longer than a day or on a schedule are held to four requests per minute.

One line in that policy decides the shape of your search box: auto-complete search is not permitted. So a free geocoder can turn a submitted postcode into a point, and it can backfill coordinates for any shop whose address you hold, once, cached. It cannot power a store finder app that fires a lookup on every keystroke. If you want typeahead, that is a paid geocoder or your own index of your own place names.

The map itself is a separate question with separate terms. The renderer is genuinely free: MapLibre GL JS is open source and costs nothing to use. The tiles it draws are served by somebody, and that somebody sets the terms, whether that is a community service with a usage policy or a vendor with a bill. So the honest answer is yes for geocoding on the conditions above, and yes for the map only once you have read the tile terms you are actually using.

OpenStreetMap Foundation, Nominatim usage policy

Ranking the nearest shop

Sorting by distance is not the hard part. With coordinates already on every location, a haversine calculation over a few hundred rows runs instantly on a phone and never needs a server. Hold the list on the device, rank it on the device, and the nearest shop appears before a network request would have come back.

Shopify does offer proximity sorting of its own. The Storefront API has a locations query that takes a near argument and a DISTANCE sort key, and a product variant exposes store availability at nearby locations with a stock count and a pickup time. Check the scope and the scope of the result before you build on it: the query needs unauthenticated read access to product pickup locations, and it returns only the locations that support in store pickup. A shop that is not set up for pickup will simply not be in the list.

That constraint is why a lot of builds end up copying the full location list out of the Admin API into their own store and serving it to the app from there. It also gives you somewhere to put the fields Shopify has no room for. A loyalty card app usually needs the same list for the same reason, because it has to know which branch the customer walked into.

The last piece is the shopper position. Location permission on a phone is a prompt the customer can refuse, so a postcode or town box has to work just as well as the blue dot. Build the typed path first and treat the permission as a shortcut, not a requirement.

The list is only as good as the person updating it

A store locator goes wrong slowly. A branch changes its Sunday hours, a unit moves two doors down, one shop closes for a refit. Nobody tells whoever owns the app, and the retail location app quietly starts sending people to a shuttered door. Every locator that stays accurate has one thing in common: the people in the shops can change their own entry.

That means a second, small surface for staff. A manager opens the app, changes today's hours, adds a note that the car park is closed, and it is live. Keep it to the fields that genuinely change, and record who changed what and when, because that is the record you want when a customer says the app told them otherwise.

Delivery is the usual next question, and it is a different app with a different shape. Whether a branch delivers, how far it goes and what it charges sits much closer to a local delivery app than to a finder. Keep the two separate in the data even when they share a screen.

All of this needs somewhere to sit: the copied locations, the hours, the staff edits, the history of changes. That is a backend question rather than an app question, and it is worth reading about where the store list lives before you commit to one.