Kotlin Multiplatform Library

Kotlin Multiplatform Library

The following blog post is an overview on Kotlin Multiplatform libraries by the KMP experts, Touchlab. You’ll find a. list of recommended libraries we use today for Kotlin Multiplatform development (including some of our own) b. video recording of Kevin presenting at Øredev 2019 on library development for Kotlin Multiplatform and c. slides from that presentation. 

What Kotlin Multiplatform libraries is Touchlab using today? 

 

Touchlab’s libraries

  • Stately: Stately is a state utility library to facilitate state management in Kotlin Multiplatform.
  • SQLiter: Sqlite driver for Kotlin Native
  • xcode-kotlin: Xcode plugin for Kotlin debugging and source formatting

Jetbrains’ libraries

Community Libraries We Use

  • Multiplatform Settings: A Kotlin Multiplatform library for saving simple key-value data
  • SqlDelight: Multiplatform SQLite model facilitation library.
  • Koin: Service Locator/DI. Multiplatform in progress.

Libraries We Find Interesting

Sample Apps

Useful introduction to Kotlin Multiplatform resources 

Kotlin Multiplatform Frequently Asked Questions

Kotlin Multiplatform Frequently Asked Questions

Can I use Kotlin Multiplatform for an existing app? 

Sam: Yes, being able to optionally share even small parts of your application lets you plug KMP in where it makes the most sense for you.

What Kotlin Multiplatform libraries is Touchlab using today? 

Touchlab’s libraries

  • Stately: Stately is a state utility library to facilitate state management in Kotlin Multiplatform.
  • SQLiter: Sqlite driver for Kotlin Native
  • xcode-kotlin: Xcode plugin for Kotlin debugging and source formatting

Jetbrains’ libraries

Community Libraries We Use

  • Multiplatform Settings: A Kotlin Multiplatform library for saving simple key-value data
  • SqlDelight: Multiplatform SQLite model facilitation library.
  • Koin: Service Locator/DI. Multiplatform in progress.

Libraries We Find Interesting

Sample Apps

How much of my code are we going to be able to share with KMP? 

Sam: One of the great things about KMP is that you have a lot flexibility in how much code is shared. As a rule we don’t recommend trying to share your UI code. Creating high quality UI is generally best accomplished using the tools and environment of each platform. Everything else is fair game. In practice you will find that the code you share will be the most critical business logic and the layers your platform developers are sick of doing twice.

How much weight does KMP add to our apps?  

Kevin: Minimal relative to other options, and proportional to how much you use. There is no re ection, and the standard library is small, so the Kotlin compiler includes only what’s actually being used. In general, minimal us- age of Kotlin in a native app will add a binary size in the 100’s of K’s. Major logic will likely get into the low megabytes.

We use Swift. How’s the interop with KMP?   

KevinIt 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 ge- nerics (I highlight that because we did that, too). 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.

What type of ecosystem and tool are available? 

JustinThe existing, mature, and exciting ecosystems of native Android and iOS development are available. Not everything can be pulled into shared code, but the beauty of sharing business logic is that most of it can be shared. A mature and loved library that is already in Kotlin is very close to joining the KMP ecosystem. For example, once SqlDelight was set up to output Kotlin, it didn’t take long to make it compatible with shared code…and iOS developers love that they don’t need to deal with CoreData anymore but they can keep all the other stuff they love.

KevinMajor libraries have been appearing over the last year, from JetBrains and other groups. This will continue as more libraries from the mobile world are ported. The Kotlin community on Android is already one of the most active in technology, so there is an existing and active develop- er base. As for tools, Jetbrains makes tools as a core business. They have tools already for multiplatform, and will continue to improve them. One of the main reasons why Kotlin is successful now, and why Kotlin Multi- platform will be successful in the near future, is because JetBrains will be building the tools.”

How will KMP affect our ability to recruit and onboard new iOS devs? 

JustinEqual or better. Some iOS devs will be happy to spend time on getting the UI and platform-specific stu right. Some iOS devs want to become mobile devs and will be happy to start learning Kotlin. All iOS devs will be happy to know that it doesn’t force them out of the ecosystem and lose their identity.

