DEV Community: Martin Ma

Blocking apps failed for me three times. A daily budget plus a counter of every override has held for 21 days.

Martin Ma — Wed, 21 Oct 2026 02:51:37 +0000

Every screen-time app I tried in 2024 assumed the problem was access. Remove access, problem solved. It is not, and I have the logs to prove it on myself.

The three attempts that failed

Full block, 9 days. I blocked the four apps I used most. Day four I started using the mobile web versions. Day nine I had reinstalled two of them and turned the blocker off "temporarily", which lasted three weeks.

Accountability partner, 5 weeks. A friend held the passcode. I asked for it three times with increasingly creative reasons, got it twice, and stopped asking because asking felt worse than the habit.

Cold turkey, 12 days. Deleted everything, kept it up for twelve days, then reinstalled five apps in one evening after a bad day.

The pattern: every method removed the access and left the reason untouched. A phone is also my map, my messages, my train ticket. "Just don't use it" is not available to me.

What actually changed: budget + counter

Two mechanics replaced blocking.

A per-app daily budget. Games get 20 minutes, short video 20 minutes, messaging and maps unlimited. Not one global hour, which runs out by noon and then gets ignored for the rest of the day.

A counter of overrides. When a budget runs out, the app does not lock. It asks once: continue now, or do the thing you said you wanted to do first. If I continue, it records that. No punishment, no streak to protect, no guilt screen. Just a number that goes up.

The counter is the part that worked, and it is the part every blocker I tried was designed not to have. Blocking is binary: you are compliant or you have failed. A counter is a measurement, and measurements are harder to lie to.

21 days of data

I logged every open and every override from 1 to 21 October.

Sleep-adjacent phone use: 90 min/night to 12 min/night
Opens per day: 41 to 19
Overrides per week: 23 to 6
Apps uninstalled: 0

The 23-to-6 drop is the interesting number. I was not overriding less because I had more willpower. I was overriding less because overriding had become visible. Seeing "23" next to a week made the next override feel like a choice rather than a reflex.

Why the "no stopping cues" framing matters

Short video, games and social feeds share one structure: no natural end. A season never ends, a feed never refreshes to a bottom, an autoplay queue always has a next item. So the useful question is not "how do I stop" but "where do I put the stopping cue".

Three cues that survived contact with a bad day:

A budget boundary — an external, pre-committed end that is not a judgement about me.
A single question at the boundary — one prompt, not a wall of options.
A visible count of crossings — the only feedback that changed behaviour without shame.

What I built, and what I left out

I got tired of stitching this together across three apps, so I built it as one: per-app budgets, one prompt at the boundary, and a plain counter of overrides, all stored on the device. It is called ChoiceField, iOS only, free.

Two deliberate omissions, because I think they matter:

No blocking mode. A block that can be bypassed teaches you that rules are optional; a budget that reports does not.
No rankings or streaks. Streaks punish a bad day twice: once when it happens, once when it resets.

If you want to look at it: App Store (US) or App Store (China).

If you only take one thing from this: stop trying to remove access, and start making the override visible. You can do that with a notebook for a week before you install anything.

相关阅读 / Related

Three compulsions, one mechanism: what 400 logged phone sessions taught me about stopping

Martin Ma — Wed, 21 Oct 2026 00:43:35 +0000

I spent three weeks logging every phone session and, more usefully, the ninety seconds before each one. Four hundred sessions later I stopped believing that doomscrolling, gaming binges and compulsive pornography use are three separate problems with three separate fixes. They are the same loop wearing different clothes, and that has a practical consequence: fixes aimed at the content always fail, because the content is not the mechanism.

This is not a moral argument and it is not a diagnosis. It is a description of a failure pattern I kept repeating, and what actually interrupted it.

The four parts of the loop

Every one of these behaviours delivers the same structure:

An unpredictable payoff. Not every pull gives something good, and you cannot tell in advance which pull will. A feed refresh, a match result, a new message, a thumbnail: all of them are draws from a distribution you cannot see.
A near-miss signal. The almost-win is more motivating than the win, because it implies the next attempt is close. This is why "one more" is such a reliable sentence.
No stopping cue. A book chapter ends. A film has credits. A podcast has an outro. Feeds removed all of them and replaced them with autoplay, preloading and "up next". The only remaining stopping point is fatigue, and fatigue arrives after forty minutes of scrolling.
Cheap re-entry. Reopening costs nothing, so the decision to continue never has to become conscious.

Once I could name those four parts, my own history made sense. Every fix I had tried attacked part four, and part four is the least important one.

What each behaviour adds

The loop is shared, but each behaviour adds one ingredient that changes the failure mode:

