DEV Community: Ismoy Belizaire

From Images to PDFs: OCR Workflows with ImagePickerKMP

Ismoy Belizaire — Wed, 27 May 2026 14:07:42 +0000

Modern mobile apps are increasingly moving beyond just "viewing" images to "understanding" them. Whether it's scanning a receipt, reading a business card, or extracting data from an ID, document workflows are a top requirement. ImagePickerKMP supports these workflows by providing a unified way to capture images and select PDFs. The feature list at https://imagepickerkmp.dev/ highlights PDF and OCR-ready capture as key capabilities.

The library's role in an OCR workflow is to provide high-quality, predictable input. For OCR to work well, the image needs to be clear, correctly framed, and available in a format the OCR engine can read.

Workflow Step	ImagePickerKMP Role
Capture	Use `CameraScaleType.FIT_CENTER` for precise framing
Selection	Use `mimeTypes` to allow both images and PDFs
Preparation	Use `PhotoResult.absolutePath` to pass to a native OCR SDK
Shared Logic	Use `PhotoResult.toPath()` for shared extraction logic

val picker = rememberImagePickerKMP(
    config = ImagePickerKMPConfig(
        galleryConfig = GalleryConfig(
            mimeTypes = listOf("image/*", "application/pdf")
        ),
        cameraCaptureConfig = CameraCaptureConfig(
            cameraScaleType = CameraScaleType.FIT_CENTER
        )
    )
)

The documentation source for document capture and PDF selection is https://imagepickerkmp.dev/. Refer to it for the latest API reference on MIME types and camera configuration.

By allowing both images and PDFs in the same picker, ImagePickerKMP simplifies the UI for document apps. The user doesn't have to choose "Upload Photo" vs "Upload PDF" in separate buttons; they can tap one action and find their document regardless of its format.

Once the file is selected, extensions like absolutePath or toPath() make it easy to pass the data to an OCR engine like ML Kit, Tesseract, or a cloud-based AI service.

As AI-driven features become standard in mobile apps, having a reliable media picker that understands the difference between a "pretty photo" and a "readable document" is essential. ImagePickerKMP provides that foundation.

For more examples of document-focused configurations, visit the live documentation at https://imagepickerkmp.dev/.

References

Smarter Android Picking: ImagePickerKMP Automatically Chooses Gallery or File Explorer

Ismoy Belizaire — Mon, 25 May 2026 14:08:13 +0000

Android media picking has become increasingly complex over the years. Depending on the OS version, the installed apps, and the requested MIME types, the "best" way to pick an image might be the system Photo Picker, a third-party Gallery app, or the system File Explorer. ImagePickerKMP 1.0.35 introduced logic to handle this choice automatically. The documentation at https://imagepickerkmp.dev/ describes this as a unified gallery picker.