SamKotlin Native will be much better received by new iOS developers than many other code sharing schemes. The ability to code UI natively while treating the common code as a normal framework is much less foreign than tools which require them to learn an all new framework.

Kevin: Developers tend to prefer the platform they use, but the idea that they are all violently opposed to change is overblown. Developers are skeptical to new tech, and often for good reason. Hopefully, including Kotlin will attract developers interested in new tech. In general, the decision to move to any “cross-platform” technology is not coming from the developers but from the management level, and it is often a mandate to pick something. It’ll be much easier to recruit iOS developers if they get to embrace Swift- UI and other new Apple tools and learn Kotlin code sharing as opposed to learning React Native or Flutter. 

How fast is the compilation time? 

KevinNot 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).

Thoughts on handling concurrent operations in Kotlin Multiplatform? 

KevinKotlin Native’s concurrency model is different than the “classical” mod- els of the JVM and Swift/Objective C. It is something that new developers, coming from either Android or iOS backgrounds, will need to understand. It can be confusing at first, but the goal of these changes is less error- prone concurrency. There are some early libraries to assist with concurrency, but later this year we expect multithreaded coroutines to emerge for Native. At that point, most concurrency will be managed by libraries (like most concurrency is managed now). You’ll need to understand how it works, but the libraries will handle the heavy lifting for you.

How do I encourage optimal code sharing from the beginning? 

JustinFocus on well-established architecture principles of keeping the UI layer thin and modularizing code. Something new may be separating Android-specific libraries from common code but this is often a small amount because business logic is, by its nature, less platform-specific.

What’s the value-add over other technologies? 

JustinKotlin is THE language for Android. KMP doesn’t significantly change the way you develop native Android apps. KMP interop is native so there is very little run-time overhead and less boiler-plate code while developing. KMP outputs a standard iOS framework so iOS devs are still in familiar territory. By its nature, it keeps up with platform-specific technologies that motivate and excite strong native developers and those looking to join the space (retention and hiring). It doesn’t create its own ecosystem so it’s not a ‘B’ big decision, easy to iterate and revert, very little up-front cost compared to others.

SamIt’s optional, meaning you can do some, and no big decisions. Natively integrated: the interop is platform native, which is unlike pretty much all other options. Open source. Code sharing, so you can write and test your critical logic and architecture, but don’t build a dissatisfying UI. The language is popular and modern. That is important for libraries, hiring, and productivity.

Does KMP work with Android WearOS, Apple WatchKit, TVOS?

KevinKotlin 1.3.60 will add support for WatchKit and TvOS. Anything on the Android side already uses Kotlin, so there are no compatibility issues (Kotlin is the preferred language for Android).

How mature and stable is KMP?

KevinThe language and tooling have gone through significant change over the past couple years, but the build tools and features of the ecosystem have stabilized. The tooling and support libraries will continue to mature rap- idly during the remainder of 2019 and into 2020. As for stability, there is no “multiplatform” at runtime. It is a build time construct. Kotlin JVM is super stable. Kotlin Native’s runtime is stable, although you will occasion- ally run into things you don’t expect. Usually a result of cryptic messaging. That will also improve over the next year. Major apps are releasing Kotlin Native into production now.

What’s the best way to set up the dev experience for iOS devs?

KevinI think it’s important to establish that the plan is not to start writing everything in Kotlin. The shared code will support the native development experience of Swift and Xcode, especially as SwiftUI takes over UI development on iOS. Introduce Kotlin as a modern language that shares much of the syntax and concepts of Swift, and at an architectural level, it’s important to start thinking of our teams as “mobile developers” rather than specifically Android and iOS. Having an Xcode plugin for Kotlin means iOS developers can start reading and debugging Kotlin in the shared code without needing to dive in with new languages and tools. Once that knowledge is learned, the iOS team can start pushing code that the Android (and possibly web) teams will use. It’s important to minimize the idea that the iOS teams will just be getting code from the Android app, although that is often the initial reaction, as Kotlin is an ‘Android thing’.

How do you start migrated a codebase to KMP?

KevinPick one part that needs to happen on both platforms, ideally something that the iOS team isn’t excited about. SQLite is a good option, if you’re us- ing it. Nobody likes Coredata. SqlDelight is a far better option. From there, possibly networking, analytics, or any logic intensive operations that need solid testing. Because it’s “optional” sharing and natively integrated, it’s easy to weave shared code into existing code.

