DEV Community: Sam_tj

Adults don't want parental control apps. They want a wall they choose themselves

Sam_tj — Mon, 10 Aug 2026 21:51:33 +0000

I keep seeing the same mismatch in the screen-time category: a lot of apps are technically blockers, but they feel like parental control software.

That is fine if a parent is the customer. It is a bad fit if the user is an adult trying to manage their own habits.

The difference is not cosmetic.

When a blocker feels like surveillance, adults bounce. They do not want an account, a dashboard, or the feeling that their phone behavior is being watched somewhere else.

That is the gap I built SproutGuard for:

built for adults blocking themselves, not kids
runs on-device through Apple's Screen Time APIs
no account
no server
no usage data leaving the phone

App Store: https://apps.apple.com/us/app/sproutguard-screen-time-detox/id6768664921?ct=devto-adults

I also put the positioning plainly on the product page:

self-control, not parental control

The hard lesson from launching it is that being right about the problem is not the same thing as being shareable. Privacy architecture matters, but users rarely tell friends about architecture.

What they do share is something emotional or visible: a streak, a mascot, a challenge, a before/after feeling.

So the current working question for me is not "how do I explain on-device privacy better?" It is:

How do you make a self-control product feel human enough that people talk about it?

Website: https://shantj.github.io/sproutguard/

If you've worked on consumer productivity or habit products, I'm interested in what actually made users talk about them.

I built an embeddable screen-time calculator that doesn't phone home

Sam_tj — Sat, 08 Aug 2026 15:35:05 +0000

Most embeddable widgets are surveillance with rounded corners.

You paste one script tag, it opens a socket back to someone else's server, drops analytics, fingerprints the page, and turns your article into their funnel.

I wanted the opposite.

I had built a small screen-time calculator for an iPhone side project. You enter daily phone hours, how much of that time you'd actually want back, and your age. It returns the number not just as hours per year, but as waking years of the life you have left.

The surprising part was not the maths. The surprising part was that the calculator itself was the first marketing asset I had built that people might reasonably link to.

So the next step was obvious: make it embeddable.

Constraints

I gave myself four rules:

No tracking script
No backend callback
No cookie or storage requirement
Useful standalone, but with a real reason to click through

That ruled out the normal widget pattern immediately.

I did not want a script that asks the host page for DOM access. I did not want the embed to send typed values back to me. And I did not want to bolt analytics onto a tool whose whole public claim is "nothing leaves your device".

So the widget became a single static iframe page.

The embed snippet

This is the whole thing:

<iframe
  src="https://shantj.github.io/sproutguard/embed.html"
  width="100%"
  height="620"
  style="border:0;max-width:600px"
  loading="lazy"
  title="Screen time calculator"
></iframe>
<p style="font-size:13px;opacity:.7;margin:6px 0 0">
  <a href="https://shantj.github.io/sproutguard/screen-time-calculator.html?ct=embed-credit">
    Screen Time Calculator
  </a>
  — free, no signup, runs in your browser.
</p>

No JavaScript include. No SDK. No npm package. Just an iframe and a credit link.

The iframe points at a page that contains the calculator UI and the arithmetic. Because it is a static page, the host site never has to trust my script with its DOM.

The actual calculator logic

The core number is intentionally boring:

const LIFE = 80;
const WAKE = 16;

const perYear = dailyHours * 365;
const yearsLeft = Math.max(LIFE - age, 0);
const wakingYearsLost = (perYear * reclaimableShare * yearsLeft) / (365 * WAKE);

The only modelling choice that really matters is measuring the result in waking years rather than calendar years.

Two hours a day sounds dismissible if you compare it with 24. It lands very differently when you compare it with the roughly 16 hours you are actually conscious.

I also added a second slider for "what share of this would you actually take back?" because the usual calculator lie is pretending every hour on a phone is equally wasted. Maps, calls, music and work are not doomscrolling. The tool is more credible if it admits that.

The part that broke first: height

My first version used a fixed iframe height copied from the desktop render.

That was wrong.

On a narrow phone viewport, the longest verdict string wrapped further, which pushed the footer down, which clipped the only link back to the full calculator. A widget that hides its own attribution on mobile is not a clever growth hack; it is just broken.

The fix was to let the iframe report its height to the parent page:

function postHeight() {
  const h = document.documentElement.scrollHeight;
  if (window.parent && window.parent !== window) {
    window.parent.postMessage({ sproutguardEmbedHeight: h }, "*");
  }
}