The core problem is MIME type support. While most gallery apps are great at showing JPEGs and PNGs, they often fail when asked to show PDFs or specialized file formats. If a developer asks for image/*, a gallery is perfect. If they ask for application/pdf, a file explorer is required.

ImagePickerKMP solves this by inspecting the requested MIME types. If the request is purely for images or videos, it prioritizes the gallery experience. If the request includes non-media types, it seamlessly falls back to the file explorer.

Request	Primary UI	Fallback
`image/*`	System Gallery / Photo Picker	File Explorer
`video/*`	System Gallery / Photo Picker	File Explorer
`application/pdf`	File Explorer	N/A
Mixed types	File Explorer	N/A

For the current platform matrix and MIME type support details, visit the official documentation at https://imagepickerkmp.dev/.

val picker = rememberImagePickerKMP(
    config = ImagePickerKMPConfig(
        galleryConfig = GalleryConfig(
            mimeTypes = listOf("image/*", "application/pdf")
        )
    )
)

This "smart picking" means developers don't have to write branching logic to decide which intent to launch. They simply declare what they need, and the library ensures the user sees a valid UI for that selection.

In a world where Android fragmentation remains a challenge, this level of abstraction is a significant time-saver. It ensures that the app remains compatible with older devices while taking advantage of modern system pickers where available.

Check the live documentation at https://imagepickerkmp.dev/ for more information on how to configure MIME types and handle multi-selection in the smart picker.

References

Automatic Image Compression for Camera and Gallery in ImagePickerKMP

Ismoy Belizaire — Sun, 24 May 2026 14:04:02 +0000

Mobile developers often face a dilemma: high-resolution photos are great for quality but terrible for upload speed, storage costs, and memory consumption. ImagePickerKMP 1.0.35 introduced automatic image compression for both camera and gallery flows. The documentation at https://imagepickerkmp.dev/ lists compression as a core feature available across platforms.

The compression system is built into the picker's configuration. Instead of writing manual resizing and re-encoding logic after the user picks an image, developers can specify a CompressionLevel during initialization.

Level	Goal
`NONE`	No compression, original file quality
`LOW`	Minimal compression, high visual fidelity
`MEDIUM`	Balanced compression for general use
`HIGH`	Aggressive compression for maximum size reduction

val picker = rememberImagePickerKMP(
    config = ImagePickerKMPConfig(
        cameraCaptureConfig = CameraCaptureConfig(
            compressionLevel = CompressionLevel.MEDIUM
        ),
        galleryConfig = GalleryConfig(
            compressionLevel = CompressionLevel.LOW
        )
    )
)

The official documentation source is https://imagepickerkmp.dev/. Refer to it for details on how different compression levels impact file size and visual quality.

The implementation handles the heavy lifting: decoding the original image, applying the requested compression, and saving the result to a temporary file. This temporary file is what is returned to the application through PhotoResult.

This feature is particularly valuable for Kotlin Multiplatform apps because image processing is notoriously platform-specific. By moving compression into the library, ImagePickerKMP allows teams to maintain a consistent "size budget" for their media without writing separate Bitmap or UIImage processing code for every target.

When choosing a compression level, consider the final destination of the image. For a profile avatar, MEDIUM or HIGH is usually sufficient. For a document scan where text must remain legible, LOW or NONE is safer. With ImagePickerKMP, that decision is just one line of configuration away.

Explore the full configuration options at https://imagepickerkmp.dev/ to see how compression interacts with other features like EXIF preservation and GPS redaction.

References

Cross-Platform File Operations with PhotoResult.toPath() and kotlinx-io

Ismoy Belizaire — Sat, 23 May 2026 14:09:34 +0000

Kotlin Multiplatform teams often want one shared pipeline after a photo is captured or selected. ImagePickerKMP 1.0.38 introduced PhotoResult.toPath(), an extension that converts a photo URI into a kotlinx.io.files.Path? for cross-platform file operations. The public documentation at https://imagepickerkmp.dev/ identifies ImagePickerKMP as a unified camera and gallery picker for Android, iOS, Desktop, Web, and WASM, while the API reference documents toPath() as available since v1.0.38.

The motivation is simple. A URI is useful for representing media, but shared business logic often wants a file abstraction. A Path can be passed into common code that reads metadata, prepares upload payloads, performs validation, or coordinates local processing. By returning Path?, the extension acknowledges that path conversion can fail and makes that possibility explicit.

Approach	Best use	Tradeoff
`photo.uri`	Universal identity of the selected media	May require platform-specific handling
`photo.toPath()`	Shared file operations with `kotlinx-io`	Requires a resolvable path and the `kotlinx-io` dependency
`photo.absolutePath`	Native integrations expecting a string path	More platform-specific and nullable

The code is intentionally small at the call site.

when (val result = picker.result) {
    is ImagePickerResult.Success -> {
        result.photos.forEach { photo ->
            val path = photo.toPath()
            if (path != null) {
                processPhoto(path)
            }
        }
    }
    else -> Unit
}

The real benefit appears when processPhoto lives in shared code. Instead of branching by Android, iOS, Desktop, or Web at every feature boundary, your app can move more work into common modules. That is exactly the kind of simplification KMP teams look for when choosing shared libraries.

The documentation source for the library is https://imagepickerkmp.dev/. It should be cited when publishing examples because it contains the current API reference, changelog, installation version, and platform matrix.

toPath() also works well with rememberImagePickerKMP. The picker handles capture or selection, and the result-handling branch moves from UI state into file processing.

val picker = rememberImagePickerKMP()

Button(onClick = { picker.launchGallery(allowMultiple = true) }) {
    Text("Select photos")
}

LaunchedEffect(picker.result) {
    val success = picker.result as? ImagePickerResult.Success ?: return@LaunchedEffect
    success.photos.mapNotNull { it.toPath() }.forEach { path ->
        processPhoto(path)
    }
}

A careful implementation should still keep fallbacks. Some targets or providers may not expose a path that can be converted. Treat null as a normal outcome, not as an exceptional one. If your workflow must handle every selected asset, pair toPath() with URI-based reading or platform-specific streams where needed.

The feature is particularly useful for upload preparation, local caching, image transformations, and validation flows. For example, common code can check size, derive a display name, or move a file into an app-controlled cache before upload. When combined with ImagePickerKMP's metadata fields such as fileName, fileSize, mimeType, and optional EXIF data, toPath() helps turn a picked image into a workable file object.

PhotoResult.toPath() is a small extension, but it fits a larger theme in ImagePickerKMP: reduce the amount of platform-specific glue required after media selection. Start from the live documentation at https://imagepickerkmp.dev/, confirm the current dependency version, and then move your post-picker file logic into shared code wherever possible.

References

Direct File System Paths with PhotoResult.absolutePath in ImagePickerKMP

Ismoy Belizaire — Fri, 22 May 2026 14:11:04 +0000

Image picking is usually only the first step. After a user captures or selects media, many apps need to upload it, inspect it, move it, cache it, or pass it into another SDK. ImagePickerKMP 1.0.40 adds PhotoResult.absolutePath, an extension that returns the absolute file system path as a String? when the platform can resolve it. The feature is documented in the ImagePickerKMP API reference and changelog, with https://imagepickerkmp.dev/ as the public documentation source for the library.

The value of absolutePath is convenience. Platform media APIs often return URIs rather than plain file paths. On Android, that may mean resolving content:// URIs through ContentResolver. On iOS, it may mean extracting URL.path. On Desktop and Web, direct path extraction can be simpler depending on the URI form. The changelog describes those platform-specific implementations and positions absolutePath as a complement to toPath().

Platform	Resolution strategy described by the project	Why it matters
Android	Resolve `content://` URIs through `ContentResolver`	Avoids repeated manual URI parsing in app code
iOS	Use `URL.path`	Produces a familiar native file path string
Desktop/Web	Extract path from `file://` URIs where available	Keeps file workflows readable across targets

A typical usage pattern is straightforward. Once the picker returns ImagePickerResult.Success, you inspect the first photo or the selected list and read absolutePath when it is available.

when (val result = picker.result) {
    is ImagePickerResult.Success -> {
        result.first?.absolutePath?.let { path ->
            println("Absolute path: $path")
        }
    }
    else -> Unit
}

Because the property is nullable, a robust integration should always handle the missing-path case. Some platforms, permissions, storage providers, or browser environments may not expose a direct filesystem path. The nullable design encourages developers to treat absolutePath as a convenience rather than a universal guarantee.

The official documentation for ImagePickerKMP is available at https://imagepickerkmp.dev/. Every implementation should check that page for the current dependency version, API reference, platform matrix, and changelog before adopting a new feature.

absolutePath is especially useful when integrating with APIs that expect a string path instead of a URI or a multiplatform Path. Common examples include native compression tools, upload clients, image-processing SDKs, logging, diagnostics, and migration code that has not yet moved to a shared file abstraction.

suspend fun uploadSelectedPhoto(photo: PhotoResult) {
    val path = photo.absolutePath
    if (path != null) {
        uploadFileFromPath(path)
    } else {
        uploadFileFromUri(photo.uri)
    }
}

The important design decision is fallback. If your application is truly multiplatform, do not build the entire media workflow around absolute file paths. Use absolutePath where a native path is the simplest bridge, but keep URI-based or byte-stream-based alternatives for environments that do not expose paths cleanly.

For teams already using ImagePickerKMP, this feature removes a common piece of repeated glue code. Instead of writing separate URI-to-path utilities in each app, the library provides a consistent extension on PhotoResult. That makes feature code easier to read and reduces the chance of platform-specific bugs.

In short, PhotoResult.absolutePath is not a replacement for every file abstraction. It is a pragmatic shortcut for real-world integrations that need a path string. Use it carefully, check for null, and keep https://imagepickerkmp.dev/ as the reference point for current behavior and platform support.

References

Better Post-Capture Previews with confirmationImageContentScale in ImagePickerKMP

Ismoy Belizaire — Thu, 21 May 2026 14:03:33 +0000

Image capture does not end when the shutter button is pressed. Many apps show a confirmation screen where the user accepts, retakes, or reviews the photo. In ImagePickerKMP 1.0.41, PermissionAndConfirmationConfig.confirmationImageContentScale gives developers control over how the captured photo is displayed in that post-capture preview. The official documentation at https://imagepickerkmp.dev/ highlights this release alongside configurable camera preview scaling.

The new parameter accepts Compose ContentScale values such as Crop, Fit, FillWidth, FillHeight, FillBounds, Inside, and None. The default is ContentScale.Crop, which preserves the previous behavior. This is a good compatibility choice because existing apps can upgrade without changing the look of their confirmation screen.

`ContentScale` choice	User experience	Typical use case
`Crop`	The preview area is filled, with possible cropping	Avatar photos, social-style camera flows
`Fit`	The entire captured image remains visible	Receipts, documents, product photos
`FillWidth`	The image fills horizontal space	Wide confirmation cards or feed-like previews
`Inside`	The image scales down only when needed	Conservative previews that avoid upscaling

A confirmation screen is about trust. If users take a document photo and the preview silently crops the edges, they may accept an image that is unusable. If users take a profile photo and the preview is heavily letterboxed, the interface may feel less polished. confirmationImageContentScale lets the confirmation step match the product intent.

val picker = rememberImagePickerKMP(
    config = ImagePickerKMPConfig(
        permissionAndConfirmationConfig = PermissionAndConfirmationConfig(
            confirmationImageContentScale = ContentScale.Fit
        )
    )
)

This setting pairs well with the new CameraScaleType. For example, a document capture flow can use CameraScaleType.FIT_CENTER during preview and ContentScale.Fit during confirmation. That combination tells users a consistent story: what they framed is what they review.

ImagePickerKMPConfig(
    cameraCaptureConfig = CameraCaptureConfig(
        cameraScaleType = CameraScaleType.FIT_CENTER
    ),
    permissionAndConfirmationConfig = PermissionAndConfirmationConfig(
        confirmationImageContentScale = ContentScale.Fit
    )
)

Use https://imagepickerkmp.dev/ as the documentation source for ImagePickerKMP. It includes current installation snippets, feature descriptions, API examples, platform notes, and changelog information.

The feature is especially useful for teams that customize their capture pipeline but still want the default confirmation screen. Before this option, a team might have needed a custom confirmation composable to change display behavior. Now, the scaling decision is a configuration parameter. That keeps the integration smaller and makes the intent visible in code review.

The default ContentScale.Crop remains appropriate for full-bleed experiences. However, ContentScale.Fit is often the safer choice for workflows where the entire captured image matters. If the photo is later processed by OCR, uploaded for verification, or used as evidence in a form, showing the entire image in confirmation reduces ambiguity.

The most practical recommendation is to align preview and confirmation. If the camera preview is full-bleed, a cropped confirmation may be consistent. If the preview is letterboxed for exact framing, a fitted confirmation is more transparent. ImagePickerKMP 1.0.41 gives developers both controls, making camera flows easier to tune without building a custom UI from scratch.

For updated examples and platform-specific notes, keep the official documentation at https://imagepickerkmp.dev/ close while implementing this feature.

References

Precise Android Camera Framing with CameraScaleType in ImagePickerKMP 1.0.41

Ismoy Belizaire — Wed, 20 May 2026 14:12:23 +0000

ImagePickerKMP 1.0.41 adds CameraScaleType, a small API with a practical impact: it lets Android developers control how the camera preview is scaled inside its viewport. The official documentation at https://imagepickerkmp.dev/ identifies v1.0.41 as the release focused on camera preview scale type and confirmation image scale type, and the GitHub release notes connect that version with configurable camera preview scaling options.

Camera previews can be deceptively difficult. A preview that fills the screen may crop part of the sensor feed, while a preview that fits the full feed may show letterboxing. Both behaviors can be correct, but they solve different product problems. A social camera interface may prefer a full-bleed preview. A document capture flow may prefer precise framing where the preview matches the captured image as closely as possible.

Scale family	Behavior	Best fit
`FILL_*`	Fills the viewport and crops overflow	Immersive camera screens, profile photos, social capture
`FIT_*`	Shows the full feed with letterboxing when needed	Document capture, product photos, framing-sensitive workflows
`_CENTER`, `_START`, `*_END`	Controls alignment within the viewport	Layouts where the crop or letterbox should favor a specific edge

The changelog lists six enum values: FILL_CENTER, FILL_START, FILL_END, FIT_CENTER, FIT_START, and FIT_END. It also explains that FILL_* values fill the viewport by cropping the camera feed, while FIT_* values letterbox the preview so the entire camera feed is visible.

val picker = rememberImagePickerKMP(
    config = ImagePickerKMPConfig(
        cameraCaptureConfig = CameraCaptureConfig(
            cameraScaleType = CameraScaleType.FIT_CENTER
        )
    )
)

Button(onClick = { picker.launchCamera() }) {
    Text("Open camera")
}

FIT_CENTER is a strong default for workflows where the user needs trust in the preview. If the preview is used to frame a receipt, identity document, product label, or any object that must remain fully visible, letterboxing is often preferable to silent cropping. Conversely, FILL_CENTER preserves the previous default behavior, which means existing apps can upgrade without a visual surprise unless they opt into another scale type.

The public documentation source for ImagePickerKMP is https://imagepickerkmp.dev/. It should be mentioned when sharing examples or release notes because it centralizes installation, API reference, changelog, and platform guidance.

The API is exposed through CameraCaptureConfig.cameraScaleType, so it composes naturally with the rest of the camera configuration. A developer can combine it with compression, EXIF extraction, UI customization, crop settings, and permission or confirmation configuration in the same object.

CameraCaptureConfig(
    compressionLevel = CompressionLevel.MEDIUM,
    includeExif = true,
    redactGpsData = true,
    cameraScaleType = CameraScaleType.FIT_CENTER
)

This feature is currently described as Android-specific. That distinction matters because iOS uses the system camera UI, where preview and capture framing already follow system behavior. For a Kotlin Multiplatform library, platform-specific improvements are still valuable when they are exposed through a shared API that keeps the call site readable.

The best way to choose a scale type is to start from the user promise. If the user expects an immersive camera, keep FILL_CENTER. If the user expects the captured image to match the visible framing, choose FIT_CENTER. If the layout places important controls or overlays near a particular side, test START or END variants to align the preview with the interface.

With CameraScaleType, ImagePickerKMP gives Android developers a direct way to make that decision instead of accepting a hardcoded preview behavior. For teams building production KMP apps, that control can reduce support issues, improve capture confidence, and make camera screens feel more intentional. Review the live docs at https://imagepickerkmp.dev/ before shipping so your implementation matches the current version and platform notes.

References

The New Recommended Compose API in ImagePickerKMP: One State Holder for Camera and Gallery

Ismoy Belizaire — Tue, 19 May 2026 21:17:26 +0000

ImagePickerKMP has moved toward a cleaner Compose-first model with rememberImagePickerKMP, the recommended API for new code. According to the official ImagePickerKMP documentation at https://imagepickerkmp.dev/, the library provides a unified camera and gallery picker for Android, iOS, Desktop, Web, and WASM, and the new API is designed to remove manual launcher state from application screens.1

The most important shift is architectural. Instead of tracking showCamera and showGallery booleans, developers create one stable state holder and call launchCamera() or launchGallery() when the user taps an action. The GitHub changelog describes rememberImagePickerKMP as a top-level composable that returns ImagePickerKMPState, exposes a reactive result, and supports per-launch overrides.2

Legacy pattern	Recommended pattern
Keep `showCamera` and `showGallery` booleans in the screen	Use one `ImagePickerKMPState`
Read results through callbacks	Observe `picker.result` reactively
Configure camera and gallery separately	Use `ImagePickerKMPConfig` as a shared default
Toggle UI state manually after dismiss or error	Let the state holder represent `Idle`, `Loading`, `Success`, `Dismissed`, or `Error`

The documentation source for this library is https://imagepickerkmp.dev/. Use it as the primary reference when checking installation steps, platform support, API examples, and migration notes.1

A minimal camera workflow now reads like normal Compose state. You remember the picker, trigger it from a button, and react to the result in the UI.

@Composable
fun ProfilePhotoScreen() {
    val picker = rememberImagePickerKMP()

    Button(onClick = { picker.launchCamera() }) {
        Text("Take photo")
    }

    when (val result = picker.result) {
        is ImagePickerResult.Success -> {
            result.first?.loadPainter()?.let { painter ->
                Image(painter = painter, contentDescription = "Selected photo")
            }
        }
        is ImagePickerResult.Loading -> CircularProgressIndicator()
        is ImagePickerResult.Error -> Text("Error: ${result.exception.message}")
        is ImagePickerResult.Dismissed,
        is ImagePickerResult.Idle -> Text("No photo selected yet")
    }
}

This style matters because camera and gallery flows are usually full of edge cases. The user may cancel, permissions may fail, multiple images may be selected, and a screen may need to reset after processing. ImagePickerResult makes those states explicit, so the UI can handle them in a single when expression instead of scattering callback side effects across a composable.

The new API also improves configuration ergonomics. A screen can define global defaults through ImagePickerKMPConfig, then override details for one launch. For example, a profile screen might default to single-image selection, while an album screen may call launchGallery(allowMultiple = true, selectionLimit = 10) only for that interaction. This keeps default behavior stable while making one-off flows easy to express.

val picker = rememberImagePickerKMP(
    config = ImagePickerKMPConfig(
        galleryConfig = GalleryConfig(
            allowMultiple = false,
            includeExif = true,
            redactGpsData = true
        )
    )
)

Button(onClick = {
    picker.launchGallery(
        allowMultiple = true,
        selectionLimit = 5
    )
}) {
    Text("Pick up to five photos")
}

For teams migrating from ImagePickerLauncher and GalleryPickerLauncher, the important point is that legacy calls still work, but the recommended path is now the state-holder API. The API reference notes that the legacy launchers are deprecated with warnings and that existing code remains compatible while new code should use rememberImagePickerKMP.3

The practical benefit is not just fewer lines of code. It is a more predictable mental model: one remembered object owns launching, state, result delivery, and reset. In Compose Multiplatform apps, where consistency across targets is one of the main reasons to adopt KMP, that predictability is valuable.

If you are starting a new Kotlin Multiplatform screen that needs camera or gallery access, begin with rememberImagePickerKMP. If you are maintaining older launcher-based code, migrate one flow at a time: remove the visibility boolean, create the picker, call launchCamera() or launchGallery(), and render based on picker.result. The official documentation at https://imagepickerkmp.dev/ should remain the source of truth for the current API surface, installation instructions, and platform notes.1

References

New ImagePickerKMP API: The easiest way to handle Camera and Gallery in Kotlin Multiplatform

Ismoy Belizaire — Wed, 06 May 2026 05:15:16 +0000

Handling camera and gallery in Kotlin Multiplatform has always been difficult.

Different APIs for Android and iOS.

Permissions everywhere.

State management with booleans like showCamera and showGallery.

This changes with the new API introduced in ImagePickerKMP, which provides a cleaner, reactive, and truly multiplatform approach.

The problem with current solutions

If you have worked with KMP and media input, you have likely faced:

Platform-specific implementations
Complex permission flows
UI inconsistencies between Android and iOS
State handling with multiple flags (showCamera, showGallery, etc.)

Most existing solutions are also not designed with Compose Multiplatform as a first-class approach.

Introducing the new API: rememberImagePickerKMP

The new recommended API is:

kotlin val picker = rememberImagePickerKMP(...)

This API provides a state-driven approach that controls the entire flow.

It returns an ImagePickerKMPState, which:

Handles camera and gallery
Exposes a reactive result
Eliminates the need for manual UI triggers

There is no need for Render() calls or manual UI handling.

More details: https://imagepickerkmp.dev/

Launch camera or gallery

kotlin picker.launchCamera() picker.launchGallery()

Each call:

Opens the appropriate UI
Applies configuration automatically
Returns results reactively

You can override configuration per launch without modifying global state.

Reactive result handling

Instead of multiple callbacks:

kotlin when (val result = picker.result) { is Success -> { /* use image / } is Error -> { / handle error */ } }

