Netflix Android and iOS Studio Apps now powered by Kotlin Multiplatform

> noticed that they even have some kind of built-in HTTP client abstraction

It goes one step further, you can have platform-neutral code to parse the API returns into Kotlin models.

https://blog.jetbrains.com/kotlin/2020/10/kotlinx-serializat...

A lot of business logic is shared in the domain layer on each platform client (and possibly on the server), and I think re-use of that is/will be Kotlin's main selling point.

Add SQLDelight for shared data access code on clients, and you can cover a lot of ground with one codebase.

What exactly is the value of this though? Isn't most non-UI code going to be buried in your server APIs no matter what? Most apps end up being 90% UI code.

I am really curious to see people's take on Kotlin Native's compiler. From what I can see with Swift compiler development, there are tons of bugs when compiling down a high-level language. Of course, part of these Swift problems can be that the team choose to pursuit performance and low-overhead above everything else (which complicated the implementation quite a bit). But still, I wonder what Kotlin has done differently to make Kotlin Native reasonably cheap to maintain going forward.

Wait, are you suggesting to use http 'internally' meaning within the same process on the device?

+1 I love this question; it doesn't get asked enough. (Also, I have interest in hearing others' answers for Kotlin Multiplatform in particular.)

Mainly depends on the depth of the apps. If they are just UI and API calls then no. If there is a lot of processing snd state management going on then the more there is the quicker it makes sense

> What are the prerequisite knowledge/skills/abilities that a two pizza team needs to keep the learning curve practical?

Just my personal experience, but if you have a good Android/Java "two-pizza team", you probably already have the makings of a good Kotlin team, given the appropriate time for folks to pick it up.

I think it's more a matter of expertise/experience than size. The different platform teams have to have gelled enough to agree on the core architectural abstractions, which is a level of maturity that goes a step beyond necessity.

So the platform teams need to have shared prior knowledge of how to build with the same architectural patterns, and they need to be sold on the possibility and merits of using those same patterns and coordinating on their plans of implementation.

If you know Kotlin already, starting a multiplatform project is pretty easy; it's mostly just Kotlin. I've done a few small things with it. Mostly the sweet spot is doing those things for which multiplatform libraries already exist so you don't have to reinvent wheels.

For a two pizza team, I'd recommend not overthinking it and to just give it a try if it makes sense for you or not if it doesn't. Hard to tell; it all depends on your requirements and how good your people are.

The main reason to use Kotlin is that it looks like Swift and most Android engineers already use it. As an Objective-C and Swift developer I can read C and C++ and dibble a bit in it but to write serious code from scratch: forget it. Kotlin itself feels quite natural, though the Java and Android libraries especially can be a bit weird at times.

> The executions I've seen of this for example often bundle curl + boringSSL for an HTTP/HTTPS stack instead of linking against the system provided networking libraries.

For this reason, I’m hesitant to make use of a shared codebase for the networking parts of an app. By using your own stack, you’re throwing out a ton of device-specific optimizations and risk things like keeping the user’s cell antenna activated for longer than needed or not gracefully handling transitions between connection types.

For most mobile apps, I think the only part that really makes sense to share between platforms are those to do with pure logic and data manipulation, since there’s not as much benefit from doing that full native, and any processing optimizations are typically surfaced in a way that’s accessible to lower level languages (and thus third party stuff like Kotlin Multiplatform).

They also said that less than 50% of the code was shared, which means there is still a lot of platform specific code.

> Almost 50% of the production code in our Android and iOS apps is decoupled from the underlying platform.

We are doing something similar on my project except using the J2OBJC compiler. The compiler is a cumbersome, unwieldy tool, but the cross platform approach overall is great. We write the core logic of our app using the cross platform approach. Platform specific APIs like geolocation or maps get handled natively, but pass their data off as inputs to the cross platform implementation. So for example, you wouldn't render a map natively, but you could write a handler for an updated location from a map, or query the network based on the current map area and return some results.

An added bonus of this approach is that it forces you to have a clear separation between your user interface code, and your business logic. A lot of mobile (and front end) apps out there have no architecture, putting API calls, state management and UI right next to each other in the same modules. Our approach forces you to keep UI code just focused on UI, while keeping all logic somewhere else, where it can isolated and as a benefit much more easily unit tested.

You would be surprised just how large of a share of your codebase can be moved into platform agnostic code if you have a solid architecture. Our UIs are "dumb" and render themselves from view models which have exactly the data needed to render the view. All the logic and state management to construct these view models can be written in the cross platform repo and shared across the Android and iOS apps. For example, to render a list, you will need to use the native UITableView or RecyclerView separately, but all the code that manages how many rows are in the list, the data each row needs, as well as updating the data when the list is reordered can be shared across platforms.

You share as much code as you want in the shared/base project and are able to create "contracts" for each UI platform that are enforced by the compiler.

If you're business logic needs these platform specific functionalities (which will definitely be the case as you've stated) then you can abstract out interfaces and let each platform handle them natively.

From another comment below it seems Kotlin Multilpatform is for multi-platform libraries, not UI!

Flutter is purely a UI toolkit. It takes a rectangle from the OS and draws everything inside, like a game would. It just happens to copy Android/Material design and iOS design. The point is to to provide a reactive UI system. Focus is converting objects to fast 2D drawing.

