Profile avatar
jorgecastillo.dev
Android at Disney+. Author of Jetpack Compose internals. 👨‍🏫 Compose course composeinternals.com 📖 Compose book jorgecastillo.dev/book
314 posts 1,611 followers 253 following
Prolific Poster
Conversation Starter

You don’t need a new productivity system. You need to stop checking Slack at 11pm and calling it “ownership” or “accountability”. Time out of work and with your people is what really matters.

Knowing how Compose injects the Composer, wraps groups, and tracks remember scopes gives you full control over recomposition. It is the difference between hoping your code is efficient and knowing it is. That is the value of understanding internals.

Most Compose performance issues come from not understanding how recomposition actually works. Not tooling. Not the framework. Just the lack of mental model. Reply with the moment it finally clicked for you.

Android 16 released yesterday. Best feature: - No glass effect android-developers.googleblog.com/2025/06/andr... Android Developers Blog: Android 16 is here

You don’t need an emulator or a real device to test Compose UI. You can assert layout, semantics, and interactions, all in milliseconds. Fully headless, blazing fast, CI ready, no flakiness. Yet most teams still don’t do this. I wonder why.

“My Compose screen is janky” Proceeds to add 12 remembers, 3 LaunchedEffects, and a random derivedStateOf. Still janky. Whats your go-to for Compose performance?

📌 Jetpack Compose rewrites every Composable into a function that takes a hidden Composer parameter and a changed bitmask. This allows the runtime to skip re-execution of UI code when inputs haven’t changed. Smart UI diffing at the compiler level 🔥

It's alive ⚙️❤️ composeperformance.com

Some engineers write code. The rare ones write code and connect teams, unblock people, align efforts, and make everyone move faster. Those are your real 10x engineers.

Optimizing Compose performance is not about removing recompositions. It’s about scoping them. Recompose the 5% that matters. Not the whole screen.

I did ~10 years of startups and ~5 in big tech. Startups gave me speed, chaos, pivoting, adapting, ownership, impact. Big tech gave me scale, process, cut through bureaucracy, monitoring, perspective.

Using remember everywhere will not save you. If you don’t understand recomposition scopes and how the compiler tracks changes, remember becomes useless clutter. Compose performance starts with understanding how it works.

Gotcha.

🚨 The Effective Android community is now open for subscription. 🔒 Full access to our private Discord: 500+ advanced Android devs, all course alumni 🎯 Deep discussions on Android+Compose. Me part of them. 💸 Discounts on all courses/books Subscribe here 🔥 buy.stripe.com/aFa4gz5OY5Da...

RenderNode is Android’s low level display list builder. It records draw commands (like drawRect, drawText) into a GPU friendly buffer. The system can replay and composite these without calling your code again. Massive perf win. Yes, Compose uses it, esp. for GraphicsLayer.

📦 Ever wondered how the Compose compiler rewrites your Composables? A real example:

Once you understand how the Compose compiler rewrites your code, how the Composer tracks invalidations, and how recomposition works, you stop coding by trial and error. You start making deliberate performance decisions. That is why I wrote Compose Internals, and Compose Performance now.

I remember my first time using Compose. It looked clean. Declarative. Reactive. But under the surface? A huge amount of complexity hidden by a single annotation. Yet almost no official docs that explained how it really worked. This why I wanted to write about it.

Your adaptive layout works beautifully on a foldable. Shame is nobody owns one. Same goes for chromebooks and tablets. People just use phones. Massively.

So often devs are way too purist to be practical.

MaterialExpressiveTheme hits alpha. github.com/JetBrains/co...

Most users only ever use 2 or 3 features per app. Many times, only 1. Yet I’ve never found a company that prioritised identifying and removing features that aren’t used enough.

The Jetpack Compose and internals cohort course starts today 🔥 For the next 7 weeks, we will dive deep into the guts of Compose, learning to master it and to use it efficiently. This is the content we are learning together this week. You are still in time: composeinternals.com

We made it to 500 members in the Effective Android community Discord today 🎆👏👏

Android devs, pitch yourself. – 5 bold words – Link to app, repo, or profile 100k+ people got this on their timeline last time we did it. 🚀 This is how it starts 👀 Be seen or be silent!

Starting next Monday 🔥🚀 This is your last chance. Now or never! open.substack.com/pub/effectiv...

Talking to some really interesting potential co authors for the Jetpack Compose performance book. I want this book to be especially useful. The people I’m contacting are the most knowledgeable ones I know in this topic. Link to be noticed once it releases leanpub.com/composeperfo...

Best library for zoom interactions on images in Jetpack Compose is Telephoto, by @saket.me github.com/saket/teleph...

If you could whisper one Android dev secret to every junior starting today, what would it be? Quote tweet this. Let’s build the Android wisdom tree 🌱

Vector/path rendering (directly using drawing APIs or formats like SVG) is incredibly powerful. But don't forget that sometimes a simple bitmap is the easiest, cheapest, fastest, and overall best solution 😀

Only 1 week left. The new cohort of Jetpack Compose & Internals is about to begin. No fluff. Just deep insights, real-world knowledge, and everything you wish someone had taught you earlier. Seats are almost gone. Book now or miss out. Last call! 🗣️ book your seat here 👇 composeinternals.com

Told Cursor that I miss findViewById()

If you were rebuilding your Android app from scratch in 2025, what would you not use again? A library, a pattern, a tool, whatever. Let’s make this brutally honest.

A pattern is only useful until it gets in your way. Over the years I’ve seen way too many devs defending ideas only because they were written in a book. Be open minded.

Mocking network responses in Macrobenchmark tests 👇 That is ok and I recommend it if you are benchmarking UI performance, layout, recomposition, scroll smoothness, frame times etc In those scenarios loading times don’t provide relevant info, they’re actually noise and a source of flakiness.

When I wrote my first book years ago I felt it clearly, and I feel it again now. Writing and teaching are the best ways to force yourself to put your thoughts in order. Putting complex topics in simple terms is really hard, but helps you building up your thinking process.

Material Motion is one of those things that has been traditionally hard to translate to real world implementation. Looks like that is changing in M3 Expressive? Really interesting post 👇

Years after writing Jetpack Compose internals, and after working on Compose initiatives in big tech, I feel that it is the right time to write about this. Jetpack Compose Performance ⚡️ leanpub.com/composeperfo...

Whats new in Jetpack Compose, Google I/O edition. android-developers.googleblog.com/2025/05/what...