Can I hire for Kotlin Multiplatform? 

Justin: The community is growing quickly but this is new technology. At this point, there are very few experts, some devs with experience, and many more getting to know it. The greatest thing WRT hiring for KMP is that Kotlin is an easy language to hire for, and since it integrates well with new tech like Jetpack Compose and SwiftUI, even the people who built their careers on Android or iOS welcome it.

Kevin: In general, hiring for positions that are seen as forward-thinking and working with popular technology will be appealing to developers. KMP is new, so there isn’t a lot of experience out there. However, there are many developers experienced with Kotlin for Android, and a lot of developer community interest in KMP. Competing for talent will be easier if you embrace technologies that developers are excited about. KMP is certainly no exception. Today, you should expect some ramp-up time for people with experience writing Kotlin for Android. However, offering experienced Android developers the chance to focus on KMP will increase the pool of candidates interested.

Useful introduction to Kotlin Multiplatform resources 

A First Time Speaker’s Journey from CFP to Stage

A First Time Speaker’s Journey from CFP to Stage

One Week to Decide

On October 29, I found out The Lead Developer New York had open CFPs — and the deadline was November 5.

I sent a slack message to my team saying “I’d love for us to send proposals regarding how multiplatform development, specifically kotlin multiplatform, changes your team, development, processes, lowers technical risk, schedule risk, cost, etc, etc.”

This was the first time I ever thought about responding to a CFP and didn’t know if it made sense to the company, to my schedule, or to any of my colleagues. What I did know was:

Thankfully, @namnum was super supportive, immediately responding to my slack message with “Hell yes! How can I help?” 

Since this is a “Lead Developer” conference, I roped in @samhill303, our head of engineering, to go through the process with me.

We only had a week, so we had to work fast. Here’s what we did:

  1. Brainstormed titles with very light outlines to add some context
  2. Talked through which ones resonated more with us personally, as a company, and the potential audience
  3. Stopped thinking about the ones that didn’t resonate
  4. Added more definition to the outlines that survived
  5. Talked about what makes a title and description interesting (both @kpgalligan and @namnum have read and written a lot of proposals)
  6. Turned 2 outlines each into descriptions with interesting titles
  7. Quick peer review
  8. Send 2 proposals each

Two Months to Wait

Normally, The Lead Developer organizers get back to applicants within a month, but, because of the holidays and some unforeseen scheduling changes, we had to wait until January.

I didn’t know that until they sent a note mid-december so I was looking at my email pretty often until then. Waiting is definitely not fun, but it is important that the people reading through proposals take their time to figure out if the talk will fit well with the conference goals and time-slots. I talked to @Geek_Manager afterwards about this and I was very impressed with how much effort the organizers put into choosing the talks for a successful conference.

The CFP response form also asked whether the talk could be 30 minutes or 10 minutes. Since I checked both options, I had the extra suspense of not knowing how long I would be on stage if I were accepted. Though that added to my anxiety, I was glad to have both options available.

In early January, I finally learned that I was accepted to give a 10 minute lightning talk!

Three Months to Prepare

The Long Outline

We had a lot going on at Touchlab in January so “prepare for the conference” was in the “Important but not Urgent” category. Being the first time I’ve done this, I really should have gotten started immediately, but, at the time, putting it off a little later made a lot of sense (see @allspaw).

The urgency came when I found out there was an opening for the February meetup. I got started right away (Feb 4) on an outline which turned into a MUCH longer effort than I planned so @kpgalligan filled in my slot with some KMP updates.

I promised to have things ready for the March meetup — and I did! It was difficult because I had such a long outline. The prep I put into the outline — organizing, researching, reorganizing, more researching, more reorganizing — was invaluable not only for putting together the meetup slides but for sharing knowledge with Touchlabers, and speaking more intelligently with existing clients and prospects. In fact, as a concrete benefit, I published an initial blog post for some of these which got picked up by Hacker Noon!

The Meetup Slides

