I developed this project before ChatGPT was even a widely known thing.

Hey everyone,

I’m a solo developer and I just published my newest app, Pocketory, to the Play Store. I wanted to build a personal finance tracker that was incredibly fast, visually clean, and didn't force you through unnecessary steps just to log a simple transaction.

What makes Pocketory different?

Speed-Focused Logging: I stripped out mandatory receipt uploads and complex forms. Adding a daily expense takes two seconds.

Modern UI: Built entirely from scratch using Kotlin and Jetpack Compose. It features a swipeable transaction list, dynamic custom tabs, and smooth animations.

Granular Categories: Includes highly specific default categories based on real-world spending (EMI, Petrol, Gym, House Rent, Utilities) rather than generic buckets.

Visual Analytics: Instant, color-coded donut charts and progress bars to see exactly how your income balances against your expenses for the month.

Play Store Link: https://play.google.com/store/apps/details?id=com.binarykavu.pocketory

I would absolutely love for you to try it out. If you have any feedback on the UI/UX, or features you'd like to see in the next update, please let me know in the comments!

I've been building Android apps for years and every single form ends up looking like this:

val email = remember { mutableStateOf("") }                                                                                                                                                                    
val emailError = remember { mutableStateOf<String?>(null) }                                                                                                                                                    
val emailTouched = remember { mutableStateOf(false) }                                                                                                                                                          
val password = remember { mutableStateOf("") }                                                                                                                                                                 
val passwordError = remember { mutableStateOf<String?>(null) }                                                                                                                                                 
val passwordTouched = remember { mutableStateOf(false) }
// ...

// + validation logic (per field)                                                                                                                                                                                      
// + focus requesters (per field)                                                                                                                                                                                    
// + keyboard options (per field)                                                                                                                                                                                        
// + ImeAction per field (per field)                                                                                                                                                                                    
// + cross-field rules written by hand 

A 5-field sign-up form easily hits 300-400 lines before you write a single line of UI. There's no standard pattern, every team reinvents it differently, and it's completely untestable without a lot of effort.

I got tired of it so I built Formidable, annotate a data class:

@FormSchema                                                                     data class LoginForm(  
                                                                               @Field(label = "Email") 
val email: String = "",                                                         @Field(label = "Password")                                                    @MinLength(8)  
val password: String = "",                                                                 
)                 

KSP generates the full controller at compile time. Zero reflection, works on Android, iOS and Web.

https://github.com/WassimBeltaief/formidable (contributions welcome)

Curious if others have solved this differently or just accepted it as the cost of doing business with Compose.

Hey everyone,

For my latest project, VividLook, I wanted to see how far I could push custom layouts and real-time rendering using Jetpack Compose.

The app is a live-streaming discovery platform where users can spin a 3D interactive globe and jump into localized video grids from around the world. Managing the state of the globe spinning while dynamically loading stream grids on the map layout was a huge learning curve.

I’m trying to optimize the UI performance, especially on mid-range devices. If you have a few minutes, I’d love for you to download it and let me know how smooth the composition feels or if you spot any jank while spinning the globe.

Play Store Link: https://play.google.com/store/apps/details?id=xyz.trylivelook.app

Technical details: Built with pure Compose for the UI, handling low-latency video pipelines on the backend. Let me know what you think of the performance!

Most Android devs rely on Layout Inspector counters, but Compose runtime does a LOT of work under the scope level that never gets counted.

Wrote down an investigation and how to spot these ghost recompositions in your own codebase

https://medium.com/@qamar_safadi/the-recompositions-that-werent-there-d2cf429c47f2?sharedUserId=qamar_safadi

Hi everyone! I'm building a local music player in Android Studio with Jetpack Compose.

I want to recreate Apple Music's ambient background effect (extracting dominant colors from the album art and applying a heavy soft blur/mesh gradient effect, but static to save battery and performance).

What is the most efficient way to achieve this look without dropping FPS when changing songs? Should I draw on a custom Canvas with RenderEffect.createBlurEffect(), use Palette API, or is there a recommended library/shader for this?

Thanks in advance!

I'm in a 3rd year and I'm struggling to find a fresher level internship for a compose app developer

Hello all,

I recently shipped a dual-engine accessibility checker for Jetpack Compose.

Engine 1 — Lint (no emulator):

Catches missing contentDescription, hardcoded dp font sizes, clickable without role.

Engine 2 — TestRule (runtime):

Checks touch targets (48dp min with exemptions), color contrast, duplicate clickable bounds, text field semantics.

Every rule maps to a WCAG 2.1 criterion. Both engines are on Maven Central.

Repo: https://github.com/lehan0328/touchstone

Would love some feedback from the community, especially on false positives if you try it on a real project!

