Changelog | mapfwd.com

What's new in mapfwd. Each release groups user-visible changes; under the hood fixes and refactors aren't listed here.

v1.1.7

Waze short URLs (waze.com/ul/{id}) now decode correctly. Their redirect chain passes through a URL with the coordinates (live-map?to=ll.<lat>,<lng> or live-map/directions?latlng=…) before ending at an error page. Redirect-following now early-exits as soon as a hop surfaces extractable coords, so we capture them mid-chain instead of landing on the error page. Also taught the Waze parser the ?to=ll.<coords> and ?latlng=<coords> formats — they show up on different paths depending on whether the chain was walked with HEAD or GET.

Sharing a place into the installed mapfwd PWA now opens mapfwd's own map view, with the shared location pinned. Earlier releases tried to auto-forward directly from /share to a native map app, but Android Chrome's PWA standalone mode blocks every flavor of automatic launch — only a real human tap on a link works. Rather than push a "tap to continue" button on every share, mapfwd now treats a share as "show me this place in mapfwd". From the map page you can copy a link, share it, or use the existing in-page UI to hand off to another map app.

Share-target on Android Chrome PWA now actually opens your map app. The auto-launch from v1.1.4's interstitial was also blocked by Chrome's external-protocol gate (page-load JS doesn't carry user activation any more than a server redirect does), so it fell through to the embedded fallback URL and loaded the source map's website inside the PWA — same symptom as v1.1.1–v1.1.4. The interstitial now does not auto-launch inside a PWA, and instead presents a big "Open" button. Tapping the button counts as user activation, which Chrome accepts, and the OS map app opens reliably. Outside the PWA (regular browser) the auto-launch still fires and the interstitial is invisible.
Switched the Android single-point native URL back to plain geo:. v1.1.3's intent://…?q=…#Intent;scheme=geo;…;end was malformed — with scheme=geo, the data URI reconstructed as geo://lat,lng?… (with a spurious // that the geo: protocol doesn't take), so even successful intent dispatch wouldn't find a handler. Plain geo: works correctly when invoked from a click.

PWA share-target on Android Chrome reliably escapes the standalone shell. v1.1.3 used intent:// URLs in a server-side redirect, but Chrome's external-protocol gating silently rejects custom-scheme launches that lack user-activation context, falling back to the embedded https URL — which then loaded the source map's website inside the PWA webview. The /share route now renders a tiny HTML interstitial with three escape hatches: an inline JS location.replace (preserves the share intent's activation), a programmatic anchor click (some Android Chrome builds honour this chain even when bare location.replace is gated), and a visible button as the guaranteed-activation manual fallback. Outside a PWA, the auto-launch fires in <100ms with no perceptible flash.

PWA share-target on Android now actually opens your map app. v1.1.2 redirected to geo: URIs, but Chrome's external-protocol gating silently blocked the launch across our /share → /a/... → ... redirect chain, so Google Maps still loaded as a webpage inside the PWA shell. Auto-forward now uses Android intent:// URLs, which Chrome routes through the OS intent system regardless of redirect-chain gesture state.
Waze share on Android now opens the Waze app. The v1.1.2 https bounce kept the URL trapped in the PWA webview; the Waze share is now wrapped in intent:// so the Waze app's app-link filter actually fires.

Google Maps share inside the installed PWA now opens your map app, not a webpage. On Android, a https://google.com/maps/... redirect kept the user trapped inside the PWA's standalone shell, loading Google Maps as a webpage. Auto-forward now uses the geo: URI for Android single points, which always breaks out to the OS-level default map app.
Sharing a Waze (or other unparseable map-service) link no longer dumps you on the homepage. When mapfwd can't decode coordinates server-side but recognises the source as a map service, it now bounces you back to the original URL so the source app's intent filter can take over. (We still can't decode Waze short URLs server-side — those need client-side resolution to convert into a regional map app.)

PWA share target now works for shared places from Google Maps. Sharing a place (POI, restaurant, business) from Google Maps to the installed mapfwd PWA used to land you on the homepage. The place-page URL format encodes coordinates in a data=…!3d{lat}!4d{lng} block with no @lat,lng segment, and the parser didn't recognise it. It does now.

Bigger reach in three large markets that don't run Google Maps as the default, plus a smarter way to share a pin into mapfwd.

Plus Codes input. Paste an Open Location Code like 8FVC9G8F+6X into any mapfwd URL — mapfwd.com/8FVC9G8F+6X or mapfwd.com/a/8FVC9G8F+6X — and it resolves to the right location. Full 11-character codes only.
Regional native-map auto-pick. When mapfwd detects you're in one of these regions, the auto-forward links open the local map app instead of Google Maps:
- Russia, Belarus, Kazakhstan, Ukraine → Yandex Maps
- China → AMap (Gaode) on Android, Petal Maps on HarmonyOS, Apple Maps on iOS (Apple Maps in CN already uses Gaode data)
- Czech Republic, Slovakia → Mapy.cz on Android
PWA share target. Install mapfwd as a Progressive Web App on Android, and mapfwd shows up in the system share sheet. Share a pin from Google Maps → mapfwd → it forwards to the right native app for your region.
Region override via ?region=XX on /a/... URLs, useful for power users behind a VPN and for bots running from VPS IPs.

URL pass-through on the /[...coords] route now reconstructs the original URL server-side, so pasting mapfwd.com/https://maps.google.com/... works reliably across all browsers.

The initial public release of mapfwd.com.

Smart auto-forward. /a/<coords> detects your device and redirects to the right native map: Apple Maps on iOS/macOS, Google Maps on Android, geo: URI on HarmonyOS / non-GMS Android, Bing Maps on Windows.
Geohash-based shareable links. Coordinates are encoded as 10-character geohashes for compact URLs. Directions use relative encoding so /a/u0762zbg61-5fdb2kf is shorter than two full hashes.
URL pass-through. Paste any map URL after mapfwd.com/ (Google Maps, Apple Maps, Bing, OpenStreetMap, Waze, HERE, MapQuest…) and mapfwd extracts the coordinates and forwards you on. Short links (maps.app.goo.gl, bit.ly) are followed server-side.
Bots. First-party bots for Telegram, Discord, Slack, IRC, Reddit, WhatsApp, Twitter, and Viber. Drop a map link in chat and get a clean mapfwd URL back, with native share-sheet hooks where the platform supports it.
Production hardening. Sitemap, legal pages (privacy, terms), security headers, and SSRF protection on the URL-resolver endpoint.