Documenter l’API pour les deux équipes

Both Android and iOS devs call your shared code, so clear documentation is as important as the functions themselves. 📝

KDoc is Kotlin's documentation comment. You write it right above a declaration, and tools turn it into readable reference pages.

Code shows what happens; good docs explain the why and the intended use. State what a caller should expect, not how it works inside.

Use the @param tag to describe each input. Callers from both apps then know exactly what to pass without reading the source.

The @return tag describes what comes back. A clear return note prevents wrong assumptions about units, ranges, or null.

Wrap names in square brackets to create links, like [Quote]. Readers jump straight to related types in the generated docs.

A tiny example beats paragraphs of prose. One snippet showing a real call answers most questions before they are asked.

Spend your effort on the public surface. Internal helpers can stay lightly commented since no outside team will call them.

Swift developers read your KDoc too, so describe behavior in plain terms. Avoid JVM jargon that means nothing on the iOS side.

Dokka reads your KDoc and produces a browsable site. Both teams get one shared reference instead of guessing from the code.

Outdated docs mislead more than no docs. Update the KDoc in the same change as the code so the two never drift apart.

Let's check your documentation know-how.

Write KDoc on your public API, explain the why, tag params and returns, add a sample, and let Dokka share it with both teams. 🎉