1. Upload is a flow, not only a request
A file upload includes permission, source selection, preview, compression, validation, network transfer, API response, retry and final confirmation. Treating it as one button hides many failure points.
The app should make progress and failure visible without forcing the user to guess whether the file was saved.
- Define allowed file types, size limits and required metadata.
- Show selected files before sending when the business needs confirmation.
- Explain failures in user language, not raw API errors.
- Avoid losing selected files during navigation changes.
- Confirm upload completion separately from form submission when needed.
2. Permissions and file source affect user trust
Camera, gallery and file picker flows should request access only when the user understands why. A denied permission is not an error by itself; it is a state the app must handle gracefully.
The app also needs to decide whether files come from camera capture, gallery selection, generated documents or external storage.
- Ask permission near the upload action, not at random startup.
- Describe why camera or media access is useful.
- Handle denial with an alternate path or clear explanation.
- Avoid asking for broader access than the feature needs.
- Review Android and iOS permission text before release.
3. Compression and API limits must be explicit
Large photos can make uploads slow, expensive and failure-prone. The backend and mobile app should agree on maximum size, accepted formats, image processing and how errors are returned.
When the API rejects a file, the user needs a recovery path, not a silent failure.
- Compress photos to the quality needed for the business purpose.
- Define API limits for size, count and content type.
- Return field-level or file-level errors when possible.
- Avoid sending full-resolution images when thumbnails are enough.
- Record correlation IDs for failed upload attempts.
4. Retry and offline behavior need careful promises
If the app promises that upload will continue later, it needs durable queueing, file persistence and conflict rules. If it does not support that, the UI should be honest about needing connection now.
A half-designed offline upload can be worse than no offline upload because users believe work was saved when it was not.
- Decide whether uploads can be queued safely.
- Keep local files accessible until the queue finishes or is cleared.
- Show pending, failed and completed upload states.
- Avoid infinite retries for invalid files.
- Provide a manual retry path when network failure is likely.
How to use this article
Treat this page as a decision aid. Use it with the related hub, checklist or service route when the topic affects production, customer experience, deployment, security or business continuity.