The goal is so nice, but converting Swift code into separate independent Kotlin code (or the opposite) manually (helped by the tool) doesn' scale. For example, fixing a bug in one platform requires fixing as well in the other...
Have you considered to create common shared Kotlin libraries encapsulating the business logic? I think this is the definitive solution for mobile development. It requires a clean and nice architecture in both platforms, but I'm pretty sure this will eventually become the standard.
Computer engineer with a Master in Web technologies. Specialized in mobile application development, with broad experience using Agile methodologies and Certified Scrum Master. Active open source contr
Hi Roldán, having to keep two separate projects with equivalent source code is indeed something that will probably not scale well (I actually mentioned it in the article). However, for small teams is not that big of a problem.
Using a unique code base or shared library written in single language and compiled for both is something that comes with its own issues as well, so it is all about deciding which of the penalties you prefer to pay. In this sense, kotlin is doing a great movement with kotlin native, but it is still too young (IMO) to be consider for production. Besides, you will need to use specific tools that will not be part of the standard and you will be bound to that choice for longer. It is definetly something very interesting, but I think is still too early (for kotlin) or too cumbersome if you go with C++, JavaScript or alike. Anyway, I would love to hear your experience if you have use that approach in a real project
Justin helps dev and product teams navigate the waters of mobile app development and is an expert at integrating them into larger technical, customer, and business ecosystems.
Kotlin Native has been maturing quickly. And the company I work for has been on the leading edge of it. Improving shared Kotlin interop with more idiomatic Swift is one of those things (e.g. generics)
I really like the decision process you had taking into account your team competencies, product goals, and technology capabilities. I wrote and presented on this as well.
Computer engineer with a Master in Web technologies. Specialized in mobile application development, with broad experience using Agile methodologies and Certified Scrum Master. Active open source contr
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 :)
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: medium.com/@kpgalligan/kotlin-ever...
"can you for example debug kotlin code from xcode?"
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: github.com/JetBrains/kotlin-native...). 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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
The goal is so nice, but converting Swift code into separate independent Kotlin code (or the opposite) manually (helped by the tool) doesn' scale. For example, fixing a bug in one platform requires fixing as well in the other...
Have you considered to create common shared Kotlin libraries encapsulating the business logic? I think this is the definitive solution for mobile development. It requires a clean and nice architecture in both platforms, but I'm pretty sure this will eventually become the standard.
blog.kotlin-academy.com/multiplatf...
Regards!
Hi Roldán, having to keep two separate projects with equivalent source code is indeed something that will probably not scale well (I actually mentioned it in the article). However, for small teams is not that big of a problem.
Using a unique code base or shared library written in single language and compiled for both is something that comes with its own issues as well, so it is all about deciding which of the penalties you prefer to pay. In this sense, kotlin is doing a great movement with kotlin native, but it is still too young (IMO) to be consider for production. Besides, you will need to use specific tools that will not be part of the standard and you will be bound to that choice for longer. It is definetly something very interesting, but I think is still too early (for kotlin) or too cumbersome if you go with C++, JavaScript or alike. Anyway, I would love to hear your experience if you have use that approach in a real project
Hi Angel, very cool what you are working on!
Kotlin Native has been maturing quickly. And the company I work for has been on the leading edge of it. Improving shared Kotlin interop with more idiomatic Swift is one of those things (e.g. generics)
I really like the decision process you had taking into account your team competencies, product goals, and technology capabilities. I wrote and presented on this as well.
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 :)
"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: medium.com/@kpgalligan/kotlin-ever...
"can you for example debug kotlin code from xcode?"
Yes. We make that plugin: medium.com/hackernoon/kotlin-xcode...
"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: github.com/JetBrains/kotlin-native...). 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.