Experimental features often suffer from documentation delays. Often the tutorials and documentation lag behind the publications. Drag and drop is one such example. As frustrating as it may seem, it’s also an opportunity to see how the feature evolves and hone some problem-solving skills. Although this article contains code snippets that may or may not be helpful, the topic is intended to help you think differently and solve the problem yourself next time you experience documentation delays.

The code and context of this article is: compose.ui version 1.10.1.

The official documentation at kotlinlang.org/docs/multiplatform/compose-drag-drop.html serves as a guide to get you started, but you’ll quickly find that it simply won’t compile.

If the provided code snippets fail to compile, the key is to look at the function signatures rather than looking for copy-paste solutions. Start by examining the two most important features: `Modifier.dragAndDropSource` and `Modifier.dragAndDropTarget`. The former needs a `drawDragDecoration: DrawScope.() -> Unit` to render the drag ghost (like a simple `drawRect` with `drawText` inside) and a `transferData: (Offset) -> DragAndDropTransferData?`Lambda.

This `transferData“Lambda is where challenges arise because the trailing Lambda calls contain functions like “”.discoverDragGestures` and a non-existent `startTransfer`. It looks complicated, but what does it want to achieve? The name says it all – it’s about generating something DragAndDropTransferData– Information that can be passed on to any control that is lucky enough to come across it.

Take a look at “DragAndDropTransferData“ – it’s an „expect“ class with no public constructor… that’s an indication that the MP part of KMP isn’t ready here yet and we need platform-specific „actual“ implementations. Prioritize JVM as the reference platform. There you will find a constructor that is very similar to the example and contains a “`”.transferable` (similar to Android primitives bundle), `Supported actions`, `DragDecorationOffset`, and `onTransferCompleted `. So how do we get this back into our lives? commonMainCode?

Expect fun createTransferData(offset: Offset): DragAndDropTransferData

Use the hints menu to generate the “actual” classes, starting with JVM. In the JVM environment, replicate the bundle-like file for your data, z.B. B. a string payload. Test iteratively: pull from source, review ghost renders, and confirm transfer data creation without crashes.

Go to landing page, `Modifier.dragAndDropTarget` requires a `ShouldStartDragAndDrop: (DragAndDropEvent) -> Boolean` and a `Target: DragAndDropTarget`. Again: “DragAndDropEvent` is just expected, so create platform-specific accessors to extract your payload. Define a custom “expect” data class like “MyDragEvent(Value text: String)` and implement `Real fun DragAndDropEvent.getData():MyDragEvent` per platform – JVM first, pull from portable.

Data class MyDragEvent(Value text: String)

Are you expecting fun DragAndDropEvent.getData(): MyDragEvent?

In `onDrop`, validate the action (z.B. copy or move), retrieve your `MyDragEvent` and apply it to the target’s status, z.B. B. when updating a list or a text field. Debug by logging offsets and actions across platforms and adjusting specifics such as iOS gesture handling or JS pointer events.

The process requires resilience: expect changes with each compose.ui update, so prioritize understanding signatures and expected/actual patterns over rigid code. Prototype on JVM, port to Android/JS/iOS, and refine gestures through testing – this mindset scales beyond drag-and-drop to any experimental KMP UI feature.

Thanks for reading!

How to Implement Drag and Drop in Kotlin Multiplatform was originally published in Google Developer Experts on Medium, where people are continuing the conversation by highlighting and responding to this story.