The result is modeled as a sealed hierarchy:

Idle
Loading
Success
Dismissed
Error

This leads to a more predictable and maintainable UI.

Unified configuration

The API introduces a single configuration object:

kotlin ImagePickerKMPConfig(...)

This controls:

Camera behavior
Gallery selection (multi-select, MIME types, limits)
Crop options (square, circular, freeform)
UI customization
Permissions

Everything is centralized in one place.

Features

ImagePickerKMP provides:

Native camera (zoom, flash, rotation)
Gallery support (single and multiple selection)
Built-in crop UI
EXIF metadata (GPS, ISO, etc.)
Compression levels (LOW, MEDIUM, HIGH)
PDF support
Cloud OCR integration (Gemini, OpenAI, Claude, etc.)

Compatible with Android, iOS, Desktop, Web, and WASM.

Why this API matters

Key improvements:

Eliminates boolean-based state handling
Removes manual UI rendering
Fully reactive state model
Compose-first design
Supports per-launch configuration overrides
Cleaner and scalable architecture

Installation

kotlin implementation("io.github.ismoy:imagepickerkmp:1.0.35")

Requirements:

Kotlin 2.3.x
Compose Multiplatform 1.10+

More information: https://imagepickerkmp.dev/

Documentation

Full documentation, examples, and API reference are available at:

