Our first release is an Xcode Plugin for Kotlin. Once installed, Xcode will recognize Kotlin files as source files, provide keyword coloring, and most importantly, will let you interactively debug Kotlin code running in the iOS simulator.
Depending on project setup, that includes regular code as well as Kotlin unit test code. We’ll be providing info on how to run your unit tests in Xcode soon.
Setting up the plugin and Xcode can be a little tricky. We’ll be doing a live code session Friday 4/26 at 3pm EST. We’ll be setting up a project, demoing debug functionality, helping out some others with setup, and time permitting, checking out App Code as well. If you’d like to watch, sign up here.
If you’re planning on using the Xcode debugger and would like some live help, tick the box on the form above. You’ll need to share your screen, or at least have an open source project we can run. We’ll be picking 1 or 2 projects and attempting to configure them live.
However, convincing iOS devs to give Kotlin MP a shot is easier with an Xcode option. This plugin is definitely not a full featured tool like IntelliJ IDEA and AppCode, but will allow iOS developers to step through and debug shared code.
Our thinking is that on many teams, iOS focused developers will start out mostly consuming Kotlin. Being able to navigate and debug in their native tools will go a long way towards interest and learning.
Xcode will ask if you’d like to load the bundle on first run. You’ll need to allow that.
This is definitely a work in progress. There are multiple facets what will be improved upon in the future. However, once configured, this is a very useful tool. Feedback and contributions very much welcomed.
In order to set breakpoints in Kotlin code, you’ll need the Kotlin source available in Xcode. For those familiar with Intellij and Android Studio, the source won’t simply “appear” because it’s in your project folder. We need to import it into Xcode.
You can import manually, but you should make sure the files aren’t copied out to the app bundle. Xcode “recognizes” Kotlin files, but doesn’t treat them the same as Swift files, for example, by default. You will also need to refresh the Kotlin files periodically as you add/remove code.
As an alternative, we have a Gradle plugin that you can point at a source folder and an Xcode project, and it’ll import Kotlin files. This plugin is very new and some planned features will likely be missed. Kotlin source for dependencies would be the most obvious. We’d love some help with this one.
As another alternative, if using Cocoapods, it’s possible to add source_filesto your podspec, but we’re just starting to experiment with this.
We’ll be posting more general updates soon. Subscribe to the mailing list, follow me and/or Touchlab on twitter, or come watch the live stream mentioned above.
My professional career started in college with Java 1.0. I started working during the bright Write-Once-Run-Anywhere heyday. We were finally going to get one platform!
Well, we know how that went. Java failed as a consumer UI platform. However, as a vehicle of portable logic, Java has been one of the biggest success stories in computers.
Thus one of my favorite quotes:
Shared UI is a history of pain and failure. Shared logic is the history of computers.
-Kevin Galligan (me)
I have been fixated on this for the last few years, because the need is obvious, as seems the opportunity. Native mobile, Android and iOS, are almost identical under the UI. They are architecturally homogenous. The web, although somewhat different, still needs mobile-friendly logic, and as WebAssembly matures, will look increasingly like native mobile at an architectural level.
Kotlin Multiplatform is a great entry into the pool of options for shared logic. It natively interops with the host platform, allowing optional code sharing. The tools are being built by JetBrains, so as the ecosystem matures, we can expect a great developer experience. Kotlin is also very popular with developers, so over the long term, Kotlin Multiplatform adoption is pretty much assured.
I believe in its future enough to move my role at Touchlab to be almost entirely Kotlin Multiplatform R&D. That means I code and speak about open source and Kotlin Multiplatform. As a business, we’ve pivoted Touchlab to be the Kotlin MP shop. We are of course still native mobile product experts, but we are also looking forward to helping clients leverage a shared, mobile-oriented architecture as the future of product development.
We are super excited to get to work with them on improving the developer experience and catalyzing the KMP ecosystem. It would not be an exaggeration to say that this team, and Square more broadly, is responsible for much of what the Android community considers best practice, if not the actual libraries themselves.
To be successful for native mobile, Kotlin Native needs to be something that Swift developers feel is productive and at least somewhat native to their modern language and environment. I think also selling iOS developers on Kotlin as a language and platform is important. This will largely be our focus for the near future.
Will it work out? We’ll see. In as much as it’s possible to make Kotlin native to iOS, I think we have one of the best possible teams to help us find out. I am very much looking forward to the challenge.
Learning More about Kotlin Multiplatform
If you want to learn more about Kotlin Multiplatform here are a couple resources:
Oh, and it needs be written for iOS, too. At the same time.
Again, different code. The question is, “Why?”
Development teams are essentially tripling their coding and testing efforts to ensure cross-platform coverage. It’s costly. It’s time-consuming. And – this might be the craziest part – it’s uncertain what the shelf life of the code will be. As we know, the future is unwritten.
As always, the goal is to be able to implement products more efficiently, and with better testing across platforms. And up to now, every cross-platform coding solution that has come along really hasn’t worked that well.
The good news is that there is now a better way. And a proven way.
We at Touchlab have been writing code in Kotlin and deploying it to Android and iOS platforms, with no hiccups.
That’s why we’ve gone all-in with Kotlin.
Kotlin is a true multiplatform language
Kotlin enables you to write once, and test once. No siloed development teams. The same code can be used across Android, iOS and Web apps with no changes, eliminating the need for a translation layer. In essence, you’re reducing the amount of business logic coded by frontend developers by consolidating it efficiently with native code, but not oversimplifying abstractions.
What’s not to love about that?
No wonder there’s a groundswell of enthusiastic support in developer communities around the world. There are 1.5 million developers currently using Kotlin, with 96,000 GitHub repositories containing 100 million lines of code. And the numbers keep growing. It’s one of the top two languages that developers are hungry to learn.
Kotlin was developed as a completely new language eight years ago, built from the ground up as a pragmatic approach to coding – a way to develop cleanly, clearly, and quickly. Simply put, Kotlin is more readable, reusable, interoperable, and safer, offering a first-rate developer experience.
Kotlin is your best bet on your complete tech stack
More important, it’s a low-risk way to code because it dovetails seamlessly with the native platforms on Java, iOS, and the web. It’s a modern language that enables you to build on what you’ve already coded, without re-working or re-inventing what you already have. Plus, because the code you share is optional, you can start small and increment as desired.
Kotlin is really an extension of Java, so it’s not a big leap for Java developers to start using Kotlin at all. In other words, you don’t have to make a big, potentially expensive decision to get started.
In fact, on Android, Kotlin was built for direct JVM interoperability. On iOS, Kotlin is ready for prime time, and the first half of 2019 will see rapid mainstream adoption. And Google officially recommends Kotlin as a language of choice.
The big considerations for any development team are cost, time, resources, and risk. And the big problem with the siloed approach is that organizations are often tripling them.
At the same time, the wrong teams are working on the wrong projects. Back-end developers should focus on architecture as well as APIs – but not UI. Enabling your back-end developers to code and test the client and server features as a unified whole enables more rapid development with safer, higher quality and identical implementation.
Our experience with Kotlin so far?
No siloed teams. More streamlined workflows. Real cross-platform functionality.
I’ve been talking about Kotlin/Native for a little while now, and one of the big things I tell people is that threading will be very different than what they’re used to. It’s just something that you need to learn and understand.
Kotlinconf was a couple weeks ago. Progress on Multiplatform was definitely a big topic. A more general discussion surfaced around how Jetbrains and the Kotlin team are thinking about concurrency. Andrey said in his Keynote that future Kotlin will focus on Saner Concurrency. I think we should unpack this a bit.
It is generally accepted that managing concurrency by using mutexes, synchronized blocks, etc (AKA. “manually” or “status quo”), is difficult and error prone. Concurrency in Java, with Java’s concurrency primitives, is difficult.
Kotlin/Native has baked into it some ideas about concurrency that make managing it safer. Andrey alluded to the idea that Kotlin, across variants, will start attempting to tackle “Saner Concurrency”. This is good to watch (37:00) to get a sense of where Kotlin is going, which makes me hopeful that not only will the various incarnations of Kotlin share the same concurrency concepts, but that those concepts will start to emerge as first class parts of the language at compile time rather than strictly runtime (Rust-like?).
By “various incarnations” I mean Kotlin-JVM will hopefully start getting some of the “new stuff” Kotlin/Native is getting🚧.
One of the consequences of change is that things will be different. We’ll need to learn new ideas, build different libraries, and adopt different ways of coding. That inevitably means resistance and time.
I wound up on the closing panel of the conference (thanks Hadi!), and one of the questions I gave an answer to addresses this issue. It wasn’t actually a question so much as expressing concern that the different threading model will slow down adoption (at 18:00)
I jumped in because, frankly, I had the same concerns earlier on. A few months ago I drafted up a blog post talking about how such a departure will impact adoption and may ultimately derail the effort. Thankfully, like most of my blog posts, I never finished it, and I don’t think that way anymore.
Considering it was on stage, at the end of a conference, I think I expressed my thoughts OK, but let me expand a bit here.
At the beginning of my talk, I told everybody about how I got there. I’d spent a couple years working on an architectural framework based on J2objc called Doppl. In short, compatible Android structures, lots of familiar libraries, and a gradle tool. Replicating testable mobile architecture across Android and iOS, in a familiar and practical manner.
How practical? The day after Google announced room, I got Room working on iOS, from the java source jars, in about 90 minutes.
Here’s the thing, though. Nobody cared. I bet more people read this post in the first week than read that post after a year and a half.
Obviously these aren’t direct parallels. The Android community wants Kotlin and iOS wants Swift, so pitching a Java/Objc thing isn’t fun (trust me). Community interest is critical, no matter how practical your pitch may be.
However, I think it’s also important to have a vision. Kotlin wants to adopt better, safer concurrency practices. They’re making the language available on many platforms, including Webassembly, and making “tough love” choices for a better future platform.
I think building something practical but somewhat compromised will make it easier to learn, and definitely easier to develop the library ecosystem necessary to support what currently exists, but it’s also uninspiring. It does not encourage change.
In short, yes, I think “giving up” on change would make adoption quicker for an individual iOS developer, but I don’t think it would be appealing to the iOS developer community. Change and new ideas, although they will take more work, are appealing and inspiring, and will ultimately be the best bet at gaining adoption.
When somebody says, “Kotlin is just Swift for Android”, this is meaningful pushback. It’s not simply “another language”.
In any case, it doesn’t matter. They’re doing it ✈️
This post started as one post, but turned into a monster. Part 2 will be released after my Droidcon UK talk Friday where we announce a new Kotlin Multiplatform state management library…
🚧 I didn’t want to derail up top, but one major issue for right now is that JVM and Native do some runtime things fairly differently. That is likely to create confusion early on, especially with teams that have engineers fully on one platform or the other. It would be great if we could run JVM with the same runtime checking as Native, even if just in a debug configuration.
If you’ve been following our development of Doppl for the last couple years, we’ve built a Gradle toolset for J2objc, an architectural structure with an Android compatible API, and published a number of popular libraries for that ecosystem. In other words, a full toolset extension of J2objc which allows sharing logic and architecture from Android to iOS.
J2objc is a mature, stable technology. If you have an iPhone, you’re more likely to have some J2objc in there than all the other non-HTML frameworks put together. J2objc makes sense not because it lets Java developers publish iOS code. It makes sense because it allows a platform native language produce platform native libraries, with optional code sharing, without any significant barrier or translation layer.
We use this framework with current clients, and would absolutely take new projects with it if we have the bandwidth to do so.
However, we’re officially out of the Doppl business.
The future of shared code and architecture, as far as we’re concerned, is Kotlin Multiplatform.
Some of the reasons we like it are the same as why we like J2objc. Native language, optional sharing, platform compatibility. As of the last few months, all R&D and open source development has been focused on KMP. As of KotlinConf this year (or shortly after) the tooling and libraries will be ready for production work. It is time to burn the ships.
To be better open source citizens, and to avoid internal distractions, we’ll be unpublishing Doppl and related libraries. If you’re one of the handful of orgs who use the library, please reach out and we’ll make sure you can access the repos.
I want to be clear that this doesn’t mean I think J2objc is bad tech. I still think it’s amazing technology. If you wanted to maximize your shared mobile architecture today, it would be significantly more productive than other options.
However, the community excitement around Kotlin Multiplatform is intense.
Over the next several months there will be a number of library announcements. It’s also not just for Android/iOS logic, but back end and front end architecture, including native mobile, web with JS, and webassembly. There is a lot of work to be done, but there’s a much wider scope of problems to solve.
We are, of course, looking for products and orgs interested in getting started. Also, I’m starting the search for our first Multiplatform specific engineer (besides me). Reach out.
It’s a little hard to believe, but this will be year #5 for Droidcon NYC. I’m super biased, but as great as every year has been, the year after seems to be a huge leveling up in terms of event and content quality.
That means this year needs to be ridiculous. It’s the 5 year, right?
This is a community conference, which means the content comes from the community. We’ve had a lot of great submissions so far, but it’s time to get the word out and make a big push to the end of CFP.
CFP Ends June 10th
That means we’ve got a couple weeks to get those submissions in. If you’ve submitted in the past, you’ve had the pleasure of experiencing my hand-rolled web system. No more! We’re using sessionize this year, which should be better for everybody:
Every year we get requests for topics of interest and some guidance for how to submit. The real answer is “whatever the committee votes on”, and what *I* think is interesting is not always what *they* think is interesting, but I’ll make some guesses for 2018.
The good part about timing for Droidcon NYC is we get the fresh topics right after I/O. You can submit anything you want, but there are always a few big themes.
There have always been a few talks about React Native (or whatever), but this year “multiplatform” has hit the mainstream (or at least people’s desire to talk about it at a native developer conference). We expect several talks, possibly a 1 day track on the topic. Most likely to be of interest are Flutter, Kotlin Multiplatform, or React Native. General topics may also be of interest.
A huge pile of things were released and/or rebranded under Jetpack. Clearly lots of stuff in there to talk about.
There’s also a whole new Android release to talk about.
This thing. TBH, I need to learn about this more. May attend talk.
Kotlin was the big news last year, but we’ve had a year to absorb it and release a bunch of new libraries. In that year, Kotlin has been embraced to the point that it’s weird to see a Java slide at an Android event. Probably lots of talks around actually implementing it.
All the other stuff…
Implemented an instant app in production? Using voice assistant stuff? VR/AR? There’s a lot of stuff going on.
If you have ideas for topics you’d like to hear about, please leave a comment (or tweet)
Droidcon NYC has generally leaned toward more advanced or “deep dive” types of talks, but there will be content for a range of experience levels. If you are interested in a specific topic, I’d personally suggest creating multiple submissions, with different levels experience and specificity.
For any topic that is very popular, there will likely be several similar submissions. Last year, for example, had several “Intro to Kotlin” submissions. We’re only likely to pick one, so again, multiple submissions is the best bet.
As for how to write a submission, there are a lot of great resources online about this. My only real advice is that there are generally hundreds of submissions, so a catchy title and shorter description will probably work better. The voting process is a lot of work (and much thanks to the selection committee for their efforts).
A Note on Keynotes
Every year roughly 0 to 2 people submit talks specifically designated as “keynote”. If this is something you’d like to submit for, I highly encourage that you do. Just please put that in your title. As in “Keynote: Android in 2028” or “Keynote: Android S should be Stroopwafel!” We will likely go back to keynotes on both mornings, and possibly something end of day as well, so we will have multiple slots to fill.
This year will be in Brooklyn. Greenpoint, specifically, which might sound odd if you’re somewhat familiar with NYC, but if you’ve been in Greenpoint in the last few years, it’s not weird at all. Brooklyn in general and Greenpoint in particular has changed dramatically over the last few years. It is a major part of the NYC tech ecosystem. Plus there’s a big parking lot for food trucks.
The talk selection committee details will be solidified in the near future. We expect to have 8–10 folks voting on submissions, with notifications going out 2 weeks after CFP ends.