Camera, photos, location, maps
The phone hardware your app can use, what it needs from you, and how to test each one properly.
These are the things a phone can do that a website cannot. All of them work in a phone preview, so you can test them before building anything installable.
Photos and camera
Supported out of the box:
- Pick an existing photo from the library
- Take a photo in the app
- Record video
- Upload either to your app's storage
Ask for it plainly:
People add up to three photos when they list a plantPermission prompts are handled for you. What is worth checking yourself is the refusal path: say no to the prompt and confirm the app still works and explains what is missing.
Microphone
Voice recording is supported, for voice notes, dictation, or anything you then hand to a speech-to-text model.
Location
Reading the person's location is supported: "near me" listings, run tracking, distance, weather for where they are.
Two things to keep in mind:
- Location prompts are the ones people refuse most often. Ask when the value is obvious, not on first launch
- Continuous background tracking is not supported. Location is read while the app is in use
Maps
Maps are supported, with one thing you have to provide.
Maps need your own Google Maps key
Map rendering is billed by Google against your account, not Mistflow's. Get a key from
the Google Cloud Console with Maps SDK enabled for Android and iOS, then add
EXPO_PUBLIC_GOOGLE_MAPS_KEY_IOS and EXPO_PUBLIC_GOOGLE_MAPS_KEY_ANDROID to your
project's environment variables in the dashboard. Without them, map screens render blank.
Maps are not included in every app by default, because they add meaningful size to the installed app. They are added when your app actually uses them.
Markers use images rather than custom-drawn views. This is not a shortcut: custom view markers are broken on current Android, and image markers behave identically on both platforms.
Files and uploads
Documents and images can be uploaded to your app's storage and read back. Ask for the behaviour you want, for example "attach a receipt to each expense".
Permissions, in general
Every capability above needs the person's consent, and the prompt only appears once. A refusal is permanent until they change it in system settings.
That gives one rule worth following: ask at the moment of use, not on launch. A prompt on first launch, before anyone knows what the app is for, is the fastest way to get permanently refused.
Testing device features
| Feature | How to test it properly |
|---|---|
| Camera and photos | On a real phone. The in-browser preview cannot use the camera |
| Location | On a real phone, outdoors if accuracy matters |
| Maps | Confirm the keys are set, then check a map screen actually renders tiles |
| Uploads | Try a large file and a slow connection, not just a small photo on wifi |
| Permissions | Refuse each prompt once and use the app anyway |
Not supported
- Health and fitness platform data (HealthKit, Google Fit)
- Bluetooth devices and wearables
- AR
- Background location or background work beyond audio
If your app depends on one of these, say so early rather than building around it.