Home base picker, sorted by location or alphabet

Summary

The owner asked (2026-10-20) that the home base picker sorts its airfields by the current location, or alphabetically, on iOS and Android. The picker shipped hours earlier (Android settings parity) sorting by the distance from the current home base, and only falling back to the device’s position when there was none:

	iOS today	Android today
Centre of the nearest list	The current home base, else the device’s last position if location access was already given (it never asks)	The current home base, else the map fallback (Klippeneck); Android has no location permission
Search order	The exact code first, then by name, at most 100	The same

This analysis replaces the centre and the search order. Recents, choosing and what is stored do not change.

Behaviour

The order is chosen automatically

There is no control on screen. The picker uses one order for the whole list, with and without a search:

The device’s position	Order	A row shows
Known (location access granted and a fix, see below)	By distance from it, nearest first	The name, code, flag and the distance (in the pilot’s distance unit, as today)
Unknown (access refused or restricted, location services off, or no fix in time)	Alphabetically by name (`a`), ignoring case and accents, in the device language’s collation; equal names by code	The name, code and flag, without a distance

The current home base is no longer the centre: someone choosing a new home base is usually standing somewhere else.

List	Rows
Without a search	At most 50, in the order above
With a search (code `e` or name `a`, ignoring case and accents, as today)	The exact code match first, then the other matches in the order above; at most 100, so with a position these are the 100 nearest matches
Recents (unchanged)	Above the list without a search, newest first, at most 5, the current one ticked

Location access

When the picker opens and the pilot was never asked, the app asks once for location while in use:
- iOS: requestWhenInUseAuthorization() (the app’s existing NSLocationWhenInUseUsageDescription). The pilot may grant approximate location; that is enough.
- Android: the runtime request for ACCESS_COARSE_LOCATION only, a new permission for the app. Not fine location.
If the pilot refuses, the picker does not ask again (Android: remember the refusal locally, so a later visit does not ask again, even where the system would allow it). The list is alphabetical. Granting it later in the system settings makes the next visit sort by distance.
The fix: the last known position if there is one, otherwise one fresh position. The list shows its loading state for at most 3 seconds while it waits (and while the permission dialog is open); after that, or on an error, it is alphabetical. The list is sorted once: a position arriving later does not re-sort it under the pilot’s finger.
The position is only used to sort and to show distances. It is not stored, synced or sent.

Edge cases

No position, no search: the first 50 airfields of the whole table alphabetically. The search is how a pilot without location finds their field.
A search with one match: one row, whichever the order.
Distances are great-circle distances (the haversine both apps already use for the nearest list).

Data

None. The stored home base (name, latitude, longitude) and the homebases records do not change. Android adds one local, unsynced flag: the picker already asked for location.

APIs

None.

Strings

None new. The rows and the loading state exist; iOS’s permission text exists. Android’s request is the system dialog.

Decisions

#	Question	Decision	Date
1	One automatic order, or a Nearest / A–Z toggle?	Automatic: by distance when the position is known, else alphabetical. Searches follow the same rule (owner).	2026-10-20
2	May the picker ask for location?	Yes, once, while in use; approximate is enough. Android adds `ACCESS_COARSE_LOCATION` (owner).	2026-10-20
3	The centre when a position is known	The device, not the current home base.	2026-10-20
4	How long to wait for a position	At most 3 s, then alphabetical; the list does not re-sort later.	2026-10-20
5	Search with a position	The exact code first, then the 100 nearest matches.	2026-10-20

Decisions 3 to 5 are defaults taken while writing this up; the owner can overrule them.

Open questions

None.

Platforms

iOS

Code (vulture-ios)	Change
`Packages/AirportScreens/Sources/AirportScreens/Hosting/Homebase/AppHomebaseSelection.swift` (`referenceCoordinate`)	Drop the current home base as the centre; ask for when-in-use access if `.notDetermined`; give the device’s position, or `nil`, within 3 s
`Packages/AirportScreens/Sources/AirportScreens/Homebase/SelectHomebaseProviding.swift`, `SelectHomebaseViewModel.swift`	Without a position, list alphabetically; a search sorts its matches the same way as the list
`Packages/Airports/Sources/Airports/AirportManager.swift` (`nearestAirports(to:limit:)`, `airports(matching:limit:)`)	An alphabetical list (localised, case and accent insensitive), and the matches sorted by distance from a coordinate when one is given
`Packages/AirportScreens/Sources/AirportScreens/Homebase/SelectHomebaseView.swift`	No distance on a row without a position

Tests: the order with and without a position, with and without a search; the exact code first; no distance without a position. Changelog.

Android

Code (vulture-android)	Change
`app/src/main/AndroidManifest.xml`	`ACCESS_COARSE_LOCATION`
`feature/settings/.../homebase/HomeBaseSettingsScreen.kt`	Ask for the permission once when the picker opens (Activity Result API)
`feature/settings/.../homebase/HomeBaseSettingsViewModel.kt`, `HomeBaseStore.kt`	The centre is the device’s position (last known, else one fix, 3 s), not `store.current`; the alphabetical order without one; a search in the same order
`domain/airports` (`Airports.nearestList`, `Airports.search`)	An alphabetical list (`Collator`, the device locale, primary strength) and matches sorted by distance from a coordinate when one is given
`data/prefs` (`LocalSettings`)	The “asked for location” flag

Location: the platform LocationManager (getLastKnownLocation, getCurrentLocation) is enough; no Play Services dependency is needed for one coarse fix. Update the Play Console data safety form if needed: approximate location is used on the device and not collected. Tests and screenshots (sorted by distance, alphabetical); changelog.

Web

No changes.

Tasks

vulture-ios: the location request and the device centre; the alphabetical order; the search order; tests; changelog (2026-10-20). The 3 s wait starts once access is known: the permission dialog is not part of it, so a pilot who grants access gets the order by distance. The alphabetical order is collated once per device language, started beside the position lookup.
vulture-android: the permission and its single request; the device centre; the alphabetical order; the search order; tests; screenshots; changelog (2026-10-20). Without a position the list has no header (“Nearest airfields” would be wrong) and its rows no distance.
vulture-docs: when built, update Home base and set status: shipped.