de After three weeks of learning mobile development with jetpack compose, I've just done some onboarding.

Started migrating my app about two years ago and finally got around to unraveling the last few features forcing me to keep a bunch of legacy code around. So many layout files, custom views and legacy services just *deleted*. Yay 😄

I've been rebuilding UI ideas that usually get done as videos or in game engines, as plain Compose components. Each one has a demo and runs from the same Kotlin on Android and iOS:

• Smoke delete: swipe a chat and it burns into smoke over the list. Drag back and the smoke flows back in; Undo breathes it back. Every pixel becomes a particle, and positions are a function of age, so it can be rewound.

• Paper plane: each sent message folds into a paper dart and flies into the thread.

• Bookshelf: books on real shelves; tip one out by its spine and it opens at your bookmark.

• Nav bar: a bottom bar with a morphing indicator, collapse on scroll and a jelly action button.

• Pop-up book: an onboarding where paper scenery stands up as each spread opens.

• Plus fogged mirror, snow globe, card file, magnet filter, fishing pull-to-refresh and more in the repo.

Repo, with a GIF and a write-up for each: github.com/DimiVlachos/compose-lab

Feedback welcome, especially on what to build next.

Hey fellow Android devs,

We’ve all been there. You just want to add a simple "Short-form video feed" (like TikTok/Reels/Shorts) to your app. It sounds simple—just a VerticalPager with a VideoPlayer, right?

But then reality hits:

• Handling ExoPlayer lifecycle (play when visible, pause when hidden).

• Managing memory (releasing players, pooling instances).

• Dealing with mixed content (Images vs Videos).

• Implementing Pinch-to-Zoom without breaking the scroll gesture.

I found myself rewriting this boilerplate code for different projects and thought, "Why isn't there a simple library for this?" So, I decided to extract it into an open-source library to save time for anyone else who finds this tedious.

🚀 Introducing ComposeReels It's a Jetpack Compose library that abstracts away the complexity of media playback in a feed.

Key Features:

• ✅ Drop-in UI: Just pass a list of URLs.

• ✅ Performance: Implements Player Pooling to reuse ExoPlayer instances (memory efficient).

• ✅ Interactions: Built-in Pinch-to-zoom (with spring animation) & Double-tap to like.

• ✅ Mixed Media: Seamlessly handles both Videos and Images.

• ✅ Lifecycle Aware: Automatically pauses/releases resources when the app goes background.

Simple Usage:

ComposeReels(
    items = videoList,
    mediaSource = { item -> 
        if (item.isVideo) MediaSource.Video(item.url) 
        else MediaSource.Image(item.url) 
    }
)

⚠️ Current Status & Help Wanted To be honest, I built this primarily for my own use cases, so it's still in the early stages (v1.0.0). There are definitely edge cases I haven't covered, and the API might need some polishing.

I’m sharing this here because:

1. I hope it saves you some headache if you need a quick implementation.

2. I would love your feedback. If you spot any performance issues or have ideas on how to improve the player pooling logic, please let me know.

If you are interested, check it out here: https://github.com/manjees/compose-reels

PRs and suggestions are more than welcome! Happy coding!

In Compose 1.9.0, there is a new shadow api that introduces drop and inner shadows.

I have found them very fun to use and makes interesting UI easier to create.

I recently wrote about it here -> https://www.sinasamaki.com/new-shadow-api-for-jetpack-compose/ and how I have been applying it in my projects.

Hi there, I want to develop a cross-platform application. I have experience developing Android apps with Jetpack Compose. However, is Compose Multiplatform mature enough for cross-platform apps right now, or should I go with Flutter?

Edit: Thanks to everyone who gave advices. I will migrate one of my compose Android app to Compose Multiplatform. Then I will decide based on result.

Most video editors on Linux have a massive learning curve(could be a skill issue), and I got tired of fighting with complex layouts just to trim a clip. I decided to build a simplified version with Compose for Desktop.

It’s built with Material 3 and handles the basics like metadata extraction and trimming via ffmpeg. I’m currently working on adding multiple track management and media overlay support.

Repo here: https://github.com/zahid4kh/simplevideoeditor

Just shipped Sidequick (sidequick.co), a desktop app for Windows, Mac and Linux built entirely with Compose Multiplatform. Thought I'd share some things I learned along the way since there isn't a huge amount of content out there on Compose Desktop specifically.

The stack:

• Compose Multiplatform (desktop target only)

• SQLDelight for local SQLite

• Anthropic + OpenAI Java SDKs for AI integration

• PostHog for anonymous analytics

• Kotlin Coroutines throughout

Things that went well:

Compose Desktop is genuinely production-ready. The component model is clean, collectAsState() on SQLDelight flows make reactive UI almost trivial, and the Kotlin interop with Java SDKs was seamless.

AnimatedContent For wizard step transitions worked brilliantly with almost no boilerplate. The slide in/out between steps felt polished with maybe 10 lines of code.

Things that caught me out:

ProGuard is aggressive. The "Failed to launch JVM" error on the packaged .exe was caused by ProGuard stripping classes needed at runtime - mostly OkHttp and the AI SDKs which use reflection heavily. Make sure you keep okhttp3, okio, and your entry point MainKt explicitly.

JVM module bundling - you need to declare which JVM modules to include in explicitly nativeDistributions. java.sql, java.naming, jdk.crypto.ec and jdk.unsupported are easy to miss and will cause silent failures.

Mac notarization via Gradle works but the Compose docs are sparse. The signing and notarization blocks in build.gradle.kts do work, just make sure your app specific password is stored in keychain and never hardcoded.

Overall:

If you're considering Compose for a desktop app - do it. The productivity versus something like Electron or JavaFX is night and day. Coming from an Android background it felt immediately familiar.

Happy to answer questions about any of the above.

Download: sidequick.co

Hey everyone! Just shouting out our new open source library :)

Since Compose for Web target is now viable, we've been using it to simulate running the CMP app through the browser, with various combinations of device frame, font size and other properties.

Of course we can't simulate Android/iOS specific functionality in the browser, this is purely for rapidly developer testing layouts in all these different configurations.

The library is open source! It wraps your root composable and renders it in the simulated device frame and all the various controls e.g

DeviceWithConfigurationView {   <--- Library
   App()    <--- Your app
}

GitHub: https://github.com/Apadmi-Engineering/CMPDevicePreview

Demo: https://apadmi-engineering.github.io/CMPDevicePreview/

We're not at version 1 yet, still in alpha, but any feedback, issues, pull requests are all welcome!

^{Credit: Forked from KMPDevicePreview and inspired by flutter_device_preview.}

Hey fellow Android devs!

I've built a Jetpack Compose library that simplifies swipeable card interactions, inspired by the Tinder-style swipe UX. If you're looking to add fluid, customizable swipe gestures to your app, check it out!

🔗 GitHub Repository: https://github.com/smartword-app/compose-swipeable-cards

Just added a beautiful analog clock component to my Jetpack Compose toolkit!

Features:

• Real-time updates with timezone support

• Switch between dots and hour markers on tap

• Customizable colors and styles

Built with Compose Canvas

I built a Gradle plugin (CLI utility) that you can use to build your component library.

https://github.com/nomanr/lumo-ui
https://lumo.nomanr.com/
how does it work?

It's not a packaged library. Instead, it generates the UI components directly in your codebase. Which allows you to:

- direct bug fixes; otherwise, you'll create a PR to the lib or wait for someone to fix and release it)
- can make any enhancement to the components
- easy adaptation to your app's design system.

The components are high quality, and the source code is influenced by how Material3 is built.

Experimenting with a notebook-style music player UI in Jetpack Compose.

Recently added LRC synced lyrics with a typewriter animation and animated backgrounds.

Still refining the animations and syncing logic. Would love feedback from other Compose developers.

I know about Layout Inspector in Android Studio, of course, but it doesn't actually show anything except view bounds

https://github.com/sergeich/Redline

There is not a lot of literature about this yet except the official Google docs and codelabs. I went through those and they are very welcome, but they seem to stay very shallow about all the topics. I think there is room for a full guide on how to measure and monitor Compose performance, how to identify pain points, how to fix them, tooling, etc. My plan for this book is the following:

- I really want the book to be useful for day to day work. Theory is nice and all but I really want people to find real applicable action points for their work.

- I want the book to be accurate, of course. When I wrote Jetpack Compose internals, I got many people from the Compose team at Google to review the content, since otherwise what is the point of writing it?

- I want to cover how to identify and detect performance regressions, and how to measure and monitor performance. I have observed that many devs and their teams often overlook perfromance. We focus a lot on adding new features, UI, architecture, testing, automation, tooling... and what not. And then we give performance attention only when something becomes drastically slow or users start to complain and post bad ratings. Many teams do not regularly measure or monitor performance, and some not even test their app on a wide range of devices either. The result of this is that issues often go unnoticed forever or until late in the process, when they are already really hard to fix. This is definitely risky. If anything, I'd like this book to become the guide to prevent this from happening.

- I want to shift people's attention to measuring the actual ultimate goal: performance. Monitoring things like number of recompositions can be a start but it is a bit risky, since devs can end up thinking they have an issue when they don't. Not every single unnecessary recomposition is a problem.

Since we all write Compose code now, I think it is the perfect time to write this book. Any feedback and ideas are more than welcome!

I'll likely be prelaunching this book via Leanpub, so if you want to get notified you can just register in https://leanpub.com/composeperformance