CamerAwesome: a Flutter camera plugin with its own built-in UI

What CamerAwesome gives a Flutter app

The problem CamerAwesome sets out to solve is stated in the repository description in plain terms: embedding a camera experience within your own app should not be that hard. The package is a Flutter plugin that gives you a camera experience you can use inside your app, either through the built-in interface or by customizing it.

That dual offering is the point of difference. Most camera plugins expose a low-level preview widget and leave the shutter button, the gallery picker, the mode switch and the capture feedback to you. CamerAwesome provides a complete interface as a single builder call, and also gives you the pieces to assemble a different one.

The `example/` directory in the repository is a full Flutter application, with its own `android/` and `ios/` folders, an `integration_test/` directory, a `lib/` directory and a `scripts/` directory, so the intended way to learn the API is to read and run the example rather than a documentation site alone. The `docs/` directory and the `docs.json` file are present for the published documentation, and the README links to a hosted version of it.

The primary language is Dart, the licence is MIT with a `LICENSE` file at the root, and the project is not archived. The last push was on 2026-10-08, though the most recent published release is 2.0.0 from 2023-11-22, and a `CHANGELOG.md` is in the tree, so the gap between the branch head and the last tag is the first thing to check before you pin a version.

The built-in interface is one builder call

The default path is deliberately short. The README gives the whole integration as:

CameraAwesomeBuilder.awesome(
  saveConfig: SaveConfig.photoAndVideo(),
  onMediaTap: (mediaCapture) {
    OpenFile.open(mediaCapture.filePath);
  },
),

The description says all you need to create a complete camera experience within your app is to use the builder. `saveConfig` decides what the camera is allowed to produce, and `SaveConfig.photoAndVideo()` allows both. The `onMediaTap` callback receives the captured media and gives you the file path, which the example opens with `OpenFile.open`.

That callback is the seam where you take over. Capturing a file and then doing something with it, uploading it, or handing it to another widget, happens entirely on the Dart side, and the plugin's own UI is not in the way of that flow.

The builder is described as customizable with a theme and with builders for each part of the interface. The README's own bullet list is cut off in the middle of that sentence, so the exact set of per-part builders is not visible here, and you should treat the hosted documentation as the authoritative list rather than assuming which parts are replaceable. What is clear is that the built-in UI is composed of separate pieces, since the customization is expressed as builders per part rather than as a single style object.

Feature parity across Android and iOS is not complete

The README publishes a feature table with one column per platform, and it is worth reading carefully rather than assuming a Flutter camera plugin behaves the same on both. The following are marked as available on both Android and iOS: asking for permissions, recording video, multi camera, enabling and disabling audio, taking photos, photo live filters, exposure level, broadcasting a live image stream, image analysis such as barcode scanning, zoom, device flash support, auto focus, live switching between cameras, camera rotation stream, background auto stop, and toggling front camera mirroring.

Two entries break the symmetry.

First, sensor type switching is marked as unavailable on Android and available on iOS. If your feature depends on switching between a wide and a tele camera, the plugin will not give you that on Android through this API, and the difference is a platform capability issue rather than a bug you can configure away.

Second, multi camera is labelled beta on both platforms, which is the only feature in the table that carries a maturity marker. A feature that is documented as beta in a published support table is one you should prototype against before committing a product flow to it.

Image analysis, listed as barcode scan and more, is the feature that most often turns a camera plugin into a scanning tool, and it is listed as available on both platforms.

Adding the dependency and the Dart import

Installation is a pub dependency. The README shows the entry in `pubspec.yaml`:

dependencies:
  camerawesome: ^2.0.0-dev.1
  ...

Note the constraint: it is a pre-release version of the 2.x line, a caret on `2.0.0-dev.1`, even though 2.0.0 itself is listed as a published release. Pub's handling of pre-release constraints has its own rules, so the exact version your project resolves is worth confirming in `pubspec.lock` after the first `pub get` rather than assuming.

The import is a single line:

import 'package:camerawesome/camerawesome_plugin.dart';

That file name is the plugin entry point and the only import the example needs to start.

If you are moving from the 1.x line, the README points to a dedicated migration guide for going from 1 to 2, hosted alongside the rest of the documentation. Since 1.0.0 was published on 2023-01-09 and 2.0.0 on 2023-11-22, the two lines are far enough apart that the guide is likely to matter, and the README also notes that `WRITE_EXTERNAL_STORAGE` is not included in the plugin starting with version 1.4.0, which tells you at least one behavioural change landed between the 1.0 and 2.0 tags.

iOS usage descriptions and the Android permission set

