kotlin-multiplatform

Guide Kotlin Multiplatform source set placement and platform abstraction decisions.

Updated Mar 13, 2026
One-click install
npx skills add https://github.com/fsales/curso-android-capgemini-proway --skill kotlin-multiplatform-fsales
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: kotlin-multiplatform
Source: https://github.com/fsales/curso-android-capgemini-proway/tree/main/exercicio/EAluno/.github/skills/kotlin-multiplatform
Command: npx skills add https://github.com/fsales/curso-android-capgemini-proway --skill kotlin-multiplatform-fsales

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) and references (resource) components.

What problem does it solve?

This Skill helps developers decide what Kotlin code should be shared across platforms and what should remain platform-specific, preventing incorrect abstractions and source set placement issues.

Core Features & Use Cases

  • Platform Abstraction Guidance: Determines when to use commonMain, jvmAndroid, platform-specific source sets, or expect/actual patterns.
  • KMP Architecture Support: Provides guidance for dependency placement, Gradle Kotlin DSL configuration, and multiplatform project organization.
  • Use Case: A developer building an Android, Desktop, and iOS application can use this Skill to decide whether a ViewModel, crypto implementation, JSON library, or navigation layer should be shared or separated.

Quick Start

Ask the kotlin-multiplatform skill where a new feature should be placed in a Kotlin Multiplatform project.

Frequently Asked Questions about kotlin-multiplatform

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I decide what code to share in commonMain vs platform-specific source sets in Kotlin Multiplatform?

Kotlin Multiplatform source set placement depends on API compatibility and abstraction requirements. Place shared logic in commonMain, use intermediate source sets like jvmAndroid for shared behaviors, and apply expect/actual declarations only when platform-specific implementations are necessary.

When should I use expect/actual declarations instead of commonMain interfaces in KMP?

Use expect/actual declarations in Kotlin Multiplatform when a common API requires distinct platform-specific implementations. Prefer standard commonMain interfaces when a shared default implementation suffices, reserving expect/actual for accessing native platform functionality.

What's the best way to organize Gradle Kotlin DSL configuration for a KMP project with Android, Desktop, and iOS targets?

Organizing Gradle Kotlin DSL for Kotlin Multiplatform involves configuring source set hierarchies and defining platform targets. Group overlapping targets using intermediate source sets like jvmAndroid to maximize code sharing and streamline dependency placement.

Does KMP architecture work for sharing ViewModels and navigation layers across Android and iOS?

Kotlin Multiplatform architecture supports sharing ViewModels and navigation layers across Android and iOS. Place these components in commonMain if their dependencies are multiplatform-compatible, or apply expect/actual patterns to handle platform-specific navigation behaviors.

Why does my Kotlin Multiplatform build fail when adding a dependency to commonMain?

Kotlin Multiplatform commonMain dependencies must support all configured targets. Build failures typically occur when a dependency lacks KMP metadata for specific platforms, requiring you to move it to an intermediate source set or find a multiplatform-compatible alternative.