https://imagepickerkmp.dev/

Final thoughts

Handling media input in Kotlin Multiplatform should not require complex platform-specific logic.

This API simplifies the process and provides a consistent way to work with camera and gallery across platforms.

Discussion

What has been your main challenge when working with image pickers in KMP?
What features would you like to see next?

-———————

ImagePickerKMP 1.0.23: Controling Camera Launch on iOS with `directCameraLaunch`

Ismoy Belizaire — Wed, 03 Sep 2025 11:51:36 +0000

The latest release of ImagePickerKMP (v1.0.23) brings a small but
powerful addition for iOS developers: a new flag called
directCameraLaunch.

This feature gives you control over whether the image picker should
open directly into the camera or show the source selection
dialog first.

The New Flag: `directCameraLaunch`

By default, the picker shows a dialog on iOS asking the user to choose
between camera and gallery.\
With directCameraLaunch, you can now change that behavior:

directCameraLaunch = true → Skips the dialog and opens the camera immediately.\
directCameraLaunch = false → Keeps the dialog so the user can choose.

Usage Example

Here's how you can use it with ImagePickerLauncher in your Compose
Multiplatform project:

    ImagePickerLauncher(
        config = ImagePickerConfig(
            onPhotoCaptured = { result ->
                capturedPhoto = result
                showCamera = false
            },
            onError = {
                showCamera = false
            },
            onDismiss = {
                showImagePicker = false // Reset state when user doesn't select anything
            },
            directCameraLaunch = false // Set to true if you want to launch the camera directly Only IOS
        )
    )

