Permissions
Golden rule (enforced by AppForge): the app requests only the permissions you enable — and asks the user only at the moment a feature actually needs them. Store reviews reject apps with unused or unexplained permissions.
Where things are configured
| Place | What it controls |
|---|---|
| Admin → WebView | Camera / microphone / location as features of the WebView (file uploads, getUserMedia, geolocation). Toggling these also updates the Permissions page. |
| Admin → Permissions | The full list incl. storage, notifications, biometric — plus each permission's iOS usage description. |
The exporter turns enabled permissions into AndroidManifest.xml entries and Info.plist usage keys. Disabled permissions leave no trace in the binary.
The catalog
- Camera — camera capture in website
<input type="file">fields andgetUserMedia. Runtime prompt appears the first time the site asks. - Microphone — website audio recording (
getUserMedia). - Location — website geolocation requests.
- Storage / Photos — gallery selection for uploads (iOS photo library text).
- Notifications — push permission (asked once on first launch when Firebase is enabled; Android 13+ also prompts).
- Biometric — the optional Face ID / Touch ID / fingerprint app lock. When enabled here, users get a "Biometric Login" switch in the app's Settings. No biometric data is ever stored — only the operating system's own authentication APIs are used.
iOS usage descriptions
Every enabled permission (except notifications) needs a sentence shown to the user in the iOS permission dialog. Sensible defaults are pre-filled — replace them with honest, app-specific texts; generic texts are a common App Store rejection reason.
Behavior when denied
Users can always say no. The app keeps working: uploads without camera fall back to gallery/files, location-based site features simply don't get a position, and push stays silent. Never assume a permission is granted.