Grant: The No-Nonsense Kotlin Multiplatform Permission Manager for Android and iOS

Stop fighting with Android manifests and iOS Info.plist. Request permissions from shared Kotlin Multiplatform (KMP) code with a clean, linear API while keeping full control over your UI.

After most teams solve shared UI communication patterns in Kotlin Multiplatform, the next wall is almost always the same: runtime permissions. On Android you juggle manifest declarations, launchers, rationale rules, and multiple API behaviors. On iOS you deal with framework-specific authorization APIs, delegates, and asynchronous completion handlers. The real KMP challenge is not “how do I ask for a permission?” but how do I unify Android and iOS permission flows into one predictable, testable, ViewModel-friendly experience.

The Current Chaos in Kotlin Multiplatform Permissions

Android: Typical implementations involve ActivityResultLauncher, ContextCompat.checkSelfPermission, manifest entries, and special handling for shouldShowRequestPermissionRationale. Each permission has edge cases, and the flow is often tied to an Activity or Fragment lifecycle.

iOS: Permission APIs differ by domain. Camera permissions use AVCaptureDevice.requestAccess, photos use PHPhotoLibrary, and other capabilities rely on their own authorization types, delegate patterns, and callback blocks.

The shared problem: you want your shared ViewModel to express a simple transactional flow like Ask → Wait → Result, without leaking platform-specific types or callback complexity into common code.

What is Grant (KMP Permission Manager)?

Grant is a permission manager designed specifically for Kotlin Multiplatform with a headless, coroutines-first approach.

• Not a UI library: Grant does not force dialogs, screens, or opinionated prompts. You own the user experience.
• A system engine: Grant abstracts the operating system permission machinery and exposes consistent results to shared code.

Why Grant Fits Modern KMP Architecture

KMP projects typically aim for shared domain logic and ViewModels with platform UI implementations. Permissions, however, are usually where platforms “leak” into shared layers. Grant’s core value is that it lets you keep platform details at the boundary while expressing permission rules in common code.

Key Features That Make Grant a Strong KMP Standard

1) Unified, Type-Safe API

Grant abstracts platform differences into a single, type-safe model (commonly an enum-like representation) so you do not have to manually map Android SDK changes or iOS authorization variants. Instead of branching on Android API level or interpreting iOS status values throughout your codebase, you ask for the permission you need and handle a consistent set of outcomes.

2) Linear Logic with Kotlin Coroutines (Suspend Functions)

Permissions are naturally transactional: request, suspend while the user decides, then return a result. Grant uses suspend functions to avoid callback hell and delegate sprawl, which makes shared code easier to read, test, and maintain.

This enables ViewModel logic that reads top-to-bottom, such as: check status, optionally show your own explanation UI, request permission, then proceed with the feature or guide the user to settings.

3) Smart Status Handling Across Android and iOS

The hardest part of permissions is handling “denied permanently” scenarios.

• Android: users can deny and select “don’t ask again,” after which the system dialog may stop appearing.
• iOS: permissions often move to a denied state where the only fix is directing the user to Settings.

Grant detects these cases in a cross-platform way, making it straightforward to implement consistent UX such as: show an in-app explanation, then deep-link the user to System Settings when needed.

Using Grant in a “Clean Architecture” KMP App

In a clean architecture setup, your shared module typically contains:

• Use cases that require a capability (camera, photos, location, notifications)
• ViewModels that orchestrate permission requests and feature flow
• Interfaces for platform services, implemented separately on Android and iOS

Grant supports this approach by allowing your shared ViewModel to depend on a permission engine rather than Android Activities or iOS delegates. This reduces coupling and keeps your shared logic portable across platforms.

Best Practices for KMP Runtime Permissions

• Explain before requesting: show a clear, user-centric rationale in your UI rather than relying on system rationale behavior alone.
• Handle all outcomes explicitly: granted, denied, and denied permanently (or equivalent) should map to distinct UX paths.
• Keep platform declarations correct: even with a shared permission manager, Android manifest entries and iOS Info.plist usage descriptions are still required.
• Centralize permission policy: define which features require which permissions in one place to avoid drift across screens.

FAQ: Grant and Kotlin Multiplatform Permissions

Is Grant a UI toolkit? No. Grant is headless by design and leaves dialogs, sheets, and onboarding screens to your app.

Does Grant remove the need for Android Manifest or iOS Info.plist keys? No. System declarations are still required. Grant simplifies runtime request and status handling.

Why is coroutines-first important for permissions? It lets you write permission logic as sequential code in shared modules, avoiding platform callbacks and improving readability and testability.

Conclusion

If you are building Kotlin Multiplatform apps and want a consistent, maintainable way to manage runtime permissions on Android and iOS, Grant’s unified API, suspend-based flow, and cross-platform status handling provide a clean foundation. It helps you keep permission complexity out of shared business logic while preserving complete control over your user experience.