Maple MapsMaple Maps
EN FR

Release notes · September 11, 2026 · iOS build 34 · Android version 21

Build 34: addresses that were there all along

Three of you wrote in to say the app could not find an address you had lived at. It could not, and for three different reasons — none of them that the address was missing. Plus a version number in Settings that has been lying since the first build.

Three of you wrote in within a day of each other to say the same thing: searching for an address turned up nothing, or turned up four streets that were not it. One was a house in Edmonton, thirty years old. Three were in Oakville and Mississauga. None of them is obscure, and none of them was missing from the map.

They failed for three different reasons, which is why it took a while to see.

Fixed: a search no longer stops at the edge of the screen

Every search carried a circle about as wide as the map you were looking at — around twenty kilometres at most. That is right for a quick filter: tapping Coffee while looking at four blocks should find the café on this street, not ten across town. It is wrong for an address you have typed out, where you have said exactly what you want and where it is is not part of the question.

So somebody in Edmonton typing an Oakville address was asking us to look within twenty kilometres of Edmonton, and Oakville is two thousand seven hundred kilometres outside that. The app said "Nothing in Canada matches that", which was true of the circle and not of Canada.

A typed search now climbs outward instead: what is on screen, then about a hundred kilometres, then no limit at all, stopping at the first that answers. What you type is usually down the road, so the common case is unchanged — and "main street" typed in Sherwood Park still finds the one you are standing on rather than the first of four hundred.

Changed: a search keeps looking until it finds what you asked for

The rule underneath all of this, and it is worth stating plainly. Tapping a quick filter — Coffee, Fuel, Charging — means "the nearest one", and the nearest one is the answer. Anything you type is different: it names a particular thing. "10434 10A Avenue NW" is one building, and another house with the same number on a different street is not a nearer version of it. "Whalesbone" is a restaurant in Ottawa, and a bistro three blocks from you is not a nearer version of that.

So a typed search now keeps looking until the thing you named is in the results, and then puts it first. If nothing anywhere matches — a misspelling, a place that is not on the map — it keeps the best it found rather than showing you nothing.

Both places we ask are held to that same test. Search runs on our own map first and falls back to an outside address service, and any non-empty answer of ours used to end the question — so a near miss from our own index could quietly suppress a better answer we never went and asked for. Ours is now scored exactly the way theirs is, and whichever actually answers what you typed wins.

Fixed: the right answer no longer loses to a nearer wrong one

Once the reach was fixed the correct address came back, and still came third. Above it sat two Edmonton streets that shared one word with the question — the house number — and nothing else.

Results were ranked by whether the name was exactly what you typed, then by distance. That works for a place: search Borden Park and you get the park, not the band shell a few metres closer. An address is never exactly its own query, though. You type "1412 cobbler lane, oakville" and the answer is called "1412 Cobbler Lane", with the town on the line underneath. Every candidate looked equally unlike what you asked for, so distance decided.

Results are now also ranked by how much of your question they actually answer, counting the town in the line underneath. The park still beats the band shell, and the branch of a chain you are parked outside still beats the one two hundred kilometres away.

Fixed: Tim Horton's, and every name with an apostrophe in it

Looking for the exact thing you typed meant asking whether a result's name is what you typed, and an apostrophe was being turned into a space on the way. "Tim Horton's" became "tim horton s", which nobody types, so it never counted as a match for "tim hortons" — the two most-searched brands in the country, McDonald's being the other. An ampersand now reads as "and" as well, in both directions, so A&W and Fish & Chips answer either way you write them.

There was a second half to this one, found later and on the other side of the wire. Our own index splits a name on the apostrophe, so "Tim Horton's" is filed as three words and "Tim Hortons" as two — and neither spelling could find the other. The map holds both: Edmonton's branches are filed without the apostrophe, the one in Prince Rupert with it. So typing "Tim horton's" in Edmonton asked a question only the distant one could answer, and answered it — a café 989 km away, while eight branches inside a kilometre went unasked for. A name with an apostrophe now looks for both spellings, and so does a plain plural, because the mismatch arrives from both directions: you type "mcdonalds" and the map says "McDonald's". That half runs on our server and is already working, whatever build you are on.

Fixed: 10A Avenue

Half of Edmonton is addressed with a letter stuck to a number — 10A Avenue, 52A Street, 108A Avenue — and nobody types the space. Our own map learned to answer either spelling first; the harder half was the service we fall back to for house numbers. The address service we fall back to for house numbers files them with one, as "10 A Avenue", and asked for "10a" it quietly drops the letter and answers on the house number alone. Hence a search for a house on 10A Avenue returning 10 92 Avenue.

The app now writes it the way that service files it, on the way out and nowhere else.

That got the right house into the list. It did not get it to the top, which took one more go: the part that ranks the answers was still counting "10a" as a single word, so it could not recognise the very thing it had just asked for. Your house scored no better than every other house on a 10434, the tie fell through to distance, and three strangers on 32 A, 31 A and 28 A came first. Both halves now split a number and its letter the same way.

Fixed: the answer no longer sits off the edge of the map

Searching Whalesbone from Edmonton finds the restaurant in Ottawa and puts it first, which is right. The map then framed everything except it — the rule that keeps a half-typed word from flying the map to Quebec measured its reach from whatever nearer result came second, and the answer fell outside.

The map now always opens out far enough to hold the thing you asked for. Only far enough: every Tim Hortons in the country matches "Tim Hortons", so it is the nearest one the map has to reach, the closest is 350 m away, and nothing moves. A half-typed word matches nothing exactly, so it still cannot take the map with it.

New: the version number in Settings is real

At the bottom of Settings there has always been a line reading "Maple Maps 0.1.0 (dev)". It has said that on every build ever shipped, because it was reading a value that no longer exists and a version from a file the build system ignores. It now reads the version and the build number off the app itself, which is the only place either of them is true. If you write in about a bug, that line is the most useful thing you can include.

New: Settings says which map is not ours

Choosing Satellite is the one thing in the app that connects your phone to an outside company directly. Everything else — the map, search, routing, traffic — goes through our own server, so what reaches anybody else is the question and not your phone. Satellite imagery does not: there is no open Canadian imagery at that resolution, so those pictures come from TomTom and your phone fetches them itself, which means they can see your address on the network and which part of the map you asked for.

That was already true and only written in the privacy policy. It is now written where the choice is made. The day and night maps are ours.

Still missing, and worth naming

Residential addresses are thin in the map data we build on. Commercial ones are there — a shop gets added because somebody adds the shop — but houses often are not, so a house number search usually ends up at the fallback service rather than answering from our own index. That is why these three reports were about houses and not about businesses.

Edmonton alone publishes three quarters of a million parcel addresses as open data, and there is a national collection of the same kind of thing. Bringing those in is the next real piece of work, and it is what finally takes search off an outside provider.

← All release notes