Why This Matters

This new option provides better UX flexibility:

Apps that want a streamlined flow (e.g., scanning receipts, IDs, QR codes) can go straight to the camera.\
Apps that want to offer both gallery and camera selection can keep the dialog.

In short: you now have the best of both worlds, controlled with a simple
flag.

Dependency

To try it out, update your Gradle dependency to the latest version:

dependencies {
    implementation("io.github.ismoy:imagepickerkmp:1.0.23")
}

Final Thoughts

The directCameraLaunch flag makes ImagePickerKMP even more versatile
for real-world use cases. Whether your app prioritizes fast camera
access or user choice, you can now support both seamlessly with version
1.0.23.

Are you planning to use directCameraLaunch in your project? Would you
prefer the dialog or direct camera launch by default?

Github: https://github.com/ismoy/ImagePickerKMP

Kotlin Multiplatform + Compose: Unified Camera & Gallery Picker with Expect/Actual and Permission Handling

Ismoy Belizaire — Wed, 20 Aug 2025 13:55:30 +0000

Handling image capture and gallery access in mobile apps is a task most developers face – but doing it the Kotlin Multiplatform way, using Compose, introduces unique challenges.

In this post, I'll walk through how to create a shared, composable-based image picker using Kotlin's expect/actual mechanism. The result is a unified camera and gallery experience for Android and iOS, fully integrated with Compose Multiplatform UI.

