FileKit for Kotlin Multiplatform file selection and saving

FileKit's shared file operations across Kotlin targets

FileKit addresses a recurring problem in Kotlin Multiplatform projects: file access does not expose the same interface on Android, iOS, macOS, desktop JVM, JS, and WASM. An application that needs to import an avatar, attach a document, choose a working directory, or export a file would otherwise need platform-specific branches around each operating system's file selection and storage facilities. FileKit places those operations behind Kotlin APIs intended for shared application code.

The intended audience is Kotlin developers building applications with Kotlin Multiplatform or Compose Multiplatform. The repository includes samples for Android, desktop, iOS, web, Windows native, and a shared application. Its platform topics cover Android, iOS, JVM, macOS, JS, and WASM. This is useful when a product needs one Kotlin codebase across several targets, but it is not a general desktop file manager or a replacement for unrestricted filesystem access.

The documented operations include picking one or more files, restricting selection to images, selecting a directory, saving documents, accessing photos, managing directories, compressing images, and connecting selected media to a gallery. The README specifically says that FileKit uses platform-native pickers. That design can preserve familiar operating-system dialogs instead of presenting one invented interaction everywhere. It also means FileKit is an abstraction over target capabilities, not evidence that every target has identical storage semantics.

FileKit modules and dependency boundaries

FileKit is split into several artifacts rather than forcing every application to install the full integration stack. The repository layout contains `filekit-core/`, `filekit-dialogs/`, `filekit-dialogs-compose/`, and `filekit-coil/`. The dependency block in the README lists all four, while the documentation separately provides Core API and Dialogs setup pages. That split matters to adopters because Compose Multiplatform support and Coil integration are distinct from the base Kotlin API.

The call surface shown in the README starts through the `FileKit` object. `openFilePicker()` requests one file, `openFilePicker(mode = FileKitMode.Multiple())` requests several files, `type = FileKitType.Image` narrows selection to images, and `openDirectoryPicker()` requests a directory. The visible repository structure also separates general core functionality from dialog implementations and Compose-specific integration.

This packaging is a better fit than placing picker calls directly in every shared UI screen. Application code can refer to the same Kotlin-facing operations, while platform behavior stays behind the library. However, the module names alone do not establish the permissions, lifecycle handling, return types, error model, or initialization requirements. The linked setup documentation is required for those details. FileKit should not be evaluated as a dependency that can be added and invoked unchanged without consulting its current platform configuration.

Installing FileKit and invoking the first picker

The README places the Gradle declarations in `build.gradle.kts`. It uses `$version` rather than hard-coding a release number, so the reader must supply the version selected for the project. The documentation also links to an installation guide for additional setup.

The documented dependency declarations are:

// build.gradle.kts
dependencies {
    implementation("io.github.vinceglb:filekit-core:$version")
    implementation("io.github.vinceglb:filekit-dialogs:$version")
    implementation("io.github.vinceglb:filekit-dialogs-compose:$version")
    implementation("io.github.vinceglb:filekit-coil:$version")
}

This block adds the core API, dialog implementation, Compose Multiplatform integration, and Coil integration. The README does not state which artifacts are mandatory for every target, so it would be unsafe to claim that all four can be omitted freely. The installation page is the authoritative place to check current module selection and platform setup.

A first file-selection call is documented directly in the README:

// Pick a file
val file = FileKit.openFilePicker()

The accompanying examples show the related selection modes:

// Pick multiple files
val files = FileKit.openFilePicker(mode = FileKitMode.Multiple())

// Pick only images
val imageFile = FileKit.openFilePicker(type = FileKitType.Image)

// Pick a directory
val directory = FileKit.openDirectoryPicker()

These examples establish the Kotlin API shape, but the visible README does not show initialization code, lifecycle binding, coroutine context, return types, or cancellation handling. A first real implementation should therefore follow the linked installation and dialog setup pages for the exact target configuration before placing one of these calls in a screen.

Native picker behavior and cross-platform constraints