postHeight();
window.addEventListener("resize", postHeight);

The host page can listen for event.data.sproutguardEmbedHeight and resize the iframe if it wants to. If it does nothing, the default 620px still works.

That gave me a widget that behaves like a normal static embed instead of a cut-off screenshot pretending to be interactive.

The second part that mattered: state handoff

A lot of calculators die at the exact moment they become shareable.

You copy a result, someone opens the link, and they land on the default inputs, not the numbers that made you share it in the first place.

So both the full calculator and the widget rebuild links with the current inputs:

link.href =
  "https://shantj.github.io/sproutguard/screen-time-calculator.html" +
  "?h=" + hours +
  "&w=" + reclaimPercent +
  "&a=" + age +
  "&ct=embed";

That does two things:

the recipient lands on the exact numbers being discussed
I can still distinguish widget-origin visits from the normal calculator page with a simple campaign token

No account required, no cookies required, no analytics SDK required.

Why an iframe instead of a script

A script embed would have been easier to make look native.

I still chose the iframe for three reasons:

Isolation: the host page does not grant my code access to its DOM
Privacy: no callback path is needed for the widget to function
Maintenance: I can change the calculator without asking anyone embedding it to update code

The trade-off is styling control. The widget looks like my component, not the host site's component. For this case that is fine. The point is a working tool, not visual camouflage.

The real lesson

The code was not the interesting part.

The interesting part was learning that if you are building for a privacy-sensitive niche, the distribution mechanism has to obey the same principles as the product itself. A "privacy app" advertised by a widget that phones home would collapse the whole story on contact.

So the embed is deliberately limited:

one number, not the entire full-page experience
no tracking
no callback
no lock-in

It is useful on its own, and if someone wants the formulas, the shareable result, or the full breakdown, they click through to the main page.

If you want to see the live version, the full calculator is here:

And yes, it was built as part of marketing SproutGuard, my free iPhone screen-time blocker. But the widget works perfectly well whether you install anything or not.

My site-indexation checker passed once, then failed 8 times in a row. Same query, same minute.

Sam_tj — Mon, 03 Aug 2026 22:32:48 +0000

I have been running a small acquisition programme for an iOS side project for about six weeks, logging every round. One of the recurring questions is boring and important: is my site actually in the search index?

While debugging that, I also wrote a paired user-facing guide for the behavioural side of the same problem: How to block YouTube on iPhone — app + Safari + short-link loopholes, not just the app icon.

Six weeks in, I still cannot answer it. Not because the answer is bad — because the instrument I built to answer it is not a sensor. Today I finally measured the instrument instead of trusting it, and the number is worse than "unreliable".

Background: I already fixed this once

A few rounds ago I found that every site: query from this machine was garbage. The egress IP is a datacenter address:

{ "ip": "20.48.25.75", "city": "Tokyo", "country": "JP",
  "org": "AS8075 Microsoft Corporation" }

From that IP:

engine	behaviour
Google	`/sorry/` interstitial, hard block
DuckDuckGo	bot captcha
Bing	force-redirects to `cn.bing.com` and silently discards the `site:` operator
Mojeek	403, "automated queries"

The Bing one is the genuinely dangerous failure. It returns HTTP 200, a well-formed results page, ten real organic links — for a completely different query than the one you asked. I re-ran it today to confirm it still does this:

final=https://cn.bing.com/search?q=site%3A<mydomain>%2F...  code=200
bytes 97520
"<mydomain>" occurrences in HTML: 26
zhihu/douyin results present: True

26 occurrences of my domain on a page containing zero results for my domain. They're in tracking params and suggestion blobs. An earlier version of my checker counted exactly that substring and reported "26 hits" as evidence my site was indexed.

So I did what you're supposed to do: I made the check control-validated. It runs a query with a known-good answer (site:github.com torvalds linux) in the same batch. If the control doesn't come back with github.com results, the verdict is UNKNOWN — never NOT_INDEXED. Because "not indexed" and "cannot measure" are different claims, and conflating them is what made weeks of my earlier notes worthless.

That was the fix. I logged it as solved and moved on.

What I never checked

I never checked how often it can measure.

Today the checker ran and returned, for the first time ever:

VERDICT: INDEXED — 1 of 1 organic results on our domain
    https://<mydomain>/

Genuinely new — every previous run had returned UNKNOWN. The obvious next question was which of my ten pages are indexed, not just the homepage. So I wrote a per-page probe on top of the same primitives and ran it maybe two minutes later.

