Trigger
Take photo, choose photo, or add several images.
Capacitor Camera Workflow
Build a complete Camera Flow in a Capacitor Mobile project, covering permissions, all six actions, Get Photo options, results, preview, cancellation, and target testing.
Camera is a native workflow in a Capacitor Mobile project
Add the Capacitor Camera extension to a Mobile project that uses the Capacitor runtime. The usual page contains a trigger, preview, progress/permission feedback, and a clear/cancel path; the actual hardware work runs in an App, Page, or Inline Flow through the Capacitor Camera actions.
Camera Flow
Checks permissions, runs the native action, and handles every result.
Preview and persistence
Displays the result, then uploads or saves it only when required.
Open the native-capability page context
This Capacitor showcase demonstrates the same architecture the Camera feature uses: native components and actions sit inside a normal Framework7 page, while App Connect state keeps the visible UI reactive.
All six Camera actions and when to use them
The current Wappler Flow schema exposes the full Capacitor Camera surface. Choose the narrowest action that matches the user task.
| Action | Use it for |
|---|---|
| Get Photo | Take one photo, choose one existing photo, or prompt between those sources |
| Pick Images | Choose multiple images from the photo library |
| Pick Limited Library Photos | Update the limited-library selection on supported iOS versions |
| Get Limited Library Photos | Read the currently selected limited-library photos on supported iOS versions |
| Check Permissions | Inspect camera and photo-library permission state before the operation |
| Request Permissions | Request camera and/or photo-library access through an explicit permissions array |
Start the Flow with a permission branch
Add Check Permissions under Capacitor → Camera. Branch on the returned camera/photos state. Continue immediately when access is granted, explain the benefit and Request Permissions when it is promptable, support limited photo access, and show a settings/help path when access is denied.
| State | Flow response |
|---|---|
| granted | Run the selected Camera action |
| prompt / prompt-with-rationale | Explain the feature, then Request Permissions |
| limited | Continue with the allowed library or offer Pick Limited Library Photos |
| denied | Do not loop prompts; show a clear settings/help path |
| unavailable | Disable the feature or offer a web/file-input fallback |
Configure Get Photo size, quality, source, and result
Name the Flow step, then configure only the options the use case needs. Smaller dimensions and sensible JPEG quality reduce memory, upload time, and storage. Source controls whether the user sees a choice, opens the camera directly, or opens saved photos.
| Option | Values or purpose |
|---|---|
| width / height | Maximum output dimensions; aspect ratio is preserved |
| quality | JPEG quality from 0–100 |
| source | PROMPT, CAMERA, or PHOTOS |
| direction | REAR or FRONT on supported iOS/Web behavior |
| presentationStyle | fullscreen or popover on iOS |
| resultType | uri, base64, or dataUrl |
| allowEditing | Enables platform-specific crop/small edits where supported |
| saveToGallery | Saves the captured/edited result to the gallery when applicable |
| correctOrientation | Rotates the returned image to the correct portrait orientation |
| webUseInput | Forces a web file input instead of the PWA Elements experience |
Customize the source prompt labels
When Source is PROMPT, use the label options to make the system choice clear and consistent with the app language. These options accept expressions, so labels can come from localization state.
| Option | Purpose |
|---|---|
| promptLabelHeader | Prompt heading |
| promptLabelCancel | Cancel label on iOS |
| promptLabelPhoto | Saved-photo/library choice |
| promptLabelPicture | Open-camera choice |
Pick Images has its own multi-select controls
Use Pick Images for a gallery or attachment workflow that accepts several pictures. Configure width, height, quality, presentationStyle, correctOrientation, and the supported iOS selection limit. Treat the result as a collection and build repeat-driven preview/removal UI.
NOTE: Platform versions differ: older iOS versions may allow only one selected picture, and limited-library actions are iOS-specific.
Choose a result type by the next operation
Do not default every image to base64. A URI is usually the lightest preview/upload handoff. dataUrl is convenient for direct image binding. base64 is useful when an API or local format explicitly requires raw encoded data, but it increases memory and payload size.
| Result type | Best fit | Tradeoff |
|---|---|---|
| uri | Preview, file handoff, later upload | May need platform/web-path conversion for a specific consumer |
| dataUrl | Direct image src binding | Larger in-memory string |
| base64 | API or storage format that explicitly requires base64 | Highest memory/payload cost and needs a MIME prefix for image binding |
Bind success, cancellation, and failure separately
On success, store the returned path/webPath/data and bind it to the preview. A user closing the camera or picker is a normal cancellation path, not necessarily an error toast. Reserve failure UI for permission, availability, read, or native execution problems, and always restore the button/loading state.
Set a busy state before the native handoff
Store the named action output on success
Bind the correct result field to the image preview
Treat user cancellation as a quiet return path
Show actionable messages for denied/unavailable/native errors
Clear the busy state in every branch
Preview first; persist only when the user confirms
For profile photos, reports, or attachments, let the user review the image before upload or local persistence. Validate size/type, optionally resize, call the server/API or Filesystem action, display progress, and keep a retry path that does not force another capture.
TIP: Keep capture and upload as separate Flow groups. That makes cancellation, retries, offline queues, and replacement much easier to reason about.
Run the complete Camera test matrix
Build and run on each supported Capacitor target after installing the extension or changing permission configuration. Test first grant, existing grant, denial, limited access, cancellation, rear/front camera where supported, library selection, multiple images, orientation, large images, offline upload, app resume, and low-memory behavior.
| Target area | Tests |
|---|---|
| Permissions | First request, granted, denied, limited, unavailable |
| Capture | Rear/front where supported, orientation, editing, save to gallery |
| Library | Single, multiple, limited-library update/read, cancellation |
| Result | URI/dataUrl/base64 binding, dimensions, quality, memory |
| Persistence | Upload/save, retry, offline, app background/resume |
Camera workflow complete
Return to the Mobile Apps hub for Framework7, Bootstrap 5 mobile, Capacitor, and desktop paths, or open the generated mobile reference for exact component properties.
