Nice to See VMWare Adopting Kotlin Multiplatform

Nice to See VMWare Adopting Kotlin Multiplatform

by | Nov 25, 2019 | Future of mobile, Thoughts

I saw Hadi’s tweet and I couldn’t agree more.

There are more and more (respected and influential) companies experimenting with and talking about Kotlin Multiplatform. Some have put it into production already. 

Personal Thoughts

Here are a few quotes from VMWare’s post and my thoughts:

Experimental Technology

 

Kotlin Multiplatform is still an experimental technology. It’s very early on in its days, and is subject to breaking changes going forward.

There are a lot of people who are afraid of this, but we should remember that Swift was also in that state until version 4, and version 5 was the first to introduce binary stability so binary frameworks would work with future releases of Swift. That didn’t stop people from learning it, experimenting with it, and putting it into production. Because they trusted Apple.

JetBrains has a long history of building developer trust. The Kotlin Multiplatform early adopters trust JetBrains. And, it is again, well deserved. Android Studio is built on IntelliJ and Google made Kotlin the official language of Android starting in 2017. You and VMWare aren’t risking much to experiment with Kotlin Multiplatform now.

 

Library Support

One issue you will most likely encounter with Kotlin Multiplatform, is that the set of libraries that support it are very small at this point

This is true. And that’s why Touchlab is working with Square and developing the xcode-kotlin plugin and making SQLDelight the recommended multiplatform persistence solution (see @joreilly ‘s writeup) and we want to support and elevate community projects when we can, like Multiplatform Settings and more.

And, of course, JetBrains isn’t letting us down on this front. The most recent example is ongoing work to support multithreaded coroutines in Kotlin Native. It’s one of the biggest missing pieces and it’s getting very close to ready.

Leverage Native Android and iOS Libraries

It wasn’t the most elegant solution, but it was better than writing our own version of libphonenumber by a mile (or several).

The interop story is really where Kotlin Multiplatform shines. Other solutions require bridges, channels, JNI on Android, and/or excessive boilerplate. When you run into the “set of libraries” issue above, you can still use existing, battle-tested libraries from the native ecosystems.

This interop story also allows for incremental refactoring that significantly lowers the risk of adopting an “experimental” technology. I wrote about this in some detail in Kotlin Multiplatform Can’t Do It All. Which is Exactly Why You Should Try It!

More to Come

Stay on the lookout for follow up posts where I will talk more about additional features, issues, and how to get the most out of Kotlin Multiplatform

