Google Docs is also migrating to Kotlin Multiplatform
> The initial step in this journey is the rollout of the Google Docs app for Android, iOS, and Web, which leverages KMP for shared business logic, validating its readiness for production use at Google scale. The Google Workspace team is thrilled to continue exploring the possibilities of KMP across its product suite, aiming to enhance productivity and deliver seamless experiences to users on all platforms.
So the trick for performant animation here is to draw on canvas and put the canvas in front of all other elements but disable pointer events on canvas so that you can still interact with the page.
Canvas draws raster images, anything resembling an object in your drawing logic is already tracked separately by necessity. So regardless, you’d presumably check against whatever data model you’re using to determine what to draw.
You call it a trick for performant animation, but I couldn't think of any other way to implement something like this. What would a naive implementation look like?
WebAssembly can be used to reuse logic between web, mobile and desktop apps. For example you can write your core logic once in Rust and then make a native UI for different platforms. We've used this approach for Koofr Vault [1] (client side encrypted cloud storage) and we couldn't be happier. Rust for core logic, React for web and desktop apps (with Tauri), SwiftUI for iOS and Jetpack Compose for Android.
They started with Java and tried to use as little GC as possible and started writing hot loops in C, C++ and Rust. Logic is in Java, other stuff is mostly native.
In terms of numbers I don't know but I personally chose it from my apps and to me it's the best framework out there at the moment.
Compared to the native tech the advantages are easy, you have a single codebase and UI for all the platforms. The native UI apis are also moving faster than Flutter in my opinion which makes Flutter lower maintenance as well on this area.
Compared to React Native, it's younger but more stable in my opinion, I don't want to deal with the js package churn rate and its bad testing story. I come back 6 months after to my flutter projects and after 2 hours I've upgraded everything, good luck with that on the js side.
If you care about Linux, Flutter is also a better choice than React Native in this scenario. React Native Gtk target is abandoned and the only realistic solution is to use an Electron wrapper (well it's not that native anymore isn't it)
The only downside to me is the web target which isn't that great, if you just want to use the web target as an app demo though, it's good enough.
I was also very surprised at that line and I was wondering if I was the one who was out of touch or the Google team were. I haven't really looked into mobile development for a few years so it could very well be the case, but it stood out to me as unlikely considering the relative impopularity of Dart and the (to my estimation) very low hype profile of Flutter where developers hang out.
But maybe they're right. I think it would be exceedingly hard to actually get real numbers on it anyway.
> Tim was a director on Flutter until a few months ago and now works at Apple.
>
> That is, he has first hand knowledge of Flutter's numbers and now that he works for a competitor, no motivation to inflate Flutter's stats.
Being the ex director of a project means you will always have a reason to inflate the stats of that project, even if it is just for personal pride. I don't see how Hickson leaving Google means he doesn't still have part of his work life tied to the project regardless of employer.
> Without getting into specifics (which I cannot share), Flutter is wildly successful in the market place and continues to grow YoY.
That's cool, but this is just more of the same and more of what people seem surprised by. Numbers don't really matter unless they're visible and verifiable.
I guess it depends on how you measure popularity. If we’re counting new apps published on App/Play Store? Perhaps, even if still quite surprising . By user numbers? Completely unbelievable.
If it is a response to that, you would have to assume that Hickson left because he pushed for or against something relating to working on Flutter. If Google wanted to place him elsewhere, for example, and he left Google because he figured he can bankroll his own work on Flutter and look elsewhere, that'd be in line with this line:
> I hope that Google finally realizes what treasured assets they have here before it's too late. The clock is ticking.
Lowering the amount they're investing in Flutter would definitely be something that would disappoint the ones who believe in it strongly in-house and taking away key people would not inspire confidence. Interestingly none of the tweets ever mention Hickson as being important, which doesn't exactly speak to the source of the complaints being Hickson leaving, but rather a much more general lowering of investment in Flutter.
Hickson left Google for his own personal reasons. Not because Flutter is losing resources or that he was asked/assigned to work on something else.
Google has not lowered the amount resources dedicated to Flutter.
Ian started the Flutter project and it's hard to point to someone more important to Flutter's success than him.
He continues to work on Flutter as does the entire Flutter and Dart teams.
How do I know this? I've been working on Flutter (off and on, currently on) for seven years and was present when Ian announced his departure from Google (not Flutter).
Fair enough. What is the impetus for this long, whinging thread that has been linked to, then? If it's not about Google at the very least not showing any confidence in Flutter it seems fairly hyperbolic.
The creator of Rerun (Emil Ernerfeldt) also created egui [1], an immediate GUI library for Rust. The library is similar to Dear ImGui but it is written in Rust and can be used for desktop and web apps (compiles to WASM and uses WebGL, demo [2]). Desktop apps can target OpenGL (does not display correct colors on macOS, does not work in VirtualBox on Windows) or WGPU (uses native APIs for each platform, works without any problems, but the binary is a big larger).
It depends on the application. If your app just displays data from a REST or GraphQL API it does not really make sense. But if your app is self-contained (it's mostly logic inside the app) it makes sense to have a shared core for models and business logic.
> The initial step in this journey is the rollout of the Google Docs app for Android, iOS, and Web, which leverages KMP for shared business logic, validating its readiness for production use at Google scale. The Google Workspace team is thrilled to continue exploring the possibilities of KMP across its product suite, aiming to enhance productivity and deliver seamless experiences to users on all platforms.
https://android-developers.googleblog.com/2024/05/android-su...