Ranked feed, announcements, event analytics, org management, event addresses and covers, runtime iOS env, UI and swipe fixes (#100, #119, #120, #122, #123, #124)

.github/workflows/deploy-mobile.yml

@@ -3,8 +3,10 @@ name: Deploy mobile (TestFlight)
 # Builds apps/community-mobile for iOS and uploads it to App Store Connect, where TestFlight hands it
 # to the internal tester group. Same shape as deploy-web.yml, one lane:
 #
-#   push to main                     -> the `testflight` profile  -> staging API (api.civfix.dev)
-#   manual run, profile=production   -> the `production` profile  -> prod API (api.civfix.org)
+#   push to main                     -> the `testflight` profile  -> staging API (api.civfix.dev), baked
+#   manual run, profile=production   -> the `production` profile  -> API chosen at runtime by install
+#                                       source: api.civfix.dev in TestFlight, api.civfix.org from the
+#                                       App Store (src/lib/apiUrl.ts + src/lib/nativeBetaInstall.ts)
 #
 # Nothing here submits for App Store review. A production build lands in App Store Connect exactly
 # like a staging one; attaching it to a version and submitting is the manual step, so a prod mobile
@@ -145,7 +147,7 @@ jobs:
           if (api !== expectedApi) {
             throw new Error(`profile '${profileName}' bakes EXPO_PUBLIC_API_URL='${api}', expected '${expectedApi}'`)
           }
-          console.log(`profile ${profileName}: EXPO_PUBLIC_API_URL='${api || "(unset -> https://api.civfix.org)"}'`)
+          console.log(`profile ${profileName}: EXPO_PUBLIC_API_URL='${api || "(unset -> resolved at runtime: api.civfix.dev in TestFlight, api.civfix.org from the App Store)"}'`)
           NODE
           echo "TARGET=$target" >> "$GITHUB_ENV"
 

README.md

@@ -100,7 +100,9 @@ build cannot ship the staging API URL to civfix.org or the production one to the
 The mobile app deploys through `.github/workflows/deploy-mobile.yml` on the same lane: a push to
 `main` that touches the app or the packages builds the `testflight` profile (staging API) on a
 GitHub-hosted Mac and uploads it to App Store Connect, where TestFlight hands it to the internal
-testers; a manual run with `profile=production` uploads a prod-API build, and attaching that build to
+testers; a manual run with `profile=production` uploads a build that bakes no API URL at all and
+picks one at runtime from its iOS install source (`api.civfix.dev` while it is handed out through
+TestFlight, `api.civfix.org` once it is downloaded from the App Store), and attaching that build to
 a version and submitting it for review stays a human step in App Store Connect. The runner executes
 the same `scripts/store-build.sh` a developer runs locally (`eas build --local`, then a direct
 `fastlane pilot upload` to App Store Connect — no EAS Submit queue), so CI and laptop builds share

apps/community-mobile/APP-REVIEW-NOTES.md

@@ -3,6 +3,48 @@
 Paste the relevant section into **App Store Connect → App Review Information → Notes**
 (and into the Play Console reviewer notes where the equivalent field exists).
 
+The **Environment** section below is the exception: it is an internal pre-submission checklist, not
+reviewer-facing copy. Do not paste it into App Store Connect.
+
+---
+
+## Environment — App Review runs against STAGING (internal; do not paste)
+
+**The binary a reviewer runs talks to `api.civfix.dev`, not `api.civfix.org`.** This is deliberate
+and needs to be understood before every submission.
+
+The `production` EAS profile bakes no `EXPO_PUBLIC_API_URL`; the app picks its API at launch from its
+iOS install source — a TestFlight/beta install (`StoreKit/sandboxReceipt`) resolves to
+`https://api.civfix.dev`, an App Store download (`StoreKit/receipt`) to `https://api.civfix.org`
+(`src/lib/apiUrl.ts`, `src/lib/nativeBetaInstall.ts`; the mechanism is written up in `README.md`).
+App Review installs through the beta/sandbox path — the same fact behind StoreKit's 21007 sandbox
+receipt status — so the reviewer's copy sees a sandbox receipt and runs against **staging**.
+
+Consequences, accepted knowingly: the approval verdict is rendered against a binary whose production
+behaviour was never exercised by the reviewer, and anything the reviewer is asked to find has to exist
+on staging. There is no OTA update channel in this project that could flip an override for review
+only, and routing beta installs to staging is the property this app deliberately wants — testers must
+never write to the live civic record.
+
+**Pre-submission checklist — all of these are about the STAGING environment:**
+
+- [ ] `api.civfix.dev` is up and healthy (`/readyz`), and staging is on the same commit as the build
+      being submitted.
+- [ ] Staging carries reviewer-visible demo content: at least one event, organization or profile
+      that shows a **Donate** card, so the "Reviewer steps" under *External donation links* can
+      actually be followed. Without it the reviewer finds nothing and the note reads as false.
+- [ ] Staging carries a demo event with a ticket QR, so the check-in scanner note can be followed.
+- [ ] A working reviewer sign-in exists on staging and the credentials in App Store Connect →
+      App Review Information match it. **This is currently missing:** `REVIEWER_OTP_BYPASS` and
+      `REVIEWER_OTP_CODE` are absent from `civfix-infra/secrets/staging/api.sops.env` (and from the
+      prod one), so the reviewer-OTP path is fail-closed on staging today. Add both to the staging
+      SOPS file and redeploy before submitting, or give the reviewer an account whose OTP they can
+      actually receive.
+- [ ] Share links opened from the reviewer's build point at `civfix.dev` and resolve there; iOS
+      universal links are pinned to `civfix.org` only, so those links open in the browser rather than
+      deep-linking back into the app. Harmless, but do not write a reviewer step that depends on a
+      share link re-entering the app.
+
 ---
 
 ## External donation links

apps/community-mobile/README.md

@@ -69,17 +69,89 @@ pnpm --filter community-mobile exec expo run:ios      # or run:android
 
 Then start the bundler with `pnpm --filter community-mobile start` (runs `expo start --dev-client`).
 
-## Store builds: TestFlight (staging API) vs App Store (prod API)
+## Store-distribution profiles: `testflight` vs `production`
 
 Two store-distribution profiles exist in `apps/community-mobile/eas.json`, differing only in the
 baked API base URL and their EAS Update channel:
 
 - `testflight` - dev/testing builds for TestFlight. Bakes
   `EXPO_PUBLIC_API_URL=https://api.civfix.dev`, so testers hit the staging API. Update channel
   `testflight`.
-- `production` - official App Store releases. Sets no `EXPO_PUBLIC_API_URL`,
-  so release builds fall back to the prod API `https://api.civfix.org`
-  (`src/lib/apiUrl.ts`). Update channel `production`.
+- `production` - official App Store releases. Sets no `EXPO_PUBLIC_API_URL`, so the base URL is
+  chosen at RUNTIME by install source: `https://api.civfix.dev` while that build is handed out
+  through TestFlight, `https://api.civfix.org` once the same build is downloaded from the App Store
+  (`src/lib/apiUrl.ts`, `src/lib/nativeBetaInstall.ts`). Update channel `production`.
+
+### How the runtime split is decided (iOS only)
+
+**This split exists on iOS and nowhere else.** `src/lib/nativeBetaInstall.ts` returns `false` for any
+other platform, so an Android release build - including one handed to internal-track testers - always
+resolves to the production API. Android's own testing tracks have no equivalent on-device marker.
+
+iOS ships the App Store and TestFlight copies of a build with different StoreKit receipts: a store
+download gets `StoreKit/receipt` in the app's data container, a TestFlight install gets
+`StoreKit/sandboxReceipt`. `src/lib/nativeBetaInstall.ts` reads those two paths synchronously through
+`expo-file-system`, so `API_URL` is a plain module constant and one session can never straddle two
+APIs. `expo-application`'s `getIosApplicationReleaseTypeAsync()` cannot make this call: it reads the
+embedded provisioning profile, which reports `APP_STORE` for TestFlight and App Store alike.
+
+Precedence is `EXPO_PUBLIC_API_URL` (when baked) -> `__DEV__` localhost -> the receipt probe.
+
+**Both receipts can be on disk at once.** Moving between TestFlight and the App Store is an in-place
+update and the previous receipt is not removed, so mere presence decides nothing: the **newer** file
+wins (`src/lib/storeKitReceipt.ts`). Everything ambiguous resolves to production - no sandbox receipt,
+a tie, an unreadable modification time, an unreadable container, a probe that throws: all `false`. A
+store download therefore cannot be routed to staging by any failure mode of this probe.
+
+**The container path is an assumption.** The probe reconstructs `Bundle.main.appStoreReceiptURL` as
+`<data container>/StoreKit/<name>`, derived from `Paths.document.parentDirectory`. If Apple ever
+changes that layout the probe goes permanently `false` - production for everyone, which is the safe
+direction but silent. A dev build logs the resolved container and both receipt stats under
+`[install-source]` so the assumption can be checked on a real device.
+
+**Identity-bearing state is scoped to the API it was written against** (`src/lib/storageScope.ts`).
+Four ids carry the API host as a suffix: the app MMKV instance (`civfix.app` - cached user, last
+identity, persisted query cache, prefs), the session token in the keychain
+(`civfix.session.token`), the secure-blob MMKV instance (`civfix.secure`) and its keychain encryption
+key (`civfix.secure-blobs.key`). Production deliberately keeps the legacy un-suffixed ids so existing
+App Store users are not signed out by this change.
+
+Three stores are deliberately NOT scoped, because none of them holds identity or server state: the map
+filter prefs including recent-search history (`civfix.ui.filters`, `@civfix/ui`
+`map/filterStorage.native.ts`), the sidebar width (`civfix.ui.sidebar`,
+`shell/sidebarStorage.native.ts`), and the push `device_id` (`civfix.device_id`, `src/lib/deviceId.ts`),
+which must stay stable per install for the backend's push-token ownership guard to recognise a
+same-device handoff.
+
+**Scoping alone does not protect the TestFlight -> App Store upgrade**, and that is the whole point of
+`src/lib/storageEnvMarker.ts` + `src/lib/legacyStorageReset.ts`. Production resolves to the LEGACY ids,
+so a prod build cannot tell its own leftovers from a pre-namespacing TestFlight install's staging
+leftovers sitting under the same ids. Every run therefore records its environment in an unscoped
+keychain item (`civfix.storage.env`), and `adoptStorageEnvironment()` runs at boot before the first
+session read: on a production boot whose marker names a non-production environment, it clears the four
+legacy ids (the blob encryption key is emptied through its own store rather than deleted, so an
+already-open MMKV instance is never re-keyed mid-process) and the in-memory query cache. The marker
+lives in the keychain, not MMKV, because the keychain is where the dangerous leftover survives an app
+DELETE - so delete-and-reinstall into the App Store copy is covered too.
+
+*What it cannot detect:* the FIRST upgrade off a build that predates the marker. There the marker is
+absent, and an absent marker beside a legacy session token is genuinely ambiguous - equally a
+long-standing App Store user whose session is legitimately theirs. Signing all of those out is the
+worse failure, so an absent marker keeps the state: that one upgrade still sends a staging token to
+prod, is rejected with a 401 and signs out, after briefly painting the cached staging user. Every later
+environment flip on that install is covered, because by then a marker exists. Note also that a purge
+clears `civfix.app` wholesale, so the locale, theme and onboarding-seen prefs of the discarded
+environment go with it.
+
+**Share links do not follow the split.** `app.config.js` `ios.associatedDomains` pins
+`applinks:civfix.org` / `applinks:www.civfix.org` only, so a `civfix.dev` link produced by a
+staging-resolved build opens in the browser rather than deep-linking into the app. Universal links
+work only against the production domain; adding `civfix.dev` would need a new entitlement and a
+matching apple-app-site-association file on that host.
+
+**App Review runs against staging.** A reviewer's copy is installed through the beta/sandbox path, so
+the probe returns `true` and review sessions hit `api.civfix.dev`. That is a deliberate, recorded
+property - see the "Environment" section of `APP-REVIEW-NOTES.md` and its pre-submission checklist.
 
 ### Hand-driven Xcode archive (`scripts/prep-archive.sh`)
 
@@ -93,8 +165,8 @@ read `.env` at *archive* time.
 So prep the native project with the target's `.env` in place, then archive by hand:
 
 ```sh
-pnpm --filter community-mobile prep:testflight   # -> https://api.civfix.dev
-pnpm --filter community-mobile prep:appstore     # -> https://api.civfix.org
+pnpm --filter community-mobile prep:testflight   # -> bakes https://api.civfix.dev
+pnpm --filter community-mobile prep:appstore     # -> bakes NOTHING; resolved at runtime
 apps/community-mobile/scripts/prep-archive.sh appstore --platform android
 ```
 
@@ -116,9 +188,11 @@ for every third-party dependency. Then: open `ios/civfix.xcworkspace`, destinati
 
 Two things this script exists to stop:
 
-- `.env` is gitignored and *persists*. A `testflight` prep silently governs every later local build
-  on that machine, so the `appstore` target writes `https://api.civfix.org` **explicitly** rather
-  than leaning on the fallback in `src/lib/apiUrl.ts`. Re-run the script before switching targets.
+- `.env` is gitignored and *persists*. A `testflight` prep would otherwise silently govern every
+  later local build on that machine. The script **rewrites `.env` on every run**, so the `appstore`
+  target's omission of `EXPO_PUBLIC_API_URL` is a real omission and not a leftover - and the banner
+  refuses to let you archive unless the built config carries **no `apiUrl` at all**. Baking one there
+  would freeze the runtime split to a single API. Re-run the script before switching targets.
 - `expo prebuild` deletes `DEVELOPMENT_TEAM` from the pbxproj on every run unless `ios.appleTeamId`
   is set, so a team picked by hand in Xcode's Signing & Capabilities pane vanishes on the next
   prebuild. The script reads the existing team back out and feeds it in via `CIVFIX_APPLE_TEAM_ID`.
@@ -143,7 +217,7 @@ Android ships by hand from this directory: prep the target, re-apply the machine
 Temurin 25).
 
 ```sh
-scripts/prep-archive.sh testflight --platform android   # or appstore -> https://api.civfix.org
+scripts/prep-archive.sh testflight --platform android   # or appstore; Android always resolves to https://api.civfix.org
 scripts/android-release-patches.sh
 export JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk-22.jdk/Contents/Home
 cd android && ./gradlew --no-daemon :app:assembleRelease   # or :app:bundleRelease for the Play .aab
@@ -312,7 +386,9 @@ to `eas build`), and never map the `testflight` channel onto a prod-published br
 Config plugins for the native modules (camera/mic/location permission strings, Google sign-in URL
 scheme, Apple auth, notifications) are declared in `apps/community-mobile/app.config.js`. The API base
 URL comes from `EXPO_PUBLIC_API_URL`, surfaced via `extra.apiUrl`; when unset, dev builds fall back
-to `http://localhost:8080` and release builds to `https://api.civfix.org` (`src/lib/apiUrl.ts`).
+to `http://localhost:8080` and release builds to whichever API the install source implies -
+`https://api.civfix.dev` from TestFlight, `https://api.civfix.org` from the App Store
+(`src/lib/apiUrl.ts`).
 
 ## pnpm + Expo + the shared packages
 