I am very much looking forward to more. And I hope you all are too!

    7 ways to convince your engineering manager to pilot Kotlin Multiplatform

    7 ways to convince your engineering manager to pilot Kotlin Multiplatform

    by | Nov 5, 2019 | Future of mobile, Kotlin Multiplatform

    We hear similar stories when we speak to mobile developers interested in a Kotlin Multiplatform pilot for their team. The story goes something like:

    You’re a developer. You’ve seen the growing momentum that Kotlin Multiplatform (KMP) is gaining in the developer community – especially since Google announced it was officially supporting Kotlin as a development language in 2017.  And now you want to try it for yourself. (Or maybe you already have.) More important, you’d like to try it on a live project, with your colleagues at your workplace.

     

    The question is, how do you convince your manager that it’s a viable framework to use? They already have enough to deal with, right? Hard deadlines, pressure to produce faster, test more thoroughly, improve architecture, deal with tech debt… the to-do’s for them go on and on and on.

     

    If you’re convinced (like we are) that Kotlin Multiplatform is the best option for unified development of business logic across iOS and Android – but are not sure how to broach the subject with your manager — we’ve put together seven key talking points for you.

    1. “One code base. One team.”

    Using Kotlin Multiplatform, we can code business logic across both platforms. That means the team doesn’t have to do the same work twice — once for iOS and once for Android. No duplication. Saves time. Saves money. (And saves a lot of nerves, too.)

    2. “Kotlin itself is skyrocketing.”

    More development teams are using it, and more individual developers want to use it, whether they’re Android or iOS. It doubled in popularity each year since 2015, and after the Google announcement in 2017, it went stratospheric. It’s especially popular among programmers looking to grow their careers. 

    3. “KMP plays nicely with both iOS and Android.”

    One way to think about it: Lexus has the same engine as a Toyota — the only thing that’s different is the exterior. Same with iOS and Android. They’re essentially the same under the UI hood, so it’s very straightforward to deploy to either platform with few if any hiccups. 

    4. “Using KMP is low-risk.”

    It’s not an all-or-nothing proposition. We can do the programming incrementally, one feature or architectural layer at a time, so there’s no disruption to hard deadlines. It’s not a major commitment to pilot a project.”

    5. Our team can focus on innovation as well as  production.

    If we’re only writing the code once for both platforms, it gives us the potential to focus on fine-tuning the architecture, designing more features, or exploring other innovations because we’re not bogged down in production only. Focus on new stuff or focus on testing. Frees up resources to do more stuff…

    6. “Keeping UI separate is a good thing. It ultimately will save us time.”

    KMP doesn’t do UI at all, but that’s actually a real advantage for us. Sharing UI across platforms can be risky because it involves doing multiple reworks and workarounds to make the UI work natively on its respective platform. With KMP, we can focus on the business logic specifically, and leave the UI to be coded separately.

    7.     “With KMP, we’re future-proofing our business logic.”

    Need help piloting KMP? Apply to KMP Hack Week!

    What is Touchlab’s KMP Hack Week?

    We’ve talked to teams who have done their own hack weeks, but they end up spending most of the time just getting set up. Our goal is to get you set up quickly with your KMP pilots. We’ll get the setup sorted on Day One, be available to talk KMP thinking, and help unblock for the rest of the week. We’ll also throw in some mini-lectures on topics that all KMP engineers should know.

    How does Kotlin Multiplatform stack up against other solutions? Our scorecard, explained.

    How does Kotlin Multiplatform stack up against other solutions? Our scorecard, explained.

    by | Aug 30, 2019 | Future of mobile, Kotlin Multiplatform

    In my last article, I explained the reasons why you should try Kotlin Multiplatform — not because it can do everything, but precisely because it can’t.

    It doesn’t do UI, or even attempt to. It does, however, do one thing really well: code business logic for iOs or Android. You code once, and deploy to either platform with virtually no hiccups because you keep the UI separate and native to its respective platform.

    Naturally, introducing a relatively new way of coding immediately draws comparisons to other popular multiplatform solutions. The scorecard with which I concluded the article is meant to be a quick, point-by-point comparative glimpse at the three predominant solutions alongside KMP. Here, I wanted to provide some specifics on why we scored each the way we did.

     UI layer

     

     

    KMP

    Why rate KMP so high on UI when it doesn’t even have a UI layer? Because it doesn’t get in the way of the UI at all. Flutter, RN, and Xamarin all say sharing UI is a benefit to buying into their respective ecosystems — but each have gaps between expectations and reality. When using KMP, you code UI separately, in native, giving you greater control of the outcome for the best user experience possible. 

    Flutter

    Flutter doesn’t enable you to easily use native components to code UI. Instead, it takes control of all rendering, providing either a transparent view that shows the native Android code underneath, or uses PlatformViews which requires fairly clumsy native interop. Either way, it essentially co-opts the entire UI on its own canvas. And if there are bugs, you have to wait for the updates from Flutter. 

    React Native

    While you can create custom native UI widgets with React Native, Javascript performance is still an issue. Often, for example, developers will say it promises 60fps, but it gets in the way of doing good UI. It also hinders development efficiency because its UI widget libraries are not maintained by React Native. 

    Xamarin

    If you have a soft spot for .NET, Xamarin will be usable to you. But Xamarin.Forms has a lot of limitations, and Xamarin itself does not really create that ecosystem of great UIs. You’ll have to make separate UIs in Xamarin, Android as well as Xamarin.iOS, which is a lot more hassle than doing them natively. Similarly, this is why we don’t recommend writing UIKit code in Kotlin Native (even though you can).

    Business logic

    KMP

    For Android, KMP is already as native as it can be. For iOS, it still has some issues with sharing business logic with idiomatic Swift code, but overall, it’s super-fast — and  the native interop means you don’t have bridge channels to deal with. 

    Flutter

    At present, Flutter does not share business logic with native code adequately. The Flutter team is working at integrating it into native apps, but at this point it is still experimental. When you need to integrate native code, you need to communicate across channels, otherwise you have to code it all in Dart — a language that is not widely used or supported. And while the Dart VM is fairly fast, it’s not as fast as a fully native solution. Basically, if you don’t want to deal with interoperability issues, it’s easier to work entirely within Flutter. 

    React Native

    To interop with native, it has to go through the JavaScript interpreter [update: Facebook knows this is a problem and recently released their own JS engine specifically for RN apps]:, so it’s always going to lag behind more native solutions. Also, it’s costly using JavaScript to bridge to native — more costly than Xamarin or Flutter.

    Xamarin

    Essentially, Xamarin presents the same problem as Flutter does: no direct interoperability with native code. You have to use C++, JNI, Java, Kotlin, or Objective-C Bindings. Currently not possible to interop with Swift, you can’t share business logic with non-Xamarin apps at all, and Microsoft has no plans to do this.

    Developer efficiency

    KMP

    Debugging is straightforward with KMP because the debugging tools you’re already using are compatible. Android coders can debug in the Kotlin IDE, and iOS coders can debug in Xcode. In the meantime, as the libraries for Kotlin Multiplatform continue to grow, you’re not locked in — just use the tool that makes sense for that ecosystem. 

    Flutter

    With Flutter, you need a wrapper for its libraries to communicate with native code.You can’t use Xcode for iOS development. And while you can use Android Studio, you’re not really building an Android app with Flutter, you are building a Flutter app and using the Flutter plugins. Essentially, you’re in foreign territory.

    React Native

    Facebook has put a lot of effort into React Native, enabling you to choose from many great debugging tools and IDEs with good integration. It has a large and growing community that stems from the web development ecosystem. Even so, you’re unable to use the native libraries as easily as you can with KMP, so you still need to put work into libraries that haven’t yet been ported and integration with existing apps. And if you aren’t already a web shop, you need to learn the whole ecosystem.

    Xamarin

    To integrate existing native libraries, Xamarin.iOS only supports binding to ObjC Frameworks, and Xamarin.Android requires Java Bindings or the JNI. Sometimes, you can’t bring any new frameworks from native iOS or Android into Xamarin Projects. Additionally, you need to use LLDB or GDB for debugging native code.

    Making the most of multiplatform

    KMP

    With KMP, Android is already fully native, so a bridge is not necessary. And, on iOS, KMP compiles a native framework with Objective-C headers, so, again, a bridge is not necessary. You can easily take a mostly business logic Android library and make it work as a KMP library (even easier if it’s already written in Kotlin). And while the UI has to be separate, it’s not a problem because the UI can then be a very thin layer that’s not dependent on the business logic layer. 

    – Common architecture practices like MVP, MVVM, and CLEAN already encourage separating business logic and thinner UIs.  It’s only a slight modification to accommodate the shared module layer.

    Flutter

    Taking an existing Android library and making it a Flutter library is a whole lot harder than it is when using KMP. Flutter is really designed to be its own self-contained ecosystem. It’s difficult to share with non-Flutter apps. And while sharing the UI is better than it is in React Native or Xamarin, you have to build your own libraries, or write in Dart.

    React Native

    React Native is not ideal for larger apps or larger teams, and even though the developer community is large, it’s mostly made up of web developers, and therefore not necessarily attuned to mobile development fully. There are significant differences — screen sizes, UI expectations, variable device performance due to CPU, RAM, and graphics chips variability, offline and low or unreliable network connectivity, and platform-specific innovations that have been driven by significant engineering investment from Apple, Google, and Samsung.

    Xamarin

    Xamarin has its own ecosystem, with a relatively small developer community, and very limited sharing with other ecosystems. You have to build the UIs in Xamarin.Forms, or you have to build them separately using C# in Xamarin.Android and Xamarin.iOS.

    Potential for code sharing

    KMP

    Even though KMP does not share the UI, which limits how much you can share, you are able to architect the app so that the UI layer is as thin as possible, which in fact is good architecture practice anyway. And it’s also good practice to make the best UI for users, which requires UI divergence between platforms anyway. Using KMP, you won’t run into obstacles when the UIs do need to diverge. And you will more easily be able to share non-UI code with less of a performance cost.

    Flutter

    Flutter provides everything except platform-specific features, which require a channel to native code. So if a library you need already exists in the Flutter ecosystem, great. But if not, you need to create it yourself which essentially requires writing code for three platforms — Android, iOS, and the Flutter Package API to communicate with the platform-specific implementations.

    React Native

    React Native provides everything but platform-specific features or high-performance logic (making it less desirable than Flutter), each of which requires a bridge to native code. If a library you need already exists in its ecosystem, you’re set. If not, like Flutter, you need to create it yourself, which requires writing code for three platforms — Android, iOS, and the React Native Bridge Module.

    Xamarin

    For simple apps, Xamarin.Forms allows you to share close to 100%. But it’s not ideal for more complex apps, where a lot of UI and any platform-specific features need to be separated into Xamarin.iOS and Xamarin.Android projects.

    Maximum app quality 

    KMP

    When coding with KMP, you get fully native UI and business logic, with the same app quality as fully native apps in iOS or Android. 

    Flutter

    While the UI is performant (“buttery smooth” as the Flutter dev-rel people like to say), it’s easy to end up with something that’s perceived as lower quality to seasoned users. Also, Dart VM is fairly fast — much faster than Javascript — but there are still channel overhead issues you must deal with. As well, support for older devices is not robust. For Flutter in particular, the UIs may look modern on older devices, but the performance may be worse than native UI and implementation.

    React Native

    On the positive side, React Native architecture encourages native views and widgets, so you don’t fall behind platform UX updates. (Users expect these; otherwise, apps start to look old to them.) There is, however, a higher risk of lower performance because of Javascript (especially true on Android devices where standard Javascript is about as performance as an iPhone 6s and Facebook recently releases their own engine specifically for RN apps on Android).

    Xamarin

    For Xamarin, UI is really an afterthought. Xamarin.Forms has been getting more attention recently, but even when incorporating native widgets, you end up writing a full app in Xamarin.iOS and Xamarin.Android before getting something that modern users would generally accept as good quality.As for performance, it is true, the MonoVM is fairly fast, but there are still bridging overhead issues.

    Kotlin Multiplatform Can’t Do It All. Which is Exactly Why You Should Try It!

    Kotlin Multiplatform Can’t Do It All. Which is Exactly Why You Should Try It!

    by | Aug 15, 2019 | Future of mobile, Kotlin Multiplatform

    Before I begin, I want to be clear that all tools are created to solve problems, but none of them solve all problems. If your development team is in a hurry, or high-quality UI is not a major priority, go ahead and choose an ‘end-to-end’ development platform like Xamarin or Flutter or React Native to code your app for Android and iOS. You’ll get the job done 🎉!

    Now, if you already have UIs for your apps, or if you want optimized UI for each platform, you’ll want to use Kotlin Multiplatform. The reason? It doesn’t do UI at all (not yet, anyway). But what it does do — and really well — is business logic for Android and iOS apps. 

    Though the other multiplatform solutions aspire to support all application layers, they can’t adequately cover them all.

    And sharing UI code across platforms is not necessarily desirable anyway. Very often when this is done, there will need to be multiple iterations to make the UI look and behave more natively. This will burn through development cycles, putting more pressure on your dev teams to deliver on time. And normally, the business is pushing for more features over UI quality. Sharing UI is risky, and it’s rarely good for morale, or for business.

     

    Unlike Xamarin, Flutter or React Native, Kotlin Multiplatform does not live within its own ecosystem. Instead, it is very much like a “choose your own adventure” book, which is what makes it so powerful.

    While KMP currently has limited libraries (though the number is growing), it does enable you to use all existing libraries and tools on iOS and Android, so there’s no need to wait for libraries or implement hacks and workarounds. You can’t do that with Flutter or React Native without running into sizable obstacles.

    The output from Kotlin Multiplatform is just another package on Android and framework on iOS. That can save a significant amount of time and headaches because there is far less time spent writing bridge code or fully re-writing the things that are missing from other solutions. 

    To code business logic in Flutter, your team first has to code shared logic in a language that is not widely used – Dart – in a new ecosystem, with a smaller community, and difficulty bridging it with existing code. In React Native, your mobile team would need to immerse themselves in the web ecosystem of JavaScript’s new IDEs and other tools . And in Xamarin, they’d have to code in C# , use Visual Studio, and a smaller, less active community. To make matters worse, whichever of these platforms your team uses, they’ll need a communication bridge between native and non-native code. 

    In Kotlin Multiplatform, however, your team can code the platform-specific business logic, with direct communication with the native platform, with no need to wait for libraries or implement hacks or workarounds.

    (You can if you want, that’s part of the adventure you choose.) And even if there are any issues, optional sharing with Kotlin Multiplatform means you only need to revert the code directly related to the issue — no ripping out the whole engine because of a bad spark plug. So, you always have choices. 

    This is important of course, because it’s the business logic that determines how all features within an app will work. Because you’re writing the native code once for this layer, you accelerate development time and help ensure a solid code base. Plus, writing one set of native code is a highly effective way of future-proofing the code for later releases.

    Kotlin Multiplatform, in other words, provides your dev teams with greater flexibility.

    The other multiplatform solutions are essentially proprietary, resulting in vendor lock-in. It also results in the need to manage, in effect, a third platform because the ecosystems are too different from the native platforms and, because they try to solve everything but they can’t solve everything, you will need to write more platform specific code than advertised.

    Unlike Xamarin and React Native, Kotlin Multiplatform doesn’t require a VM. Flutter doesn’t require a VM in production, but it does put you in a non-native ecosystem writing in a non-native language unlike Kotlin Multiplatform which respects the native languages and ecosystems of each platform. Kotlin Multiplatform is the most native multiplatform solution your team can use today. 

    KMP doesn’t hide the fact that you’re dealing with multiple platforms because it already compiles to a native library for iOS or Android.

    There are no intermediate layers to deal with, virtually eliminating any interop bottlenecks. And since Kotlin Multiplatform works with the native platform ecosystems rather than becoming its own, devs can use the tools and libraries they’ve always used including new platform innovations like SwiftUI and Jetpack Compose. Limitations you do encounter are not dead ends because you can always code around them with Kotlin, Swift, or whatever language lets you solve the issue with the least risk.

    In sum, here’s how we measure the world of multiplatform solutions. Next week, we’ll share more details about the specifics of our rankings. In the meantime, if you’re interested in speaking to us about Kotlin Multiplatform, please contact us.

     

    Measure multiple cross-platform development solutions

    A First Time Speaker’s Journey from CFP to Stage

    A First Time Speaker’s Journey from CFP to Stage

    by | May 23, 2019 | Meetup talks, Thoughts

    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.