ADR-034: Web app hosting and mobile app distribution¶
| Status | Accepted |
| Date | 2026-04-10 |
| Deciders | CTO, Head of Architecture |
| Affects repos | bank-app |
Status¶
Accepted — 2026-04-10
Context¶
ADR-007 established two build targets for bank-app: a static web build for back office
staff and a Capacitor mobile build for customers. This ADR decides where the web build is
hosted and how the mobile build is distributed and updated.
Decision¶
Back-office web app — Cloudflare Pages¶
The build:web output is deployed to Cloudflare Pages via the SST StaticSite construct.
Zero cost, global CDN, first-class SST v3 integration. The back-office app is a static
asset bundle (HTML, JS, CSS) — no customer data resides on the CDN. All data is fetched
at runtime from API Gateway (ADR-025) over HTTPS. Data residency obligations apply to the
API and database layers, not the static assets.
Cloudflare Pages preview deployments are used for UAT branches. Production deployment maps to the main branch. Staff access the back-office URL via their corporate browser — no app store distribution for back office.
Customer mobile app — App Store and Google Play only. No OTA updates.¶
The Capacitor build is submitted to the iOS App Store and Google Play Store through the standard review process. No over-the-air update mechanism is used.
The customer app is a regulated financial application. App store review provides a change management gate consistent with DT-007 (change and release management). OTA updates bypass this gate and create a gap in the change audit trail. APRA and RBNZ expect change controls on customer-facing financial software — app store release satisfies this; OTA does not.
Constraints this creates for bank-app¶
- Back-office build must be fully static — no server-side rendering at the CDN layer; data fetched client-side from API Gateway
- Mobile releases follow the standard pipeline: build → test gates → Capacitor build → App Store Connect / Play Console submission → store review → release
- No expedited release path outside this process for core functionality changes
Rejected alternatives¶
| Option | Reason rejected |
|---|---|
| CloudFront + S3 (back office) | Viable but more configuration overhead; Cloudflare Pages is simpler, free, and has equivalent capability |
| Vercel (back office) | Excellent Next.js DX; cost at scale; outside the AWS boundary adds operational surface |
| OTA updates for mobile | Bypasses app store review gate; incompatible with change management obligations under DT-007 |
Signoff record¶
| Date | Name | Role | Status |
|---|---|---|---|
| 2026-04-10 | Ross Millen | CTO | Approved |
| 2026-04-10 | Ross Millen | Head of Architecture | Approved |
| 2026-04-10 | Ross Millen | Head of Data | Approved |
Capabilities¶
| Capability | Description | Relationship |
|---|---|---|
| CAP-073 | Dual-mode rendering engine (customer + back office) | enabled — back office on Cloudflare Pages; customer on App Store/Play Store |
| CAP-110 | App navigation & deep linking | enabled — Capacitor native shell distributed via App Store enables deep links |
Related decisions¶
| ADR | Title | Relationship |
|---|---|---|
| ADR-007 | Frontend framework — React/Next.js with Capacitor | defines the two build targets this ADR deploys |
| ADR-022 | CI/CD and deployment strategy | app store release is part of the standard pipeline |
| ADR-025 | API layer — HTTP API Gateway and SST | back office web app fetches all data from API Gateway |
All ADRs
Compiled 2026-05-22 from source/entities/adrs/ADR-034.yaml