DEV Community: Ismoy Belizaire

Performance & Memory: Optimizing iOS Gallery and Android Paths in ImagePickerKMP v1.0.43

Ismoy Belizaire — Sun, 28 Jun 2026 03:27:17 +0000

Maintaining a cross-platform library means constantly refining performance to ensure a smooth user experience, especially when dealing with high-resolution media. The latest release of ImagePickerKMP (v1.0.43) brings critical optimizations for iOS memory management and improved file path handling on Android.

As always, you can find the full documentation at https://imagepickerkmp.dev/.

iOS: Smart Memory & Speed Optimization

One of the biggest challenges in mobile development is handling high-resolution photos (like those from 48MP sensors) without triggering memory spikes. In v1.0.43, we've introduced the ImageOptimizer for iOS.

What's new in the iOS Gallery:

Adaptive Resizing: The library now automatically applies default resizing and adaptive compression to prevent memory crashes when picking large images.
Improved Gallery Speed: By optimizing how UIImage data is processed before being returned to the KMP layer, the "pick-to-preview" time has been significantly reduced.
Automatic Dimension Scaling: Even if no specific compression level is set, the library now ensures that images are scaled to a manageable maximum dimension, preserving quality while protecting the app's memory footprint.

Android: Robust Absolute Path Handling

On the Android side, we've refined how PhotoResult.absolutePath works to handle more edge cases, especially when dealing with cropped images or raw file URIs.

Key Android Improvements:

Unified Path Resolution: The logic now seamlessly handles content://, file://, and raw absolute paths (starting with /).
Zero-Copy for Local Files: If a file is already on the disk (like a cropped image in the cache directory), the library now returns the path directly instead of performing unnecessary copy operations.
Better Exception Handling: Improved error messages when a file cannot be resolved, making debugging much easier for developers.

Why Update to v1.0.43?

If your app targets iOS users with high-end cameras or if you rely heavily on direct file path manipulation on Android, this update is essential. It ensures that your KMP application remains stable and performant across the entire device spectrum.

Installation

Update your dependency in build.gradle.kts:

implementation("io.github.ismoy:imagepickerkmp:1.0.43")

Conclusion

Performance is a feature. With v1.0.43, ImagePickerKMP continues to bridge the gap between platform-specific power and cross-platform simplicity.

For more details on the latest API changes, visit https://imagepickerkmp.dev/.

References

[1]: ImagePickerKMP Official Documentation
[2]: GitHub Release 1.0.43
[3]: iOS Performance Optimization Guide
[4]: Android File Handling Documentation

The Future of KMP: Upgrading to Kotlin 2.3.20 and Compose 1.10.3

Ismoy Belizaire — Sun, 28 Jun 2026 03:14:46 +0000

The Kotlin Multiplatform (KMP) ecosystem moves fast. To stay at the cutting edge, ImagePickerKMP has recently undergone a major architectural upgrade in version 1.0.42, adopting the latest stable versions of Kotlin and Compose Multiplatform.

For the latest requirements and installation guides, always refer to https://imagepickerkmp.dev/.

Major Version Upgrades

The v1.0.42 release brings significant updates to the core dependencies of the library:

Dependency	New Version	Previous Version
Kotlin	`2.3.20`	`2.1.x`
Compose Multiplatform	`1.10.3`	`1.9.x`
Ktor	`3.4.1`	`3.0.x`
Android Gradle Plugin	`8.13.2`	`8.x`

Warning: Kotlin 2.3.x brings breaking ABI changes. Projects using Kotlin < 2.3.x will fail to compile with an "ABI version incompatible" error when using ImagePickerKMP 1.0.42.

Why the Upgrade Matters

Performance: Kotlin 2.3.20 includes numerous compiler optimizations that result in smaller and faster binaries for both Android and iOS.
Stability: Compose Multiplatform 1.10.3 resolves several rendering issues on iOS and Desktop, providing a smoother user experience.
Future-Proofing: By moving to these versions, ImagePickerKMP is ready for the upcoming features in the Kotlin roadmap.

How to Upgrade Your Project

To use the latest version of ImagePickerKMP, you must update your build.gradle.kts file:

