Design mobile uploads so users can tell whether a file is selected, transferring, being checked or attached to the intended record. Preserve useful progress after interruptions without creating duplicate attachments. File transfer and business completion are separate outcomes, particularly when a background process validates or transforms the upload.
Let’s plan your mobile upload journey.
Bring your workflow and the decisions you need to make. We’ll help you clarify requirements, review the trade-offs and define a practical next step.
Define the attachment before building the picker
Specify file purposes, accepted formats, size limits and the record that owns the attachment. Explain restrictions before the user spends time selecting a file. If an image must show a particular detail, provide an understandable capture instruction rather than a cryptic server rejection.
Decide whether the app keeps a local copy and for how long. Shared devices, account switching and abandoned drafts affect the design. Store temporary material only within the agreed access and retention boundaries.
Use explicit transfer states
| State | What users should understand | Acceptance case |
|---|---|---|
| Selected | File is local and not yet submitted | Removing it prevents transfer |
| Uploading | Transfer is in progress | Interruption gives a meaningful next step |
| Received | Server has the file | Attachment is not falsely shown as approved |
| Checking | Validation or scanning remains | Pending status survives refresh |
| Attached | File belongs to the correct record | Authorised users can retrieve it |
| Rejected | File cannot be used | Reason and permitted correction shown |
Use progress indicators that reflect what is measured. If only transferred bytes are known, do not label 100 percent as completion of every downstream check.
Recover without repeating the business action
For a hypothetical field-service report, a photo upload may finish just before the app loses connectivity. On retry, verify the existing upload reference before creating another attachment. Keep the report submission identifier separate from individual file-transfer attempts.
If resumable transfer is supported, test its actual boundaries. Otherwise explain that the transfer will restart. Test app suspension, low storage, expired sessions and the user changing accounts during a pending upload.
Include server-side controls
OWASP's file-upload guidance recommends layered validation and controlled storage rather than trusting a supplied filename or content type. The mobile picker is a convenience, not the security boundary.
Apply authorisation when retrieving or deleting an attachment as well as when uploading it. An unguessable file URL alone should not substitute for the chosen access model.
Upload questions
Should a failed attachment block the whole form?
Decide from the record's requirements. An optional image can remain pending; mandatory evidence needs a clear completion rule.
Can uploads continue after leaving the screen?
Only where the supported app lifecycle and implementation provide that behaviour. Show the pending work and verify it on representative devices.
Include upload recovery in mobile acceptance testing. Bring file types and expected usage to a mobile app consultation.
This article explains what to build, not legal advice. Rules change; confirm against the current official text before relying on it.