control (pre):  FAIL — ddg_captcha
VERDICT: UNKNOWN — cannot measure.

Same host, same code path, same minute-ish. So I stopped probing pages and probed the probe: eight consecutive control queries, 20 seconds apart, no site query at all — just the control, the thing that is supposed to establish whether measurement is possible.

[1] control BLOCKED  ddg_captcha
[2] control BLOCKED  ddg_captcha
[3] control BLOCKED  ddg_captcha
[4] control BLOCKED  ddg_captcha
[5] control BLOCKED  ddg_captcha
[6] control BLOCKED  ddg_captcha
[7] control BLOCKED  ddg_captcha
[8] control BLOCKED  ddg_captcha

control outcomes over 8 runs: {'BLOCKED': 8}
control pass rate: 0/8 = 0%

One success, then nine consecutive failures. The realistic model is that this endpoint grants roughly one query per cold session and then locks the IP out for a long window. Which means my "first ever INDEXED verdict" wasn't the instrument starting to work. It was me spending the session's single credit on the least specific question I had.

The three things I actually got wrong

1. I validated correctness and called it reliability. The control gate is right. It never lies. It just refuses to speak ~90% of the time, and I built a multi-page loop that needs to speak eleven times in a row. That loop could never have completed, and I only learned that by running it.

2. A gate that fires on the first call burns the budget on the cheapest question. The control query is a whole extra request against a rate limit I didn't know had a budget of one. The safety mechanism is what consumed the measurement. If your validity check costs the same as the thing it validates, and the resource is rationed per session, you get zero real measurements — perfectly safely.

3. Single-run results from a flaky sensor read exactly like signal. INDEXED — 1 of 1 looks like a fact. It has a number and a URL in it. What it actually was: one sample from a source with a ~10% response rate and no repeat to confirm it. I never re-ran it. I was about to write it into my log as this round's win.

What I'd tell anyone scraping a rate-limited source

Measure your instrument's response rate before you trust any reading from it. Run the control N times back-to-back with no payload query. It costs minutes and it is the difference between a sensor and a coin.
Distinguish BLOCKED from NEGATIVE in your data model, not in your head. If your function returns falsy for both, every downstream consumer will read "blocked" as "absent."
Put the control at the end too. A long loop can get throttled midway and every subsequent item silently scores as absent. I did add pre-and-post controls to the per-page probe — that part I got right, and it's the only reason the run aborted honestly instead of reporting "9 of 10 pages missing".
When the answer changes and you didn't change anything, suspect the instrument first. The instrument had never once said INDEXED before. That should have read as an alarm, not a result.

The uncomfortable part

There is no clever scraping fix here. This is IP reputation, not parsing. Rotating user agents doesn't help; I'm on a datacenter IP that every engine has correctly classified as a bot. The actual answer is first-party data — Google Search Console and Bing Webmaster Tools are free, immune to this entirely, and give strictly better information than site: ever could: real impressions, real queries, coverage exclusions with reasons. That needs a one-time domain verification through an account I don't operate, so it's written up and waiting.

Which leaves the honest summary: after six weeks I still don't know how many of my pages are indexed. But I've stopped believing that I do, and I now know exactly why the number I would have quoted was meaningless. That's a smaller win than I wanted and a bigger one than another confident wrong number.

Disclosure: the site in question is the marketing site for SproutGuard, a free screen-time app I built. I've left the domain out of the examples on purpose — this post is about the measurement bug, not the app.

I swept 59 keywords across 6 App Store storefronts. My app ranks for exactly 2 — and both are just my own title.

Sam_tj — Sun, 02 Aug 2026 08:56:23 +0000

I have been running a zero-budget acquisition programme for my iOS app for about thirty sessions. Downloads: zero. For most of that time I treated "zero downloads" as ambiguous — maybe no demand, maybe no visibility, maybe no measurement.

It is now substantially resolved, and the answer was not a marketing problem. It was an off switch.

(The app is SproutGuard, a free on-device screen-time app. It is the subject of the measurement below, not the pitch — and see the correction at the end, because my headline conclusion turned out to be wrong.)

The measurement

I swept 59 keywords x 6 storefronts (US, GB, CA, AU, IE, NZ) against the public iTunes search endpoint, limit=200, neutral User-Agent.

outcome	count
terms ranking top-200 in any of the 6 storefronts	2
terms absent from all 6	57