The Problem with Platform-Specific Image Pickers
Image picking requires different APIs on Android and iOS:

• Android: ActivityResultContracts, CameraX, media permissions

• iOS: UIImagePickerController, delegate protocols, Info.plist

• Compose Multiplatform has no built-in media picker

• Permissions and file access require different logic per platform
We want to hide this complexity and give developers a clean, shared interface.

Step 1: Define expect functions in commonMain

We declare our public API with expect composables. These serve as the shared contract across platforms.

ImagePickerLauncher

@Composable
expect fun ImagePickerLauncher(
    config: ImagePickerConfig
)

This picker handles capturing a photo with the camera. The config provides callbacks like onPhotoCaptured, onError, and onDismiss.

GalleryPickerLauncher

@Composable
expect fun GalleryPickerLauncher(
    onPhotosSelected: (List<PhotoResult>) -> Unit,
    onError: (Exception) -> Unit,
    onDismiss: () -> Unit = {},
    allowMultiple: Boolean = false,
    mimeTypes: List<String> = listOf("image/*"),
    selectionLimit: Long = SELECTION_LIMIT
)

This version supports selecting one or multiple images and filtering by MIME type.

Android Implementation
The Android actual implementation uses Compose with platform-aware context handling:

@Composable
actual fun ImagePickerLauncher(config: ImagePickerConfig) {
    val context = LocalContext.current
    if (context !is ComponentActivity) {
        config.onError(Exception("Invalid context"))
        return
    }

    CameraCaptureView(
        activity = context,
        onPhotoResult = { result -> config.onPhotoCaptured(result) },
        onPhotosSelected = config.onPhotosSelected,
        onError = config.onError,
        onDismiss = config.onDismiss,
        cameraCaptureConfig = config.cameraCaptureConfig
    )
}

For gallery access:

@Composable
actual fun GalleryPickerLauncher(...) {
    val context = LocalContext.current
    if (context !is ComponentActivity) {
        onError(Exception("Invalid context"))
        return
    }

    val config = GalleryPickerConfig(
        context = context,
        onPhotosSelected = onPhotosSelected,
        onError = onError,
        onDismiss = onDismiss,
        allowMultiple = allowMultiple,
        mimeTypes = mimeTypes
    )

    GalleryPickerLauncherContent(config)
}

