r/androiddev

I've been working on CoinCurrently for almost 6 years at this point. After 4 years I felt really stuck and kind of realized that I won't get much further alone so I made a post on Reddit that I was looking for a designer. I found a guy and once we started revamping the app, we realized that there's so much more we want to do and that requires a better backend. Doing both the iOS and Android app, I figured we need a dedicated guy for backend. The team grew to 3 people. After almost a year and a half, we finally finished revamping the entire app. It's now better looking, easier to use and is faster than ever. Free, no ads, no tracking. It's all on your device. I'm really proud to show the new CoinCurrently to the world.

A: In my opinion, the problem CoinCurrently solves is ease of use. The bigger crypto trackers are so crammed with things and the UI looks very cluttered. We've spent a ton of time to make it as easy to use as possible, everything stored on device, no tracking, no ads, no account

B: I know there's a ton of crypto trackers out there but in my opinion, crypto should be privacy focused. A lot of the bigger apps and websites requires you to sign in to use certain features and they obviously use it for targeted ads. Nothing like that in CoinCurrently.

C: CoinCurrently is freemium. All features are available for free, but you can do more of it with premium. Monthly for $3.99 or annually for $29.99

I would appreciate your feedback so we can continue to make it a better app

iOS: CoinCurrently iOS

I know this is an iOS forum but I'll just throw in the Android and Web link too if anyone prefers those platforms, I hope that's okay.

Android: CoinCurrently Android

Web: CoinCurrently Web

Most voice input on Android - SpeechRecognizer.createSpeechRecognizer(context) calls — gets routed to Google's network-backed recognizer. I wanted that path to run locally, so I wrote one.

The service hooks the framework's SpeechRecognizer API. Once it's set as the default, any app calling createSpeechRecognizer(context) (no ComponentName) ends up in our pipeline and gets back transcription that never left the device. Pipeline is Silero VAD + Parakeet TDT v3 (114 languages, ~890 MB INT8) on ONNX Runtime with NNAPI.

Honest caveat: Gboard, Samsung Keyboard, and Google Assistant ship their own recognizers and skip the system default. So the default-IME voice button on most phones won't go through this. What does: accessibility tools, custom dictation UIs, and anything calling the framework API directly.

Models download on first use (~1.2 GB) via a foreground WorkManager job so it survives backgrounding. After that, fully offline.

Setup + demo APK: github.com/soniqo/speech-android

audio.soniqo:speech:0.0.9 on Maven Central

Library:

Happy to answer questions about the binder lifecycle, the foreground worker setup, or why SpeechRecognizer is such a tarpit of edge cases.

Finally found a developer with actually honest release notes 😭😂

I've been working on offline-first sync for Android apps that use Room.

Pattern: local write immediately → outbox queue → push/pull when online → handle conflicts if the same row changed on server.

Short demo (GIF): offline add → sync → wipe local DB → pull restores data.

Technical bits:

• Room stays the source of truth for entities

• Separate SQLDelight outbox (survives process death)

• KSP generates sync handlers from Entity/DAO

• Gradle plugin wires KSP + serialization

Stack is Kotlin 2.1, minSdk 24. Apache 2.0, sample + mock server in the repo.

Repo (if useful): https://github.com/Arsenoal/syncforge

Genuinely looking for architecture feedback:

1. Would you trust a library-owned outbox next to Room, or keep everything in-app?
2. What's the minimum you'd need before trying this in a non-toy app?

Happy to share Gradle setup in comments if anyone wants to poke at it.

I need to show user consent screen to users to connect their G drive for backup/sync. I'm struggling to get my Branding verified. Google asks for

1. Application home page - https://densermeerkat.github.io/June/
2. Application privacy policy link - https://densermeerkat.github.io/June/PRIVACY

My app is open source and available on GitHub. I don't have any dedicated homepage. I tried adding my repo URL and enabled GitHub Pages and added google site verification from Google Search console to verify the ownership to me, still the console isn't satisfied.

I know its a hot topic choosing between minimalism and a "out there" look but I fancied a go at building something I haven't seen before with a 3D element.

The basis is for folder use and organisation, each satellite orbiting is a folder and within it can contain up to 90 apps, if you have a lot on your phone you can have up to 8 folders per page and no limit to pages.

You can move and reorganise where on the centre sphere the apps live for quick single tap access. There's even a handy favourites dock you can summon from the bottom.

The A-Z scroller can either be clicked or swiped in from the right and a designated widgets page can be summoned from the left. This on top of the widgets you can stack on the home page.

I'm also building this to be foldable compatible.

There will be an expansive theme library, shown here is the sci-fi captured star theme and the earthy theme.

What do people think so far? Managed to optimise it pretty well so far and isn't drawing huge amounts of processing or battery, comfortably ran it all day on my pixel 10 pro fold.

