Skip to content

iOS: would you accept an opt-in capture controller that preserves original colors? #174

Description

@juanlabrador

iOS: would you accept an opt-in capture controller that preserves original colors?

The problem

On iOS the plugin uses Apple's VNDocumentCameraViewController. For document
scanning it's excellent, but for identity verification (KYC) it has three
limitations we couldn't work around from the outside:

  1. It applies automatic filters that wash out colors. The returned image is
    processed for readability, not for fidelity. For an ID card that means shifted
    tones and lost detail — some verification providers reject those images.
  2. The filter buttons can't be removed. Users can switch to grayscale or
    black & white, which silently breaks the same flows.
  3. Multi-page capture is forced. For a single-sided ID it's confusing UX, and
    the user has to tap "Save" after every shot.

Android already has an escape hatch for the first point — AndroidScannerMode.base
keeps real colors, which is exactly why we use it. iOS has no equivalent, because
the limitation lives inside Apple's controller rather than in this plugin.

What we built, and why we're asking

We maintain a fork where iOS uses a custom capture controller instead of Apple's. The
pipeline is:

  1. Preview with AVCaptureSession + AVCapturePhotoOutput.
  2. On shutter tap, capture a raw JPEG — no filters applied.
  3. Run VNDetectDocumentSegmentationRequest (Vision framework, the same model Apple's
    own Notes app uses) to find the document's four corners.
  4. Apply CIPerspectiveCorrection with those corners to the raw image, so the
    result is cropped and deskewed with the original colors.
  5. If detection fails, return the flat photo rather than failing the capture.
  6. Show a confirmation preview with Retake / Use.

It's been running in production for a while in an identity-verification flow.

We'd rather contribute this than keep a fork, but we don't want to send 500+ lines
of Swift you may not want
, so we're asking first.

Questions before we write anything

  1. Is this in scope? It's a second capture path, not a change to the existing one.
    Our intent is that it be strictly opt-in — e.g. an IosScannerMode alongside
    the existing AndroidScannerMode — so current behaviour stays untouched by default.

  2. How would you want it shaped? Our fork is based on 1.4.0, and iOS has been
    restructured since (SPM layout, CunningDocumentCropperViewController,
    CroppingOverlayView, MagnifierView). We'd port onto the current architecture
    and reuse what's already there rather than duplicating it — but you know better
    than us where the seams should be.

  3. Is a framing guide overlay welcome, and if so how? Our version draws a centered
    rectangle with a fixed aspect ratio plus a dimmed surround, which materially improves
    capture quality for cards. In our fork the ratio is hardcoded to the ID card format we
    needed. If you'd want it, we'd expose the ratio as a parameter — or we can
    leave the overlay out entirely and contribute only the capture path.

  4. Anything you'd want us to avoid? Minimum iOS version, dependencies, testing
    approach — happy to follow whatever you prefer.

If you'd rather not take this direction, that's completely fine — knowing now saves us
both time, and we'll keep maintaining our fork.

Thanks for the project, and for how actively you keep it maintained.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions