Michal Bialas

The hottest Jetpack Compose projects and libraries on GitHub in 2023 to take inspiration from🔥🔥 🚀🤓 ⚡⚡ Cool open-source projects in a thread 🧵⚡⚡ #android #androiddev #Productivity #kotlin #JetpackCompose #compose #tooling #opensource #inspiration

@SebastianRoehl With this post, you answered the question I asked earlier about choosing the right technology for your needs: hybrid vs native. Got your point, cheers 🍻

@SebastianRoehl If you had the experience you have right now and could start from the scratch, would you choose flutter again or native technologies like swift / swift ui and kotlin / jetpack compose?

TIL how animations work with SwiftUI. Much more intuitive than how it's done in Flutter IMO 👌

@cyrilmottier What minSdk do you support?

Enhance your shading language skills 💪. Such effects make your app shine and stand out. Wave effects here were created with GLSL. The rest is classic Compose. If you look closely, you can see some glitches as it runs on a snapshot. AGSL is here to the rescue on Android 13+!

@Zhuinden Well, it’s not so modern anymore 😉😅

google/modernstorage library: deprecated before 1.0.0 stable release (or even a beta release), permanently archived and abandoned since Feb 22, 2024 Last commit made 2 years ago, on Feb 15, 2022. github.com/google/moderns… #androiddev #mandroiddev

@PreusslerBerlin @Zhuinden @donnfelker How did it end up? After all these years, do you think they still have the same core? 😁

You’ve got a legacy Android app, and you can only focus on one of these at a time. Which one do you choose first?

For me, it's a red flag because, nowadays, I haven't heard about any greenfield projects written with Rx. The trend is towards Coroutines. Still, I don't deny that Rx is a stable, well-established, and reliable library, which my team uses on a daily basis and will continue to do so for the next several months or even years.

@mmbialas @donnfelker @PreusslerBerlin Rx wasn't particularly "commonly popular" even at the time when android devs were talking about it, it was hipster tech. What I'm not sure about is why the framework offering a stable feature set and having no open/known bugs waiting to be fixed after years of dev is a red flag…

I think alike, however, these 'some' developers are in the majority, and this is not a technology problem but a people one. My team and I reviewed over 50 recruitment challenges and projects this year, and none of them used Rx. This is eye-opening. When you deal with legacy code based heavily on Rx and have a team that can maintain it, it’s fine. But people come and go, change their jobs, etc. And now, people with ~4-5 years of experience don’t even bother to look at Rx. In many cases, they haven’t used Rx at all. Coroutines are part of Kotlin, so that’s a natural choice. It also seems that Rx is more like in the LTS phase. The last release was on September 29, 2023; there is 1 PR, and 17 issues, most of which are questions. That’s the reason I’m quite concerned about Rx. I’m also into @PreusslerBerlin approach to slowly migrate to Coroutines and live with two frameworks for some time. @danlew42 also wrote great article about it 3 years ago (blog.danlew.net/2021/01/28/rxj…), and it’s still up-to-date.

@mmbialas @donnfelker @PreusslerBerlin There's no reason for RxJava to be deprecated. RxJava is developed as community effort, partly by people who use the library in production in their codebases. They have a vested interest in continued support. Some Android devs deciding "it's not hip" doesn't mean it's obsolete.

@donnfelker @PreusslerBerlin Still, at some point, you would need to migrate 100% to the newer technology when the older one becomes deprecated. The question is how to plan wisely to not fall behind. I have the same dilemma with Rx/Coroutines, and I'm curious if Rx will be deprecated anytime soon.

I don't like the idea of replacing things either. New UI in compose, old XML stuff, leave alone. I'm all for that. As for Rx stuff, its platform level you can end up in some weird situations with too much back and forth with libs like kotlinx-coroutines-rx2. It works, but its has a lot of footguns.

@adrianwita @donnfelker I was actually mainly comparing KMP to pure native solutions in Kotlin and Swift. JS is a different story though.

@mmbialas @donnfelker It’s hard to any multiplatform framework to compete with React Native because JS devs are cheaper, there is more of them and companies think „What will I do with all those Kotlin developers if we change our mind?” Unless they notice how many RN problems the KMP solves.

This post by @donnfelker is pure gold donnfelker.com/why-kotlin-mul… The article presents a pragmatic approach for choosing the right technology for your needs, or, generally speaking, the right tool for the job. History repeats itself, as seen with Cordova/Phonegap, Ionic, Xamarin, React Native, and currently with Kotlin Multiplatform. This is a great read for everyone who has an impact on the tech stack, from business owners to engineering managers, tech leads, and developers. #Mobile #KMP #multiplatform #androiddev #iosdev #webdevelopment

@indiana_sloan @vishnuhx @donnfelker Hah, I wish to be on your iOS team 🫠

@mmbialas @vishnuhx @donnfelker Every case is different for sure and it's not a one size fits all. But in my experience the android and KMP don't need to be different teams. The android team are already writing the logic, just now in a shared module

@indiana_sloan @vishnuhx @donnfelker Okay, but every case is different. What is the size of your team, and how many people work on Android and iOS in your project? Did you start from scratch in that particular project, or did you slowly migrate to KMP?

@mmbialas @vishnuhx @donnfelker I disagree with this, based on my experience. For us, our android/kmp team is one and the same. We don't resource any more android engineers on a KMP project than we would on a typical native android project. We do however significantly need less iOS resource

@pablichJ @donnfelker I believe it also depends on the market. Are you referring to the US market? In the EU, it is quite different.

@mmbialas @donnfelker I don't know but checking the job market recently tells a different story. Flutter and React Native are gaining popularity.

1. I believe this approach is only valid for simple, short-lived apps, such as concert or one-time event apps, and especially for greenfield projects. When planning, for instance, a banking app, it must be designed to last for at least 4-5 years or even more. Therefore, the stack needs to be rock-solid and proven. I’m not convinced that GenAI is the best idea. 2. Yeah, this is FAANG approach and I love it. Still, when you recruit for non-FAANG company, it’s almost impossible to find generalist software engineer. 3. Valid point. But I still remember the Airbnb React Native soap opera. Hopefully, it won’t be the same with KMP.

3️⃣ Community and adoption momentum. There’s lot of people and companies investing in KMP right now. It all started before a stable release.

I feel exactly the opposite about Kotlin Multiplatform. It’s probably the first multi-platform approach that might work for mass adoption. Here is why: 1️⃣ Right on time for the market where one could build an app using genAI with a limited platform knowledge

@vishnuhx @donnfelker Yeah, but still, as you wrote, you would need an additional team:Android,iOS,and a KMP team specializing exclusively in KMP. If a company cannot afford 3 teams, it's almost certain that the Android team will take on the KMP part, impacting the lead time for the Android platform.

I have a different take on this - #KMP is different from any cross-platform technology that ever existed. I see it as a tool to develop portable common logic rather than a tool to build complete apps in an alien technology that uses a runtime on top of the iOS/Android platform (like Flutter or RN). KMP allows the native teams to continue working on their native code, while the KMP team contributes the business logic independently. The native teams consume the KMP output as a normal dependency. The same business logic can be exported to any platform as well. This nature of KMP makes it a true "multi-platform" tool to make the business logic common on both platforms, which saves a lot of time and effort in replicating it on multiple platforms. It utilizes Kotlin's ability to compile to native (K/Native) instead of using a custom runtime. Having said that, Compose Multiplatform may not succeed or won't become very popular because building a common UI makes it another Flutter/RN and forces iOS devs to learn Compose to build iOS apps. But KMP has great potential to succeed without disrupting the ongoing iOS/Android native development or forcing iOS devs to learn Kotlin.

Okay, but by adding another layer (KMP), you increase complexity. Some business logic is shared, while some, which has 'failed,' is not. That's my concern. I'm also curious about the interop between KMP and Swift/ObjC. As you mentioned, the adaptation of Kotlin was so great because it added syntactic sugar, which was much needed at that particular time when we needed it

@mmbialas @noraltavir @donnfelker Say the app needed a new feature to be written, with complex and/or critical logic. You could write the Android side in Kotlin. With KMP, you can *also* publish an iOS Framework to CocoaPods/SPM, and call it. If that "fails", OK, write it in Objc/Swift. You had to anyway.

@kpgalligan @donnfelker Thanks for the link, I will watch this 👍

@mmbialas @donnfelker "If you only consider ... developers ... self-development, then ... everything new is great. However, when you think about the entire picture ... it is not so awesome" Yeah, exactly. That's the difference here. I completely agree. youtube.com/watch?v=-tJvCO…

@ZGV2ZWxvcGVy @donnfelker Yeah, I'm in favor of an "all-in" approach too. Otherwise, after few years it could be a maintenance hell.

@mmbialas @donnfelker Good article. I, too, see many developers wanting to try out KM and integrate it in an already developed apps. I understand why, however I don't understand why their teammates are not pushing back on this idea. I would really not want to see half integrated framework.

After posting this tweet, YouTube immediately recommended to me The State of #Kotlin #Multiplatform youtube.com/watch?v=bz4cQe… 😅

Fair point, and obviously the technology I mentioned is thankfully far far behind KMP. But the questions is, if the struggle we’re talking about is worthy to migrate to KMP when your project works as intended but it has “old” tech, like java + kotlin / swift + objc and they don’t share common logic? I believe it’s a question without a right answer.

@mmbialas @donnfelker While I think Donn made good points in his article, particularly around getting buy-in from ios devs but kotlin multiplatform is different from the tech mentioned in your tweet and I don't think the argument that they struggled and so KMP will as well is valid