kmp-native-authoring

Scaffolds first-party C/C++ native cores for Kotlin Multiplatform libraries with CMake and C-ABI headers.

2|Updated Jun 6, 2026
One-click install
npx skills add https://github.com/ronjunevaldoz/kmp-agent-skills --skill kmp-native-authoring-ronjunevaldoz
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: kmp-native-authoring
Source: https://github.com/ronjunevaldoz/kmp-agent-skills/tree/main/skills/kmp-native-authoring
Command: npx skills add https://github.com/ronjunevaldoz/kmp-agent-skills --skill kmp-native-authoring-ronjunevaldoz

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Writing a brand-new native core (renderer, codec, engine) for a Kotlin Multiplatform library requires up-front decisions about directory layout, CMake configuration, and public header design that are expensive to change later. This Skill structures that native core correctly from day one so it can be built once for Android, iOS, and Desktop and bridged to Kotlin without rework. ## Core Features & Use Cases - Native Project Scaffolding: Defines a single native/ directory with one CMakeLists.txt reused across Android NDK, iOS/Kotlin-Native cinterop, and JVM/Desktop JNI targets. - Public C-ABI Header Design: Produces a stable extern "C" header using opaque handles, paired create/destroy functions, and plain C types so both JNI and Kotlin/Native cinterop can consume it. - Native-Side Testing: Sets up gtest/ctest suites that run in their own CI job, independent of the Kotlin test tasks. - Use Case: You are writing a custom Vulkan renderer for a KMP library from scratch. Use this Skill to lay out the directory, author the public header, configure CMake with per-platform link branches, then hand the stabilized header off to kmp-jni-pro for the Kotlin bridge. ## Quick Start Scaffold a new C++ native core with a public C-ABI header and CMake build for my KMP library's custom Vulkan renderer.

Frequently Asked Questions about kmp-native-authoring

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

FAQPage Schema
How do I structure a C++ native core for a Kotlin Multiplatform library?▼

Use one native/ directory with a single CMakeLists.txt, an include/ folder holding the public C-ABI header, a src/ folder for C++ internals, and a tests/ folder for gtest. The same CMake project builds for Android NDK, iOS cinterop, and Desktop JNI.

What should a public C-ABI header look like for JNI and Kotlin/Native cinterop?▼

Wrap declarations in extern "C", expose opaque pointer handles instead of structs with C++ members, and pair every _create function with a _destroy. Keep STL types, exceptions, and templates out of the boundary since neither JNI nor cinterop can cross them safely.

Can I use unsigned C integer types in a header consumed by Kotlin?▼

Kotlin/Native cinterop maps uint8_t through uint64_t directly to UByte, UShort, UInt, and ULong, but JNI has no unsigned primitive at all. Keep sizes, indices, and array lengths signed even where C convention uses unsigned, per Kotlin's own guidance.

When should I use expect/actual instead of writing a separate C++ native core?▼

Use a plain Kotlin/Native expect/actual implementation when the native need is trivial, such as a handful of pure functions with no state or build complexity. A separate C/C++ core is justified for stateful engines, renderers, or codecs with real build requirements.

Why should native tests run separately from the Kotlin test suite?▼

Native tests built with gtest and run via ctest execute in their own CI job with only a C++ toolchain, so a native regression fails before any Kotlin code compiles. Bundling them into jvmTest delays detection and couples native failures to the Kotlin build.

What are the limitations of exposing C++ types across a JNI boundary?▼

STL containers, exceptions, and templates cannot cross a JNI or cinterop boundary reliably. Convert them to plain arrays with length parameters and integer error codes at the boundary, keeping C++ idioms internal to the implementation.