Even though the outline was so long, it was incredibly useful for speeding up the slide making process. Here’s what I did:

  1. Move the outline 1:1 to slides — copy/pasting line items into slides, batching multiple lines into one slide if that seemed appropriate
  2. Replace outline in slides to more slide-friendly bullet points and move outline to speaker notes
  3. Lower the amount of text on each slide by incorporating graphical representations
  4. Replace outline in speaker notes with natural language

I went through a few iterations of graphics, speaker notes, and slide CRUD. By demoing sections of the slides internally, I could incorporate feedback and iterate towards the following goals:

  • Language sounds natural
  • Individual slides aren’t confusing given what I’m saying at that point or what I’ve said up to that point
  • Individual slides aren’t distracting
  • Organization of slides tells a story
  • The story isn’t more than 30 minutes

Not all the goals were met for the meetup but there was very good progress. Here are the Meetup slides with some transitions removed. The talk came in at about 20 minutes, there were a ton of good questions at the end, I was told the content was good, my ability to present was good, and, most importantly, I felt much more confident afterwards.

The Webinar Slides

This event was a “crazy idea” from marketing. We didn’t know if it made sense or if it would actually happen but from the blog post and the success of the meetup, we knew it could happen.

The meetup slides didn’t include the images from the blog post and our webinar was meant to be more about “How to Evaluate Mobile Multiplatform Solutions” so I worked on editing the Meetup slides to include them and also update the story for a different audience.

I followed essentially the same process as putting together the meetup slides, the big difference being Touchlab’s designers (Nelmer, Frances) gave me some help. They had only a few days to improve my slides and we were all working feverishly until 5 minutes before to integrate designs into the final version. It didn’t all get done, but they did an incredible job, and we knew this wouldn’t be the last time they could help (the real show would be Lead Dev). Next time, I’ll bring design in earlier, much earlier.

The webinar surpassed expectations! We were expecting about 50 people to show up…we had over 100 and 70% stuck around for the entire presentation!

The Lightning Outline

The meetup presentation was about 20 minutes and the webinar was about 30 minutes. I needed to take what I made and learned from both, and bring it down to 10 minutes. Making the meetup 30 minutes from the original outline was difficult enough, so I knew there’d have to be some drastic changes.

So I made a new, hyper-focused outline, the lighting outline and got to work slicing, dicing, mixing, and matching the meetup and webinar slides.

Keeping the technical model from the webinar, the 3 dimensional perspective inspired by the above-the-line/below-the-line framework, and the timeline from the meetup — even after removing all but the most currently relevant solutions (goodbye RoboVM, j2objc, etc) — it was nearly 20 minutes 😩.

The Lightning Slides

In order to make this a 10 minute lightning talk I started thinking of it as a movie trailer. If a 2 hour movie can have a 2 minute trailer, I should be able to bring this down to 10 minutes. Luckily, White October Events has a youtube channel with all of the past Lead Dev recordings. I could use previous lightning talks as inspiration.

I removed the intro to me, Touchlab, and the talk. I removed orienting the audience with what I will talk about. I removed extra details/context for various slides.

This got it down to 13 minutes…nearly there. I experimented with talking faster: down to 10 minutes! OK, but I didn’t want to rush too much. What was left was editing the speaker notes. I removed adverbs, adjectives, combined sentences then simplified them. I was ruthless in prioritizing details and removing the less important ones. Then, finally, I ran through a couple times clocking in under 11 minutes 😅 

Editing down from 30 minutes to 20 didn’t take very long. Editing down from 20 to 13 took a little bit longer. Editing down to 11 took a lot longer because there’s so much that I felt important that I didn’t want to lose and when I made the decision to lose it, I’d read through again and want to bring it back in favor of losing something else.

I knew I couldn’t make it shorter without modifying pacing so that’s what I worked on until the day of the conference. I also found out there would be a clicker and confidence monitors, so I tried to recreate that the best I could too.

One week before the conference, I was about to submit my final slides. But then Touchlab announced partnering with Square and introduced the Kotlin Xcode Plugin. These were both such important news I had to find a way to add them to the slides. I already had one slide where I described what KMP will look like for iOS in the near future so I broke it up into multiple slides to showcase the partnership, the plugin, and a few select multiplatform libraries that are pushing the ecosystem forward. My final lightning slides were finally final and I sent off the email to make it official.

