:loudspeaker: Hi folks! The <Kotlin Toolchain 0.13...

# kotlin-toolchain

[klikh]

📢 Hi folks! The Kotlin Toolchain 0.13 has been released, with the following features:

• Swift Package Manager import
• The kotlin new command and a reworked kotlin init
• Better onboarding UX for iOS development
• Improvements to the progress UI in the command line
• New Sync status in the IDE
• …and more.
With this release, JetBrains now recommends Kotlin Toolchain for most new KMP projects. This is a big milestone for us.

Check out our public blog post and our GitHub release notes for more info.

[Eugen Martynov]

I have CMP project. Is it in area of most recommended KMP projects?

[Eugen Martynov]

(Reading blogpost and documentation first)

[Paul at Avans Breda]

Thanks for the blog post! The improvements are really nice and we really enjoy using the Kotlin Toolchain.

One question, with 'Kotlin new' we have the options:

What do you want to create?
❯ Compose Multiplatform application                                                               
    Compose Multiplatform clients for Android, iOS, desktop, and web, with an optional Ktor server
  JVM console application                                                                         
    A plain JVM console application without any framework                                         
  Kotlin Multiplatform library                                                                    
    A multiplatform library targeting Android, iOS, and the JVM                                   
  Ktor server application                                                                         
    A Ktor server application with the Netty engine                                               
  Spring Boot application (Kotlin)                                                                
    A Spring Boot application written in Kotlin                                                   
↑ up • ↓ down • enter select

So what is the recommended approach when you need:
> Android app, with an optional Ktor server

[joffrey]

We will reword the choices a little bit. At the moment, if you choose Compose Multiplatform application, you actually get to the wizard where you can choose the components you want. You can then select only Android + server

[joffrey]

message has been deleted

[joffrey]

It gives you this:

├───app
│   ├───androidApp
│   │   ├───res
│   │   │   ├───drawable
│   │   │   ├───drawable-v24
│   │   │   ├───mipmap-anydpi-v26
│   │   │   ├───mipmap-hdpi
│   │   │   ├───mipmap-mdpi
│   │   │   ├───mipmap-xhdpi
│   │   │   ├───mipmap-xxhdpi
│   │   │   ├───mipmap-xxxhdpi
│   │   │   └───values
│   │   └───src
│   └───shared
│       ├───composeResources
│       │   └───drawable
│       ├───src
│       ├───src@android
│       ├───test
│       └───test@android
├───core
│   └───src
└───server
    ├───resources
    ├───src
    └───test

[Paul at Avans Breda]

Actually this seems a KMP structure wich only targets Android.
I was looking for a less nested structure where androidApp is on the same level as core and server.

[joffrey]

Yeah I understand. We don't have a preset template for this case at the moment. You can always trim this one of course.

[Anton Prokhorov]

I have CMP project. Is it in area of most recommended KMP projects?

Most likely, but depends on your build setup and what Gradle-related/dependent libraries did you use? We haven't yet worked on the migration path from Gradle, but you can try to install this agent skill and try migrating it with agent, if agent one shot it, it's pretty certain your project in this area

[joffrey]

@Paul at Avans Breda I have to add, though, that we generally encourage modularization. So the overall structure might actually fit your needs anyway, just changing shared for a bunch of jvm/lib modules instead (if you need them JVM-specific).

[Anton Prokhorov]

@Paul at Avans Breda is android and server a final set of target platforms for your app? just out of curiousity

[Paul at Avans Breda]

Yes in our educational setting it is.

[joffrey]

We're considering adding a CLI command to add a new module, so maybe this will be a case that can leverage this. You can start with an Android app or a Ktor server project, and then add the other module via a simple command

[Paul at Avans Breda]

That would be really helpful. For now what we did:
• start with a Kotlin Toolchain Ktor project
• (In IntelliJ project Window) add on project level a new directory and add a module.yaml for product: android/app

[joffrey]

Yes, that definitely works. Generally an Android module is a bit more annoying to setup, with the assets, the manifest, etc. Maybe we should have a simple Android app template, and then you'll be able to create a Ktor server module by hand (which I think will be easier)

