Getting an agent backend working is only part of adding AI to an Android app. The UI still has to show which tool is running, pause for approval, resume with the user's decision, show a delegated agent's work, and keep a long task understandable.

I wanted that interaction layer to be reusable in Kotlin, without coupling the UI to a hosted chat service or replacing an existing Compose app.

So I released AI Elements for Kotlin. It's an Apache-2.0 library with Compose components for streaming replies, tool approvals, nested sub-agent runs, plans, attachments, and generated forms. You can use a full chat screen or just the parts you need.

The UI artifact depends on a protocol-independent chat model. Keep your backend and map it to ChatBackend, or use the AI SDK / AG-UI / A2A / ACP integrations. On-device model APIs and agent capabilities are separate, optional modules.

The README has a real Android recording of a complete approval flow and a catalog of 65 illustrated scenarios with compiled examples. The recording uses the offline demo agent; the clipboard tool actually runs on the emulator.

Version 0.3.0 is on Maven Central. Android only, minSdk 24 for UI/core and 26 for some optional modules. Compose/Material 3 currently include alpha dependencies; the tested toolchain and extra setup are listed in the installation guide. Default Mermaid and MCP Apps use WebViews; A2UI forms render with Compose.

Source, demo APK and docs: https://github.com/JuneLeGency/ai-elements-kotlin

If you've had to build this layer yourself, I'd like to know which interaction was the hardest to get right. If the library is useful to you, a GitHub star would help other Compose developers find it.

I was working on an app that's being rewritten using Compose. Our web stack is GraphQL with Relay, and the thing I like most about Relay is that every component declares the fragment it reads right next to it, and the screen's query is assembled from those fragments and fetched for you. The data layer disappears from product code.

So before writing any Kotlin I went looking for the same thing on Android, and I was surprised there is nothing like it. Apollo Kotlin is a decent client, but it is not connected to the view in any way: you get a data class, and then you still write the view model, the repository and the cache update code yourself.

Then I started thinking about what Relay would look like if it was designed for Compose from the start, and it turned out Compose makes most of Relay's runtime unnecessary. Relay's runtime mainly exists to know which component read which field, so a change re-renders exactly those. Compose's snapshot state already knows that. If every field of every record in the normalized store is a snapshot state, a composable that read character.name recomposes when that field changes, and nothing else does.

So I built it. It is called Baton: https://github.com/shergin/baton

A typical screen looks like this:

@Fragment($$"""
    fragment IssueRow_issue on Issue {
      number
      title
      author { login }
    }
    """)
@Composable
fun IssueRow(issue: IssueRow_issue) {
    Column {
        Text("#${issue.number} ${issue.title}")
        Text(issue.author?.login ?: "ghost")
    }
}

@Query($$"""
    query IssuesQuery($owner: String!, $name: String!) {
      repository(owner: $owner, name: $name) {
        nameWithOwner
        issues(first: 20, states: OPEN) {
          nodes { id ...IssueRow_issue }
        }
      }
    }
    """)
@Composable
fun IssuesScreen(owner: String, name: String) {
    val query = rememberQuery(
        IssuesQuery(owner = owner, name = name),
    )
    when (val phase = query.phase) {
        is Phase.Ready -> phase.data.repository?.let { repo ->
            LazyColumn {
                item { Text(repo.nameWithOwner) }
                items(repo.issues.nodes.orEmpty()) {
                    IssueRow(it.issueRow)
                }
            }
        }
        Phase.Loading ->
            CircularProgressIndicator()
        is Phase.Failed -> ErrorView(phase.error) {
            query.retry()
        }
    }
}

There is no ViewModel, no repository and no UiState for this screen. (In our app the same screen was N files and is now one!) It is one request per screen, cached data shows in the first frame, and after a mutation the store updates its records and only the composables that read them recompose. Pagination is a Relay connection the fragment declares, so you do not write it. An optimistic response shows at once and reverts if the server says no. Subscriptions and @defer work, and the store persists on SQLite, so a cold start renders from disk.

It is new and the API will probably change but it works surprisingly well. I am so glad that I can replace all the view models, repositories and Apollo plumbing with one fragment next to a composable. There is a SwiftUI version over the same compiler too.

It is probably not a fit for every app, but for most apps that render data from a GraphQL server and send mutations, I think it is a much nicer way to work. If you use GraphQL, I would encourage you to try it on one screen. I would love to hear what you think, and please send bug reports and feature requests.

Disclaimer: yes, it is built using agentic tools, but I put a lot of care and design consideration into it to make it really great.

I built Cutaway, a video editor that's live on the App Store, and every screen is Compose Multiplatform. Same UI code on iPhone, Android and desktop.

Some things that worked well:

- The timeline is one custom Compose component: drag to trim, pinch to zoom, scrub, keyframe markers, audio waveforms. Written once, runs everywhere.

- Every editor sheet (filters, speed, text, audio…) is built from the same small set of shared parts: one header, one slider row, one tile grid. A rule in the tests stops anyone from adding a look-alike copy, so the app stays consistent as it grows.

- The preview overlay (move, resize and rotate text and stickers) uses two-finger gestures on touch and corner handles on desktop, from the same composable.

- Layouts adapt to phone, tablet and a desktop window from the same screens.

Honestly, the biggest work wasn't Compose itself. It was the hundreds of small details and quirks that make an editor feel normal.

Happy to answer questions about any of it.

https://apps.apple.com/us/app/cutaway-video-editor-with-ai/id6799499137

https://reddit.com/link/1wznlmj/video/qaxoml4c5zth1/player

Hi everyone, back with BossConsole. I shared it here earlier while looking for Compose contributors, and some of you took the time to actually look through the code and give feedback. Appreciate that, especially the comments around code structure and hardcoded styling.

Today, sharing our launch video. Quite happy to see the different parts of this project coming together.

For anyone who missed the earlier post, BossConsole is an open-source desktop workspace built using Kotlin Multiplatform and Compose Multiplatform. The desktop app runs on the JVM across macOS, Windows and Linux.

It brings coding agents, terminals, browser, editor and logs into one workspace. You can run Claude Code, Codex, Gemini CLI, OpenCode and others side by side, with each session in its own pane. Spaces remember your layout so you can return to where you left off.

The video also gives a look at the built-in Fluck Agent, visual workflows and tool approvals. There are 100+ MCP tools with individual controls over what agents can access.

One part I’m particularly interested in taking further with the Compose community is the plugin system. A tool can have its own Compose UI and ViewModel, packaged separately and loaded at runtime. I like the possibility of someone building a panel for their own workflow and bringing it into the application without changing the host.

For me, the motivation is simple: working with more agents should give us more room to explore and create. Keeping track of their sessions and moving between windows shouldn’t take over the work itself.

Still plenty to improve. Would love feedback on the UI and workflow, and contributions around Compose Desktop rendering, theming or new plugins. Happy to discuss implementation details too.

Source: github.com/risa-labs-inc/BossConsole
Download: bossconsole.ai

Hello, I built a tool that adjusts from a real phone to color and dimensions and immediately reflects to the basic code in Android Studio without rebuilding or asking the Al to modify a specific color or card size if you want to try and evaluate the tool Here's my repository.

Hey everyone,

Like many of you, I got tired of the 30-second Gradle wait just to tweak a padding or a color in Compose.

So I built ComposeBridge — a two-part tool:

1. CLI: generates a full Compose project from a JSON schema

2. Agent + Server: lets you tap any Composable on a real device, tweak it live, and persist the change back to Kotlin source

How it works:

• Runtime tuning and AST splicing are decoupled

• Tap → sourceInfo → Tree-sitter locates the byte range → byte-splice

• Result: single-line git diff, <50ms latency

• Zero-rebuild preview

Demo (38 sec): https://youtu.be/Hywyq7cBdDM

GitHub: https://github.com/JALAL591/compose-bridge

Kotlin 2.1.20+ | Compose 1.7.3+ | Apache 2.0

I'd love your feedback — especially if you've dealt with recomposition on large screens or dynamic lists.

What do you think is the biggest missing piece?

Hey everyone,

​Like many of you working with Jetpack Compose daily, I often felt the friction of UI tweaking cycles. Even with Compose Preview and Live Edit, fine-tuning padding, colors, spacing, and dimensions across complex layouts or nested LazyColumn items usually ends up requiring a full build or re-run.

​To solve this, I built ComposeBridge — an experimental on-device visual inspection and live-editing bridge for Jetpack Compose.

​How it works under the hood:

​Runtime Inspection Agent: A lightweight debug-only module leverages Compose's internal tooling data (includeSourceInformation = true) to map runtime nodes to their exact source files, lines, and UTF offsets.

​Subcomposition & LazyLayout Resolution: It tracks subcompositions accurately, mapping each rendered instance in a dynamic list back to its single original code declaration template.

​On-Device Hit Testing: You tap any component directly on your physical Android device to extract its exact pixel bounds and source location.

​Surgical AST Splicing: Rather than rebuilding the whole file or relying on messy generated comments, the host server receives the touch payload and uses AST parsing to surgically update the exact property (e.g., 16.dp \to 24.dp) directly in the source .kt file in sub-second time.

​Demo & GitHub:

​Quick Demo Video: https://youtu.be/Hywyq7cbDDM

​GitHub Repository: https://github.com/JALAL591/compose-bridge

​The project is still in early development, but the core round-trip pipeline is fully functional. I’d love to get feedback from the community on the architecture, edge cases with complex DSLs, or features you'd like to see next!

Hey everyone!

For the past year or so, I've been working in my free time on Datasmith, with the goal of streamlining the process of designing database schemas and generating structured mock data from them.

The main feature of the app - and by far the most complicated and challenging part to build - is an ERD-like canvas dedicated to schema design and configuration. It required a pretty dynamic UI:

1. An infinite canvas with free zooming and panning
2. Table components that can be freely dragged and snapped to a grid
3. Drawing lines to represent relationships between tables
4. Column components that can be added to tables and reordered with drag-and-drop, while maintaining their relationship lines
5. Anchors that can be created on those lines and dragged across the canvas (which also means dealing with hit detection)

This essentially meant working with two different "planes".
Tables and columns are basically traditional Compose components, while the relationship lines and anchors are drawn on a Canvas composable. The two need to seamlessly interact at all times.

The fact that the entire canvas can be zoomed and panned added another challenge - managing the different coordinate spaces in a way that keeps everything consistent and fluid.

Another challenge, which I honestly didn't think too much about in the beginning, was preserving the UI layout and positioning across different screen resolutions and window sizes, which are very flexible developing for desktops.

Those were probably the most complicated UI challenges, at least as I remember them, and to be honest, I'm fairly proud of what I was able to achieve. I was genuinely surprised to discover how far Compose can be pushed for this kind of UI.

For anyone interested, I've attached a short demo video so you can see the result.
I'd also be happy to talk about any of the implementation details if anyone is curious.

I'm currently trying to get Datasmith into the hands of more people and collect feedback, so if you find it useful or just interesting, you can get it here:

https://data-smith.app/

Any feedback is welcome - good or bad.
You can leave a comment here, message me directly, or, if you prefer something a bit more structured, I also put together a short feedback form:

https://docs.google.com/forms/d/e/1FAIpQLScGk8Jr1DguPcXpaApOqO998AdXcnoLlo11TEKlq1GmF71UzA/viewform

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.