On iOS, three keys have to be added to `ios/Runner/Info.plist`:

<key>NSCameraUsageDescription</key>
<string>Your own description</string>

<key>NSMicrophoneUsageDescription</key>
<string>To enable microphone access when recording video</string>

<key>NSLocationWhenInUseUsageDescription</key>
<string>To enable GPS location access for Exif data</string>

The location key is for Exif metadata, which is easy to overlook: if you want coordinates embedded in the photos, the app must be granted location access, and the string you write is what the user sees in the permission prompt.

On Android, the minimum SDK version has to be raised to 21 in `android/app/build.gradle`:

minSdkVersion 21

Recording video with audio needs `RECORD_AUDIO` in the `AndroidManifest.xml`:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
        package="com.example.yourpackage">
  <uses-permission android:name="android.permission.RECORD_AUDIO" />

  <!-- Other declarations -->
</manifest>

And saving location in Exif metadata needs fine and coarse location permissions. The README also notes that storage permissions depend on the Android version and on where you want to save files, pointing at the official Android documentation on data storage.

The permission handling is a first-class feature in the support table, listed as asking permissions on both platforms, but the app still has to declare them.

Gradle dependency overrides and the version conflicts they solve

Buried in a collapsed section of the README is the part that saves people hours. Some of the dependencies CamerAwesome uses can be overridden, and the version is set through variables in the `buildscript` block:

buildscript {
  ext.kotlin_version = '1.7.10'
  ext {
    // You can override these variables
    compileSdkVersion = 33
    minSdkVersion = 24 // 21 minimum
    playServicesLocationVersion = "20.0.0"
    exifInterfaceVersion = "1.3.4"
  }
  // ...
}

The README is blunt about when to use them: only change these variables if you are sure of what you are doing. The worked example is a conflict with another plugin over the Play Services Location library, which surfaces as a runtime linkage error rather than a build failure:

java.lang.IncompatibleClassChangeError: Found interface com.google.android.gms.location.ActivityRecognitionClient, but class was expected

That error is the kind that appears at runtime on a screen you did not expect, and the fix documented here is to pin `playServicesLocationVersion`.

The `minSdkVersion` default of 24 with a comment that 21 is the minimum is a second useful signal: the plugin compiles against a higher floor than the one it requires, so you can lower it if your other dependencies allow.

The repository also ships a Dart lint setup, with an `analysis_options.yaml` at the root and one in the example app, and a `pigeons/` directory that holds the platform channel code generation definitions used to keep the Dart side and the native sides in step.

Where CamerAwesome is the wrong choice

The first wrong case is a product that needs identical behaviour on Android and iOS, because the plugin's own support table shows the platforms diverging on sensor type switching and marks multi camera as beta on both.

The second is an app where you cannot let a plugin own the camera UI. The built-in interface is the fastest route in, and it is also a constraint: the design system of the camera screen becomes the plugin's, and the customization path is expressed as builders for each part of the interface. If your design calls for a capture flow that looks nothing like the default, you are rebuilding most of it, and at that point you are paying for the plugin's capture and analysis layer only.

The third wrong case is a codebase with a heavy Android dependency graph. The override variables exist precisely because conflicts with other plugins happen, and the documented symptom is a runtime `IncompatibleClassChangeError` rather than a compile error, so a conflict can reach production unnoticed unless you test on a device.

There is also a project-level caution. The plugin is published on pub.dev as `camerawesome` and the README shows a pre-release constraint, `^2.0.0-dev.1`, while the most recent published release is 2.0.0 from 2023-11-22 and the branch head moved on 2026-10-08. The plugin is also offered as a template inside ApparenceKit and the homepage points there. For a dependency that sits inside a mobile app, a stable tag from the changelog is a safer anchor than the head of a branch that is still receiving pushes.

Editorial conclusion

CamerAwesome fits Flutter teams that want a working camera experience in a day rather than a native camera integration of their own, and that are willing to accept a plugin which owns the capture UI. It does not fit a product that needs the same feature set on both platforms, since sensor type switching is marked unavailable on Android while multi camera is still labelled beta, and it does not fit a team unwilling to configure iOS usage descriptions and Android permissions by hand. Before adopting it, check the `camerawesome` version constraint in your `pubspec.yaml` against the `CHANGELOG.md`, confirm the `minSdkVersion 21` floor in `android/app/build.gradle` fits your other plugins, and read the migration guide before moving from the 1.x line, since the API changed across that boundary.

Frequently asked questions

Official sources

1. Apparence-io/CamerAwesome on GitHub
2. License: MIT
3. Project website
4. README
5. Releases