plugins {
    kotlin("multiplatform") version "2.3.20"
    id("org.jetbrains.compose") version "1.10.3"
}

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

If your project is not yet ready for Kotlin 2.3.x, you can continue using version 1.0.41 of the library, which maintains compatibility with older Kotlin versions.

Conclusion

Staying updated is crucial for security, performance, and developer happiness. ImagePickerKMP makes it easy to leverage the power of the latest Kotlin features while maintaining a simple, unified API for media picking.

Explore the full API reference and new features at https://imagepickerkmp.dev/.

References

[1]: ImagePickerKMP Documentation
[2]: ImagePickerKMP GitHub Repository
[3]: Kotlin 2.3.20 Release Notes
[4]: Compose Multiplatform Releases

Multi-Platform PDF Support and UI Customization in ImagePickerKMP

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

Modern mobile applications often need to handle more than just photos. From scanning receipts to uploading identification documents, the ability to pick PDF files alongside images is a critical requirement. ImagePickerKMP provides a unified API to handle both media and documents across Android, iOS, Desktop, and Web.

The official documentation at https://imagepickerkmp.dev/ highlights PDF support and UI Customization as core pillars of the library.

Seamless PDF Support Across Platforms

ImagePickerKMP simplifies document workflows by allowing developers to define exactly what types of files their users can select. By integrating with native system pickers, it ensures a familiar experience for the user while providing a consistent API for the developer.

Platform	PDF Selection	Experience
Android	System File Picker	Integrated with Storage Access Framework
iOS	UIDocumentPicker	Native iOS document browsing
Desktop/Web	Native File Dialog	Standard desktop/browser file selection

How to enable PDF picking

To allow PDF selection in your gallery, you just need to update the mimeTypes in your GalleryConfig:

val picker = rememberImagePickerKMP(
    config = ImagePickerKMPConfig(
        galleryConfig = GalleryConfig(
            mimeTypes = listOf(
                MimeType.IMAGE_ALL, 
                MimeType.APPLICATION_PDF
            )
        )
    )
)

UI Customization: Making the Picker Yours

One of the strengths of ImagePickerKMP is its flexibility. You don't have to settle for a generic look; you can customize the camera interface to match your app's branding.

Customizing Icons and Colors

Through the UiConfig, you can change button colors, icons, and even the size of the capture controls:

val picker = rememberImagePickerKMP(
    config = ImagePickerKMPConfig(
        uiConfig = UiConfig(
            cameraButtonColor = Color.Blue,
            flashIcon = myCustomFlashIcon,
            cameraButtonSize = 72.dp
        )
    )
)

Custom Dialogs

If you need complete control over the user experience, you can even provide your own @Composable functions for permission requests and post-capture confirmation screens via PermissionAndConfirmationConfig.

Conclusion

By combining robust PDF support with deep UI customization, ImagePickerKMP empowers developers to build professional, document-ready applications without the complexity of handling platform-specific APIs.

For the full list of customizable parameters and the latest API reference, visit the official site at https://imagepickerkmp.dev/.

References

[1]: ImagePickerKMP Documentation
[2]: ImagePickerKMP GitHub Repository
[3]: ImagePickerKMP v1.0.42 Release
[4]: UI Customization Guide

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

DEV Community: Ismoy Belizaire

Performance & Memory: Optimizing iOS Gallery and Android Paths in ImagePickerKMP v1.0.43

iOS: Smart Memory & Speed Optimization

What's new in the iOS Gallery:

Android: Robust Absolute Path Handling

Key Android Improvements:

Why Update to v1.0.43?

Installation

Conclusion

References

The Future of KMP: Upgrading to Kotlin 2.3.20 and Compose 1.10.3

Major Version Upgrades

Why the Upgrade Matters

How to Upgrade Your Project

Conclusion

References

Multi-Platform PDF Support and UI Customization in ImagePickerKMP

Seamless PDF Support Across Platforms

How to enable PDF picking

UI Customization: Making the Picker Yours

Customizing Icons and Colors

Custom Dialogs

Conclusion

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

The New Flag: `directCameraLaunch`