[louiscad]

I wish for kotlin init and the IDE wizard to support creating module templates, and creating new modules from templates.

[louiscad]

Quoting the last paragraph of this page: kotlin-toolchain.org/dev/user-guide/multiplatform#…
> In the future, Kotlin Native will also support joint Kotlin+Swift compilation in the same way, but this is not the case yet. At the moment, Kotlin code is first compiled into a single framework per ios/app module, and then Swift is compiled using the Xcode toolchain with a dependency on that framework. This means that Swift code can reference Kotlin declarations, but Kotlin cannot reference Swift declarations. See more in the dedicated Swift support section.
Does that still stand true, in light of the recent blog post?

[joffrey]

> I wish for kotlin init and the IDE wizard to support creating module templates
Yep, this is in the plans. I think we have some YT issue lying around for the new module wizard support (EDIT: KTC-4921). And for the CLI, as I said, this is also part of the plan, so you should get your wish eventually 🙂

[joffrey]

> Does that still stand true, in light of the recent blog post?
This blog post is about discontinuing the IDE support for editing Swift code. It's orthogonal to the Swift interop in Kotlin/Native itself. And I'm almost certain the paragraph still stands for the pure Kotlin/compiler side of things, and the Kotlin Toolchain as a result. Let me just tag @amakeev here to confirm.

[louiscad]

I am wondering what would be the developer experience for this in particular, if the IDE doesn't support editing Swift:
> In the future, Kotlin Native will also support joint Kotlin+Swift compilation in the same way, but this is not the case yet.

[joffrey]

I think the idea is that there is little demand to work with Swift code from IntelliJ (devs basically go to Xcode to edit their Swift code), and it's a tremendous amount of work to maintain the Swift language support. So my understanding is that devs will have to do just that: go to Xcode for Swift, stay in IDEA for Kotlin. But again, I'll let @amakeev comment on the vision here.

[Pearce Keesling]

This is awesome! I was under the impression we were years away from this being usable. Recommending it for "most" projects seems to mean it's much further along than I thought. What are the types of things that make a project not fall in that bucket?

[joffrey]

The keyword here is new. We recommend it for most new KMP projects 🙂 This is because existing Gradle-based projects with lots of customizations might not be able to migrate, especially those making use of Android variants, custom dependency manipulation, or arbitrary task wiring. But we expect to cover the needs of most new projects.

Within that group, some friction can be met with technologies like SQLDelight, because the lack of plugin publication/consumption means you need a bit of manual tinkering to basically implement a simple version of the plugin locally. Also, the Kotlin/JS + server combination is not in our focus right now, so this might also not be well covered, although we do support Kotlin/WasmJS now. There are definitely a couple other things, but they don't come to mind right now.

Actually, we're eager to hear from the community what exactly they are missing from the current offering, so if you give it a go, let us know! kodee loving

[Pearce Keesling]

We probably fall into the "other" category but I'll do some poking around to see what exactly the blockers are and I can report back.

[joffrey]

That would be amazing, thanks! 🙏🏼

[amakeev]

@louiscad if I get your question in regard to Swift support correctly. The discontinuation announcements applies only to the IDE functionality. Compiler scope, Swift export, SPM import are not affected. The excerpt from the Kotlin Toolchain that you mentioned primarily meant that Kotlin Toolchain was designed to support future multi-platform functionality like full Swift interop (KT-49521). There is already a good progress on Swift Export, but no ETA on Swift Import. If and then it becomes available such mixed code bases should be naturally supported by Kotlin Toolchain

As to how the developer experience in the IDE would look like - this is a fair question. We’ll be collecting feedback on how Kotlin Toolchain is used, which use cases are popular and whether there is demand for Swift

[Pearce Keesling]

We were able to actually get it all working! I had to add a plugin with our own tasks to bridge some gaps (we had to hack some stuff together for SKIE and test balloon support) but it worked. Unfortunately builds/tests are substantially slower (up to 2x) so we probably won't make the jump at this time