DEV Community

Discussion on: Playtomic's Shared Architecture using Swift and Kotlin

angelolloqui profile image
Angel G. Olloqui Author

Nice! Kotlin Native is indeed maturing quickly, and I am starting to think that it might be my choice if I would have to start with Playtomic from scratch today.
I would love to see a deeper article of your experience, especially on your day to day problems. How is the developer experience? can you for example debug kotlin code from xcode? how fast is the compilation process? how well does the bridging work? how much of your code gets reused at the end of the day? how is it forcing you to adopt a particular architecture... so many questions :)

Thread Thread
kpgalligan profile image
Kevin Galligan

"How is the developer experience?"

Improving. The tooling and libraries need some work, but Kotlin is made by Jetbrains, and they are arguably the best tooling vendor in the business, so it'll be great soon. The community is also growing quickly, largely transitioning from Android rather than coming from "out of nowhere". We've made Droidcon NYC 2019 a very Multiplatform conference:

"can you for example debug kotlin code from xcode?"

Yes. We make that plugin:

"how fast is the compilation process?"

Not super fast, but the general dev process is to code on the JVM side first, which is more optimized, then rebuild the Xcode framework and call it from iOS. The next major version of Kotlin should be focused on various performance improvements (compilation being one of them).

"how well does the bridging work?"

It currently presents to Swift/Objc as an Objc library. The usual Swift Objc interop issues will apply, but the generated header takes advantage of many of the naming you can insert for Swift. You can also now have generics (I highlight that because we did that too, wink: With ABI stability, direct Swift interop will be more of a priority. Possibly early next year, but there is no timeline yet from the team.

"how much of your code gets reused at the end of the day?"

It is "optional sharing", as the shared code produces a framework that can be called from Swift/Objc. You can share networking, storage, threading, architecture, etc. That will be difficult to introduce on an existing app, or perhaps the existing iOS team would prefer to start with smaller pieces, so just combine database and remove core data. That kind of thing. It depends. UI, not yet. This is defintely for "business logic" and architecture. Critically, of course, you can share tests.

"how is it forcing you to adopt a particular architecture"

Related to above, if you are doing discrete modules (data, tax calculations, networking), you don't really need a shared architecture. If you want common architecture, that's a more complex question, and will have simpler answers soon. A lot of the Kotlin/Native world is waiting on multithreaded coroutines. That will trigger several architectulal libraries built on top in quick succession. Questimate, later this year. Today, you have a few options. I just mention the coroutines one as when that emerges, the "today" options will become the "yesterday" options pretty quickly. We will have a few architecture talks at Droidcon, though.