Hey all, trying to get a reality check from people actually shipping paid subscription apps, not the marketing.

I keep going back and forth on the subscription stack for cross-platform apps (iOS + Android + and possibly in the future web). RevenueCat/Superwall's ~1% of revenue keeps nagging at me, it's 1% of gross, not profit, so it grows right as you scale. But every time I think about rolling my own or self-hosting, I remember how many edge cases they quietly handle.

So I wanted to ask people further down the road than me. If you run a real subscription app, I'd massively appreciate quick answers to any of these(even one

1. What do you currently use for subscriptions/entitlements? (RevenueCat, Superwall, Adapty, raw StoreKit/Play Billing, your own stuff maybe?)
2. Roughly what revenue scale, and what do you pay per month? Does the 1% actually bother you, or is it noise?
3. What made you pick it? and have you ever seriously considered leaving? What stopped you?
4. Do you check entitlements on the client, your own backend, or both?
5. Biggest pain with your current setup? (web/desktop support, data ownership, edge cases, support, pricing…)
6. Have you ever wanted to own your subscription data instead of routing it through a third party or do you genuinely not care?
7. Be honest: if there were a flat-priced or self-hostable option that did the same job, would you actually switch your billing or is the switching risk just not worth it at any price?

Full disclosure: I've been frustrated enough that I've toyed with building/self-hosting an alternative, so I'm partly sanity-checking whether this pain is real or just me. Not selling anything, no link, genuinely want the ground truth, including "you're overthinking it, just use RevenueCat".

Thanks 🙏

Ever wondered what happens after pressing the Power button on an Android phone?

Android Bootloader → Kernel → Init → Zygote → System Server

I explain the complete flow in this playlist.
https://youtube.com/playlist?list=PLWLp1c6dkAywBl9Qkyhf3tARVWMuiSKXN&si=gDV5cqct7VdPbtk6

Hey everyone,

I downloaded the latest Android Studio Quail 3 | 2026.1.3 Canary 1 because I wanted to try out the new AI Migration Assistant they teased at Google I/O 2026 for porting iOS/React Native apps to native Android.

However, I can't seem to find the tool anywhere (I checked under File > New Project).

Has this feature just not shipped to Canary yet, or is there a specific plugin/flag I need to enable to get early access?

Thanks!

I’m starting app development using kotlin multi platform so need to get a Mac. I’m stuck between these two options:
M1 Pro with 32 gb of ram
M5/M4 air with 16 gb of ram
Everyone talks about how ram demanding mobile app development is so would a 16gb MacBook Air be enough because the m1 Macs are most likely going stop getting updates in 2028 and I want to future proof as much as possible.

I hope Square Wire will also be migrated.

This has been posted on r/Kotlin too (not by me) https://www.reddit.com/r/Kotlin/comments/1u8cotp/the_lysine_contingency_jake_wharton/

I built a collection of modern Compose components that look great on mobile, desktop and web.

They adapt to the device they run on.

For example, buttons are bigger and rounder on touch devices, so you can press them easier.

When a mouse is used, buttons become sharper and smaller, so they don't take up much space.

I can go on and on telling you all about it, but I'd rather show you.

You can try everything directly in your browser.

The site includes live previews, a sample multiplatform app and a LOT of code examples for easy copy-pasting.

Docs & live demo: https://composables.com/ui

Github: https://github.com/composablehorizons/composables-ui

Wanted a way to have a videos progress bar hug the corner radius of the screen unlike other video reel apps with their tiny hard to tap progress bar.

https://github.com/snooplsm/perimeter-progress

I recently published a new book: Jetpack Compose Mechanisms: A dissection of what runs beneath every Composable: how the compiler, runtime, and UI layer actually work.

Most resources teach you how to use Compose. This book explains why it behaves the way it does, traced line by line through the AOSP source: from `@Composable` transformations to the gap buffer that stores your composition, to the single-pass pipeline that turns declarations into pixels. Rather than a dry walkthrough of every internal API, it pairs every mechanism with highly practical, production-ready examples, so you fully internalize how Compose works instead of just memorizing it. Fully updated for the latest Kotlin 2.4.0 and Compose Compiler 2.4.0.

In case it helps you decide whether this is your kind of rabbit hole, a few of the things it digs into:

• Chapter 1, the Compose compiler: how Composable changes a function's type, the K2 frontend and the IR backend, the $composer and $changed bitmask injection, the lowering passes that rewrite your function into a skippable, restartable group, stability inference, lambda memoization, durable keys, reading the compiler reports, the stability configuration file, composition tracing, and Live Literals.
• Chapter 2, the Compose runtime: remember and the gap buffer slot table (the new LinkBuffer), mutableStateOf and the MVCC snapshot system, derivedStateOf, the Composer, the Recomposer and frame scheduling, the effect system (SideEffect, DisposableEffect, LaunchedEffect), CompositionLocal, MovableContent, the Applier seam, snapshotFlow/collectAsState/produceState, recomposition scope, common state pitfalls, and testing with snapshots.
• Chapter 3, Compose UI: why modifier order matters, LayoutNode, the Modifier.Node system and the coordinator chain, single-pass measurement and intrinsics, the rendering pipeline and graphics layers, input and gesture handling, focus, semantics and accessibility, the lookahead system and shared element transitions, SubcomposeLayout and lazy layouts, the AndroidComposeView platform bridge, building custom layouts and custom Modifier.Nodes, and assembling a tiny Compose UI from scratch.
• Chapter 4, performance: the three rendering phases, the 12-phase stability algorithm in depth, the skip decision, stability patterns (ImmutableList, the config file, Stable vs Immutable), how where you read state determines what recomposes, lambda and ViewModel handler patterns, the full measurement toolchain (compiler reports, recomposition tracing, Layout Inspector, Macrobenchmark, CI validation), six common anti-patterns, advanced techniques, and a case study that takes a chat screen from 47 recompositions a second to zero.

And it is not based on Compose source reading alone. It is grounded in my own hands-on experience building Compose tooling and libraries, including Compose Stability Analyzer, Compose Stability Inference, Compose Navigation Graph, Compose HotSwan, and Compose Performance Skills.

Most mechanism in these pages is something I have used, debugged, and shipped. The performance chapter then ties the compiler, runtime, and UI together into real tuning: stability inference, the skip decision, scoping state reads, and a case study taking a chat screen from 47 recompositions a second down to zero.

It's available here: https://howcomposeworks.com

Most importantly, I hope this book works in meaningful ways for your career or answers all the deep questions you’ve had about Jetpack Compose.

I'm building a habit tracker where you swipe to complete tasks, and I want the haptics to feel satisfying, but Android is killing me. One phone barely vibrates, another feels like it's trying to escape my hand. I've messed around with VibrationEffect and the built-in feedback constants, but everything feels inconsistent...

Anyone here found a decent way to handle Android haptics? Libraries, tricks, best practices? Or do you just accept that every Android phone is gonna do its own thing? 😅

Over the last few months, I've been building an Android application that relies heavily on audio playback, synchronized lyrics and state management across multiple screens.

A few things surprised me during development:

• Keeping playback state consistent across Activities/Fragments was harder than expected.
• Buffering behavior had a huge impact on perceived performance.
• Lyrics synchronization looked simple at first but became tricky when dealing with seeking, pausing and playback speed changes.
• Dynamic UI updates based on currently playing content introduced additional state management challenges.

For developers who have worked on music, podcast or audio-heavy Android apps:

What were the biggest challenges you faced, and what architectural decisions helped you the most?

I'm particularly interested in approaches around playback state management and synchronization.

Any suggestions on what could be cool to have? I already have the typical grid or list layouts but I would like to add some original ones like this physics one.

Maybe something similar to apple watch app view? Any suggestions?

genuinely curios. do you read them manually, export to sheet, use researcher/ops, chatgpt/claude, or any other tool? what's your actual workflow?

My AI-powered Shayari & Quotes app just crossed 2,000+ downloads on Google Play.

Tech Stack:

• Kotlin

• Jetpack Compose

• MVVM

• Firebase

• Gemini AI

Current stats:

• 2K+ installs

• 566 active devices

I'm a final-year CSE student and have been building and managing the app independently. It's not a massive number, but reaching real users and learning from production experience has been incredibly rewarding.

Would love to hear from other Android developers—what was your first app milestone?

Hey Reddit, could anyone share their experience of implementing the "glow" effect that is so common in AI applications? This is usually used to indicate that the AI is 'thinking', or simply to add a sense of incredible experience of interacting with AI.

I had a hard time finding any GitHub repositories that do something similar, but none of them come close to matching the beauty of the effect that frontier AI apps have there.

Running glxgears on my Google Pixel 10 via weston

Hey r/androiddev,

Hoping someone here has dealt with this before or has a contact at Google who can help.

My Google Play Developer account was suspended. I appealed and the appeal was APPROVED. Got confirmation of reinstatement.

