Design a Small Public API
Decide what to expose and what to keep internal.
Design a Small Public API is a free Kotlin Multiplatform Academy lesson on CoddyKit — lesson 1 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the Kotlin Multiplatform Academy learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.
What a Public API Is
Your module's public API is the set of functions and types other code is allowed to call. It is the front door both apps walk through.
Small Surface Wins
A small surface area means fewer things to learn and fewer things to break. Expose only what callers truly need, nothing more. 🎯
Start From the Use Case
Design backwards: write the call site you wish you had first. Let that ideal usage shape what your public functions look like.
// Imagine this is how both apps will call you
val text = greeter.greet("Maya")Expose Intent, Hide Steps
A good API shows the intent and hides the steps. Callers say what they want, not how the work gets done inside.
Name Things Clearly
Clear names are half your API. A method called priceWithTax tells the whole story without any extra docs to read.
fun priceWithTax(base: Double, rate: Double): Double {
return base + base * rate
}Prefer Simple Inputs
Take plain, obvious inputs like strings and numbers. Simple parameters make your API easy to call from both Android and iOS.
Return Useful Types
Return shared data classes instead of loose values. A typed result is self-describing and far harder to misuse.
data class Quote(val total: Double, val currency: String)Hide the Helpers
Internal helpers and rough edges should stay private. Only the entry points a caller actually uses belong in the public API.
Easy to Add, Hard to Remove
Every public thing is a promise. It is easy to add new API later, but removing it can break callers, so expose less up front.
Stay Platform-Neutral
Keep the API platform-neutral. If a signature mentions Android or iOS types, it cannot serve both apps from shared code.
Design for the Reader
The best APIs read like a sentence at the call site. Optimize for the caller, not for whoever wrote the implementation.
Quick Check
Let's test your API design instincts.
Recap
A great public API is small, clearly named, and shaped by real use cases. Expose intent, hide steps, and both teams will love it. 🎉
Frequently asked questions
Is the “Design a Small Public API” lesson free?
Yes — the full text of “Design a Small Public API” is free to read here on the web, and the Kotlin Multiplatform Academy course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the Kotlin Multiplatform Academy course, upgrade to CoddyKit PRO.
What will I learn in “Design a Small Public API”?
Decide what to expose and what to keep internal. You practise Kotlin Multiplatform Academy with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.
Do I need any experience to start Kotlin Multiplatform Academy?
No prior experience is required. Kotlin Multiplatform Academy on CoddyKit is structured for beginners through advanced learners; this is — lesson 1 of 4, so you can start here or from the beginning and move at your own pace.
How long does the “Design a Small Public API” lesson take?
Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.
Can I write and run code in this Kotlin Multiplatform Academy lesson?
Yes. Every Kotlin Multiplatform Academy lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.
All lessons in this course
- Design a Small Public API
- internal vs public Visibility
- Organize Packages Inside the Module
- Document the API for Both Teams