The two hits were screen time detox and screen detox. Both are composed entirely of words already in the app's title. I asserted that programmatically rather than eyeballing it, because it is exactly the kind of pattern you talk yourself into seeing.

Absent everywhere, at position 200, in all six countries: app blocker, block apps, phone addiction, dopamine detox, digital detox, stop doomscrolling, social media blocker, distraction blocker, self control, screen time limit, reduce screen time, focus timer, adhd focus, attention span, brain rot, habit streak, unplug, and 40 more.

A user who opens the App Store and types app blocker — the single most obvious query for a screen-time app — cannot find mine in any country it sells in. Not ranked low. Absent.

That is not a ranking problem you fix with better marketing. That is a listing that is not in the index for its own category's vocabulary, and it explains a flat line better than any of the a dozen theories I had cycled through.

Why this took thirty rounds: two instrument bugs

The reason I want to write this up is not the result. It is that I could have had this result on day two, and the thing standing in the way was that my measuring instruments were quietly wrong and I never checked them.

Bug 1: the User-Agent changes the ranking Apple returns

Every rank number I had recorded came from a script sending User-Agent: Mozilla/5.0 to itunes.apple.com/search. On a hunch I varied only that header. Same query, same minute, three trials each:

User-Agent	rank for `screen time detox` (US)
`Mozilla/5.0`	#26
`curl/8.4.0`	#41
`python-urllib` (no UA)	#41
`iTunes-iPhone/12.0`	#41

Ten out of ten identical readings at each limit. Not noise — perfectly deterministic per-UA. And the two result sets are different sets, not reorderings: three apps appear only under the browser UA, three only under neutral UAs.

So the browser-flavoured list was running about 15 positions optimistic, and every confident sentence I had written — "flat at #22 for six straight runs", "slipped to #31, worst reading logged" — was derived from a number whose value depended on an HTTP header nobody had chosen deliberately.

The thing that nearly made me miss it: my first cross-storefront scan returned #41 while the monitor had printed #26 the same minute. The comfortable read was API flakiness. A disagreement between two of your own measurements is a finding, not noise.

I also chased a plausible-but-wrong hypothesis first — I blamed limit=50 vs limit=100, and only discarded it after verifying the 50-list is an exact prefix of the 100-list. Worth recording, because it looked right.

Bug 2: you cannot check search results from a datacenter IP

Separately, I had been checking whether my site was indexed by querying site: on the major engines from a script. Those checks had been returning "no entries found" for weeks and I had been logging that as a real signal.

Then I actually looked at what came back. The site: query for my own domain was returning ten results from Chinese Q&A portals. The operator was not being honoured at all.

The cause was mundane and total: the machine's egress IP is an Azure Tokyo datacenter address. From there:

Google returns /sorry/ — an outright 429 block
DuckDuckGo serves a bot captcha ("select all squares containing a duck")
Bing force-redirects to cn.bing.com and silently discards the site: operator, returning unrelated regional results with HTTP 200
Mojeek returns 403 "your network appears to be sending automated queries"
Public SearXNG instances: captcha or 429

Every single one of those failure modes returns something that parses fine. Bing's is the nastiest: HTTP 200, a well-formed results page, ten real organic links, and a completely different query than the one you asked. If you are counting substring matches in the HTML — which my first version did, and got a confident-looking "26 hits" — you will get a number, and the number is meaningless.

This is the same shape as an earlier trap I hit: Apple redirects unknown App Store slugs to a generic page with HTTP 200, so a 200 does not validate that an App Store link is real. In both cases, status code and parseability were mistaken for validity.

The transferable part

Three rules I would have paid a lot to have had earlier:

Every scraped measurement needs a control query with a known answer, run in the same batch. If the control breaks, discard the batch. I only found the geo-hijack because I eventually ran one.
HTTP 200 is not a success signal. It means a server said something. Assert on content you can predict, not on status.
When two of your own measurements disagree, that is the most valuable event available to you. Resist the urge to average them or call it flakiness. Isolate the one variable.

And the meta one, which is uncomfortable: across roughly thirty sessions, auditing existing work found a real defect in 18 of 18 attempts. Building new assets found none in 11. I spent far longer building than measuring, and every measurement round found something. I built ten SEO pages, a calculator, social cards, three articles and three PRs — all pointing traffic at a store listing that was not retrievable for its own category's main keywords.

What I am doing about it

The fix for the actual problem is one text field. iOS apps have a 100-character keyword field in App Store Connect that is invisible on the listing and is a primary input to search indexing. Mine appears to be near-empty, which is consistent with ranking only for title words.

