Half a million mountains, zero network calls

Searching for a mountain is the first thing you do in Summit, and it is the obvious candidate for a server. Send a query, get back matches, keep the app small. Every mapping app in the world works this way.

The problem is where people actually use a climbing app. Trailheads, ridgelines, huts, the parking lot at the end of a long day. The moments when you want to log a summit are disproportionately the moments with no bars.

So the database ships inside the app

Summit bundles 505,970 peaks from GeoNames as a 50 MB SQLite file, covering 222 countries. There is no peak search endpoint because there is no server. Search works on a plane, in a canyon, and in airplane mode, and it works identically for everyone forever, because the data cannot go down or change under you.

That is a real tradeoff. It is 50 MB of download before you log a single climb, and the peak list is frozen at whatever GeoNames had when the app shipped. I took that deal happily. A search that always works beats a search that is always current.

Ranking without a search server

Half a million rows means "contains the letters you typed" is useless on its own. Type "rainier" and you want Mount Rainier first, not a nameless 800-foot bump that happens to match. So results are tiered:

• Exact name matches first
• Then whole-word matches
• Then prefix matches
• Then substring matches anywhere in the name
• And within every tier, the tallest peak wins

Elevation turns out to be an excellent relevance signal for this specific problem. If two peaks share a name, the famous one is almost always the big one. That single sort key does most of the work a ranking model would otherwise have to learn.

The best offline feature is one the user never realizes was a choice.

Nobody opens Summit and thinks about the bundled database. They type a mountain name in a place with no signal and get their mountain. That is the whole point.