apps/community-mobile/app.config.js

@@ -33,6 +33,14 @@ function resolveSourceCommit() {
   }
 }
 
+const EAS_DEVELOPMENT_PROFILES = ["development"]
+
+function apsEnvironmentMode() {
+  const profile = process.env.EAS_BUILD_PROFILE
+  if (!profile) return "development"
+  return EAS_DEVELOPMENT_PROFILES.includes(profile) ? "development" : "production"
+}
+
 const SPLASH_BG_LIGHT = tokens.color.neutral.paper
 
 const APP_LINK_HOSTS = ["civfix.org", "www.civfix.org"]
@@ -229,6 +237,7 @@ module.exports = ({ config }) => ({
       "expo-notifications",
       {
         color: "#FF7A6B",
+        mode: apsEnvironmentMode(),
       },
     ],
     [

apps/community-mobile/app/_layout.tsx

@@ -48,11 +48,12 @@ import {
   ToastProvider,
   setBrandAboutPresenter,
   setOnboardingTourPresenter,
+  setApiHost,
   setScanPresenter,
   setSourceCommit,
   setWebOrigin,
 } from "@civfix/ui"
-import { CARTO_API_KEY, DONATE_BROWSER_MODE, SOURCE_COMMIT, WEB_ORIGIN } from "@/config"
+import { API_URL, CARTO_API_KEY, DONATE_BROWSER_MODE, SOURCE_COMMIT, WEB_ORIGIN } from "@/config"
 import { nativeCamera, setCameraNavigator } from "@/lib/nativeCamera"
 import { nativeCalendarFile } from "@/lib/nativeCalendarFile"
 import { nativeClipboard } from "@/lib/nativeClipboard"
@@ -72,6 +73,7 @@ import { chatSocket } from "@/lib/ws"
 import { usePrefsStore } from "@/store/prefsStore"
 import { resolveActiveLocale } from "@/lib/locale"
 import { goHome } from "@/lib/goHome"
+import { adoptStorageEnvironment } from "@/lib/legacyStorageReset"
 import { isExternalUrl } from "@/lib/links"
 import { codeScannerSupported } from "@/lib/scannerSupport"
 import {
@@ -178,6 +180,7 @@ async function openInAppBrowser(url: string): Promise<void> {
 
 setWebOrigin(WEB_ORIGIN)
 setSourceCommit(SOURCE_COMMIT)
+setApiHost(API_URL)
 
 const mobileCapabilities: PlatformCapabilities = {
   ...makeFakeCapabilities(),
@@ -330,7 +333,11 @@ function useBootstrap() {
     setUnauthorizedHandler(() => {
       useAuthStore.getState().markUnauthed()
     })
-    void hydrate()
+    void adoptStorageEnvironment()
+      .catch(() => false)
+      .finally(() => {
+        void hydrate()
+      })
     return () => setUnauthorizedHandler(null)
   }, [hydrate])
 }
@@ -628,7 +635,11 @@ export function ErrorBoundary({ error, retry }: ErrorBoundaryProps) {
       <Text style={crash.title}>{copy.title}</Text>
       <Text style={crash.body}>{copy.body}</Text>
       {__DEV__ ? <Text style={crash.detail}>{String(error?.message ?? error)}</Text> : null}
-      <Pressable accessibilityRole="button" onPress={onRetry} style={crash.action}>
+      <Pressable
+        accessibilityRole="button"
+        onPress={onRetry}
+        style={({ pressed }) => [crash.action, pressed ? crash.actionPressed : null]}
+      >
         <Text style={crash.actionLabel}>{copy.action}</Text>
       </Pressable>
     </View>
@@ -686,6 +697,9 @@ function crashStyles(t: Theme) {
       borderRadius: t.radius.pill,
       backgroundColor: t.colors.brand.bloom,
     },
+    actionPressed: {
+      opacity: 0.85,
+    },
     actionLabel: {
       fontSize: t.fontSize["16"],
       fontWeight: "600",