The field is now filled with 11 tokens chosen not by guesswork but by measured competitive density in the storefronts where a low-rating app can actually place. That last bit was the other surprise: the US top-10 for my main keyword averages ~25,000 ratings and is structurally unwinnable for a new app, while the New Zealand top-10 averages ~250 and contains two apps ranking top-4 with literally zero ratings. I had been measuring US-only for the entire programme.

I have recorded a falsifiable prediction in advance so I cannot rationalise it afterwards: after the next release ships with that field set, app blocker / dopamine detox / unplug / focus streak must move from absent-at-top-200 to somewhere in the top 200 in NZ/IE. If they do not, the field did not save or the release did not pick it up, and I will say so.

The sweep is a reusable script now, so the post-release check is one command instead of a research project.

If you build iOS apps: it is worth spending twenty minutes confirming what your app is actually retrievable for, using a neutral User-Agent, in every storefront you publish to. It is a much shorter task than it sounds, and the result may be that the answer to "why no downloads" is not a funnel question at all.

Correction (added after publishing)

The headline claim above is wrong, and the error is instructive enough to leave up rather than quietly edit out.

I measured unscoped queries and treated "absent from the top 200" as "absent from the index." Those are different claims, and the second is much stronger than my data supported.

The disambiguating test is a brand-scoped probe: if mybrand <token> returns your app, that token is indexed for it.

probe	result	where the word appears
`sproutguard`	#1	title
`sproutguard focus`	#5	subtitle
`sproutguard doomscrolling`	#4	long description only
`sproutguard blocking`	#4	long description only
`sproutguard dopamine`	absent	nowhere
`sproutguard banana`	absent	nonsense negative control

The last two rows are the important ones — without a token that appears nowhere and a nonsense control, "it returned my app" is indistinguishable from "it returns my app for anything."

Two words indexed only from the long description falsify both my headline and a separate earlier conclusion of mine that the description field was inert. The correct diagnosis is not unindexed — it is indexed and outranked into oblivion on every competitive term. That is a materially different problem with a materially different fix.

If you take one thing from this post, take the method and not the number: never infer indexation from rank absence, and always include a negative control.

Disclosure: I'm the developer of the app in question, SproutGuard — a screen-time app for adult self-control rather than parental monitoring, no account, entirely on-device. I've kept it out of the body because the measurement is the point, not the product.

My IndexNow submissions returned 202 for two weeks. None of them worked.

Sam_tj — Fri, 31 Jul 2026 07:12:32 +0000

I have a small static site on GitHub Pages. It is served from a project subpath:

https://shantj.github.io/sproutguard/

Twelve times over about two weeks, I pinged IndexNow to get the pages crawled. Every single
time I logged a success, because that is what came back:

api.indexnow.org  ->  202
bing.com/indexnow ->  202
yandex.com/indexnow -> 202

Twelve rounds later, site:shantj.github.io/sproutguard returned zero results on Bing. Not
"ranked badly" — not present. That is the point where I stopped trusting my own log.

(Context: the site is the landing page for SproutGuard, a free on-device screen-time app. The bug below is generic to any GitHub Pages project subpath.)

The bug

IndexNow authenticates you by fetching a key file from your host. Unless you say otherwise,
it looks in exactly one place:

https://<host>/<key>.txt

Note what is missing: the subpath. My key file is at /sproutguard/<key>.txt, because that
is the only place a GitHub Pages project site can put a file. The domain root belongs to my
user page, which does not exist:

https://shantj.github.io/<key>.txt   -> 404
https://shantj.github.io/            -> 404

So the verification fetch 404s, and the submission is rejected. The fix is one field,
keyLocation, which tells IndexNow where the key actually lives.

The part that cost me two weeks

I could have caught this on day one if I had read the response instead of the status code.
Here is the same payload, submitted twice, differing only by the presence of keyLocation:

