JUSTIN: Thank you, everybody.
I only have ten minutes, so I'm gonna get right into it.
Oh, I need to have this.
See, it's my first time.
So I forgot to have this.
People have been searching for the Holy Grail of cross-platform tools for a long time.
Because if you had one, your developers wouldn't repeat themselves, your apps would have more
features in less time, you would fix a bug on one platform and it would be fixed on all
the others, and not only would your users be happy to get more features and bug fixes
faster for cheaper, but you would be able to include more users who are on a platform
because of personal socio-economic or accessibility reasons.
The elephants in the room are telling you that the performance is going to be worse.
Innovation is going to suffer.
The UI will be full of compromises.
And that this is a big decision that's gonna be costly to revert if anything goes wrong.
It's time to leave the cross-platform baggage behind and learn about multiplatform.
A lot of blog posts and marketing material talk about apps as either "web native" or
"hybrid".
Basecamp in their blog illustrates that they mix web and native tech to skew the app towards
the native side.
But I wanted to go deeper.
So I looked for academic material, and I found actually quite a few.
I was surprised by how many I found.
I simplified that, and I organized it into this model.
The input step is how the developer is writing their app.
The process step is what the build chain does to the input, in order to create an output.
The output determines the type of app generated.
I analyzed many multiplatform solutions, and I'm gonna show you some of the more popular
ones.
With Ionic, you write your app with standard web technologies.
The runtime includes your web views and plugins, and everything is wrapped in a native container
and you get your hybrid app.
Hybrid solutions promise to make things easy, but you need to work really hard to make a
hybrid app meet native expectations.
React native makes React, which worked well on web, and makes it work on hybrid apps.
The runtime provides widget and all the React magic that they're really good at, and the
native code is output at runtime by JavaScript core.
With Xamarin, you write your code in C#. IOS doesn't allow third party execution engines,
but on Android, it can just in time compile to native code at runtime, and that makes
it slightly more native on iOS than it is on Android.
With Flutter, you're still writing in a foreign language.
This time Dart.
But for production builds, it will compile all the necessary runtime libraries for widget
rendering and business logic directly to native code ahead of time on both of the platforms.
So Flutter is a bit more native than Xamarin.
Kotlin Multiplatform is the most native solution yet.
It's also the least risky choice.
On mobile, it's not a costly decision.
In React native, it's difficult to integrate with non-React native apps.
Xamarin, it's impossible to integrate with non-Xamarin apps, and Flutter is still in
the early stages of learning to play nice with others.
On Android, Kotlin has been the best way to build fully native apps for the last several
years.
Kotlin multiplatform on iOS compiles to standard Objective-C format, so it can integrate natively,
and as a bonus, it outputs to JavaScript and web assembly for integration with webapps.
So now we can revisit this spectrum with a little more context.
Xamarin is more native on iOS than Android.
React native runs in the JavaScript core interpreter on both platforms.
Flutter is native on both platforms by the current definition, and I'll refine that next.
Progressive webapps usher in platform-supported hybrid apps, so you don't need to use Cordova
anymore, while web assembly ushers in native code for the web, and it's not just for the
web, which is very interesting.
Kotlin Multiplatform spans this whole spectrum.
I was inspired by the Stellar report to refine my definition of native.
In terms of multiplatform app development, there are the makers and the managers, the
tools to get the job done, and the platform provided services and implementations.
Let's not forget the users.
In this model, we have to ask some new questions for each multiplatform solution.
Are the developers using first class tools for their platform's ecosystem?
Can the app take full advantage of what the platform provides?
And do the generated apps meet user expectations?
Now, it is possible to build a bad app, whether you use the tools that come with the platform
or not.
But if a solution makes it difficult or impossible to use the platform provided UI tools, then
meeting user expectations takes more effort and it becomes more risky.
The web is interesting because dev tools are changing constantly.
Each browser is essentially another web platform, though those are converging these days.
And users have come to expect the unexpected on web.
React started on the web, and even though it's still early days for React native on
web, it does exist and ticks all the boxes.
For a technology that didn't start on the web, Kotlin Multiplatform is doing better
than the rest.
Since Google owns Flutter and Android, Flutter is gaining traction on Android.
But Kotlin Multiplatform is the one that ticks the boxes here.
On iOS, Flutter loses much of its charm.
But Kotlin Multiplatform, although it is slightly foreign to iOS developers right now, it generally
fits into the native iOS development experience.
And it keeps getting better for iOS developers.
This is one of the big reasons that Touchlab and Square are working together.
We're working on xcode integration.
Touchlab is helping with that, and high quality platforms are being created by the community
at large.
So shared code is the history of computing.
Early on, platforms were mainly defined by their hardware architecture, and the best
multiplatform solutions during this era were fully native multiplatform solutions.
They either cross compiled or they transcompiled or they were tools that allowed you to use
the -- develop better for all of these platforms.
In the '80s, the cheap personal computers and servers began converging on Mac, Windows,
and UNIX flavors.
I'm gonna skip over the details of operating systems, desk tops, and servers, but the multiplatform
tools here did need to cater to different UIs and APIs of the operating system now.
The web has always promised to be the platform-independent platform.
But the many browsers and their many quirks have been an obstacle in that area.
Partially native solutions like Java and Flash have tried to fix that.
You all remember Java Applets and Flash applications on the web.
When announcing the iPhone, Steve Jobs used the term "baby internet" for what mobile devices
could support before the iPhone.
And "desktop class applications" for what they could support with the iPhone.
Responsive web set the stage for better hybrid solutions going towards more desktop class
applications on the web.
And V8 set the stage for partially native JavaScript solutions, which made the web faster
on your desktop.
It also allowed JavaScript to be on the server now, and be performant there.
In the modern era, we see fully native solutions making a comeback.
And that's because, to get the benefits of multiplatform without the costs, the solutions
must be more native.
So while Kotlin Multiplatform is not perfect, and let's be completely honest -- you are
an early adopter if you start now -- except on Android, where Kotlin is first class...
It does have the benefits you're looking for.
And it is significantly improving upon the things that you worry about.
It provides native performance, native interop allows you to keep up with platform-specific
innovations, and you can spend high value time and effort developing the best user experience
possible with the native UI tools and libraries.
On mobile, you don't need to leave the worlds of Android Studio, Xcode, Kotlin, or Swift.
And on the web, JavaScript isn't going away.
Web assembly is maturing, and Kotlin Multiplatform supports both.
So you aren't locked into a foreign ecosystem.
Before I leave the stage, I want to give you some homework.
Lots of people are talking about Kotlin Multiplatform.
Go find them at YouTube and conferences like this.
It is an Open Source platform.
So dig as deep as you like.
The community is growing and very supportive.
So join in on the conversation.
And of course, Touchlab is on the front lines, and we're happy to chat about it.
Thank you so much.
(applause)