Short-form video adds infinite supply and zero cost per item. There is no unit of completion, so there is no natural place to stop.
Games add progression: daily streaks, energy timers, seasons. These convert "I want to stop" into "I will lose something if I stop", which is a much harder feeling to argue with.
Compulsive pornography use adds shame and secrecy, which is the most destructive addition of the three, because shame removes the two things that would otherwise end the loop: talking about it, and being seen doing it.

That last point is why "just have more willpower" is not merely unhelpful but actively counterproductive there. Willpower framed as a moral test turns a habit into an identity, and an identity is much harder to change than a habit.

Why deleting the app fails

Deleting an app attacks re-entry only. It is real progress, but it creates two new problems.

First, one dramatic failure mode. One bad evening, one reinstall, and weeks of effort are gone. A limiter makes a bad evening cost twenty extra minutes instead of the whole system.

Second, it does not survive substitution. Remove the game and the same loop is waiting in a feed. Remove the feed and it is waiting in a shopping app. The loop is the target, not the app.

Three changes that held up

Ordered by measured effect over those three weeks:

1. Charge the cost to the app, not to the day. A single daily limit for the whole phone is spent by noon and then means nothing, which is exactly when the loop is strongest. Per-app budgets keep the expensive apps constrained and leave messaging and maps alone, which also removes the usual excuse for overriding: "but I need it for work."

2. Make every override visible. When bypassing a limit was silent, I did it five or six times a week and forgot each instance. When it was counted, the number itself became the restraint. No lock, no punishment, just a tally I had to look at. This was the single highest-leverage change, and it is the one piece nothing off the shelf gave me.

3. Put a stopping cue back. I added a four-second question before the feed loads: ten minutes or an hour? It converts an automatic reach into a decision. Most of the time the honest answer is ten, and the session ends when the number does instead of when I get bored.

Numbers, with the obvious caveat

One user, three weeks, self-logged. Treat this as a case study, not evidence:

Bedtime scrolling: about 90 minutes to about 12.
Sessions per day: 41 to 19.
Overrides per week: 23 to 6.
Nothing uninstalled; no arguments with anyone about my phone.

What this does not fix

A limiter does not change the product's incentive. The loop exists because it works, and no timer makes it stop working. It also does not help if the behaviour is a symptom: if you are avoiding a specific task, or using a feed to manage anxiety, a timer mostly adds shame. Deal with the underlying thing first, then use the limiter for the residual habit.

The tool, since I built one

I eventually built these mechanics into a small iOS app, mainly because I wanted the override counter to exist as a number I could not avoid. It is called ChoiceField, it is free, and the method does not require it: per-app Screen Time limits plus a tally of every override kept where you cannot miss it gets most of the way there.

App Store (US): https://apps.apple.com/us/app/id6769946195
App Store (China): https://apps.apple.com/cn/app/id6769946195

If you try the loop framing on your own logs, I would like to know which part broke first: the stopping cue, the counter, or the per-app budget. That comparison is more useful to me than agreement.

相关阅读 / Related

The group chat that leaves you feeling worse is a design problem, not a personality flaw

Martin Ma — Wed, 21 Oct 2026 00:41:20 +0000

I spent three weeks logging what happened in the ninety seconds before I opened my phone, and which sessions I regretted. The surprise was not the volume. It was which app produced the regret.

Short video was the biggest time sink. But the sessions that left me feeling worse afterwards were almost always messaging and social feeds, and the mechanism was different from what I expected.

Three ways a feed makes you feel worse, none of which are your fault

Comparison with a curated sample. You see forty people's best moments and compare them to your ordinary Tuesday. This is not a character flaw; it is what happens when a sample is selected for display and you treat it as representative. Nobody's feed shows the argument they had at breakfast.

Ambiguous social signals. A message that was read and not answered, a post with fewer reactions than expected, a group chat where the joke landed for everyone but you. These are low-information events with high emotional weight, and the feed gives you no way to resolve them. So you keep checking, which is the loop.

Obligation without boundaries. Group chats have no closing time. A thread that starts at 11pm expects an answer, and the expectation is social rather than technical, so there is nothing to push back against except your own attention.

Put together, the pattern is: you are not addicted to people, you are managing an inbox that never declares itself finished.

What I changed, in order of effect

I separated messaging from feeds, and gave them different rules. Messaging gets no limit, because it is genuinely useful and the cost of missing something is real. Feeds get a per-app budget. Bundling them into one daily phone limit was the mistake I made for two years: the useful app spent the budget, so the feed got the remainder, and I felt justified.

I made overrides visible. When bypassing a limit was silent I did it five or six times a week and remembered none of them. Counting them changed the behaviour more than any lock. A number I have to look at is a better constraint than a wall I can climb.

