As such, there has been a bit of open source, but nothing super committed. The last several years have been largely focused on the non-technical side of running a mobile development shop. It is a great time to get involved.Ī bit of my own background. This particular field is wide open but very likely to be very active very soon. If you’ve come into Android fairly recently and wanted to do some open source work, you’ll notice it’s pretty crowded. However, I’m predicting as more examples of multiplatform emerge and the tools stabilize, we’ll see a flood of multiplatform libraries emerge.
Some communication and coordination will be useful, so 10 groups don’t build the same thing (although a little competition doesn’t hurt either). There is intense interest in creating things for Kotlin. To say a lot of developers like Kotlin would be an understatement. It’s non-trivial, but it’s not starting over either. To build a new ecosystem, you can just take the current result of that work and build analogs. Similarly, “smartphone” mobile has a decade of iterating on libraries and best practice ideas. You shouldn’t need to do the same on your second platform. Product development involves iteration, which involves throwing away a lot of work. One of the reasons why the discussion around “cross platform” is broken is we think 2 apps means 2x work. It sounds like a lot of work, but a few things to keep in mind. Something with a schema)Īll of these need fully Kotlin-ized rewrites. If you open a production Android app and look at the library list, it’ll probably be huge, but if you really looked at it, the list of things critically necessary for shared architecture would be pretty short. Android is a mature ecosystem, which means you have a lot of special purpose stuff. We don’t need everything currently available on the JVM side, just the critical stuff. Just logic, and to a limited degree (size of that area varies widely according to how much logic, obviously).
The middle represents what you could theoretically share. On the iOS side, the Native team has wrapped a bunch of resident libraries with the interop, but that’s kind of it. Obviously, the JVM side has a ton of stuff available. The slide above represents roughly how building multiplatform would look today, from a “how much code are you sharing” perspective. Kotlin multiplatform for mobile consists of common Kotlin, Kotlin/JVM, and Kotlin/Native.
0 kommentar(er)