Marked as WIP as still got a couple features to build out and tidy up as well as styling the 2D UI and popups.

based on ChefKissInc/Inferno emulator (huge thanks to them) with a few patches to make it work on Android.

Runs on Qemu through Termux

Source code with patches available at https://github.com/AlexZorzi/Inferno-Android

Note: Video has been cut in some loading screens to make it shorter

Why?

why not lmao

reposted, fixed video.

Figured it would have gotten the llm treatment.

Quick note first: I run a small ASO tool (Applyra), and that's where this data comes from, I stare at a lot of store listings. Just sharing the patterns because they're useful.

Over the last few months I've gone through a few hundred indie apps, mostly stuff people posted here or on X for feedback, roughly half iOS half Android. What got me was how repetitive it is, and how mechanical the fixes are once you stop thinking "marketing copy" and start thinking "indexed fields with rules". This isn't generic "optimize your metadata" advice. Every point below is a specific field, what each store does with it, and the fix. About 80% of the apps I look at get at least three of these wrong.

1. Half the title is empty (~70%). The title is the single heaviest ranking signal on both stores, weighted above everything else you write. You get 30 characters and most apps use a third of it. Concrete one I see constantly: an app whose entire title is "BudgetX". Seven of 30 characters, and it ranks for exactly one thing, its own brand. Same app titled "BudgetX: Expense Tracker" picks up expense and tracker for free and still fits in 30. Brand first, then your main keyword, then fill the rest.

2. Wasting or duplicating the second field (~60%). iOS subtitle (30 chars) and Android short description (80 chars) are both indexed and both heavily weighted. Two failures here. First, fluff like "Your daily companion", that ranks for nothing, nobody searches it. Second, the one people miss: on iOS, Apple reads your title, subtitle and keyword field as one combined pool and counts each word once. So repeating a title keyword in the subtitle is dead space. Use it for a fresh set of terms, not a rephrase. On Android the short description is also the first line users actually read, so make it keyword-rich and readable, e.g. "Track expenses, set budgets, save money".

3. Misunderstanding the description (~50%). iOS: the long description is NOT indexed. Zero effect on search rank, it only does conversion work once someone's already on the page. People burn a full day tuning 4,000 characters that move nothing. On iOS only three fields rank you: title, subtitle, keyword field. Android: the exact opposite, the description IS indexed and density matters (aim ~3-5% for your main term).

4. iOS keyword field used wrong (~45%). 100 characters, comma separated, no spaces. The classics: spaces after commas (across 20+ keywords that's 10-15% of the field gone), repeating words already in your title or subtitle (again, each word counts once across all of it), and writing phrases instead of singles, because "budget,tracker" beats "budget tracker", Apple recombines singles into every permutation itself. And don't spend characters on your brand name, your category, or stop words like "the" and "app". Apple already indexes those.

5. Android keyword stuffing (~25%). The opposite failure, usually from people who just learned the description is indexed and overcorrect. Same keyword 50 times, a raw keyword dump at the bottom, one sentence rewritten six ways. It's a double loss: Google's classifier demotes obviously unnatural density, and the unreadable copy kills your conversion at the same time. Hit your keyword naturally a few times, land around 3-5%, stop.

6. Skipping localization (~55%). The free traffic almost nobody touches. iOS: each storefront indexes at least two locales, so the keywords in your primary English listing (UK or US) already rank you in nearly every storefront in the world, with Canada being the main English market that needs its own. And every extra localization is its own indexed title/subtitle/keyword field, with keywords NOT combined across locales, so adding a language is a clean way to index a fresh batch of terms. Android is different: an English-only listing still shows up to other-language users (Google falls back to your default and can auto-translate), it just won't rank for searches in those languages. Localizing Spanish, Portuguese, German or French is how you get indexed for their search terms, and an LLM is fine for the keyword research.

7. Chasing keywords you can't win (~65%)! "Photo editor", "meditation", "fitness tracker", not happening with 50 downloads and a 4.2 against incumbents with 8-figure budgets. Difficulty scales with the leaders' download velocity and ratings, not just search volume, so a "low volume" term can be wide open while a popular one is sealed. Go long tail where you can actually place: "vintage photo filter", "meditation for anxiety", "retro film camera". Rank for ten of those, build velocity and reviews, then earn your way up to the head terms. You climb, you don't teleport.

8. Changing five things and tracking none (~80%). The big one. People tweak the listing, see nothing in three days, call ASO a scam, quit. Two problems: keywords take 2-4 weeks to settle (Apple's reindex is slow), so they bail right before it lands, and changing five things at once means a rank move tells you nothing about which change caused it. Change one or two variables at a time, log what and when, give it a full cycle.

The pattern I keep landing on: the apps that win aren't doing anything secret. They treat the listing as a set of indexed fields with rules and work them deliberately, while everyone else writes marketing copy and hopes. The bar really is that low, which is the optimistic read.