Apple Maps' Lake America rename is a data-trust lesson

Apple Maps now shows Lake America where it used to show Lake Ontario, at least if you open it from inside the United States. TechCrunch reported that Apple followed Google in adopting the new name after an executive order signed on August 27, 2026 directed the Interior Department to make the change within 30 days.

I don't have a strong opinion about the politics. I have a very strong opinion about what this does to anyone building software on top of map data, and that includes a lot of small teams here in Sri Lanka.

---

🗺️ The same lake, three different answers

The most interesting detail isn't the rename. It's that the answer now depends on where the person asking is standing.

Where the user is	What Apple Maps shows
United States	Lake America
Canada	Lake Ontario
Anywhere else	Both names

Google made the same change, and pointed at its process for it: it updates geographic names when official government sources such as the Geographic Names Information System (GNIS) change. MapQuest declined and kept the old name.

Key takeaway: A place name returned by a maps API is not a fact about the world. It is a fact about which government registry that vendor decided to mirror, filtered through where your user's IP address resolves.

That's three vendors, three outputs, for one body of water that has not moved.

---

🧱 Your app's "facts" are someone else's mutable table

If you've shipped anything that touches a geocoding API, you've probably done this:

// looks fine, is a bug
const region = await geocode(lat, lng)
await db.savedPlaces.insert({ userId, label: region.name })

You just wrote a display string into your database and treated it as an identifier. When the upstream name changes, you get one of three failure modes:

1. Silent drift. Old rows say one thing, new rows say another. Your GROUP BY label quietly splits into two buckets and your analytics are wrong.
2. Broken joins. Anything matching that string against another table stops matching.
3. Failing tests. A snapshot test asserting on a place name breaks on a day you changed nothing.

This is not a maps-specific problem. It's the same class of bug as storing a country's display name instead of its ISO code, or storing "Twitter" instead of a stable platform ID. Renames are the visible case; the general rule is that anything a third party can edit is not a primary key.

---

🛠️ How I structure reference data so a rename can't break anything

On this site I run a pile of calculators sitting on data that genuinely changes: tax brackets, EPF rates, exchange rates, public holidays. A gazette notification is functionally the same event as an executive order renaming a lake. Someone upstream edits a value and my page is now wrong until I notice.

The pattern I've settled on:

Concern	Brittle approach	What I do instead
Identity	Store the display name	Store a stable ID or code; render the name at display time
Freshness	Fetch and hope	Every data module exports a LAST_VERIFIED date
Provenance	No comment	File header cites the official source URL
Change detection	Notice when a user complains	Diff a saved snapshot against a fresh pull
Disputed values	Pick one silently	Store all variants, choose per audience

That last row is exactly what Apple has done. Showing both names outside the US and Canada is the honest answer to a contested field, and it's a reasonable pattern to copy when your own data has no single correct value.

The change-detection row is the cheapest win. Pull your reference dataset on a schedule, keep last week's copy, and diff the two. If nothing changed, the diff is empty and you ignore it. If something changed, you find out before your users do. For a one-off manual check you can paste two versions into our text diff checker and see what moved in a few seconds. For anything recurring, a scheduled job writing to a log file is fine. The tooling doesn't matter; having the check at all does.

---

🇱🇰 We have been through this already

Sri Lankans don't need this explained in the abstract. Ceylon became Sri Lanka in 1972, and half a century later you will still find "Ceylon" sitting in legacy databases, product labels, company names, and dropdown lists in enterprise software written abroad. Colombo streets routinely carry two names, the older one and the post-independence one, and people use both interchangeably depending on age and neighbourhood.

If you've ever built an address form for Sri Lankan users, you already know the practical consequences:

• The same address arrives spelled four different ways.
• District and province names transliterate inconsistently between Sinhala, Tamil, and English sources.
• Postal codes exist but adoption is patchy, so you can't lean on them as the only key.
• International vendor dropdowns sometimes still list us under a name we retired before most of us were born.

None of that is solvable by picking the "correct" name. It's solvable by accepting that names are labels, keeping a canonical internal ID, and mapping many labels onto it.

---

💡 What this means for you

If you're building anything that consumes external reference data, whether that's a maps API, a currency feed, a tax table, or a list of universities, take four things from this week's news:

1. Never store a third party's display string as your key. Store an ID you control or a stable code, and resolve the name when you render.
2. Assume the answer is geo-conditional. The same API can return different values to your CI runner in Europe and your user in Colombo. Test with that assumption, and don't write assertions against volatile display text.
3. Date-stamp your data. A LAST_VERIFIED constant costs nothing and tells the next person, possibly future you, whether to trust the number.
4. Diff on a schedule. Automated change detection is a few lines of code and it converts a class of embarrassing bugs into a boring notification.

Bottom line: Apple and Google didn't break anything technically. They updated a field to match an upstream source, which is exactly what they said they'd do. The lesson isn't that vendors are unreliable. It's that "authoritative" means "someone has authority over it," and that someone isn't you.

Build accordingly.