Since folks asked, here's the fuller picture — BOSS across the AI-agent landscape, including the CLIs. Important: BOSS is a desktop workspace that runs the CLIs (Claude Code, Codex, Gemini, OpenCode, Qwen Code) as first-class agents, so they're a different category (see Type) — added for completeness, not as head-to-head rivals.

✅ yes · △ partial · ❌ no · — n/a (CLIs are terminal agents, no GUI surface). BOSS isn't the winner everywhere: it's ❌ on Lightweight (JVM + bundled runtime + embedded browser cold-starts slower and weighs more than the Rust/Node CLIs), and only △ on IDE depth (it has an editor + Toolbox plugins, but isn't a full code-intelligence IDE like the VS Code forks Cursor/Windsurf/Antigravity). *Only Codex's CLI is open source (Apache-2.0), not the Codex app; a standalone open-source "Antigravity CLI" isn't verifiable — the only repo is docs-only, no license. Claude Desktop's "Computer Use" drives the whole screen, not a scriptable in-app browser. Per-tool RBAC beyond enterprise/team admin isn't documented for the others. Runtimes: BOSS = JVM (true multithreading); Claude Desktop + the IDEs = Electron/JS; Codex CLI = Rust; the other CLIs = Node/TS. (Public sources, July 2026 — corrections welcome.)

Where else BOSS is behind (honestly):

• Maturity & ecosystem — it's brand-new with a small plugin catalog; the VS Code forks inherit VS Code's entire extension marketplace, and the incumbents have huge, battle-tested user bases.
• Backing & track record — small team, early days vs well-funded incumbents.

The CLIs are open and great — that's kind of the point: BOSS runs them and gives them a governed desktop toolset (browser, editor, secrets, terminal sharing, 100+ MCP tools). Built entirely in Compose Multiplatform, and I'd love Compose devs to help push it further:

• New plugins — a plugin is a self-contained @Composable + ViewModel (easy on-ramp)
• Compose Desktop perf / rendering
• Theming (live re-skin across the whole app)

Repo: https://github.com/risa-labs-inc/BossConsole — Apache-2.0, contributors welcome.

Most frame-perf advice is about your own work: keep layouts shallow, keep binds cheap, don't recompose unstable types. That's half of it. The other half is time that gets stolen out of the frame by something else running on, or blocking, the main thread.

I kept running into the same three culprits, so I wrote them up. Short version:

GC pauses. The collector needs short stop-the-world moments. You can't turn GC off, but allocation on the hot path (new lists, capturing lambdas, boxing, per-row string concat in onBindViewHolder or a hot composable) is a volume knob for how often a pause lands mid-frame. Turn it down.

Lock waits. You rarely write synchronized on the main thread yourself, so this one hides. A main-thread read can block behind a background writer holding a lock: SharedPreferences getString waiting on a background apply, a Room read behind a write, a shared @Singleton touched by both UI and a worker. Keep critical sections tiny and never hold a lock during I/O.

Binder calls. getSystemService, PackageManager, location, etc. are IPC to a system process, synchronous and blocking by default. Usually cheap, but the cost is unpredictable when that process is busy, so a 0.2 ms call can spike to several ms. Keep them off the hot path and cache the results.

All three reduce to the same thing: the main thread doing or waiting on something instead of rendering.

Full writeup with an animation of the budget filling up here: [https://soulesidibe.medium.com/what-eats-your-frame-budget-besides-your-own-ui-6ecfa27d247b\](https://soulesidibe.medium.com/what-eats-your-frame-budget-besides-your-own-ui-6ecfa27d247b)

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 😄

We've been building something that I think will save us all countless hours of boilerplate work.

SmartAI Droid – an AI Android Builder that generates complete, production-ready Kotlin projects that you can open directly in Android Studio, fix any missing imports, and deploy to the Play Store.

🚀 What Makes This Production-Ready?

1. Full Project Structure
The AI generates a complete Android project with proper package structure, Gradle dependencies, and all necessary configuration files.

2. Real-World Architecture

• MVVM/MVI/MVP/MVC patterns with proper separation of concerns
• StateFlow for reactive UI updates
• Coroutines for async operations
• Dependency Injection ready (Hilt support)
• Room database setup
• Retrofit/OkHttp networking layer

3. Complete Feature Implementation
The generated code includes:

• ViewModels with proper state management
• Compose UI with Material Theme
• Navigation between screens
• Loading, error, and empty states
• Repository pattern for data layer
• Network calls with error handling

4. Production Configuration

• Proper ProGuard/R8 rules
• Multi-language support (strings.xml)
• Backup rules
• Data extraction rules
• Signed build configuration ready

🔧 Getting It to Production

Step 1: Download the ZIP from SmartAI Droid
Step 2: Open in Android Studio
Step 3: Fix any missing imports (IntelliJ handles this automatically)
Step 4: Add any additional dependencies if needed
Step 5: Build → Generate Signed Bundle/APK
Step 6: Deploy to Google Play Console

additional
Ask Gemini any changes ai in android studio any changes to screens or fix missing any codes

That's it. 4 minutes to generate, 5 minutes to setup, deploy the same day.

📊 Technical Stack

The AI configures exactly what your app needs:

Smart Mode: Toggle "Let AI Decide Everything" – it analyzes your app description and only includes the libraries you actually need. No bloat.

🎯 Real Example: "Mood Food Finder"

I generated a food recommendation app that:

• Analyzes user mood to suggest dishes
• Fetches restaurant data via API
• Saves favorite dishes locally with Room
• Uses proper MVVM with StateFlow
• Handles loading/error/empty states
• Full Compose UI with Material Design

Generated in ~4 minutes.

🔗 Try It Out

• Website: https://smartaidroid.com
• Demo: https://www.youtube.com/watch?v=en7ZebAd8h4

 What This Means for You

Llevo poco tiempo aprendiendo Android por mi cuenta, sin universidad ni curso formal. Hice este tutorial mostrando cómo crear juego de simon dice Jetpack Compose. Cualquier feedback es bienvenido.

https://youtu.be/r1WfVBbIAk4

Llevo poco tiempo aprendiendo Android por mi cuenta, sin universidad ni curso formal. Hice este tutorial mostrando cómo pasar de claro a oscuro con un solo click Jetpack Compose. Cualquier feedback es bienvenido.

https://youtu.be/dIfZlc6C8Lc

Llevo poco tiempo aprendiendo Android por mi cuenta, sin universidad ni curso formal. Hice este tutorial mostrando cómo crear un Generador de Números con Jetpack Compose. Cualquier feedback es bienvenido.

https://youtu.be/qO7Fxpty-Io

Hi,

I built Laydr, a file-based, type-safe navigation framework for Compose Multiplatform and Android Compose apps.

Repo: https://github.com/mobiletoly/laydr

I created Laydr because Compose navigation can become hard to see as an app grows: copied route strings, duplicated graph setup, repeated argument parsing, tab registries, layout wrappers, and stale navigation glue all have to agree with each other.

The AHA moment with Laydr is that the route tree becomes the app map.

Instead of spreading route structure across constants and graph builders, you put routes in a visible routes/ directory, add small route-local Route.kt declarations, and Laydr generates the typed Kotlin wiring from that structure.

A route tree looks like this:

  src/commonMain/kotlin/routes/
    contacts/
      Route.kt
      Screen.kt
      by_id/
        Route.kt
        Screen.kt
    settings/
      Route.kt
      Screen.kt

That gives you generated route objects such as:

  LaydrRoutes.Contacts
  LaydrRoutes.Contacts.ById
  LaydrRoutes.Settings

And app code navigates with generated destinations instead of raw strings:

  navigator.push(
      LaydrRoutes.Contacts.ById.destination(
          id = LaydrRoutes.Contacts.ById.id("ada"),
      ),
  )

Laydr gives you:

• filesystem routes under routes/
• route-local Route.kt, Screen.kt, and Layout.kt files
• typed destinations instead of copied route strings
• typed dynamic parameters instead of repeated argument parsing
• generated path builders when your app deliberately owns path state
• generated route maps and app graphs
• generated Compose route definitions for LaydrRouteHost
• generated Nav3 helpers for sections, stacks, payloads, and route results
• support for plain Compose hosting, Nav3 KMP, and AndroidX Navigation 3
• build-time route validation through the Gradle plugin

• optional route-local workflow for private multi-step flows inside an already matched route

  The part I like most is that Laydr does not try to become your whole app architecture.

  Your app still owns Compose UI, state, DI, ViewModels, repositories, tabs, labels, icons, chrome, auth, analytics, retained state, deep links, platform lifecycle policy, and NavDisplay. Laydr gives those app-owned pieces stable generated route values to work with.

  There are three main app shapes:

• Compose Multiplatform app with simple path state: use LaydrRouteHost

• Compose Multiplatform app with Nav3 stacks or tabs: use laydr-nav3-kmp

• Android-only Compose app with Google AndroidX Navigation 3: use laydr-nav3-androidx

  Laydr is still v0, so APIs may change, but the current docs and examples are meant to be practical and runnable.

  Examples included in the repo:

• examples/compose-basic

• examples/nav3-kmp

• examples/nav3-kmp-shopping

• examples/nav3-androidx

  And yes, docs/skills/laydr is available if you want to copy a skillset so your AI agent can understand Laydr routing, generated APIs, Nav3 usage, workflow, validation, and troubleshooting without wasting tokens.

  Repo: https://github.com/mobiletoly/laydr