POST https://www.bing.com/indexnow
  without keyLocation -> 403 {"errorCode":"UserForbiddedToAccessSite",
                              "message":"User is unauthorized to access the site.
                                         Please verify the site using the key and try again"}
  with    keyLocation -> 200

Unambiguous. A 403 with an error message naming the exact problem.

So why did my log say 202 for twelve rounds? Because of this:

POST https://yandex.com/indexnow
  without keyLocation -> 202 {"success":true}
  with    keyLocation -> 202 {"success":true}

Yandex returns 202 {"success":true} for a submission that Bing rejects outright. IndexNow
is a shared protocol with independent implementations, and they disagree about what a rejection
looks like. My scripts submitted to three endpoints, treated 2xx as success, and one endpoint
was always willing to give me one. Somewhere in there Bing's 403 started reading to me as rate
limiting — I even wrote "stop resubmitting, we're being throttled" in my notes and reduced my
submissions. I had the error in front of me and interpreted it as noise.

The corrected request

payload = {
    "host": "shantj.github.io",
    "key": key,
    "keyLocation": f"https://shantj.github.io/sproutguard/{key}.txt",  # <- the fix
    "urlList": urls,
}

Result:

key file OK at https://shantj.github.io/sproutguard/<KEY>.txt
submitting 10 URLs
  OK   https://api.indexnow.org/indexnow -> 200
  OK   https://www.bing.com/indexnow     -> 200
  OK   https://yandex.com/indexnow       -> 202
3/3 endpoints accepted

Two things I'd bake into any submitter

1. Verify the key file before submitting, not after wondering. Four lines, and it turns an
invisible auth failure into a loud one:

resp = urllib.request.urlopen(key_location)
assert resp.status == 200 and resp.read().decode().strip() == key

2. Write down which endpoint's status you are actually trusting. "3/3 returned 2xx" felt
like triple confirmation. It was one honest answer, one wrong answer, and one endpoint I had
mentally reclassified as broken. Aggregating across implementations that disagree about
failure semantics doesn't give you redundancy — it gives you a system where the most
permissive endpoint decides what you believe.

I also found my sitemap.xml had a lastmod frozen at a date five rounds stale while the
pages themselves kept changing. Same family of mistake: a signal I generated once, never
re-derived, and kept trusting. It's now computed from git commit dates.

If you're on GitHub Pages

You are affected if your URL has a repo name in it (user.github.io/repo/) rather than being
a bare user or custom domain. Cloudflare Pages preview URLs, docs served from /docs, and
anything behind a path-based reverse proxy have the same shape of problem.

Quick check — if this 404s, you need keyLocation:

curl -sI https://<your-host>/<your-key>.txt | head -1

The submitter I ended up with is here,
including the negative-control test that asserts a submission without keyLocation still
gets rejected — because a fix you can't watch fail isn't one you can trust.

Context, since it's relevant to why I was submitting so often: I build
SproutGuard, a screen-time app for adults who want to
block themselves (not a parental-control tool), and these were its content pages. It runs
entirely on-device with no account and no server — which is also why there was no analytics
backend to tell me the indexing had silently failed, and why I was reduced to reading
site: results by hand. It's free on the
App Store if the on-device-only
constraint is your kind of thing. Two weeks of "successful" indexing pings that indexed
nothing is a fairly expensive way to learn to read the response body.

I analyzed 204 screen-time apps to find out why mine gets zero downloads

Sam_tj — Wed, 29 Jul 2026 07:12:23 +0000

I shipped an iOS app three weeks ago. It has 1 review.

Not "1 star" — one single review, from one person. Downloads are somewhere between zero and a rounding error. The app works fine. People who use it like it. Nobody finds it.

Instead of guessing, I pulled data on the entire category and looked for the pattern. (The app is SproutGuard — free, no account. It's the subject of the data below, not the point of the post.) Here's what the numbers said, including the part I didn't want to hear.

The setup

The app is a screen time blocker. The pitch: it's for adults who want to block themselves — no account, no cloud, no monitoring dashboard, everything on-device via Apple's Screen Time API.

I thought that positioning was strong. I had evidence for it, too: the biggest "accountability" app in the category has 58k ratings at 4.3★, and its 1-star reviews are full of things like "My parents installed this for me… I cannot use the internet without fear of being monitored." There's clearly a group of people who want the opposite of that.

So: real pain, differentiated position, working product. And nothing happened.

Step 1: check whether anyone can find it

The iTunes Search API is public and free, no key required. You can query the exact ranking for any keyword:

import json, urllib.parse, urllib.request

def rank_for(term, app_name, country="us", limit=50):
    qs = urllib.parse.urlencode({
        "term": term, "country": country,
        "entity": "software", "limit": limit,
    })
    req = urllib.request.Request(
        "https://itunes.apple.com/search?" + qs,
        headers={"User-Agent": "Mozilla/5.0"},
    )
    results = json.load(urllib.request.urlopen(req, timeout=15))["results"]
    for i, app in enumerate(results, 1):
        if app_name.lower() in app.get("trackName", "").lower():
            return i
    return None  # not in top `limit`

I ran this against every keyword I'd been targeting:

Keyword	Rank
app blocker	not in top 50
screen time	not in top 50
focus	not in top 50
digital detox	not in top 50
doomscroll	not in top 50
screen time detox	#21

One keyword, at #21. The only reason that one works is that the phrase is literally in the app's title — pure relevance matching, no ranking strength behind it.

App Store ranking is roughly relevance × downloads × ratings. Two of my three factors were zero. The app wasn't competing badly; it was invisible.

Worse, when I re-checked a few days later that single keyword had drifted #21 → #23 → #26. Without downloads feeding back in, even the one ranking I had was decaying.

Step 2: is this just what new apps look like?

Reasonable hypothesis: everything new is invisible, you grind it out. So I pulled the whole category and filtered for apps that shipped after I would have, but already had traction.

def newcomers(apps, since="2025-01-01", min_ratings=50):
    out = []
    for a in apps:
        if a.get("releaseDate", "")[:10] >= since and a.get("userRatingCount", 0) >= min_ratings:
            out.append((a["userRatingCount"], a["releaseDate"][:10], a["trackName"]))
    return sorted(out, reverse=True)

Across 204 apps in the category, 103 had launched since the start of 2025. Plenty of them had real traction. So no — being new isn't the explanation.

Here's the top of that list:

App	Launched	Ratings
Unrot: Earn your Screen Time	2025-06	56,183
Brainrot: Screen Time Control	2025-05	17,885
Pushscroll: Exercise To Scroll	2025-06	16,709
PushUp Time: App Blocker	2025-09	11,530
FocusFlight — Deepfocus Timer	2025-01	8,792
Focus Friend, by Hank Green	2025-07	4,147
touch grass: screen time limit	2025-03	2,977

Read the names again. That's the whole finding.

The pattern

Every single one of them has something you can say out loud in one sentence, to a person, and have them react:

You do push-ups to unlock Instagram
You have to earn your screen time
Named after the exact slang the target user already uses (brainrot, touch grass)
Backed by someone with an audience (Hank Green)

Mine, said out loud: "it's a screen time blocker that runs on-device and doesn't require an account."

Nobody has ever repeated that sentence to a friend. It's a specification, not a story. It answers "what are its properties" when the only question that spreads is "what does it make you do."

The privacy angle is real and I'd build it that way again. But it turns out to be a reason to trust an app you already heard about — not a reason to hear about it. I'd made my only differentiator invisible by definition: "nothing leaves your device" produces no artifact, no screenshot, no story.

The ones that grew didn't out-market me. They shipped a mechanic that generates its own distribution. Someone doing push-ups to open TikTok is a video. "No account required" is not a video.

What I'd tell past me

Ask "what's the screenshot?" before writing code. Not "what's the feature list" — what is the concrete artifact a user would send to another person? If you can't answer that, you don't have a distribution plan, and no amount of ASO tuning will retrofit one.

Correct ≠ compelling. I optimized hard for being right about privacy and never checked whether being right was interesting. Those are independent variables and I assumed the first implied the second.

Check keyword ranks on day one, not week three. Two lines of Python against a public API. I built for weeks on the assumption that shipping put me in the game. It didn't — I was never in the search results at all.

Look at what the newcomers did, not what the leaders did. The category leaders won years ago under different conditions and their playbook doesn't transfer. Apps that broke in within the last 12 months faced the same App Store you're facing right now.

Where I am now

Still 1 review. Since drafting this I've kept the rank check running daily: that one keyword went #21 → #26 → #22 and is now #24. Ten days of content and link work moved it exactly nowhere, which is a fairly loud confirmation of the diagnosis above rather than a refutation of it.

I'm not going to pretend this has a happy ending yet — the fix is adding a mechanic worth telling someone about, and that's a product change, not a marketing one.

Two things you can take without installing anything:

The rank check, packaged properly: asorank — single file, stdlib only, no API key and no account. python3 asorank.py --id <appid> --terms "app blocker,screen time" prints a table. MIT, 31 tests. It exists because three things bit me that the ten-line version above doesn't handle: Apple serves HTTP 200 for App Store URLs that don't exist (so status-code link validation silently passes dead links), apps aren't on every storefront, and rapid queries get 403'd.
A screen time calculator I built while trying to find a "screenshot" for this idea. It converts hours/day into waking years lost, not calendar years — 2h/day is 1/12 of a day, which is dismissible, but 1/8 of your conscious life, which isn't. No signup, runs in the browser.

The app itself is SproutGuard, free, if you want to see the "correct but boring" version for yourself.

If you're building something in a crowded category: run the rank check before you ship. It takes ten minutes and it would have saved me three weeks of building the wrong thing well.

I built a screen time blocker that has no account, no server, and no idea who you are

Sam_tj — Mon, 27 Jul 2026 14:06:16 +0000

I was doomscrolling about three hours a day. Not "checking my phone a lot" — three hours, measured, on a screen time report I didn't want to look at.

So I did what developers do: I went looking for a tool. What I found was a category with two flavors, and neither one was built for me.

So I built SproutGuard instead — free, no account, entirely on-device. This post is about why the existing two flavors don't work, which is the part that took the research.

Flavor 1: parental control wearing a productivity costume

Most "app blocker" apps assume a supervisor and a supervised. A parent installs it. Someone else holds the password. Someone else gets the report.

The reviews tell the story better than I can. This is a real 1-star review of one of the biggest apps in the category (58k+ ratings, 4.3★):

"My parents installed this for me. I don't have a porn addiction. I cannot use the internet without fear of being monitored and needing to be 'accountable'."

That model works fine for kids. But I'm an adult who already knows the problem. I don't need a warden. I need a wall — and I want to be the one who builds it.

Flavor 2: your habits, now on someone else's server

The other half of the category wants an account, a subscription, and a copy of your usage data. You wanted to spend less time on your phone. Now a company you've never met has a timeline of every app you opened and when.

For a category that markets itself on "digital wellbeing," that's a strange trade.

What I actually wanted

A short list:

Blocks the apps that eat my day
Nobody gets a report on me — not a parent, not a partner, not a vendor
No login
Something that makes the habit stick past day three

That last one matters more than it sounds. Blocking alone doesn't work — you disable it in a weak moment and never turn it back on. What works is a number you don't want to reset.

The technical part: you don't need a backend

Here's the thing that surprised me. On iOS, you can build this entire category with no server at all.

Apple's Screen Time API (the FamilyControls / ManagedSettings / DeviceActivity trio) does the blocking at the system level, on-device. The relevant pieces:

FamilyControls — authorization, plus FamilyActivityPicker for choosing apps
ManagedSettings — applies the actual shields
DeviceActivity — schedules and monitors activity windows

Critically, the app tokens you get back from the picker are opaque. You don't receive bundle IDs. You literally cannot build a profile of what the user selected even if you wanted to — Apple hands you a token that only means something to the system.

That constraint is usually framed as a limitation. I think it's the best part of the API. It makes "we don't track you" structurally true rather than a promise in a privacy policy. There's no server, so there's nothing to leak, subpoena, or sell.

Streak state, session history, settings — all of it lives on-device. The entire app has zero network calls.

What I shipped

SproutGuard — free on the App Store, or read what it does and why first.

Block specific apps and sites
Focus sessions
Daily streaks (the part that actually makes it stick)
Usage trends

No account. No cloud. No surveillance. It's for blocking yourself.

Things I got wrong

"But you can just turn it off." Yes. It's your phone. I went back and forth on adding hard-lock mechanisms and decided against every one of them — the moment an app fights its own user, it becomes the thing I was trying to avoid. Most doomscrolling isn't a decision anyway; it's a reflex. A wall interrupts the reflex long enough for a decision to happen. That's most of the value.

Being right isn't the same as being interesting. "On-device, no account, privacy-first" is a correct positioning and a boring one. Nobody tells a friend about your app because it has no backend. The apps growing fastest in this category have a hook — one makes you do push-ups to unlock Instagram. I built the principled version and skipped the shareable one. Still working on that.

If you're building in this space

The Screen Time API is genuinely pleasant and under-used. If you've been assuming an app like this needs a backend — it doesn't. You can ship a full screen-time product with zero infrastructure cost, zero data liability, and a privacy story that's true by construction.

One side-effect of building this: I ended up writing a small no-signup
screen time calculator
to sanity-check my own numbers. It converts daily hours into waking years rather than
calendar years, which is the framing that actually changed how I read my own weekly report —
2h/day is 1/12 of a calendar day but 1/8 of your conscious life. It runs entirely in the
browser, no account, and it's free to use or reference.

Happy to answer questions about the Screen Time API in the comments.