ما ليس موجودًا في Common stdlib

Not every Kotlin API is multiplatform. The common stdlib is a careful subset, and many familiar JVM tools are missing.

Anything under java packages is JVM-only. It compiles on Android but breaks the moment iOS tries to build it.

The old java.util.Date and Calendar do not exist in common code. Reach for kotlinx-datetime instead.

JVM file APIs like java.io.File are absent from commonMain. File access needs a multiplatform library or expect/actual.

Full reflection is a JVM feature. Common code only gets a tiny subset, so design without heavy runtime introspection.

java.lang.Thread is unavailable in common. For background work you use coroutines, which are fully multiplatform.

If an import starts with java or javax, it cannot live in commonMain. That prefix is your warning sign.

Put JVM-only code in common and the build fails fast with an unresolved reference for the iOS target. That is helpful, not scary.

When you need a platform API, either find a multiplatform library or wrap it yourself with expect/actual per target.

Stick to Kotlin stdlib types and kotlinx libraries in common, and your shared layer stays portable everywhere. 🙂

Before sharing logic, ask whether it needs a JVM-only API. If so, isolate it so commonMain stays clean.

Avoid java.* APIs in commonMain. Use stdlib types, kotlinx libraries, or expect/actual to keep shared code truly portable.