Add a camera to an AI-built mobile app: permission, capture and upload boundaries

A worked example: where the task becomes difficult

A fictional repair app lets customers photograph a damaged component. A generated screen requests camera permission immediately on launch and fails if permission is denied. A better journey explains the request when the customer chooses to attach a photo, offers a supported alternative and preserves the rest of the enquiry. Use controlled images that do not include bystanders or private documents.

Decisions to make before implementation

Identify the app runtime and the current camera library’s supported device behavior. Separate permission state, capture result, local attachment and server upload. Decide whether location metadata is needed and avoid retaining it by default without a reason. Define size, orientation, compression and deletion rules. A captured image remaining on the device is not evidence that the support team received it.

A practical sequence for the work

Use the sequence below as a task boundary, not as a claim that the example has been executed. Work with approved inputs and the project’s actual architecture. If a required integration or permission is unavailable, keep that stage visibly incomplete rather than generating a plausible substitute result.

• Specify the photo task and inspect the current platform camera contract.
• Implement permission and denial states at the point of use.
• Capture and preview a controlled image with explicit remove or retake actions.
• Verify protected upload and downstream attachment availability separately.

A detailed brief you can adapt for your agent

Replace the illustrative context with your approved facts and controlled inputs. Keep the stated boundaries when adapting the brief. The expected deliverable matters more than a particular tool name: ask for an explanation grounded in the inspected material and evidence for the requested outcome.

Add damage-photo capture to this existing mobile project. Inspect its runtime and camera-library contract first. Request access only when attaching a photo, handle denial and allow retake or removal. Use controlled images and verify upload separately. Do not claim physical-device capture from a simulator-only test.

Failure modes that an attractive preview can hide

Simulator support can differ from physical-device behavior. Do not declare the camera verified from a mocked preview. Avoid repeatedly requesting access after a denial or blocking unrelated app tasks. A large image can exhaust upload limits; enforce the approved contract at the receiving boundary and keep input recoverable.

Technical references: Expo: camera

Acceptance checks and the evidence to retain

Keep permission states, device evidence, attachment policy and upload result. Mark unsupported devices or untested capture paths explicitly.

Specific answers

Common questions