10 Minutes to Speak

After all the prep — the meetup, the webinar, the seemingly endless rounds of practice while editing down to 10 minutes — I was feeling really good. I was still nervous (even writing this, thinking about “the day of” is making my heart race and my hands shake) but I knew it would work.

Thanks to the speaker’s dinner, I got to meet people I’d be sharing the stage with. Talking about stuff other than “the day of” allowed me to relax and, most importantly, understand that everyone else on the stage are also people who get nervous and have to prepare. I could think of them as friends which meant when I walked to the venue the next day, it felt like a reunion.

Because of my prep the weeks before and because of the speaker’s dinner, I was much less nervous. What I was worried about was the execution. Since I used Keynote, I expected the layout, size, animations, graphics would all be fine. But I had never used confidence monitors before and I knew from practice that it’s possible my speaker notes would be too small, I’d get lost in my notes, lose my pacing, and potentially choke (not really, because I did get lost in the Meetup and it was fine, but this was crossing my mind because anxiety is real).

That morning, I saw other speakers running over their talks one last time, I saw them chatting about nothing in particular, and I saw them go to the stage before the audience arrived to become familiar with the setup. So I asked to pull up my slides, I stood on the stage, and flipped through the first few to test the speaker notes. They looked great.

I spent the rest of the time before my talk watching those before me, getting into the feel of the conference, getting wowed at the presentations (while not feeling bad about mine).

And then it was time to mic up. I talked to @lara_hogan, @Geek_Manager, and @samhill303 before the lights dimmed. Then started feeling my hands shake again, but I wasn’t first on stage, so I did some breathing and thinking (sorry @iamagiantnerd for not giving you my full attention).

And then I was on the stage shaking @lara_hogan’s hand. And then I started to talk. And then I noticed I didn’t have the clicker. And then I saw the countdown clock. And then I heard the audience laugh. And then I saw some people look interested. And then I was done.

Closing Thoughts

Speaking in front of so many engineering leaders was amazing and I spent the rest of the day winding down talking to other speakers, audience members, sponsors, and even some potential business partners.

When the recording came online, I was expecting the worst. But other than looking down at my notes a bit too much, I’m actually really proud of how it turned out. Once again, @whiteoctevents did an amazing job with everything.

I know for sure that I have grown in so many ways from this experience and I plan to speak again. The personal benefits of going through this entire journey are immense and I highly recommend giving it a try. I hope writing down my journey helps you on your journey.

Kotlin Xcode Plugin

Kotlin Xcode Plugin

For native mobile developers using Kotlin Multiplatform, the iOS dev experience will be critical. Over the next several months at least, that will be the primary focus of Touchlab’s Kotlin R&D and our collaboration with Square.

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.

Download Plugin Archive Here

 

 

Live Code!

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.

 

App Code?

We are still very much fans of JetBrains tools and look forward to a fully integrated dev experience with AppCode. Check out the blog post about updated support in v2019.1. AppCode has started to ship with an interactive debugger, and we look forward to this product maturing along with Kotlin as a platform.

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 Plugin?

A few years back Apple shut down most plugin functionality for Xcode. However, that mostly applies to executable code that may alter output. Although the Kotlin Plugin goes in the “Plugin” folder, it does nothing prohibited by Apple, so requires no special permissions. You can simply copy the language config files and restart Xcode.

Xcode will ask if you’d like to load the bundle on first run. You’ll need to allow that.

Click “Load Bundle”

 

Status

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.

 

Kotlin Source

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.

 

Next Steps

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.

Also come hear Justin at The Lead Dev NYC!

Touchlab & Square Collaborating on Kotlin Multiplatform

Touchlab & Square Collaborating on Kotlin Multiplatform

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.

Square’s Jesse Wilson recently announced his team’s commitment to Kotlin Multiplatform.

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:

The Case for Kotlin: Risk-Free, Cross-Platform, Future-Friendly… and Ready to Work – Right Now

The Case for Kotlin: Risk-Free, Cross-Platform, Future-Friendly… and Ready to Work – Right Now

It’s madness, really.

An app is written for the Web.

Then, it’s written for Android.

Same app, different code.

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.

Yes, it’s working now!