Netflix Android and iOS Studio Apps now powered by Kotlin Multiplatform(netflixtechblog.com)
netflixtechblog.com
Netflix Android and iOS Studio Apps now powered by Kotlin Multiplatform
https://netflixtechblog.com/netflix-android-and-ios-studio-apps-kotlin-multiplatform-d6d4d8d25d23
112 コメント
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.
that’s not true at all. especially for apps like netflix or youtube, but even average apps
source: have worked on apps you likely use every day
source: have worked on apps you likely use every day
I've worked on plenty of small to mid-size apps and that's not how we ever do it. Like I said, we build views and API requests. That's just the same MVC framework for the past decade or so. And I've done the same for streaming services albeit not at the scale of Netflix. Given how apps like Netflix and YouTube are so nicely synced between mobile, web and STBs I'd still imagine all the logic and persistence is server-side. I can only speak from my experience though, I'd love to understand how you've done it and when you need to embed a lot of non-UI code in a client.
Both Netflix and Youtube (premium) can be used completely offline. I would guess that the iOS and Android apps have a pretty encompassing local data model to keep track of everything from watched status to settings changed in the preferences. Not to say that it isn't synced with the server, but the server isn't the only representation.
most MVC apps do still have a decent amount of business logic for things like caching (either http responses, or images, or a local db), authentication etc.. In theory the goal for a lot is to have a dumb client like you said but that's rarely the case.
If you can have your apps share their data models between both android and iOS you can have the apps share the HTTP request/response handling and their DB code etc and then it truly becomes just a dumb client.
YouTube/Netflix also have complex video encoding/playback code that can be written in c++ and shared between clients.
Most social media apps liek FB/Insta/Snapchat have complex camera and photo handling code as well as async messaging code. Which if you have things like retries or photo compression/encryption you'd probably want to share between clients. etc..
If you can have your apps share their data models between both android and iOS you can have the apps share the HTTP request/response handling and their DB code etc and then it truly becomes just a dumb client.
YouTube/Netflix also have complex video encoding/playback code that can be written in c++ and shared between clients.
Most social media apps liek FB/Insta/Snapchat have complex camera and photo handling code as well as async messaging code. Which if you have things like retries or photo compression/encryption you'd probably want to share between clients. etc..
Let’s say you’re creating a presentation builder app and one of the requirements is that it work in airplane mode since people are likely to use the app to put together presentations while literally on an airplane. Having all the logic server-side simply doesn’t work for that use case.
Sounds more like you've never written an app.
But put logic aside being able to use the same programing language across platform eliminate a lot of the context switching.
But put logic aside being able to use the same programing language across platform eliminate a lot of the context switching.
> Isn't most non-UI code going to be buried in your server APIs no matter what?
As someone who has had to maintain apps across web, iOS and Android, the answer to that is most definitely no.
As someone who has had to maintain apps across web, iOS and Android, the answer to that is most definitely no.
I don't get it. If you're sharing logic across web and mobile doesn't that demand moving as much work as possible to the server? I've built a plenty of web and mobile apps and that's how I've always done it. Maybe I'm not thinking of the kind of tasks you're talking about. Can you give an example of what kind of process would need to be run on device that's independent of UI?
Giving a good experience with poor connectivity means the clients need to be able to reason about updates to the domain model and potential conflicts. At this point they need to reason about almost as much as the server.
Search for "offline first" to see how people are exploring architectures like this.
Edit: source: I worked on a product bundling chat functionality as a plug in.
In fairness, I think this is not so relevant for apps which are consumption first, but if there's any kind of collaboration, or even just writing from the client, you want to show an optimistic (at least; some systems make the client state canonical) representation regardless of sync status.
Search for "offline first" to see how people are exploring architectures like this.
Edit: source: I worked on a product bundling chat functionality as a plug in.
In fairness, I think this is not so relevant for apps which are consumption first, but if there's any kind of collaboration, or even just writing from the client, you want to show an optimistic (at least; some systems make the client state canonical) representation regardless of sync status.
Some use cases I think about off the top of my head:
- Data model operations on local copy of data: For some use cases you can't just send everything to the server all the time, instead you want a local representation which is periodically synced with the server
- Logging / monitoring: Expose a single logging / monitoring API which can be shared across platforms
- Input validation / rules engine: Consider implementing a syntax highlighter, you wouldn't want to do that on the backend. Even simple form validation might sometimes be preferable to do client side, calling the multiplatform validate(data_model) and getting per-field validation back would allow for a lot of logic re-use.
- Do work that could be done on the server: Because of a lot of factors, like privacy or cost you might want to do work that could be done on the server. I.e, calling some sensitive third party API (banking?) where you have to transform requests/responses. Or maybe computation on large sets of data (video compression?) which otherwise would need to be sent to the backend.
- Interact with devices only locally accessible: IoT/bluetooth things
- Data model operations on local copy of data: For some use cases you can't just send everything to the server all the time, instead you want a local representation which is periodically synced with the server
- Logging / monitoring: Expose a single logging / monitoring API which can be shared across platforms
- Input validation / rules engine: Consider implementing a syntax highlighter, you wouldn't want to do that on the backend. Even simple form validation might sometimes be preferable to do client side, calling the multiplatform validate(data_model) and getting per-field validation back would allow for a lot of logic re-use.
- Do work that could be done on the server: Because of a lot of factors, like privacy or cost you might want to do work that could be done on the server. I.e, calling some sensitive third party API (banking?) where you have to transform requests/responses. Or maybe computation on large sets of data (video compression?) which otherwise would need to be sent to the backend.
- Interact with devices only locally accessible: IoT/bluetooth things
You end up duplicating the logic achieve to offline-first, and reduce network roundtrips. Eg your sign up page final validation is probably the server's job, but if you want to give earlier/faster failure messages, you'll want it on the frontend too.
Server authoratative validation is security; frontend validation is UX
Server authoratative validation is security; frontend validation is UX
If you're moving most of logic to the server, why have an app at all? Just build a website. For me app means offline work.
Mobile apps often achieve better conversion rates than mobile websites - at least for e-commerce.
If it's only the reason why build app, it looks like providing WebView wrapper based app is just fine.
Authentication and identity management comes to mind immediately.
But, of course, there are plenty apps that prefer to do things locally, for so many reasons - if Spotify downloads songs, it does so locally. Or a note taking app such as Evernote needs to capture and compress whatever was drawn on the screen. Not to mention games!
If you think about more than CRUD apps, you’ll see that there are plenty things to be run on the device which are independent of UI.
But, of course, there are plenty apps that prefer to do things locally, for so many reasons - if Spotify downloads songs, it does so locally. Or a note taking app such as Evernote needs to capture and compress whatever was drawn on the screen. Not to mention games!
If you think about more than CRUD apps, you’ll see that there are plenty things to be run on the device which are independent of UI.
They literally say in the article that 50% of their code is decoupled from the platform.
Wait, are you suggesting to use http 'internally' meaning within the same process on the device?
No. Internal as in to “your” backend API’s.
> 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.
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.
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.
I believe kotlin does not persuit performance and low overhead. But given that there are multiple variants of kotlin compilers (js, jvm, native) I think it will be a lot of work to maintain that, any behaviour need to be done in three places. Assuming that JetBrains can make some money from the Tools they sell, kotlin is probably in the right hands. May be good also have some vested interest for Kotlin to suceed.
fyi Jetbrains is combining the js, jvm, and native compiler pipelines. All three will use the IR infrastructure currently used by kotlin/native.
Does anyone know how far down Kotlin Multiplatform is likely to scale, because most engineering org charts are not the shape and quality of Netflix's engineering org chart?
At what size and level of expertise/experience does it make sense to consider it?
What are the prerequisite knowledge/skills/abilities that a two pizza team needs to keep the learning curve practical?
At what size and level of expertise/experience does it make sense to consider it?
What are the prerequisite knowledge/skills/abilities that a two pizza team needs to keep the learning curve practical?
> 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.
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.
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.
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.
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.
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.
Exactly - the team from the article went with a shared architecture from the start. They set themselves up to make this kind of thing possible.
I mention size because it tends to correlate with institutional experience and availability of relevant expertise in the org chart.
+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
Can anyone comment on whether Kotlin Multiplatform could be used instead of Flutter if the goal is write once for both iOS and Android? I am excited about porting my Android apps to Kotlin from Java and then having a path to iOS, as opposed to rewriting the entire thing in Flutter. Is that possible?
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.
Naturally it isn't on Google's and JetBrains interest to talk about them.
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.
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.
[deleted]
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.
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.
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.
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.
This is for an internal app, makes sense that it worked out well for them because the internal app is mostly a greenfield project. Some resume padding and performance review check offs for those associated with the project, however this Kotlin Multiplatform is NOT stable enough for most large scale applications.
For starters good luck turning on / off features, handling UI state, and tying in the business logic to that state. And good luck mangling dependencies and build times with a new added Kotlin dependency :-)
For starters good luck turning on / off features, handling UI state, and tying in the business logic to that state. And good luck mangling dependencies and build times with a new added Kotlin dependency :-)
I've always felt that JS could have been the language for shared mobile & server business logic. Write a throwaway script in a light, fast interpreted language, and then share it with your compiled, native platform-specific UI code. If you need to update that one script, the app can phone home and get the latest. No need to update the entire app.
That's how I wrote multiplatform code 7 years ago, using hidden webviews in the background.
Unfortunately, Android or iOS to this day have not supported JS (or really Node/V8) as a first-class citizen. The best approach is still just to use webview, which has a performance cost, amongst other complexities.
Time will tell if Kotlin Multiplatform is light enough and has the minimum number dependencies to warrant its inclusion in mainstream, high-traffic applications.
That's how I wrote multiplatform code 7 years ago, using hidden webviews in the background.
Unfortunately, Android or iOS to this day have not supported JS (or really Node/V8) as a first-class citizen. The best approach is still just to use webview, which has a performance cost, amongst other complexities.
Time will tell if Kotlin Multiplatform is light enough and has the minimum number dependencies to warrant its inclusion in mainstream, high-traffic applications.
Square has been using it for awhile: https://developer.squareup.com/blog/developing-on-ios-and-an...
My experience is that the development speed suffers a bit when you need to handle more than one code base and it also more difficult to test because the UI depends on the business logic but now they are separate and used by 2 different UI code bases
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.
To be honest, I’m kinda surprised they don’t just go Cordova, one platform for all.
> Cordova
It's usually pretty easy to tell Cordova apps from native apps. The quality is wildly different and they tend to "feel" wrong, even to users who aren't super technical.
I would never recommend that route unless you're on a shoestring (<$10k) budget.
Even then I'd recommend Flutter first.
It's usually pretty easy to tell Cordova apps from native apps. The quality is wildly different and they tend to "feel" wrong, even to users who aren't super technical.
I would never recommend that route unless you're on a shoestring (<$10k) budget.
Even then I'd recommend Flutter first.
This is a myth, repeating it amplify it but doesn't make it more true.
Moreover Cordova is outdated and you should compare the current state of the art which is Ionic/Capacitor.
Contrary to flutter it doesn't feel wrong and actually doesn't have big performance issues contrary to the former.
The fastest 2D renderer (skia) is made for chromium and second class citizen such as flutter are doomed to be inferior, plus their human resources are lacking. Example of an not so old, non production-ready issue:
https://github.com/flutter/flutter/issues/31138
It isn't a myth. I've seen examples of recently created Cordova apps that feel like broken web pages, not real mobile applications.
I suppose it would be possible to make one that isn't bad, but that seems like more effort than just making a native app in the first place.
It seems weird to say Cordova being a poor experience is a myth and then to say Flutter will always be bad. Flutter is already lightyears ahead of Cordova.
I don't know anyone shipping Capacitor projects, so can't really compare that.
I suppose it would be possible to make one that isn't bad, but that seems like more effort than just making a native app in the first place.
It seems weird to say Cordova being a poor experience is a myth and then to say Flutter will always be bad. Flutter is already lightyears ahead of Cordova.
I don't know anyone shipping Capacitor projects, so can't really compare that.
> I don't know anyone shipping Capacitor projects, so can't really compare that.
as someone who was tasked with porting a cordova app to native (android), i can second this opinion (as a dev and user)
edit: sorry, i mistook "capacitor" or "cordova" (^_^;)
as someone who was tasked with porting a cordova app to native (android), i can second this opinion (as a dev and user)
edit: sorry, i mistook "capacitor" or "cordova" (^_^;)
This isn't the Netflix app. It's this: https://help.prodicle.com/hc/en-us
Yeah, often is easier to just have a good requirements doc and have iOS and Android team + qa make sure it is adhering.
> Even after a considerable amount of work, it still suffers from memory leaks in some concurrent execution scenarios, and we don’t have a clear solution to address them.
https://blog.jetbrains.com/kotlin/2020/07/kotlin-native-memo...
Why is this not a problem for Netflix?
https://blog.jetbrains.com/kotlin/2020/07/kotlin-native-memo...
Why is this not a problem for Netflix?
I fucking hate deep linking on iOS. That opens the medium app and nothing useful in it.
Will jetpack compose be able to make cross-platform the UI code too?
As far as I know not yet. But the way it is build it could be adopted in the future.
I am doing something similar for my apps but instead of using Kotlin I am writing it in either Swift or C#
How are you using Swift on Android?
There are several ways to use Swift on Android. It's basically Swift <-> C interface <-JNI-> Java. The following links could be a good starting point for Swift on Android.
[^1] https://github.com/apple/swift/blob/main/docs/Android.md
[^2] https://github.com/readdle/swift-android-toolchain
[^1] https://github.com/apple/swift/blob/main/docs/Android.md
[^2] https://github.com/readdle/swift-android-toolchain
Would you really use a JNI bridge and end up with a possibly heavier codebase? Swift for Android isn't officially supported by Android yet. I'd rather use Kotlin Multiplatform instead.
Sounds messy. You’d have to manually define the JNI calls on both sides if I’m reading correctly?
Good to know it’s possible though. Just maybe with more tooling...
Good to know it’s possible though. Just maybe with more tooling...
JNI is so expensive when cross the language barrier, you have to be conscious to constantly minimize your API exposure. This may be helpful in long-term, but not helpful for onboarding purposes.
On the other hand, if you can lower Kotlin to native code, it may be more natural to interact with (of course, there are still these nonsense of Java's default UTF-16 string <-> Swift's native UTF-8 string conversion).
Interoperability between high level languages are just hard. I am skeptical of either way, but I can see how it is more appealing to go from Kotlin to Swift direction.
On the other hand, data modeling and high-level data transformation doesn't require all language features. It is possible to do such with a limited DSL that supports product / sum types, some filter / map / flatmap / zip, and boom, you now have your view models for UI rendering. As long as we've made up our mind on string UTF-16 / 8 or have some performant library to do lazy transformation on these. We can go a long way on standardize business logic cross iOS / Android platform.
On the other hand, if you can lower Kotlin to native code, it may be more natural to interact with (of course, there are still these nonsense of Java's default UTF-16 string <-> Swift's native UTF-8 string conversion).
Interoperability between high level languages are just hard. I am skeptical of either way, but I can see how it is more appealing to go from Kotlin to Swift direction.
On the other hand, data modeling and high-level data transformation doesn't require all language features. It is possible to do such with a limited DSL that supports product / sum types, some filter / map / flatmap / zip, and boom, you now have your view models for UI rendering. As long as we've made up our mind on string UTF-16 / 8 or have some performant library to do lazy transformation on these. We can go a long way on standardize business logic cross iOS / Android platform.
Java is replacing JNI with Panama efforts, but don't expect that to come to Android.
In fact, in 10 years Google has never made available their internal tools that simplify JNI integration, leaving the community on their own to create our tools.
In fact, in 10 years Google has never made available their internal tools that simplify JNI integration, leaving the community on their own to create our tools.
I am using the Elements compiler (supports Swift, Go, Visual Basic, C#, Java and Object Pascal) that allows sharing business logic and write UI code separately in the appropriate platform's tool.
[deleted]
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?
This is a big move! I haven't seen many people use Kotlin Multiplatform for mobile app dev. Personally, never trusted Google due to their inability to stick with one technology. They have Kotlin Multiplatform and Flutter both for cross platform development. But Netflix's strategy might just encourage others to adopt too.
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.
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.
Flutter is more controlled by Ad Words team than Google as a whole, without it there wouldn't exist any Dart.
Kotlin isn't really a Google project (although they adopted it). It's made by Jetbrains.
Long term given the lack of motivation to support modern Java on Android, Kotlin will be tied to Android anyway as it will need to choose how much Java/JVM it can support and still be the Google loved child for future Android development.
Kotlin has many full time paid compiler developers by Google
Do you have a source for this? I develop a plug-in for JetBrains IDEs professionally, I talk a lot to people there and I’ve never heard this.
Just look at the paid members of the kotlin foundation:
(Ctrl find Google)
https://kotlinlang.org/foundation/kotlin-foundation.html#kot...
https://github.com/jsjeon is probably the most prolific one as I often see him in the commit history.
BTW which plugin are you working on?
https://github.com/jsjeon is probably the most prolific one as I often see him in the commit history.
BTW which plugin are you working on?
But if you look at the contributor history for the repo, he's at #54, just after JetBrains' actual CEO. I don't think you could make the claim that Google contribute significantly to the language itself based off that.
I develop https://cursive-ide.com.
I develop https://cursive-ide.com.
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
I wouldn't be too worried. I mean I think it's possible but I feel like it's a while away.
As a native Android dev, my arm-chair hypothesis is that currently both of those (kotlin, flutter) are targeting different developers and until either one starts including the other developers then I don't see any one winning over.
Kotlin - loved by native devs Flutter/Dart - web devs (previous experience with JS)
*I'm biased as a Native android dev but from my experience this is the case. Also Kotlin is really a great/fun(ctional)/expressive language
As a native Android dev, my arm-chair hypothesis is that currently both of those (kotlin, flutter) are targeting different developers and until either one starts including the other developers then I don't see any one winning over.
Kotlin - loved by native devs Flutter/Dart - web devs (previous experience with JS)
*I'm biased as a Native android dev but from my experience this is the case. Also Kotlin is really a great/fun(ctional)/expressive language
Flutter has been a Ad Words team all along, go watch Android Fireside sessions at past Google IO to watch the teams political correct answers when asked about their opinion related to Flutter.
Google is currently designing jetpack compose which is their latest UI framework and is in Kotlin, I don't see them dropping such a wonderful language.
Flutter on the other hands might just disappear
The blog post reads like a high level overview and skips the real engineering behind the scenes. I wonder how they'll integrate native functionalities like geolocation/audio-video/maps etc which are highly platform specefic.
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.
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.
This approach is also great for testing. We use rust for parts of our mobile apps. If we were to do it again the rust part would be way larger.
I've tried to use rust on mobile apps, but type conversion & manual memory management does make using it really hard and unappealing. Did you find a better way using rust that mitigate theses kinds of problems ?
It all depends on your integration point and use case. The extra interopability work has to pay for itself. One possible trick is to use a message passing architecture and pass json/protobuf messages between the code bases.
Some companies also use lots of ffi code generation tools.
Some companies also use lots of ffi code generation tools.
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.
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.
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.
> Almost 50% of the production code in our Android and iOS apps is decoupled from the underlying platform.
With Apple, you can never expect them to expose platform specific APIs to other languages and frameworks outside their ecosystem.
> Netflix has been developing a mobile app called Prodicle to innovate in the physical production of TV shows and movies
I assume this has nothing todo with video as its on a phone, but does anyone in the TV business know what this app actually does or could do - time management/planning/todo/contacts/legal/safety guidelines repository etc?
I assume this has nothing todo with video as its on a phone, but does anyone in the TV business know what this app actually does or could do - time management/planning/todo/contacts/legal/safety guidelines repository etc?
Oh, all of those things:
https://help.prodicle.com/hc/en-us/articles/115001787672-Wel...
I am very unconvinced by cross platform UI solutions, as such I like the idea of Kotlin Multiplatform. Sharing non UI code has always been possible via C/C++, but it suffers from several issues not the least of which is having to write C/C++. 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.
Aside from Kotlin I also think Rust with C FFI or WASM are good potential avenues to explore here. In the WASM case generic business logic can be written in Rust and compiled to WASM, platform capabilities such as networking/GPS etc can be exposed to the WASM VM via functions provided by the host. Further, with WASM it would also be possible to run the same code across web, native clients, and the server.
Aside from Kotlin I also think Rust with C FFI or WASM are good potential avenues to explore here. In the WASM case generic business logic can be written in Rust and compiled to WASM, platform capabilities such as networking/GPS etc can be exposed to the WASM VM via functions provided by the host. Further, with WASM it would also be possible to run the same code across web, native clients, and the server.
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.
Yeah that’s definitely a strength of Kotlin multi platform. My general point is that doing cross platform UI specifically leads to poor experiences, whereas sharing non UI code doesn’t have that issue
Why would ionic leads to poor experiences?
Cross platform solutions all share several issues that result in poor experiences:
Reimplementing platform UI
Poor reimplementaions of platform UI, such as navigation, that almost always looks subtley wrong or doesn't "feel" right in terms of interactivity. This also often lead to shipping a single platform's UI convention on every platform, for example Material on iOS or iOS patterns and conventions on Android.
Poor UX
An app's UI is more than just how it looks, just as important is how it feels, and if it fits in and feels at home as an app on the platform. Often cross platform solutions generate apps that have slightly "off" UX, such as sluggish interactivity(RN has this this issue), missing gestures(such as backswipe). In general many small cuts that deterioriate the user experience
Focus only on the visual
The visual representation of an app is only one part of the UI as mentioned above, an obvious other example is accessibility which is often lacking with cross platform tech, especially on iOS. I wrote a whole blog post about how Flutter Web fails[0] in this regard yesterday.
Binary size
By necessity cross platform solutions reinvent a lot of what the platform already provides which leads to larger binaries(performance is a feature).
Performance
Ionic for example, runs in a non-JIT(on iOS) enabled webview so can never match the performance of native. React Native runs a JS enging(again no JIT on iOS) which demands more from the device and uses more battery than native in my experience(performance is a feature).
In general, cross platform UI works by targetting a lowest common denominator of the platforms which naturally results in a worse experience.
0: https://hugotunius.se/2020/10/31/flutter-web-a-fractal-of-ba...
Reimplementing platform UI
Poor reimplementaions of platform UI, such as navigation, that almost always looks subtley wrong or doesn't "feel" right in terms of interactivity. This also often lead to shipping a single platform's UI convention on every platform, for example Material on iOS or iOS patterns and conventions on Android.
Poor UX
An app's UI is more than just how it looks, just as important is how it feels, and if it fits in and feels at home as an app on the platform. Often cross platform solutions generate apps that have slightly "off" UX, such as sluggish interactivity(RN has this this issue), missing gestures(such as backswipe). In general many small cuts that deterioriate the user experience
Focus only on the visual
The visual representation of an app is only one part of the UI as mentioned above, an obvious other example is accessibility which is often lacking with cross platform tech, especially on iOS. I wrote a whole blog post about how Flutter Web fails[0] in this regard yesterday.
Binary size
By necessity cross platform solutions reinvent a lot of what the platform already provides which leads to larger binaries(performance is a feature).
Performance
Ionic for example, runs in a non-JIT(on iOS) enabled webview so can never match the performance of native. React Native runs a JS enging(again no JIT on iOS) which demands more from the device and uses more battery than native in my experience(performance is a feature).
In general, cross platform UI works by targetting a lowest common denominator of the platforms which naturally results in a worse experience.
0: https://hugotunius.se/2020/10/31/flutter-web-a-fractal-of-ba...
A few things:
Ionic is not Flutter. Flutter has to ship a ton of code to reimplement things Ionic can use right from the browser. Size increase is marginal with Ionic and Ionic can be used to build high lighthouse performance PWAs which Flutter Web cannot in its current state.
Ionic does use a JIT-ed webview. WKWebView is JIT'ed, but JavaScriptCore (which React Native uses) is not.
The rest of your points are subjective and we find Ionic apps, when designed well like any other app, have great performance and user ratings.
Ionic is not Flutter. Flutter has to ship a ton of code to reimplement things Ionic can use right from the browser. Size increase is marginal with Ionic and Ionic can be used to build high lighthouse performance PWAs which Flutter Web cannot in its current state.
Ionic does use a JIT-ed webview. WKWebView is JIT'ed, but JavaScriptCore (which React Native uses) is not.
The rest of your points are subjective and we find Ionic apps, when designed well like any other app, have great performance and user ratings.
Hi Yesimahuman, I am really tired of seeing again and again the same myths being said about Ionic. Why not put an end to this by showing to the world scientific evidence?
I just created this issue for tracking such an effort and flutter strive for the same goal:
https://github.com/ionic-team/ionic-framework/issues/22417
Plus it would allow tracking/catching performance regressions
I think a better way to think of flutter web is flutter is using the web browser as a graphics layer to create a video game or desktop app, like SDL. It's not attempting to create an html web document.
Also nowadays the dominant computation platform of the world is mobile phones, with most of the world being Android and many with money being iOS. Desktop UIs like the web with custom screen reader & extensions & custom css mod and such are not the P0 priority. I would also imagine it's not the majority of people with these accessibility needs using it either. Desktops are the world of the office worker, middle aged person who's calcified into desktops or other power user types.
It would be hooking into iOS & Android standardized accessibility APIs. I'd imagine it executes far better there, because non-selectable text in UI elements are pretty much platform standard for mobile & desktop apps.
Furthermore in that light I'm guessing that flutter web & desktop are also P2 projects to the P1 flutter mobile projects, and android / material design is P0.
Also nowadays the dominant computation platform of the world is mobile phones, with most of the world being Android and many with money being iOS. Desktop UIs like the web with custom screen reader & extensions & custom css mod and such are not the P0 priority. I would also imagine it's not the majority of people with these accessibility needs using it either. Desktops are the world of the office worker, middle aged person who's calcified into desktops or other power user types.
It would be hooking into iOS & Android standardized accessibility APIs. I'd imagine it executes far better there, because non-selectable text in UI elements are pretty much platform standard for mobile & desktop apps.
Furthermore in that light I'm guessing that flutter web & desktop are also P2 projects to the P1 flutter mobile projects, and android / material design is P0.
You can build great experiences with Ionic. Like anything, going the extra mile to build a great app still applies.
> 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).
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).
Yeah I agree with the points about using your own stack, it's building towards the lowest common denominator that is the sockets support in libc. I think it should be possible to link against the platform libraries, but it's more work than just shiping your own stack.
Kotlin is a really nice language to use. I learnt it recently but have not done any billable work with it yet.
Hopefully soon..
The app mentioned is developed by Netflix but held in a company called Prodicle LLC and makes no mention of Netflix in description. Just kind of interesting.
Netflix is mentioned everywhere on the website though https://help.prodicle.com/hc/en-us/articles/115001787672-Wel...
Cool to see a big company using Kotlin multi platform.
It sounds like this tool is used internally. Given that, was it not possible to issue tablets of a single platform to users instead? Or are users using their personal devices?
It sounds like this tool is used internally. Given that, was it not possible to issue tablets of a single platform to users instead? Or are users using their personal devices?
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).
For me it makes perfect sense to e.g create an internal API client using this. You use platform specific frameworks for making the actual HTTP requests[1], but can write all higher level business logic in Kotlin and expose that. Adding a new REST route or change data validation would be done only once and be in sync on all platforms.
But I'm guessing that you have to pretty knowledgeable about the underlying platforms to know how (and if it's even possible) to create a good abstraction above the platform code. For something like audio/video playback or BLE, I'm guessing that there might be enough differences between Android and iOS that an abstraction that fit both is really unwieldy. And even if you create something resonable today, one of the platforms might introduce new features which destroys your abstraction.
[1]: I noticed that they even have some kind of built-in HTTP client abstraction: https://kotlinlang.org/docs/mobile/use-ktor-for-networking.h...