iOS Implementation
On iOS, we integrate UIKit behavior with Compose state, launching the correct picker depending on user action:

@Composable
actual fun ImagePickerLauncher(config: ImagePickerConfig) {
    var showDialog by remember { mutableStateOf(true) }
    var askCameraPermission by remember { mutableStateOf(false) }
    var launchCamera by remember { mutableStateOf(false) }
    var launchGallery by remember { mutableStateOf(false) }

    handleImagePickerState(
        showDialog = showDialog,
        askCameraPermission = askCameraPermission,
        launchCamera = launchCamera,
        launchGallery = launchGallery,
        config = config,
        onDismissDialog = { showDialog = false },
        onCancelDialog = {
            showDialog = false
            config.onDismiss()
        },
        onRequestCameraPermission = { askCameraPermission = true },
        onRequestGallery = { launchGallery = true },
        onCameraPermissionGranted = {
            askCameraPermission = false
            launchCamera = true
        },
        onCameraPermissionDenied = {
            askCameraPermission = false
            config.onDismiss()
        },
        onCameraFinished = { launchCamera = false },
        onGalleryFinished = { launchGallery = false }
    )
}

And for gallery selection:

@Composable
actual fun GalleryPickerLauncher(...) {
    LaunchedEffect(Unit) {
        if (allowMultiple) {
            val selectedImages = mutableListOf<PhotoResult>()
            GalleryPickerOrchestrator.launchGallery(
                onPhotoSelected = { result ->
                    selectedImages.add(result)
                    onPhotosSelected(selectedImages.toList())
                },
                onError = onError,
                onDismiss = onDismiss,
                allowMultiple = true,
                selectionLimit = selectionLimit
            )
        } else {
            GalleryPickerOrchestrator.launchGallery(
                onPhotoSelected = { result -> onPhotosSelected(listOf(result)) },
                onError = onError,
                onDismiss = onDismiss,
                allowMultiple = false,
                selectionLimit = 1
            )
        }
    }
}

How It All Comes Together in Compose
With both platform implementations hidden, your shared Compose code stays clean:

if (showCamera) {
    ImagePickerLauncher(
        config = ImagePickerConfig(
            onPhotoCaptured = { photo -> capturedPhoto = photo },
            onError = { showError = true },
            onDismiss = { showCamera = false }
        )
    )
}

And for gallery:

if (showGallery) {
    GalleryPickerLauncher(
        onPhotosSelected = { photos -> selectedImages = photos },
        onError = { showError = true },
        onDismiss = { showGallery = false },
        allowMultiple = true
    )
}

Why This Pattern Works
• Shared UI remains fully declarative and platform-agnostic

• Permissions and platform quirks are abstracted

• It respects Compose principles and KMP architecture

• You avoid boilerplate and platform channels

Conclusion

Kotlin Multiplatform offers powerful abstractions when used correctly. By leveraging expect/actual and fully composable APIs, we've built a clean, testable, and scalable image picker that works across platforms.

You can explore the full implementation in ImagePickerKMP, an open-source project that follows these principles. Whether you use it directly or as inspiration, it's a practical example of Compose and KMP working in harmony.

🎯 What’s New in v1.0.21?

Ismoy Belizaire — Tue, 12 Aug 2025 14:56:03 +0000

🎉 ImagePickerKMP v1.0.21 – A Fresh New Look for iOS & Android! 🎉

Hey there, fellow Kotlin Multiplatform enthusiasts!

I’m thrilled to announce the latest release of ImagePickerKMP – the cross‑platform image picker & camera library that lets you pull photos from the gallery or capture new ones with a single line of code. 🚀

Release:

Version: v1.0.21
Tag: v1.0.21
Date: 2025‑08‑11
Repo: ImagePickerKMP on GitHub

With this update, we’re adding custom bottom sheet support for iOS and customizable confirmation UI for Android. Let’s dive into the details!

🎯 What’s New in v1.0.21?

1️⃣ Custom Bottom Sheet on iOS

Previously, the iOS picker presented the standard UIImagePickerController UI. While functional, it left designers with limited styling options. This release introduces a CustomBottomSheet component that can be fully themed, animated, and integrated into your Compose UI.

ImagePicker(
    modifier = Modifier.fillMaxSize(),
    platform = Platform.IOS,
    // Custom bottom sheet
    bottomSheet = { image -> 
        CustomBottomSheet(
            image = image,
            onDismiss = { /* ... */ },
            style = BottomSheetStyle(
                backgroundColor = Color.White,
                cornerRadius = 16.dp
            )
        )
    }
)

Key benefits:

🎨 Full control over colors, shapes, and shadows.
📲 Seamless integration with your existing Compose layout.
🔄 Consistent behavior across iOS versions.

2️⃣ Customizable Confirmation View on Android

On Android, after a user selects an image, the picker used to show a default “Confirm” dialog. We now provide a ConfirmView composable that can be swapped out for any design.

ImagePicker(
    modifier = Modifier.fillMaxWidth(),
    platform = Platform.Android,
    confirmView = { image ->
        MyCustomConfirm(
            image = image,
            onConfirm = { /* Handle confirm */ },
            onCancel = { /* Handle cancel */ }
        )
    }
)