FileKit's use of platform-native pickers creates its central engineering trade-off. The benefit is that users encounter the file chooser supplied by their operating system instead of a generic FileKit interface. The cost is that capability, restrictions, and presentation can differ by target. File selection is mediated by the host platform, and FileKit does not turn every desktop, browser, and mobile storage model into the same underlying filesystem.

The documented target list is broad: Android, iOS, macOS, JVM on Windows, macOS and Linux, JS, and WASM. The repository reinforces that breadth with dedicated sample directories for Android, desktop, iOS, web, Windows native, and shared code. Still, target support should not be read as proof that every operation behaves identically. The README does not publish a matrix showing whether compression, gallery integration, directory management, or save operations have the same availability on each target.

There is also a web-specific boundary implied by the architecture. A browser-facing JS or WASM application cannot automatically gain unrestricted local filesystem access merely because it uses a cross-platform Kotlin API. The visible README states that native pickers are used, but it does not explain browser file capabilities or WASM limitations. Engineers should confirm the exact web behavior in the dialog documentation before designing a workflow that assumes arbitrary path access.

The documented integrations with Coroutines, `kotlinx-io`, and Coil are also signals of an ecosystem-oriented library rather than a self-contained picker. They can fit an existing KMP stack, but they also make the surrounding dependency choices relevant to evaluation.

FileKit versus separate platform picker implementations

The real alternative is to call each target's native file picker directly from platform-specific application code. This approach avoids a shared FileKit dependency and gives each target direct access to its operating system's own selection APIs. It is a reasonable choice for a JVM-only Android application, a native iOS-only app, or an application that already has a mature platform abstraction for file access.

FileKit takes a different route. It places calls such as `FileKit.openFilePicker()` and `FileKit.openDirectoryPicker()` in a common Kotlin API while delegating the user-facing picker behavior to platform-native facilities. That reduces duplicated call sites when shared Compose Multiplatform UI must initiate the same kind of operation on Android, Apple targets, desktop, JS, or WASM. It also centralizes integration with Compose Multiplatform, Coroutines, `kotlinx-io`, and Coil.

The trade-off is loss of direct platform specificity at the call site. Developers still need to understand target rules because FileKit delegates to native pickers, and the broad target list does not document identical behavior for every optional operation. A project with specialized Android document handling or unusual Apple storage requirements may already have more precise code than a cross-platform layer can express cleanly.

FileKit's modular packaging offers a narrower compromise. A developer can evaluate `filekit-core` separately from `filekit-dialogs`, `filekit-dialogs-compose`, and `filekit-coil`. The README lists the artifacts together, while the separate documentation pages indicate that setup differs by module.

Release cadence, MIT licensing, and adoption cost

FileKit is not archived, and its last push was on 2026-10-13. Recent releases include `0.16.0` on 2026-09-07, `0.15.0` on 2026-08-08, and `0.14.2` on 2026-06-13. This release history gives adopters current versions to inspect, but it does not by itself establish API stability or compatibility between releases.

The project is licensed under the MIT License. That permits use, modification, distribution, and private use subject to the license terms, and the notice must accompany copies or substantial portions of the software. This is a statement about the repository's stated license rather than legal advice about a particular product or distribution.

The visible upgrade path includes a migration guide for moving from FileKit 0.8 to 0.10. Its existence is direct evidence that major API migration guidance has been necessary. Teams pinned to older FileKit releases should account for that work rather than assuming calls such as `openFilePicker()` remain unchanged. The current quick start and installation documentation should be checked against the exact release selected in Gradle.

Dependency and setup cost are concentrated in KMP application modules. The repository includes platform samples and dedicated documentation for core and dialogs, which provides useful reference paths. The README still leaves target initialization, permissions, error behavior, and capability differences outside its visible examples.

Editorial conclusion

FileKit is a practical choice for Kotlin Multiplatform and Compose Multiplatform applications that need the same file-oriented API on several targets. It is less suitable for a single-platform application whose existing platform SDK already supplies every required dialog and permission flow. Before adoption, check the installation guide for current module setup, verify the capabilities and behavior required on each target, and confirm that the dependency split fits the project. The first release check should be whether `filekit-core` plus the required integration modules cover the application's complete picker, save, and media workflow.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. vinceglb/FileKit on GitHub