https://kotlinlang.org logo
#multiplatform
Title
# multiplatform
e

eygraber

02/23/2024, 8:31 PM
It seems like best practice for a while was to have separate app modules for each target (e.g. android, ios, wasmJs, etc...), but now I've seen several projects having one app module with separate source sets for the different targets. Is there official guidance for this, and if not, is there any good write up of the pros and cons of the two approaches?
j

Jeff Lockhart

02/23/2024, 8:48 PM
JetBrain's older templates had separate app modules. But the current template used by kmp.jetbrains.com has a single module. My guess it was an effort to simplify getting started, where there's only one place you need to understand putting platform-specific code.
👍 1
p

Pablichjenkov

02/23/2024, 8:53 PM
Same opinion, it was an effort to welcome newcomers I guess. Big projects will go multiple modules anyway.
y

yschimke

02/23/2024, 10:49 PM
I guess also as you are sharing more code, KMP libraries like Apollo, Ktor. Or using expect/actual. The target platform is an awkward way to modularise.
✔️ 1
Modules might be more around features or form factors.
e

Edoardo Luppi

02/23/2024, 11:02 PM
> separate app modules for each target This was a very strange paradigm. The expect and actual declarations were fragmented over multiple places, making it very hard to handle a consistent amount of except declarations. Edit: I see this seems to be Compose-specific, but yes there was a time when expect/actual were split by module
p

Pablichjenkov

02/24/2024, 12:04 AM
Definitely
the target platform is an awkward way to modulirize
It sounds to me, at the beginning, the App module per target was better to mix with an existing target code. Perhaps more oriented to show devs how to
integrate
with existing code. Which is still one of the biggest selling points.
e

eygraber

02/25/2024, 1:01 AM
Maybe it's different for me because my project is highly modularized, and the apps for the different platforms have little to no shared code because they're just entry points.
p

Pablichjenkov

02/25/2024, 2:12 AM
For your case I agree that 1 module for all targets is more than enough.
p

Pamela Hill

02/25/2024, 12:52 PM
I would suggest following the wizard structure on kmp.jetbrains.com. It's the latest in our thinking
👍 1
e

eygraber

02/25/2024, 9:47 PM
I'm not sure if there's a "one size fits all" approach here. For example, my project currently has separate modules for the different apps (Android, ios, Desktop, Web) because all those modules do is setup the platform to call into my actual code, e.g. the Android app module sets up the
Application
and
Activity
, Web sets up the call to
CanvadBasedWindow
etc... It also allows me to have simpler Gradle files that focus on the specific platform, while having all of them in one file would be less manageable (I could make separate convention plugins to setup the specific apps, but then it's less localized). However I could see other applications benefiting from having everything in one module.
2 Views