I put a stopping cue before the feed, not inside it. One question on the home screen: ten minutes or an hour. It takes four seconds and converts an automatic reach into a decision. Most days the honest answer is ten.

I stopped answering group chats on the app's schedule. Two windows a day, and a sentence in the group explaining it. Nobody objected. The obligation was mostly in my head, which is exactly why it had no natural end.

The numbers

Three weeks, one user, so treat this as a case study and not evidence:

Regretted sessions per week: 19 to 5.
Night-time opens: about 90 minutes to about 12.
Overrides per week: 23 to 6.
Apps uninstalled: none. Arguments with friends about my phone: none.

What this does not solve

A limiter does not make a group chat kinder, and it does not fix the comparison problem, which is upstream in the product. If the feed is where you go to avoid a specific task, a timer mostly adds shame. Deal with the task first.

What it does fix is the specific pattern I kept repeating: opening for a legitimate message, then drifting into a comparison feed for forty minutes with no memory of deciding to.

I built these mechanics into a small iOS app, mainly because I wanted the override counter to exist and nothing off the shelf had it. The method itself needs no app: per-app Screen Time budgets, plus a tally of every override kept somewhere you cannot avoid.

If you have tried something similar, tell me which part held up and which one you dropped. I am especially interested in whether separating messaging from feeds worked for you, or whether the split just moved the problem.

App: ChoiceField, free on the App Store (iOS 17+): https://apps.apple.com/us/app/id6769946195

相关阅读 / Related

Games, short video and social feeds share one loop. That is why deleting the app never works.

Martin Ma — Tue, 20 Oct 2026 16:16:59 +0000

Most advice about compulsive phone use treats three different problems as one: games, short-form video, and social feeds. They feel different, so people try different fixes for each. Underneath, they run the same loop.

The loop, stated plainly

A variable-reward loop has four parts:

An unpredictable payoff. Not every pull gives something good, and you cannot tell in advance which pull will.
A near-miss signal. The almost-win is more motivating than the win, because it implies the next attempt is close.
No stopping cue. Nothing in the interface says "this is a natural end". No chapter break, no credits, no outro.
Cheap re-entry. Reopening costs nothing, so the decision to stop never has a chance to become conscious.

Slot machines are the cleanest example, which is why the mechanics are easy to study there. Games add progression and daily streaks. Short-form video adds autoplay and preloading. Social feeds add the audience: the payoff is other people's reactions, which are maximally unpredictable.

Once I saw the loop, the reason my fixes kept failing became obvious.

Why deletion fails

Deleting an app attacks part four only. It makes re-entry expensive, which is real progress, but it leaves the other three parts intact and adds two new problems.

First, it creates a single dramatic failure mode. One stressful evening, one reinstall, and weeks of effort are gone. With a limiter, a bad evening costs you twenty extra minutes, not your whole system.

Second, it doesn't survive substitution. Remove a game and the same loop is waiting in a feed. The loop is the thing to design against, not the app.

What actually interrupts the loop

Three changes held up over three weeks of logging, in order of effect:

Charge the cost to the app, not the day. A single daily limit for the whole phone gets spent by noon and then means nothing, which is exactly when the loop is strongest. Per-app budgets keep the expensive apps constrained and leave messaging and maps alone, which removes the usual excuse for overriding.

Make the override visible. When bypassing a limit was silent, I did it five or six times a week and forgot every instance. When it was counted, the count became the restraint. No lock, no punishment, just a number I had to look at. This is the single highest-leverage change I made, and it is also the one nothing off the shelf provided.

Put a stopping cue back. A book ends. A film has credits. A podcast has an outro. I added the equivalent manually: one deliberate question before the feed loads, asking whether I want ten minutes or an hour. It takes four seconds, and it converts an automatic reach into a decision. Most of the time the honest answer is ten.

What this does not fix

None of this changes the incentive of the product. The loop exists because it works, and a timer cannot make it stop working. It also does not help if the behaviour is a symptom: if you are avoiding a specific task, or using the feed to manage anxiety, a limiter will mostly add shame. Deal with the underlying thing first, then use the limiter for the residual habit.

What it does fix is the specific failure I kept repeating: a session that started for a legitimate reason and ended two hours later, with no memory of deciding to continue.

Numbers, since anecdotes are cheap

Three weeks of logging, one user, so treat it as a case study and not evidence:

Bedtime scrolling: about 90 minutes to about 12.
Sessions per day: 41 to 19.
Overrides per week: 23 to 6.
Nothing uninstalled, no argument with anyone about my phone.

I later built these mechanics into a small iOS app, mostly because I wanted the override counter to exist. But the method needs no app: per-app Screen Time limits plus a tally of every override, kept somewhere you cannot avoid seeing. The tally is the whole trick.