Kotlin multi platform as described here has no UI system, it’s a way of compiling Kotlin to binaries that are easily linked to both Android and iOS apps, with some bridging back and forth conversions into the native systems in each case. You’ll still need two separate code bases to call the common binary and handle UI.

I took a fairly deep dive looking at Flutter last spring and I was impressed. My work involves semantic web and deep learning, I am not a UI developer professionally, but I enjoy small UI projects.

Try spending one or two evenings with Flutter writing a simple app and build it for two or three platforms to see what the few issues are.

Definitely possible. You can refactor your Android app to be split up into essentially two "modules", one with your business logic and then the UI/native platform specific libraries.

Once you have that setup you can then add a different platform "web/iOS". The base module would have setup certain contracts that new "platforms" would have to implement.

My understanding is that this isn't really the case. Flutter is focused on the user interface portions of an app and Kotlin MP is focused on non-UX portions. Flutter does have some docs on incrementally moving apps at https://flutter.dev/docs/development/add-to-app. This seems early, but with Tim Sneath (experienced with the issues involving moving Microsoft devs between UI frameworks and interop), I suspect that this area will get fleshed out.

What you need to do is analyze your situation and make a decision on whether you have significant non-UX code which will be a bear to maintain long-term. Most people do not, so maintaining a platform-agnostic layer is unrealistic.

To help with this, let's look at an older example: Microsoft. In https://channel9.msdn.com/Events/CPP/C-PP-Con-2014/024-Micro... they describe how they are using C/C++ as the basis for their Office applications. Why? They have a load of legacy code that needs to be reused and they needed the exact behavior on all platforms. This code runs on the client and can't be moved off to the server-side which would be the preference when feasible.

Since iOS and Android can consume C/C++ code it makes sense to maintain as much of the application in C/C++ as possible for sharing while creating native apps which are as thin as reasonable. They can do iOS and Android specific things where it brings value, but centrally, they can decide if it should be something available across all platforms, or even architect it partly in C/C++, and partly in the native API for the mobile platform. This allows them to bring it quickly from Android to iOS in a future release.

Microsoft can easily afford to do everything described above. If we look at Netflix they are in a similar position, but don't have as much legacy C/C++ code. Kotlin MP feels like a nice alternative given Netflix's situation.

Do you feel like you are in a similar situation? Few developers are in this situation, but it's attractive to architecture astronauts. While somewhat unpleasant, duplicating functionality in native iOS and Android code bases might be the right thing for your apps now. If not, there are in-between options such as moving to Flutter for all your UI code and Dart becomes your main client language. You have to be able to live with any compromises (I'm more familiar with Xamarin which is an aging, but similar trade-off.) That seems like one of the better balances today with good momentum behind the platform and strong implementation.

Looking at the current state of things though, they would probably end up writing a bunch of native code anyway because they'll be missing out on a lot of native functionality that their app currently uses, but isn't really fully accessible through best-effort flutter plugins.

You already have at least three paths with Java, Gluon Mobile, Codename One and RoboVM.

Naturally it isn't on Google's and JetBrains interest to talk about them.

It sounds like it's a production tool used by people creating shows; the different studios making 'Netflix shows' are not, to my understanding, actually part of Netflix. They're just partners, so they probably have their own set of hardware already (or yes, are just using personal devices).

Oh, all of those things: https://help.prodicle.com/hc/en-us/articles/115001787672-Wel...

Square has been using it for awhile: https://developer.squareup.com/blog/developing-on-ios-and-an...

Kotlin isn't really a Google project (although they adopted it). It's made by Jetbrains.

Yeah it does seem odd theyre pushing both flutter/dart and jetpack/kotlin, usually more choice is a good thing, but I'm increasingly uncomfortable about the effect on Kotlin if google goes full in on flutter instead

As has been pointed out, Kotlin is not really controlled by Google the way that Flutter is.

Also Kotlin Multiplatform and Flutter are very, very different use cases.

For anyone who isn't aware:

Kotlin Multiplatform lets you share business logic. Think "make a library that can be used on iOS and Android". You still need to write the UI and platform-specific plumbing separately for each.

Flutter includes the UI and can give you apps running on both platforms (and web and desktop, too!) with 100% shared code†.

†In practice, though, you may need to get your hands dirty with platform-native code for functionality not already covered by the plugin ecosystem, though that need diminishes over time.

Bingo. Very few companies have had any form of success in multi platform development tools. Netflix probably will simply because their app logic is generally so incredibly simple compared to others. (View list, select video, play video) sure there’s some complex backend logic and streaming tech but overall the app is simple. $5 says the iOS app isn’t THAT common however.

To be honest, I’m kinda surprised they don’t just go Cordova, one platform for all.

They share a rule evaluation engine and offline SQL store.

Netflix is mentioned everywhere on the website though https://help.prodicle.com/hc/en-us/articles/115001787672-Wel...

How are you using Swift on Android?

C# is really great I've used it for cross-platform desktop applications but there are a lot of mobile developers that don't know it. .net has the nicest libraries in my opinion. If I look at the fights I need to have with Gradle every time.....so many things have already been solved by Microsoft decades ago (WPF with MVVM was really a joy to work with) only to be reinvented later in a bad way by Google.

Are any of the C# ones opensource? Are you using Xamarin Forms for the UI or native UI solutions?

As far as I know not yet. But the way it is build it could be adopted in the future.