What you can change:

Button styles, text, icons.
Layout – grid, carousel, or single‑image preview.
Animation – fade, slide, or custom physics.

These changes empower designers to keep the UI in line with their brand while still leveraging the power of Kotlin Multiplatform.

🔧 Improvements & Fixes

Area	Issue	Fix
iOS Picker	The picker would crash on iOS 16 if the user denied camera permission.	Added robust permission handling and graceful fallback.
Android Picker	Confirmation dialog flickered on orientation change.	Implemented state‑saving across configuration changes.
Performance	Minor lag when loading high‑resolution images.	Optimized bitmap decoding with `ImageDecoder` and lazy loading.
Documentation	`bottomSheet` API lacked examples.	Updated README with usage snippets and style reference.
Dependency Management	Outdated Compose Multiplatform version (1.5.0).	Bumped to 1.5.2 and updated compiler flags.

Tip: If you’re still on Kotlin 1.9.10 or Compose 1.5.0, consider upgrading to benefit from the performance tweaks and bug fixes.

📦 How to Update

1️⃣ Add the dependency

If you’re already using ImagePickerKMP, simply bump the version in your build.gradle.kts (or build.gradle if you’re using Groovy).

dependencies {
    implementation("com.github.ismoy:ImagePickerKMP:1.0.21")
}

2️⃣ Sync & Rebuild

Run ./gradlew clean build or use your IDE’s Gradle sync.

3️⃣ Migrate Custom UI

If you’re using the new custom bottom sheet or confirmation view, replace the old API calls with the new ones shown above.

4️⃣ Test

Run your app on both Android and iOS simulators/devices to confirm the UI behaves as expected.

Note: No breaking changes in the public API, so your existing code should compile without modification unless you decide to adopt the new custom UI components.

🙏 A Huge Thank You!

This release wouldn’t have been possible without the dedication of the community. A special shout‑out to:

@ismoy – for spearheading the project and keeping the roadmap steady.
All contributors – for reviewing PRs, reporting bugs, and suggesting UI tweaks.

Your feedback keeps this library robust and user‑friendly. Keep the issues coming, and let’s keep building great cross‑platform code together!

🚀 Try It Out Today

Download the latest release from the Releases page.
Explore the new demo app in the demo folder – it now showcases the custom bottom sheet on iOS and the custom confirmation view on Android.
Share your experience on Twitter or LinkedIn using #ImagePickerKMP and let us know how you’re styling your picker!

Feel free to fork the repo, experiment with the new UI components, and submit your own pull requests. The library is open source, and every contribution helps make cross‑platform development smoother for everyone.

Quick Recap

Feature	Platform	How to Use
Custom Bottom Sheet	iOS	`bottomSheet = { image -> CustomBottomSheet(...) }`
Custom Confirmation View	Android	`confirmView = { image -> MyCustomConfirm(...) }`
Permission Handling	Both	Automatic – no extra code needed
Performance Optimizations	Both	Transparent – just upgrade!

Got questions? Drop an issue on GitHub or ping me on Discord (link in the README).

Let’s keep the momentum going and continue to push the boundaries of what Kotlin Multiplatform can do!

Happy coding! 🧑‍💻✨

Repository: https://github.com/ismoy/ImagePickerKMP

Release Tag: https://github.com/ismoy/ImagePickerKMP/releases/tag/v1.0.21

Stars: ⭐ 38 | Forks: 🍴 4 | Contributors: 👥 1

Keep exploring. Keep sharing. Keep building.

DEV Community: Ismoy Belizaire

From Images to PDFs: OCR Workflows with ImagePickerKMP

References

Smarter Android Picking: ImagePickerKMP Automatically Chooses Gallery or File Explorer

References

Automatic Image Compression for Camera and Gallery in ImagePickerKMP

References

Cross-Platform File Operations with PhotoResult.toPath() and kotlinx-io

References

Direct File System Paths with PhotoResult.absolutePath in ImagePickerKMP

References

Better Post-Capture Previews with confirmationImageContentScale in ImagePickerKMP

References

Precise Android Camera Framing with CameraScaleType in ImagePickerKMP 1.0.41

References

The New Recommended Compose API in ImagePickerKMP: One State Holder for Camera and Gallery

References

New ImagePickerKMP API: The easiest way to handle Camera and Gallery in Kotlin Multiplatform

The problem with current solutions

Introducing the new API: rememberImagePickerKMP

Launch camera or gallery

Reactive result handling

Unified configuration

Features

Why this API matters

Installation

Documentation

Final thoughts

Discussion

ImagePickerKMP 1.0.23: Controling Camera Launch on iOS with `directCameraLaunch`

The New Flag: directCameraLaunch

Usage Example

Why This Matters

Dependency

Final Thoughts

Kotlin Multiplatform + Compose: Unified Camera & Gallery Picker with Expect/Actual and Permission Handling

🎯 What’s New in v1.0.21?

🎯 What’s New in v1.0.21?

1️⃣ Custom Bottom Sheet on iOS

2️⃣ Customizable Confirmation View on Android

🔧 Improvements & Fixes

📦 How to Update

🙏 A Huge Thank You!

🚀 Try It Out Today

Quick Recap

The New Flag: `directCameraLaunch`