I’m making a simple break timer app. After playing around with swing for deskop I figured out that i...

# multiplatform

[Giuliopime]

I’m making a simple break timer app.
After playing around with swing for deskop I figured out that it wasn’t powerful enough on macOS, especially regarding windows management.
So this is the ideal targets of my app:
• Android -> Compose multiplatform
• Windows -> Compose multiplatform
• Linux -> Compose multiplatform
• iOS -> Native UI with shared kotlin business logic
• macOS -> Native UI with shared kotlin business logic
To build the iOS and macOS apps I decided to go with the multiplatform target in Xcode, which targets iOS, ipadOS and macOS all at once.
Using cocoapods in a Xcode multiplatform project is not supported yet so I need to use Swift packages (xcFrameworks), which seems to be buildable from the native.cocoapods plugin already.
Now with that out of the way, what should my project structure look like?
I don’t like putting the shared compose UI for android/windows/linux inside the shared module because that would get included in the swift package too and it’s not needed.
Any suggestion is appreciated!

[Giuliopime]

FIgured out it might not be the best decision to create a multiplatform project with xcode as it might be hard to create the related submodules in shared for the expected/actual mechanism. Or is that possible by configuring two submodules shared/iosMain and shared/macMain ? Would they get compiled correctly in the xcFramework?

[hfhbd]

Just create another Gradle module consumed by the compose targets.

[Giuliopime]

Not inside the shared one right, a standalone one?

[hfhbd]

Yes. Just to mention, I talk about Gradle modules, not Xcode (broken by design) modules.

[Giuliopime]

yeah ofc

[Giuliopime]

Any opinion on the multiplatform xcode setup?

[hfhbd]

I never used the cocoapods plugin but the xcframework which does work very well with Kotlin Multiplatform and Xcode multiple targets.

[Arkadii Ivanov]

I believe xcframework builds all architectures every time, which is pretty slow for development. You could try the regular integration via embedAndSignAppleFrameworkForXcode Gradle task. This should build only the current architecture.

[Giuliopime]

Yes I would only use that for deploying in prod, also if I don't change the business logic much it wont be a big issue

[mikehearn]

Which features do you lack in Swing for WM?

[mikehearn]

(there are libraries that add some missing features)

[Giuliopime]

On macos it's not possible to open a window above other full screen windows with swing

[Giuliopime]

That's the main issue

[Giuliopime]

And it's just a plus for me to make a native app because I can manage timers for native apis like background tasks, instead of having a simple coroutine