Mobile & notifications
iOS parity, server-backed data, push notifications, token refresh, and StuartTech tracking.
The iOS app uses the same production API and server-backed church records as the website. People, requests, care plans, forms, tasks, and settings should not live as offline-only local records on device.
Mobile access follows the same privacy model as the website: server-side row scope, Queue Manager redaction, admin elevation, auditing, and confidential-care filters apply before data reaches the app.
How to
Sign in and stay signed in
Native clients identify themselves with X-Client: ios, store tokens securely, and use refresh-token rotation so staff can stay signed in without bypassing server session revocation.
Use server-backed notifications
Push registration uses the StuartTech shared notification stack and stores APNs device tokens on the server. Server notifications should include only minimal, non-sensitive copy and deep-link metadata.
Configure Apple push
APNs delivery requires the iOS app identifier to have Push Notifications enabled in Apple Developer, a valid APNs .p8 key, and server runtime config for team ID, key ID, bundle ID, signing key, and production/sandbox target.
Track usage through StuartTech
Mobile usage tracking should use the StuartTech shared usage layer and StuartTech-owned tracking endpoints, including stuarttech.com tracking infrastructure when configured.
Tips
- Do not include pastoral details, care notes, safety-report content, or full PII in notification payloads.
- If push is not configured, the app should continue to work without local-only fallback data.
- The website and iOS app should show the same current server data for demo and logged-in tenants.
Mobile setup is an admin/operator concern. Runtime access remains governed by each user's role and record scope.