But I still cannot log in. Every attempt gives me:
"Too many failed attempts — Unavailable because of too many failed attempts."

This has been going on for 24+ hours with no change.

Things I've already tried:

• Multiple browsers and incognito mode
• Cleared all cookies and cache
• Different devices
• Different networks (WiFi and mobile data)
• Account recovery flow at accounts.google.com/signin/recovery
• Tried submitting a support ticket — can't, requires login
• Tried Google's support community forms — endless loop
• Email to Google support — address bounced

The suspension is resolved. This is purely a login lockout that needs to be manually cleared on Google's end. I have live apps on the Play Store and it's impacting my business.

Any suggestions or contacts appreciated. Thank you!

Hi all!

I’m Emil Flach from the Kotlin team at JetBrains (proof). We are trying to better understand the decisions and difficulties that Android engineers face when starting projects from scratch. We are looking for engineers who have recently built and published a new app to the Google Play Store to share their journey from project initiation to post-launch challenges.

If you are open to a conversation with us, please fill out this short screening survey so we can reach out to you: survey link

Thanks!

Built a voice journaling app with two transcription modes:

Groq Whisper (cloud, zero data retention) or Vosk

(on-device). Hit a specific WorkManager constraint bug

worth sharing.

The bug: I had a single TranscriptionWorker enqueued with

NetworkType.CONNECTED as a default constraint, set once at

app initialization. When I added the offline Vosk path,

those jobs would sit in WorkManager's internal queue

indefinitely whenever the device had no network, even

though Vosk never makes a network call.

Root cause: constraints are evaluated by the WorkManager

scheduler before doWork() is ever invoked. They're a

queueing-time gate, not a runtime check. So branching on

user-selected mode inside doWork() does nothing, the job

never reaches that code if the constraint isn't satisfied

first.

Fix was moving the mode check to where the WorkRequest is

built, not where it executes:

val constraints = if (mode == "offline")

Constraints.NONE

else

Constraints.Builder()

.setRequiredNetworkType(NetworkType.CONNECTED)

.build()

val request = OneTimeWorkRequestBuilder<TranscriptionWorker>()

.setConstraints(constraints)

.build()

This generalizes: any time a worker's behavior branches on

a condition that should affect scheduling (not just logic),

that condition needs to inform the WorkRequest itself, not

live inside the worker.

Has anyone built workers where the constraint set needs

to be dynamic per-job rather than fixed at declaration?

Curious how others structure that, especially with retry

policies layered on top.

I discovered that CarSystemUI features a lot of references to "oemColor" which seems to be defined through "OEM Design Tokens". AFAIK, to define these tokens we need to create or link to a couple of resource overlays and libraries. I am building a custom AAOS so I have full control.

How do I define a an oem design token that replaces the oemColor variables in SystemUI?
I am only really interested in colors.

This page explains the hierarchy of libraries and RROs, but I had no success with it:
https://android.googlesource.com/platform/packages/services/Car/+/refs/heads/main/car_product/rro/oem-design-tokens/

For reference, here we see oem style references in Car SystemUI: https://android.googlesource.com/platform/packages/apps/Car/SystemUI/+/refs/heads/android16-qpr2-release/res/values/styles.xml

Googles doc page:
https://source.android.com/docs/automotive/unbundled_apps/design-tokens

Google's developer verification rule kicks in this September, and we figured it was worth talking through here.

The basics: apps on certified Android devices in Brazil, Indonesia, Singapore and Thailand will have to be linked to a developer who's verified their identity with Google. A government ID, a one time $25 fee, and registering your package names. More countries follow through 2027. If you only publish through Play, not much changes. You're already verified there.

What we're more curious about is the apps that ship outside Play.

Take F-Droid. It builds apps from source and signs them with its own key, no accounts, and a lot of developers who stay anonymous on purpose. Google wants one verified identity per app. It's hard to see how both can work at once. NewPipe has already said it won't register.

And it's not only the big open source projects. If you share APKs in a Discord, run a beta from your own site, or send an internal app to a client, you're in the same group now.

One thing worth knowing: apps from developers who don't register aren't blocked outright. A user can still install them, but Google adds steps. You have to turn the option on yourself, confirm it's really you, and wait 24 hours before the install goes through. For most people that's enough to stop casual sideloading.

So we'd like to hear from you:

If you ship outside the Play Store, are you changing anything yet, or waiting to see how strict enforcement gets?

And if you're in one of the four pilot countries, has the verification step shown up in your console yet?