DEV Community: EltaCrew

I turned my website directory into an offline Android app. Here's the one SQL trick that made it work

EltaCrew — Sat, 12 Sep 2026 09:45:26 +0000

For about two months I've run a small web directory of useful sites and AI tools at eltacrew.com/sitedex. It's a server-rendered Astro site with Postgres behind it. This week I shipped the same directory as an Android app — and the interesting part isn't the app, it's the constraint I gave myself: the app must work with the network off, and must show every user the same "today's picks" without asking a server.

Here's how that went.

The constraint

A directory app that fetches a list from an API is a web page with extra steps. If the API is slow, the app is slow; if I take the server down, the app is dead. So the data (~800 sites, 9 categories, tags, pricing, descriptions in 5 languages) ships inside the APK as a JSON asset and is loaded into a Room database on first run. Search, filter and browse all hit SQLite locally. The only things that touch the network are the site thumbnails (served from my box) and the ad SDK.

That gave me a second problem.

"Today's picks" without a server

On the web version the home page shuffles the featured sites once a day, so it looks alive but stays stable within the day. The server just does that. In the app there is no server in the loop, and I also wanted this to be a Paging query — the list is long and I didn't want to load 800 rows to shuffle them in Kotlin.

So the shuffle has to be an ORDER BY expression that SQLite can evaluate, seeded by the date, and I need Kotlin to be able to compute the same ordering (for the detail screen's "next / previous" navigation).

The seed is just today's date:

fun today(): Int {
    val c = Calendar.getInstance()
    return c.get(Calendar.YEAR) * 10000 + (c.get(Calendar.MONTH) + 1) * 100 + c.get(Calendar.DAY_OF_MONTH)
}

And the ordering key is a linear congruential hash of (id, seed):

ORDER BY (id * 1103515245 + :seed * 12345) % 2147483647

fun key(id: Int, seed: Int): Long =
    (id.toLong() * 1103515245L + seed.toLong() * 12345L) % 2147483647L

Two things bit me here, and they're the reason this post exists:

SQLite has no md5(), no XOR, no random(seed). Anything fancier than multiply/add/modulo isn't available in a Room query without a custom function. So the hash is deliberately dumb.
SQLite integers are 64-bit; Kotlin Int is 32-bit and wraps. My first Kotlin version used Int and produced a different order from the SQL, so "next" on the detail screen jumped somewhere random. Do the arithmetic in Long on the Kotlin side and it matches exactly.

Pull-to-refresh uses a seed derived from the current time instead, so it's a genuinely new shuffle that can never collide with the day's seed.

What else is in the app

Three view modes (mixed cards, list, grid), search, category and pricing filters.
Five languages (en, ko, ja, zh, es) — the descriptions are bundled, not translated at runtime.
A submit form that posts to the web directory, so app users and web users feed the same catalogue.
No login, no account, no billing code. Ads are one banner in a reserved slot plus a dismissible native card on start and exit — no interstitials, app-open or rewarded ads (InterstitialAd/AppOpenAd/RewardedAd: zero occurrences).

What I'd tell past me

Bundling the data was the right call. First-run is instant and the app is indifferent to my server's uptime. The cost is that adding sites means shipping an app update — fine for a directory that changes weekly, wrong for anything real-time.
If Kotlin and SQL both need the same ordering, write the SQL first and make Kotlin imitate it, not the other way around.
Paging treats an empty table as "loaded, zero rows", not "loading" — so on first run, before the JSON import finished, the list was a blank white screen with no spinner. Gate the list on the import, not on the query.

It went live this week; the web version has been up since July. If you try the app and something's off — especially a site that's dead or miscategorised — the submit form goes straight to me.

Play Store: https://play.google.com/store/apps/details?id=com.eltacrew.sitedex
Web: https://eltacrew.com/sitedex

I'm the developer of both the site and the app.

I read 13,861 reviews of 5 countdown / D-day apps. Half the anger is about one feature being put behind a paywall

EltaCrew — Sat, 12 Sep 2026 09:45:00 +0000

I just shipped a small exam-countdown app for Android called ExamDay. The category ("D-day" apps, as they're called in Korea) is old and crowded, so before writing the listing I pulled the public reviews of the five most-installed countdown apps on Google Play and read everything rated 1–3★.

This is about the category, not my app. If you're building anything with a home-screen widget, the middle section is the part to read.

What I looked at

App	Installs	Rating	Text reviews	1–3★
TheDayBefore	10M+	4.58 (112k)	4,222	459
Countdown Widget	10M+	4.16 (135k)	3,122	998
Time Until	5M+	4.55 (50k)	3,017	615
Days To	1M+	4.66 (28k)	3,002	771
Days counter	1M+	4.61 (7k)	498	54

Method: google-play-scraper (Python), en + ko, newest first, up to 3,000 per language per app. Play only returns reviews that have text. 2,897 reviews rated 1–3★, keyword-bucketed, sorted by count and by "helpful" votes.

The complaints, ranked

#	Complaint	Reviews	👍 helpful votes
1	Too many ads	858	1,451
2	Widget (paywalled, doesn't refresh, wrong size)	541	1,016
3	Paywall / subscription	448	1,105
4	Got worse after an update	187	540
5	Too complicated for a countdown	190	211
6	Notifications forced	95	208
7	Status bar / lock screen	43	58

(A "date calculation" bucket also scored high, but it's mostly the word "count" matching — I only quote reviews I read.)

Buckets 1, 3 and 4 are largely the same story told three ways.

The one-time purchase that became $15 a week

Countdown Widget has the lowest rating in the set (4.16) and the most 1★ reviews (841). Almost all of the upvoted ones say this (70, 62, 51, 47, 38, 33 👍):

"I previously paid to unlock the premium features as it used to be a one time payment. Now I've lost what I've had all this time, am slammed with ads non-stop, and to get the premium version back, I have to pay $14.99 a week?!?"

"THEY'RE TRYING TO SIGN PEOPLE UP FOR $780/YEAR!!! …for a simple timer."

"ridiculous amount of ads. edit for dev: of course the paid version doesn't have ads. it's also 18 dollars a week. for a countdown."

Whatever you think about pricing, the mechanics are instructive: users who had paid were moved to the free tier, and the free tier got heavier ads at the same time. That's where the 👍 comes from — not the price, the reversal.

Widgets: the whole point, and the thing that breaks

Days To (47, 32, 27 👍):

"I downloaded this app to set up a widget, only to find that having a widget is a 'premium' feature. I'd say the widget aspect is pretty integral to having a countdown on your phone."

"It's a lovely app with beautiful background options… My only complaint is it doesn't have widgets."

Time Until (43, 32 👍):

"I paid for this. What happened to the widget? It's useless now. The whole point of the countdown is to be able to see the countdown. The widget does not refresh anymore. You got to open and 'apply' each time."

"Homescreen widget 'literally never' loads or works anymore… It's been broken for like a year or more"

And the most-upvoted review in the whole dataset (89 👍), also Time Until: the widget doesn't honour the display options, custom image placement, or scale its text when the widget is enlarged.

Nobody is asking for much. They want the number on the home screen, updated at midnight, in the size they chose.

Ads, specifically

TheDayBefore (79 👍): "the app itself seems great, but I just can't stand the ads, they pop up way too often and you have to actually watch it for 20+ seconds to close it." Time Until (37 👍): "every three taps, I get another ad… My phone is set to mute. The full screen ads when opening completely ignored that." Days To (21 👍): "Creating a countdown takes 3 or 4 steps, and there is an advertisement after each."

Small things people cared about

Can't create a countdown without a reminder (Time Until, 24 👍).
Full-screen view is partially hidden under the status bar; long event names break mid-word (24 👍).
Wants a recurring daily countdown ("time until wake up, 6 am every day") (25 👍).
Korean review: D-17 works but D+17 (days since) doesn't (4 👍).

What I took from this

Don't paywall the widget. In a countdown app it isn't a premium feature, it's the product. Three of the five apps got their worst reviews for exactly this.
Never move paying users down. The reversal is what people upvote.
Ads in a countdown app have almost no surface to hide behind — the app is opened for three seconds. A full-screen ad is 100% of the session.
The widget must update by itself at midnight and survive reboots; "open the app and press apply" is a bug, not a workaround.

What ExamDay does about it (and what it doesn't)

Only things you can check in the app or listing:

Widgets are free and built in — a single-exam widget and a multi-exam widget (grid or list), both configurable from the home screen. No premium tier exists; there is no billing code in the app.
Ads: one banner in a reserved slot plus a dismissible native card at start and on exit. InterstitialAd, AppOpenAd, RewardedAd: zero occurrences. The banner is folded away on onboarding, the notification explainer and the full-screen view.
No login, no server of ours. Backup is a single file you export and import yourself.
Reminders are opt-in (D-30/7/3/1/day, with a "Not now" on the explainer) and scheduled with setExactAndAllowWhileIdle.
The day count is computed from midnight to midnight and rounded, so the 23- and 25-hour DST days don't shift it by one (unit-tested — the #1 app in this list has an old review about exactly that bug).
21 exam presets, photo backgrounds (5 built-in or your gallery), full-screen view, study timer, stats, spaced-repetition review reminders (1/3/7/15 days).

What it doesn't have yet: sharing a countdown as an image, recurring countdowns, calendar import, and a persistent status-bar countdown — all things people asked for above. It shipped this week, so I can't yet tell you how reliably the widget refreshes on every launcher; if it doesn't on yours, tell me.

Play Store: https://play.google.com/store/apps/details?id=com.eltacrew.examday

Data collected 2026-09-12 with google-play-scraper. Quotes are verbatim from public Google Play reviews; Korean ones are my translation. I'm the developer of ExamDay; competitor names identify the public listings analysed.

I read 18,464 reviews of 6 habit tracker apps. The #1 upvoted complaint is something none of them fixed

EltaCrew — Sat, 12 Sep 2026 09:43:52 +0000

I just released a small habit tracker for Android called HabitDeck. Before writing its store listing I wanted to know what people actually complain about in the apps that already have millions of installs — not what I assumed they complain about. So I pulled every public review I could for six of the biggest habit trackers on Google Play and read the 1–3★ ones.

This is about the category. If you're building or choosing a habit app, the ranking below is the useful part.

What I looked at

App	Installs	Rating	Text reviews	1–3★
Habit Tracker – Habit Diary	10M+	4.75 (135k)	3,119	225
HabitNow	5M+	4.73 (93k)	3,226	230
Loop Habit Tracker	5M+	4.71 (63k)	3,567	216
Goal & Habit Tracker Calendar	5M+	4.77 (52k)	3,582	164
Routinery (Routine Planner)	1M+	4.52 (18k)	3,746	858
HabitKit	500k+	4.60 (12k)	1,224	227

Method: google-play-scraper (Python), en + ko, newest first, up to 3,000 per language per app. Play only returns reviews with text. I keyword-bucketed the 1,920 reviews rated 1–3★ and sorted by count and by "helpful" votes.

The complaints, ranked

#	Complaint	Reviews	👍 helpful votes
1	Paywall / subscription	450	1,197
2	Notifications don't fire (or fire wrong)	267	779
3	Crashes / slow to open	171	525
4	Lost data / backup	149	368
5	Widget	141	240
6	Confusing / can't do X	98	319
7	Ads	100	246
8	Tracking / privacy	52	184

Two things surprised me.

The single most-upvoted review is about editing yesterday

119 👍, Korean, on Loop (the open-source one, 5M+ installs):

"If I forget to check or check the wrong thing and the day changes, the previous day isn't shown, so I can't check it or fix it. Annoying. And you can't set a 7-day view — it only shows 4 days."

Nothing else in 18,464 reviews got close to that vote count. It's not a crash, not a paywall — it's I missed a tap at 11:58 pm and now my record is wrong forever. Every habit app has a streak; not every habit app lets you repair it.

Paywall complaints are mostly about not being told

Routinery's low ratings are dominated by one story (45 👍):

"No indication that you're on a 7-day trial. I had to find out why my routines were 'archived.' On the second day of using this app, I'm prompted to resubscribe for a membership plan to have more than two routines."

A Korean review of Habit Diary (29 👍): after ignoring the premium prompt for a few days, they could no longer create habits. And a fair one (42 👍): "Problem is the cost, 20 USD per year? I pay less for far more comprehensive apps."

The pattern isn't "free users hate paying." It's the limit appeared after I'd already invested days of data.

Notifications: the thing a habit app exists for

HabitNow, 47 👍, written at 3:19 am:

"DO NOT USE THE ALARMS!!! …I paid for the premium version, but I'm writing this at 3:19 in the morning after my 10:30pm alarm has yet again gone off hours differently"

Routinery, 30 👍: "notifications not working (they only pop up when you open the app, so don't actually notify you when it's time to start a routine)". Goal & Habit Tracker, 60 👍: the reminder sound options they'd used since 2016 were removed in an update.

Android has made exact, background alarms progressively harder (Doze, exact-alarm permission, OEM battery killers). Apps that schedule with setRepeating or a WorkManager job drift or get dropped; users experience it as "the app forgot me."

Fifteen seconds to tick a box

Habit Diary, 55 and 51 👍:

"I love this app and UI, but the load time is atrocious. It's a full 15 seconds every single time I open the app for the first time that day."

"marking them as done HAS to be a lightweight task and not something I have to spend 5-10 seconds staring at a loading screen (and then an ad, but…)"

The dev's reply blamed connectivity — which tells you the app waits on a network round-trip before it lets you tap a checkbox.

Widgets and backups, briefly

Widget: "Widgets freeze often. Those are the main reason I use the app" (Loop, 18 👍); a request to invert the check widget so undone habits are the bright ones (36 👍). Backup: "App crashes whenever I try to sign in. Extremely frustrating, since I'm paying for online backups" (Routinery, 16 👍).

What I took from this

Let people fix yesterday. The most-agreed-with complaint in the category is a missing edit affordance.
If there's a limit, show it on day one, not day three. The anger is about surprise, not price.
A habit app's notification is its product. Schedule each alarm individually with exact timing and reschedule after it fires; anything periodic gets dropped on real phones.
The tap that marks a habit done must not wait on the network.

What HabitDeck does about it (and what it doesn't)

Only things you can check in the app or listing:

No subscription, no billing code, no habit-count limit. Everything in the app is free, and there is no "trial" state to fall out of.
No login, no server of ours. Data is a local Room database; there's no network wait before the home screen. The only network traffic is the ad SDK.
Ads: one banner in a reserved slot plus a dismissible native card at start and exit. InterstitialAd, AppOpenAd, RewardedAd: zero occurrences. The banner is folded away on the onboarding, notification-explainer and PIN screens.
Reminders are scheduled one at a time with setExactAndAllowWhileIdle and re-armed after each fires — no setRepeating, no WorkManager. It asks for exact-alarm and battery-optimisation exemption up front and explains why before the system dialog.
Backup is a single file you export/import yourself — no account, free.
7 tracker types (water, sleep, mood, quit-smoking, counters…), calendar + stats, focus timer, PIN lock.

What it doesn't have yet, honestly: no home-screen widget, and you can't edit a past day — the calendar is read-only. That second one is the #1 complaint above, and it's the next thing I'm building. The app shipped this week, so I have no stability data to quote. If it breaks, tell me.

Play Store: https://play.google.com/store/apps/details?id=com.eltacrew.habitdeck

Data collected 2026-09-12 with google-play-scraper. Quotes are verbatim from public Google Play reviews; Korean ones are my translation. I'm the developer of HabitDeck; competitor names identify the public listings analysed.

I read 30,118 reviews of 7 phone-sensor apps (compass, ruler, sound meter…). The top complaint isn't accuracy

EltaCrew — Sat, 12 Sep 2026 09:43:49 +0000

I just shipped a small Android app called MeasureKit — nine phone-sensor tools in one place (compass, ruler, sound meter, magnifier, bubble level, clinometer, vibration meter, protractor, light meter). Before deciding what to put on its first Play Store screenshot, I wanted to know what people actually hate about the apps that already own this category. So I pulled every public review I could get for the most-installed app in each tool's niche and read the low-rated ones.

This post is about the category, not my app. If you build anything that turns a phone sensor into a "measurement", the pattern below will look familiar.

What I looked at

Tool	App	Installs	Rating	Text reviews	1–3★
Compass	Digital Compass	10M+	4.66 (616k)	6,000	765
Ruler	Ruler (nixgame)	10M+	4.37 (115k)	4,411	556
Sound meter	Sound meter: SPL & dB	5M+	4.62 (53k)	3,271	294
Magnifier	Magnifier + Flashlight	10M+	4.86 (242k)	6,000	187
Bubble level	Bubble Level (gamma)	10M+	4.69 (334k)	6,000	435
Vibration	Vibration Meter (sira)	5M+	4.39 (36k)	3,118	368
Light meter	Light Meter - Lux Meter	1M+	4.78 (17k)	1,316	86

Two more (a protractor and a clinometer) had one review each, so they're out. Method, so you can reproduce it: google-play-scraper (Python), languages en + ko, newest first, up to 3,000 per language per app. Play only returns reviews that have text, so those are text reviews, not total ratings. I then bucketed the 2,693 reviews rated 1–3★ by keyword and sorted the buckets two ways: by count, and by how many other people clicked "helpful" on them.

The complaints, ranked

#	Complaint	Reviews	👍 helpful votes
1	Too many ads	482	1,147
2	Not accurate	223	567
3	Scale / units wrong	136	868
4	Confusing / can't get out	76	198
5	Calibration / sensor	58	345
6	Privacy / tracking	37	337
7	Paywall	31	180

(The keyword classifier is crude — a "crash" bucket got 453 votes from a single Korean compass review that is really about accuracy. I only quote reviews I read myself.)

Accuracy is not the #1 complaint for a category whose entire job is being accurate. Ads are, by count and by votes. And the ad complaints aren't "there are ads" — they're about a specific trick.

1. Ads that cover the Android navigation buttons

The most-upvoted English review in the whole set (136 👍), on the sound meter:

"Once opened, you can't exit the app. Once opened, all the usual Android buttons and menus disappeared."

And the next three, same app (81, 72, 71 👍):

"It purposely obscures access to the android soft buttons, uses intrusive ad tactics to increase your 'interaction'…"

"The ads run right on top of the buttons for the back button and the home screen."

"…positioning the ads into the screen space that the bottom bar, where all the close app controls are, along with a very short reclose time is kind of devious"

On the bubble level (42 👍): "the ads pop up every time my screen turns off. There is no close button so I have to hit back." A level is something you hold with one hand against a shelf. Turning the screen off is the use case.

2. The ruler that needs a ruler

The single most-upvoted review in the dataset is Korean, on the ruler (192 👍):

"It looks really convenient with all the fitting functions, but the divisions don't set themselves per phone, so if you want to use it you need an actual ruler anyway. I wonder if the people leaving reviews had 1 cm set correctly, lol."

That's the whole problem with a screen ruler in one sentence: Android reports a nominal DPI, real panels differ, and if the app doesn't make calibration obvious, every measurement is off by a few percent and the user finds out at the worst time. Another one (71 👍) tried to calibrate against a real 4-inch mark and found the 1, 2, 3 inch marks still slightly misaligned — the calibration UI itself was imprecise.

Tablet users notice it most (15 👍): "on a tablet the size is way off."

3. The sound meter floor

61 👍:

"It doesn't matter how quiet it doesn't display below around 30–35 dB. Makes me wonder if it's a calibration issue or a compatibility issue with my phone or if my phone's mic is just bad."

This is a real physical limit — phone mics and their AGC don't go much lower — but the app gave no hint, so the user blamed themselves and the app equally.

4. Privacy consent as a wall

124 👍 on the ruler, 51 and 39 on the compass:

"It takes over half an hour to manually go through and uncheck every data tracking company that wants to track your data through this app."

"Privacy nightmare! It's a decent compass but I don't appreciate several hundred companies claiming they have a 'legitimate interest' in tracking me… you have to disable each individually."

A compass. It needs one sensor and zero network. The users know that, which is why the reaction is so strong.

5. Units and background

Vibration meter (64 👍): "Uses Mercalli instead of any unit of measure of amplitude or frequency. Completely useless." And (50 👍): "does not work in background, once cellphone is in standby state screen goes dark, the app does not detect anymore."

What I took from this

In a tool app, the ad placement matters more than the ad count. Nobody in 2,693 low reviews complained about a banner in its own slot. They complained about ads over the back button, ads on screen-off, and ads with a 1-second close delay.
Say what the sensor can't do, on the screen. The ruler and sound meter reviews are people discovering a hardware limit with no warning. A one-line "phone mics aren't calibrated instruments — adjust the offset in settings" would have turned a 3★ into a shrug.
Calibration has to be a first-class feature, not a hidden menu. The ruler's top complaint in two languages is the same thing.

What MeasureKit does about it (and what it doesn't)

Only things you can verify in the app or the listing:

No interstitial, app-open or rewarded ads. InterstitialAd, AppOpenAd, RewardedAd: zero occurrences in the codebase. There is one banner in a reserved slot at the bottom of the screen — it never overlays the tool or the system buttons — plus a dismissible native card at start and on exit.
No subscription, no billing code, no login, no server of ours. The only network traffic is the ad SDK.
Permissions are per tool and optional: mic (sound), camera (magnifier), location (compass — true north, sunrise/sunset, altitude; the compass works without it). Deny one and only that tool shows an in-screen note.
Ruler calibration is in Settings and on the ruler screen itself (a CAL button), with cm and fractional-inch scales.
Sound meter shows dB(A) with a user offset, and the screen says outright that a phone mic is not a calibrated instrument.
Vibration meter reports m/s² and g (RMS, peak, 8-hour limit), not just a Mercalli word.
Compass shows a sensor-accuracy warning and only applies true-north correction when it actually has a location.

What it doesn't do: it won't measure vibration with the screen off (no foreground service), it's a screen ruler, not a 3-metre tape, and its sensor readings are only as good as your phone's — same as everyone else's. It shipped this week, so I have no stability data worth quoting. If it breaks for you, tell me; that's the data I don't have.

Play Store: https://play.google.com/store/apps/details?id=com.eltacrew.measurekit

Data collected 2026-09-12 with google-play-scraper. Quotes are verbatim from public Google Play reviews; the Korean ones are my translation. I'm the developer of MeasureKit; competitor names are used only to identify the public listings analysed.

I read 524 reviews of 5 AdMob dashboard apps. Here's what people actually complain about

EltaCrew — Fri, 11 Sep 2026 13:53:26 +0000

I build a small AdMob/AdSense revenue dashboard for Android called AdDeck. Last week I needed to decide what to put on its first Play Store screenshot, and I didn't want to guess. So I pulled every public review I could get for the five most-installed AdMob dashboard apps on Google Play and read the low-rated ones, one by one.

This post is the result. It's mostly about the category, not my app — if you're building or choosing any tool that touches your ad revenue, the pattern is worth knowing.

What I looked at

App	Installs	Rating	Text reviews collected	1★	2★	3★
Dash For AdMob	50,000+	4.55 (897 ratings)	283	51	10	15
AdMobile – AdMob Metrics	50,000+	4.63 (950 ratings)	201	16	3	8
AdMob Dashboard (sirmaur)	1,000+	–	23	2	0	1
Ad Earnings – Admob Dashboard	1,000+	–	12	2	1	0
AdMoola	1,000+	–	5	0	0	0

Method, so you can reproduce it: google-play-scraper (Python), languages en + ko, sort by newest, all pages. Only reviews with text are returned by Play, so the counts above are text reviews, not total ratings. I then classified the 103 reviews rated 1–3★ by keyword into eight buckets and summed the "helpful" votes (👍) on each.

Two apps carry almost all the signal — Dash For AdMob and AdMobile. The other three simply don't have enough reviews to say anything.

The eight complaints, ranked

#	Complaint	Reviews	👍 helpful votes
1	Crashes / won't open	21	6
2	Infinite loading / data never shows	14	40
3	Too many ads	11	48
4	Trust / privacy	10	7
5	Paywall / subscription	7	8
6	Numbers don't match the console	4	8
7	Feature requests (widget, CTR, same-name apps)	3	0
8	Session expires / re-login	2	2

Counting by number of reviews, crashes win. Counting by how many other people clicked "helpful", the ranking flips: ads and loading problems are what the silent majority agreed with.

What each bucket actually says

1. Crashes. Most of these cluster around one update in April 2026 ("crashing on launch after update… check 16kb page size"), plus a steady drip of "keeps closing" across 2024–2025. This is the cost of an app that shipped years ago and is maintained in bursts. Nothing to learn here except: the category is old.

2. Infinite loading. The single most-upvoted review in the whole dataset (21 👍) is:

"…it has been unable to load anything besides their own ads. It will not display my own in[formation]."

And the second (6 👍):

"I have reported it for more than 1 year, the monthly and yearly report only shows loading forever."

3. Too many ads. This is the bucket with the most helpful votes (48), and the reviews are almost funny in their consistency:

"Littered with ads so people can see their ad revenue. Not for me."

"The ads are too much now, UX is dead. Implement ads tastefully."

"Interstitial ads are not organic. Find another way to use them or remove them." (11 👍)

Think about the user here. They are a developer who earns money from ads. They open an app to check that money. And the app makes them watch a full-screen video ad first. Of course they hate it — it's their own business model pointed back at them.

4. Trust and privacy. The apps ask for Google account access, and a meaningful number of users refuse:

"I can't give you full permission of my google Account. I can't trust this type of publisher."

"After registration I started receiving spam emails."

"Disaster application asking for personal information too." (AdMobile)

Some of these are misunderstandings (AdMob's reporting API does need an OAuth grant). But the fear is rational: this is financial data, and the user cannot see where it goes.

5. Paywall. AdMobile's low ratings are mostly this:

"You have to buy a subscription to see anything useful. Google's Admob mobile website is much better."

"Basic functionalities as premium paid features."

And a Korean Dash For AdMob review describes being charged ₩13,000/year the moment they tapped "payment settings" while trying to cancel.

6. Wrong numbers. "Always shows 100% match rate while AdMob says 54.98%." "Not showing the accurate earnings." Small bucket, but it's the scariest one for a dashboard.

7–8. The rest. People want a home-screen widget, CTR as a metric, and a way to tell an Android and iOS app with the same name apart. Sessions expiring daily annoy a couple of people.

What I took from this

Three things, in order of how sure I am:

An ad-revenue app must not be ad-heavy. The users are ad professionals. Full-screen and video ads in this category are self-sabotage, and the helpful-vote count says the community agrees.
Trust has to be visible, not claimed. "We respect your privacy" means nothing. What users can actually verify: the OAuth scope the app asks for, whether there's a server, whether there's a subscription.
Crashes and loading are the symptoms of age. I can't promise my app won't crash — it has ~10 installs and I have no crash data worth quoting. What I can do is not repeat the choices above.

What AdDeck does about it (and what it doesn't)

I'll keep this to things you can check in the app or on the Play listing, not adjectives.

No interstitial or video ads. The app has a native ad and a banner. That's it. (InterstitialAd, AppOpenAd, RewardedAd: zero occurrences in the codebase.)
No subscription, no paywall. There is no billing code in the app. Everything is free.
Read-only OAuth scopes only — admob.readonly and adsense.readonly. The app cannot change anything in your account.
No server of ours. The only hosts the app talks to are *.googleapis.com. Tokens and data stay on the device.
Widget, CTR, per-app ranking, mediation totals — the things people asked for above — are in.

What I can't claim: that it never crashes, that it's fast, or that its numbers are more accurate than anyone else's. It reads the same AdMob and AdSense reporting APIs everyone else does, and it's too new to have meaningful stability data. If you try it and it breaks, tell me — that's exactly the data I don't have yet.

Play Store: https://play.google.com/store/apps/details?id=com.eltacrew.addeck

Data collected 2026-09-11 with google-play-scraper. Review quotes are verbatim from public Google Play reviews. I'm the developer of AdDeck; the competitor apps' names are used only to identify the public listings analyzed.

How to track ad revenue across AdMob, AdSense and mediation networks in one dashboard

EltaCrew — Mon, 07 Sep 2026 10:56:20 +0000

If you monetize apps or sites with more than one ad network, you've probably hit this wall: your revenue is real, but it's scattered. AdMob reports one number, AdSense another, and your mediation partners — AppLovin, Unity, Meta Audience Network — each have their own console. There's no single place that tells you what you actually earned yesterday.

This post walks through why that happens, the options for pulling it together, and the trade-offs of each.

Why ad revenue ends up scattered

Each network is its own product with its own reporting API and its own definition of a "day":

AdMob reports mobile ad revenue, and can also surface mediation earnings if you route those networks through AdMob mediation.
AdSense is a separate product for web/content, with a separate login and API.
Mediation networks each keep their own dashboard, and their totals don't always match what AdMob attributes to them (different time zones, different rounding, reporting lag).

The result: to answer "what did I make yesterday, across everything?" you open several tabs and add it up by hand. Do that every morning and it gets old fast.

Option 1: A spreadsheet

The zero-cost starting point. Export CSVs from each console, paste into one sheet, sum.

Pros: free, full control, works with any network that offers an export.
Cons: manual, error-prone, and always a day behind. Time zones and currency conversion bite you. It doesn't scale past a couple of networks.

Option 2: The network APIs + your own script

Each major network exposes a reporting API (AdMob has the AdMob API; AdSense has the AdSense Management API; most mediation networks have reporting endpoints). You can pull them on a schedule and combine.

Pros: automated, exactly the fields you want.
Cons: you're now maintaining OAuth flows, token refresh, rate limits, and a place to run it. That's real engineering time for something that isn't your product.

A few things to get right if you go this route:

Use read-only scopes. For revenue, you only need read access. Never request a scope that can modify account settings.
Normalize time zones before you sum. AdMob's "today" and a mediation network's "today" can differ by hours.
Expect reporting lag. Same-day numbers are estimates and get revised. Don't treat the last data point as final.

Option 3: A dashboard that does the merge for you

If you don't want to build and babysit the pipeline, a purpose-built dashboard reads the networks for you and presents one combined view. The things worth checking before you connect your accounts:

What OAuth scope does it request? Revenue reporting only needs read access. If a tool asks for write scopes, ask why.
Where does your data live? Some tools pull your revenue into their own servers. An on-device app that never routes data through a third-party server has a much smaller blast radius.
Can you revoke it easily? OAuth access should be revocable from your Google account in one click.

A concrete example

I built a small Android app called AdDeck for exactly this, and it's a useful illustration of Option 3 done conservatively:

It connects with a read-only OAuth scope — it can read revenue and nothing else.
It runs 100% on-device: numbers go from the ad networks straight to your phone, with no backend in the middle, so no server is sitting on your earnings data.
It shows today's total, a per-app ranking with day-over-day change, and the month-to-date trend, and lets you tap any app for its own 7-day trend plus eCPM, CTR and fill rate. A home-screen widget shows the number without opening the app.

It's free on Android: https://play.google.com/store/apps/details?id=com.eltacrew.addeck

The takeaway

There's no single "right" answer — a spreadsheet is fine for two networks, a script makes sense if reporting is core to your workflow, and a dashboard saves time if you'd rather not maintain one. Whichever you pick, the two rules that matter are: read-only access, and know where your revenue data is stored. Everything else is convenience.

I got tired of opening four ad dashboards every morning, so I built one

EltaCrew — Mon, 07 Sep 2026 10:54:23 +0000

I run a handful of small Android apps on the side. The code is the fun part. The part that quietly wore me down was the reporting.

My ad income lands in a few different places — AdMob, AdSense, and mediation networks like AppLovin and Unity. Every morning I'd open three or four dashboards, log into each one, line up the dates, and add the numbers in my head just to answer one dumb question: how much did I make yesterday?

So I built AdDeck to answer that on one screen.

What it does

Connect once with a read-only OAuth scope, and it merges every network's revenue: today's total, a per-app ranking with each app's day-over-day change, and the month-to-date trend.
Tap any app for its own dashboard — earnings, a 7-day trend, and the metrics that actually drive decisions (eCPM, CTR, fill rate).
A home-screen widget shows yesterday's number without opening the app. This is the part I use most.

Two things I refused to compromise on

Read-only. The OAuth scope only reads revenue reports. AdDeck can't change your account settings or touch payouts, and you can revoke access anytime from your Google account. When you're asking someone to connect their ad accounts, "what's the worst this app can do?" has to have a boring answer.

No backend of mine. A lot of tools like this pull your data into their own servers and process it there. AdDeck doesn't. The numbers go from the ad networks straight to your device, and the math happens on-device. Nothing routes through a server I control — which means I have no way to look at your revenue, and I'm not sitting on a pile of other people's earnings data.

Where it's at

It's free and Android-only for now. Early, honest state: it does the merge, the per-app drill-down, and the widget well; the network list is still growing.

If you run apps across multiple networks, two questions I'd love answers to:

Which ad network should I support next?
If the widget could show exactly one number, which would you want — yesterday's earnings, month-to-date, or progress toward a target?

Play Store: https://play.google.com/store/apps/details?id=com.eltacrew.addeck

md to html without uploading your files: a browser-based converter that doesn't choke on Mermaid or KaTeX

EltaCrew — Mon, 10 Aug 2026 23:49:42 +0000

Every few weeks I need to hand a Markdown document to someone who doesn't live in a text editor. A README for a client, meeting notes, a short spec with a couple of diagrams. And every time, the same two problems showed up:

Anything beyond plain GFM breaks. The moment a document contains a Mermaid diagram or LaTeX math, a lot of the converters I tried give up. You get a code fence where a flowchart should be, or raw $...$ soup in the middle of a paragraph.
The documents I convert are the ones I least want to upload. Internal notes, drafts, client material. A lot of online converters process your files on their servers, and for work documents that always made me uncomfortable.

So I built a small tool that fixes both for me: a free md ↔ html converter that runs entirely in your browser. No install, no sign-up, and your files are never uploaded — conversion happens client-side.

What it does

Both directions. Markdown → HTML and HTML → Markdown, on the same page. The HTML → Markdown side accepts a .html file, pasted HTML source, content copied straight from a web page, or a URL.
GFM support: tables, task lists, strikethrough.
Code blocks come out syntax-highlighted.
Mermaid diagrams and KaTeX math actually render. The rendering engines are lazy-loaded only when your document uses them — a plain Markdown file never triggers those downloads at all.
Batch conversion: drop several files at once, then download results individually or grab everything as one ZIP.
Print / save as PDF with print-friendly styling, straight from the preview.
UI is available in English and Korean.

The part I actually built it for: single-file HTML export

My least favorite thing about sharing converted Markdown used to be the images/ folder. You send the HTML, forget the folder, and the recipient gets a page full of broken image icons.

Here's how the tool handles it: drop your .md files and your image files into the page together. The converter matches images referenced in the Markdown by filename, encodes each one as a base64 data URI, and embeds it directly into the generated HTML.

The output is one self-contained .html file. You can email it, drop it into a chat, or archive it, and the images display offline — no asset folder to zip alongside, nothing to fetch from a server later.

One trade-off worth knowing: base64 encoding makes embedded images take more bytes than the original files, so a screenshot-heavy document produces a noticeably chunkier HTML file. For the documents I share, that trade has been worth it every time.

Honest limitations

The tool is client-side with one exception: the optional "import from URL" feature. Browsers can't fetch arbitrary cross-origin pages, so that single path goes through a small proxy on my server. That is the only point where anything touches a server — if you never use URL import, nothing does. I'd rather say that plainly than have someone discover it in the network tab.
It's a converter, not an editor or a static site generator. It converts the documents you give it; it won't build a site, navigation, or a theme around them.

Wrapping up

The link is up top if you want to poke at it. It's free and there's nothing to sign up for, so the cost of trying it is one browser tab.

If you convert Markdown to HTML (or back) regularly — what's the thing that most often breaks for you? Footnotes, front matter, deeply nested lists, tables with inline code? I'd genuinely like to know what to test against next.

Reading Markdown on Android was worse than it should be, so I built a viewer

EltaCrew — Thu, 06 Aug 2026 07:42:52 +0000

Markdown is the default format for notes, docs and READMEs, but reading it on Android is oddly painful. Most apps I tried would break one of: tables, LaTeX, code highlighting, or wiki links. I wanted GitHub-quality rendering in my pocket.

So I built MdViewer. The parts I care about most:

Rendering correctness. Tables, task lists, inline/block LaTeX, syntax highlighting for common languages, images and [[wiki links]] all render the way desktop tools show them.
Folder workflow. You point it at folders (your Obsidian vault, a notes dir, a cloned repo) and it lists every .md inside. Pull to refresh.
Offline GitHub import. Type owner/repo and it downloads the repo's .md files for offline reading. Private repos work with a token.
Small extras that add up: heading outline, in-doc search, highlights, bookmarks, PDF/HTML export, an editor with live preview, on-device OCR.

It is free (ads) and Android only:
https://play.google.com/store/apps/details?id=com.eltacrew.mdviewer

If you find a file it renders wrong, I genuinely want to know.

Disclosure: I am the developer.