If you have tried something similar, I would like to know which part held up and which one you dropped, and whether the loop framing matches what you see in your own logs.

相关阅读 / Related

Short-form video has no stopping cues - that is the whole design

Martin Ma — Tue, 20 Oct 2026 13:46:29 +0000

I spent three months tracking why I could not stop watching short dramas.

It was not the episodes. It was that nothing in the interface ever says stop.

What a stopping cue actually is

A book chapter ends. A film has credits. A podcast episode has an outro. Each one is a
built-in moment where you get to decide whether to continue. Short-form video removed all
of them: autoplay, seamless transitions, and a feed that preloads the next clip before
you have finished judging the current one.

The result is that the only decision point left is your own fatigue - and fatigue is the
worst possible decision-maker, because it arrives after the behaviour has already run.

Three things I measured on myself

I logged every session for three weeks, then changed one variable at a time.

Sessions start intentionally, then drift. 71% of my sessions started with a
specific reason ("check one clip", "look up that actor") and crossed the 20-minute mark.
So the problem is not starting - it is the absence of a checkpoint afterwards.
A single daily budget does not work. With one global limit, I either blew through
it by noon and ignored the rest, or hoarded it and felt punished. Splitting the budget
per app changed the behaviour, because exhausting the video app no longer blocked
messaging or maps - so there was no legitimate excuse to override it.
Invisible overrides are not limits. When overriding was frictionless and unrecorded,
I overrode it 5-6 times a week and forgot each time. When the app started showing
"bypassed 4 times this week", the number itself became the restraint.

What I built instead of a blocker

I did not want another app that hard-locks the phone, because hard locks create a
single dramatic failure mode: you disable the whole thing in a bad moment and lose
everything.

Instead I built three small mechanics:

a one-line intention prompt before the app opens (costs two seconds, no punishment)
per-app budgets rather than one number for the whole device
a visible count of the times you chose to override

That is the entire product. It is deliberately boring, because the mechanism that
survives contact with a tired brain is the boring one.

The honest limits

This does not fix the feed's design, and it is not therapy. If your use is a symptom of
something larger, a timer is the wrong tool. What it does fix is the specific case of
"the session started fine and ended three hours later".

I shipped it as a small iOS app - ChoiceField - mostly because I wanted the
bypass counter to exist and nothing off the shelf had it. The mechanisms are easy to
copy manually: Screen Time limits per app, plus a note where you tally every override.

If you have tried something similar, I would like to know which of the three held up for
you and which one you dropped.

相关阅读 / Related

Designing friction instead of blocking: what I learned building a screen-time app

Martin Ma — Sat, 17 Oct 2026 23:45:36 +0000

App Store: https://apps.apple.com/us/app/id6769946195

The problem with every blocker I tried

I've tried the usual stuff on my own phone: hard limits, one-tap locks, deleting apps. They all fail the same way. The block is absolute, so the fix is absolute too — you flip the switch off, and you're back to zero. Every attempt resets to the same starting line.

My wife had the same pattern, worse: down at eleven, still awake at two, half of it short video and half of it shopping. So instead of another lock, I tried the opposite: keep access, add a small pause.

Three rules we committed to

Never make it impossible. If the user can't get back in, they'll remove the app — and then there's no signal left to work with.
Make the exit visible. Every bypass is counted and shown back to you. Hiding friction removes the feedback loop that changes behaviour.
Never go around the system. No MDM profiles, no fake network tricks. Use the platform's own Screen Time stack.

What that looks like on iOS

Under the hood it's the Screen Time APIs (Family Controls authorization, DeviceActivity for monitoring, ManagedSettings for shields). The interesting part isn't the API calls — it's the choices on top of them:

Per-app allowance instead of one global limit. A single 60-minute budget for the whole phone gets spent in ten minutes. Per-app budgets spread out.
A pause screen, not a wall. When the allowance runs out you get a sentence and a way back in: wait a bit, or use one of a small number of unlocks you chose in advance.
Unlocks are logged, not blocked. The point isn't prevention at all costs: it's seeing the pattern (three unlocks at 1am is information, not failure).
Friend Freeze. A trusted person can freeze apps for you for a set window. Accountability without surveillance.

What changed, measured

Before: phone in hand until 2am, screen time after midnight ~50 minutes. After six weeks: down to about 20 minutes, and the useful part — it didn't feel like a fight. The unlock count went from 5–6 a night to 0–1.

If you want to try it

ChoiceField is free to start on iOS 17+. No account, everything on-device.

https://apps.apple.com/us/app/id6769946195

If you're building something similar and want to compare notes on the Screen Time APIs — especially the entitlement review process — happy to share what we hit.

相关阅读 / Related