DEV Community: Richard Andrews

7,920 Minutes/Month Wasted on My Phone. Now What?

Richard Andrews — Mon, 23 Mar 2026 14:34:38 +0000

Last year I opened my iPhone's Screen Time report and stared at it for a long time. 78 hours of YouTube. 43 hours of JioHotstar. 11 hours of Instagram. In a single month. That is 132 hours — more than five full days — spent watching other people live their lives while I put mine on pause.

If you are reading this, you probably know the feeling. The guilt that hits every night when you realize the day is gone and you have done nothing meaningful. The gap between who you want to be and what your Screen Time report says you actually are. That gap was eating me alive.

This is the story of how I went from wasting 132 hours a month on my phone to completing 85% of my daily habits, building a 14-day streak, and finally breaking the shame cycle that had controlled my life for years. The solution was not willpower. It was not discipline. It was one simple principle that anyone can apply.

132 Hours Gone: The Wake-Up Call

I am not going to sugarcoat this. I was addicted to my phone. Not in the casual "I scroll a bit before bed" way. In the "I wake up, immediately open YouTube, and suddenly it is 11 AM" way. The numbers do not lie:

78 hours on YouTube. That is nearly 2.5 hours every single day, watching videos I would not remember an hour later.
43 hours on JioHotstar. Entire seasons of shows consumed in weekend binges that left me feeling empty.
11 hours on Instagram. Reels, stories, explore page, repeat. The same loop, hundreds of times.

I tried Apple's Screen Time limits. You know what happened? I tapped "Ignore Limit" within seconds. Every single time. It is the most useless button in iOS — a speed bump on a highway. I tried setting a passcode I would not remember. I memorized it within a day. I tried deleting apps. I reinstalled them within hours.

I tried willpower. I told myself I would not open YouTube until after lunch. I lasted two days. I tried app timers. I swiped past every notification. I tried the "put your phone in another room" trick. I just walked to the other room. Every strategy assumed I had discipline. I did not. That was the entire problem.

The worst part was the shame spiral. You waste three hours scrolling, then you feel guilty about wasting three hours, and then the guilt makes you feel terrible, and then you scroll more to escape the feeling of feeling terrible. It is a loop, and nothing I tried could break it.

The One Principle That Changed Everything

The idea came to me on a random Tuesday afternoon. I was staring at my phone, Instagram open, knowing I should be reading the book that had been sitting on my nightstand for three weeks. And a thought hit me:

What if my phone would not let me open Instagram until I had read for 30 minutes?

Not a reminder. Not a timer. Not a popup I could dismiss. An actual lock. A real barrier between me and the app — and the only key is doing the thing I actually want to do with my life.

That was the insight that changed everything: willpower does not work, but barriers do. You do not eat junk food if there is no junk food in the house. You do not skip the gym if your friend is waiting for you there. The most effective behavior change systems do not rely on motivation. They change the environment so the desired behavior is the path of least resistance.

I wanted to apply that same principle to screen time. Instead of trying to restrict phone use (which feels like punishment), I wanted to flip the relationship entirely. Earn your screen time. Do the habits you care about, and your apps unlock as a reward. The screen time is not the enemy. It is the incentive.

I searched the App Store for something like this. I found app blockers that work on timers. I found friction-based tools that add a pause before opening apps. I found habit trackers with streaks and reminders. But nothing that combined all three into a single system: lock the apps, tie the unlock to habits, and make the lock unbypassable.

So I decided to build it myself.

From Idea to App Store in Under 3 Months

Some context: I am a product manager by day, but I have software development experience from earlier in my career. I had built side projects before, including a few iOS apps that shipped to the App Store but never gained traction.

I started building in late 2025. My goal was simple: get a working app into the App Store as fast as possible, validate whether the concept actually works, and iterate from there. No elaborate roadmap. No six-month timeline. Just build the core loop and ship it.

The core loop was straightforward: lock apps, set habits, check off habits, unlock apps. But the Screen Time API nearly killed the project.

The Screen Time API Fight

Apple's Screen Time API (FamilyControls framework) is the only way to enforce real app locks on iOS without jailbreaking. It is also one of the most poorly documented APIs Apple has ever shipped. The official docs are sparse. Stack Overflow threads are full of developers hitting the same walls. The error messages are cryptic.

Here is what made it hard:

Authorization is fragile. The FamilyControls authorization can silently fail, revoke itself, or behave differently between iOS versions.
Apple's review process is strict. Apps using the Screen Time API get extra scrutiny during App Store review. My first submission was rejected.
Limited community knowledge. Because so few apps use this API, there is almost no community support. Most problems I hit, I had to solve from scratch.

But the upside of building on the Screen Time API is massive: the lock is real. It is enforced at the operating system level. You cannot bypass it by force-quitting the app, restarting your phone, or switching accounts. When Habit Doom locks Instagram, Instagram is locked. Period.

From first line of code to App Store approval, the entire process took under three months. I built it solo, mostly during nights and weekends. And yes, one of my daily habits in the app was "Build Habit Doom." More on that later.

Why Gamification Beats Willpower

Here is a truth most self-improvement advice ignores: you cannot hate yourself into better habits. Restriction without reward does not work. If the system feels like punishment, you will abandon it. The key is making good behavior feel like winning, not suffering.

I spent a lot of time studying what actually makes people stick with behavior change. The answer was not discipline. It was gamification — but the right kind. Not fake badges and confetti. Real rewards tied to real desires.

Streaks and Loss Aversion

Habit Doom tracks two types of streaks: individual habit streaks and Perfect Day streaks (where you complete every habit on your list). Streaks work because of loss aversion — the psychological principle that losing something hurts roughly twice as much as gaining it feels good. Losing a 14-day streak hurts more than gaining day 15 feels rewarding. That asymmetry is the engine.

But in Habit Doom, the streak is backed by a real consequence: if you break it, your apps are still locked tomorrow and you have to start from scratch. The streak is not just a number. It is tied to your daily experience of using your phone.

Earned Screen Time

Every time you complete your habits and unlock your apps, Habit Doom tracks how much screen time you have earned. You can see a running total: "Time Earned: 1:01:50." This reframes your relationship with screen time entirely. Instead of feeling guilty about scrolling, you see it as something you legitimately earned by doing the work first. Screen time stops being a vice and starts being a reward.

The Lock Screen

When your apps are locked, Habit Doom displays them with padlock icons. The lock screen creates urgency. You see the apps you want, you see the padlocks, and you feel motivated to go do your habits so you can unlock them. It is motivation through visibility, not punishment.

The Results: 10% to 85% in 4 Weeks

I tracked everything from day one. Here are the results after four weeks:

Habit completion rate: 10% to 85%. Before Habit Doom, I completed maybe one out of ten habits I set for myself. After four weeks, I was hitting 85% consistently.
Longest daily streak: 14 days. The longest streak I have ever maintained on any habit system, ever.
138 total check-ins. Across all my habits, 138 individual completions in four weeks.
35 hours 30 minutes of earned screen time. Every minute of it was guilt-free.

Here is what I was tracking:

Read. 11-day streak, my most consistent habit. The lock mechanic turned "I should read more" into "I read every day."
Guitar Practice. 23 check-ins. I went from picking up my guitar once a month to playing almost daily.
Drink Water. 79 check-ins. The simplest habit on my list, but the one that made me feel the best physically.
Build Habit Doom. 20 check-ins. Yes, one of my habits was literally building the app. I shipped a complete iOS app in under three months while working a full-time job, largely because I could not negotiate my way out of it.

The biggest change was not in the numbers. It was in how my days felt. Before Habit Doom, I would wake up, scroll for an hour, feel guilty, and then try to be productive through a fog of shame. After Habit Doom, I wake up, do my habits (because my apps are locked anyway), and then open my phone feeling like I earned it. The guilt is gone. The shame spiral is broken.

4 Lessons That Apply to Any Habit

1. Stop relying on reminders. Start building barriers.

Reminders assume you have willpower in the moment. You do not. Barriers are different. A barrier does not ask you to make a choice. It removes the bad option entirely. If you want to change your behavior, stop trying to motivate yourself and start redesigning your environment.

2. You do not need to quit the things you love. You need to earn them.

The goal was never to stop using social media. It was to stop using it compulsively. The difference between scrolling with guilt and scrolling after you have earned it is the difference between a vice and a reward.

3. Real rewards beat fake rewards. Every time.

Badges and confetti feel good for a week, then you stop caring. The best motivation is not artificial. It is connecting the habit you need to build with the reward you already desire.

4. Accountability works best when you cannot negotiate with it.

One of my daily habits was "Build Habit Doom." The app was holding me accountable to building the app. I shipped a complete iOS app in under three months while working a full-time job, largely because I could not negotiate my way out of it.

I built Habit Doom to be that system. It is live on the App Store, free to download. Whether you use my app or build your own barriers, the principle is the same: stop trying harder and start making the bad choice impossible.

My current read streak is 11 days and counting. The shame spiral is gone. The 78-hour YouTube months are behind me.

You already know what you need to do. The only question is whether you will keep scrolling or finally do something about it.

97 Downloads. $0 Revenue.

Richard Andrews — Mon, 23 Mar 2026 14:15:08 +0000

I am going to share every number. No spin. No "we are seeing great traction" corporate speak. Just the raw data from Habit Doom's first month on the App Store.

Habit Doom is an iOS app I built solo that locks your distracting apps (Instagram, TikTok, YouTube) until you complete your daily habits. No timer. No gentle reminder. A real lock at the operating system level.

This is either inspiring transparency or embarrassing public self-exposure, depending on how you look at it. Either way, it is real.

The Top-Line Numbers

Here is the dashboard as of mid-March 2026, roughly one month after launch:

Let me break down what each of these numbers actually means.

Where Downloads Come From

90.6% of downloads came from App Store Search. People searched for something (habit tracker, app blocker, screen time) and found Habit Doom. 4.2% came from App Store Browse (being featured in categories). 3.1% from App Referrer, and a trickle from Web Referrer.

This tells me two things:

My App Store listing is working. A 7.94% conversion rate from product page view to download is solid for a new app. People who find it are interested enough to download.
Nobody knows this app exists. 90.6% organic search means I have done essentially zero marketing. The downloads I have are from people actively searching for this type of app.

By country: United States (22), Canada (10), India (10), United Kingdom (7), Saudi Arabia (5). The app is resonating in English-speaking markets, which makes sense given the listing is only in English.

By device: iPhone 83 (86.5%), iPad 13 (13.5%). I did not expect iPad to be 13% but I am glad I added iPad support.

The Onboarding Funnel

This is where it gets interesting. I track every step of onboarding with PostHog:

40 people started onboarding
36 completed it (90% completion rate)
Average time: 1 minute 19 seconds

90% onboarding completion is genuinely good. The onboarding flow I rebuilt three times is working. People understand what the app does and how to set it up.

But then comes the critical drop-off:

36 completed onboarding
19 created their first habit (52.78%)
17 dropped off (47.22%)

Almost half of the people who successfully complete onboarding never create a single habit. They understand the app. They set it up. Then they leave. This is the biggest problem in my funnel right now, and the number one thing I need to fix.

There is also a Screen Time permission challenge. The app needs access to Apple's Screen Time API to lock apps — that is the core feature. Roughly a third of users deny this permission during onboarding. Without it, the app is just a habit tracker with
no locking. I need to do a better job explaining why this permission matters before asking for it.

Engagement: The Bright Spot

The people who stick around are using the app a lot:

21.8 sessions per active device (people open the app over 20 times per day on average)
13 daily active users (last 7 days)
~150 daily check-ins across all users
46.5% daily habit completion rate
2,766 total check-ins completed (all time)
408 total habits created (all time)

21.8 sessions per active device is a big number. It means the people who use Habit Doom are checking in throughout the day: completing habits, checking their progress, unlocking their apps. The app is not a "download and forget" experience for active users. It is part of their daily routine.

The most popular habits people create: Read, Workout, Drink Water, Meditate, Go on a Walk. These are exactly the habits I was hoping people would track.

One metric I find fascinating: the reward usage split. About 55% of lock events are manual (users choosing to lock their apps early) versus 45% from the timer expiring automatically. This means more than half the time, users are voluntarily locking their apps before their time runs out. They are actively choosing to use less screen time than they earned. That is the behavior change I was hoping for.

The Retention Problem

Here is the hard part.

Weekly stickiness drops from about 55% on day 0 to 7.5% by day 7. That means of the people who use the app on any given day, only 7.5% are still using it a week later.

DAU/MAU ratio sits around 10%. Industry benchmarks for habit and productivity apps are typically 15-25%. I am below where I need to be.

22 people have deleted the app. That is 27% of total downloads. Some of those are people who denied the Screen Time permission and could not use the core feature. Some are people who tried it and decided it was not for them. Some are probably people I
lost at the "create your first habit" step.

What the Numbers Are Telling Me

Looking at the full funnel, the story is clear:

What is working:

App Store listing and conversion (7.94% is healthy)
Onboarding flow (90% completion)
Core engagement for retained users (21.8 sessions/day, 150+ daily check-ins)
The right habits being created (Read, Workout, Meditate)
Users voluntarily locking apps early (the behavior change is real)

What is broken:

Onboarding-to-first-habit drop-off (47% never create a habit)
Screen Time permission denial rate (roughly a third)
Week 1 retention (55% → 7.5%)
Zero marketing or distribution (90.6% is organic search)

The app works. The people who use it, love it. But too many people drop off between "I downloaded this" and "I created my first habit," and too many people leave in the first week.

What I Am Doing Next

Based on these numbers, here is my plan:

1. Fix the onboarding-to-habit gap. 47% of people who complete onboarding never create a habit. I need to either include habit creation as part of onboarding or make the first-habit-creation screen impossible to miss.

2. Better Screen Time permission explanation. Before asking for the permission, I need to show users exactly what they get: a 5-second demo of apps being locked and unlocked. Make the value undeniable before the system popup appears.

3. First-week retention push. The biggest drop happens between day 1 and day 7. I need better notifications — not "reminder to check in" spam, but meaningful nudges tied to streaks and progress.

4. Start marketing. 97 downloads from organic search alone is a signal that demand exists. People are searching for this. I need to start writing content, posting on social media, and getting the word out.

5. Fix the IAP flow. Update: All three IAPs — Monthly ($2.99/mo), Yearly ($19.99/yr with 14-day free trial), and Lifetime ($34.99) — are now approved and live on the App Store. It took two weeks of fighting App Store Connect bugs and recreating products from scratch due to a product ID mismatch. The full story is here.

The Honest Version

97 downloads in a month is not a success story. It is a starting point.

But looking at these numbers, I am not discouraged. 21.8 sessions per active device tells me the core product works. 2,766 check-ins tells me people are building habits. Users voluntarily locking their apps early tells me the behavior change is real.

The problem is not the product. The problem is that not enough people know about it, too many people drop off before they experience the value, and I have not started charging money yet.

Every one of those is fixable. None of them require me to rebuild the app. They require better onboarding, better marketing, and a working payment flow.

I shipped 4 failed apps before this one. I fought 21 bugs to get the core technology working. I am not going to stop at 97 downloads.

Next month I will share these numbers again. They will either be higher or I will tell you exactly why they are not.

Habit Doom is free on the App Store. If you have read this far, you might as well be download number 98.

The AI Agent That Saved My App

Richard Andrews — Mon, 23 Mar 2026 13:36:45 +0000

I want to tell you about January 24, 2026.

That was the day I wrote “Fixed all issues with Automatic App Locking” in my code log. Two saves later, same day: “Fixed auto app blocking.” It was not fixed. Not even close. I would write the word “Fixed” nine more times over the next six days before the thing actually worked.

This is the real story of building Habit Doom, an app that locks your distracting apps until you complete your daily habits. Not the polished version. The version with 21 things that broke, an AI assistant that helped me survive, and a moment on January 30 that I will never forget.

If you have ever tried to build something (an app, a business, a creative project) and wondered whether the struggle is normal, it is. This is what normal looks like.

What I Was Trying to Build

The idea is simple: pick the apps that distract you (Instagram, TikTok, YouTube), set daily habits you want to build (reading, exercise, drinking water), and the apps stay locked until the habits are done. I have written about why I built it and what I learned from failing at it multiple times before.

But I have never written about the building itself. The parts that made me want to throw my laptop out the window.

The app needed to do three things:

Lock apps. Real locks that you cannot bypass by closing the app or restarting your phone.
Unlock apps when habits are done. With a timer so screen time is earned, not unlimited.
Re-lock apps automatically. When the timer runs out, and again at midnight for the next day.

Number 1 was doable. Number 2 was fine. Number 3 nearly killed the entire project.

Starting From Zero

I am a product manager by day. Not a professional developer. I had built a few apps before, none of them successful, but I was far from an expert.

I started by taking an iOS development course on Udemy. It was genuinely great. The fundamentals clicked. I understood how to build screens, handle data, make things look right.

But there is a massive gap between "I finished an online course" and "I can ship a real app." I was taking entire days to build screens that should have taken an hour. So I tried an AI code editor called Cursor. Suddenly I was moving three times faster. The AI handled the repetitive parts. I handled the decisions.

Then I hit the wall.

The Wall: Apple's Screen Time API

To lock apps on iPhone for real (not just show a “please stop” popup, but actually lock them so they cannot be opened), you need to use Apple’s Screen Time API. It is the only way. And it is one of the most poorly documented APIs Apple has ever released.

It was originally built for parental controls. The community of developers using it is tiny. Most of the problems I ran into had no answers on the internet. None.

Here is the thing I learned the hard way: one lock is not enough.
The app can be closed. The phone can be restarted. The user can ignore it for hours. The lock has to survive all of that. It has to re-engage at midnight. It has to re-lock when the timer expires, even if the app is not running.

I ended up building three independent locking systems that all do the same thing:

Layer 1 catches the lock when you try to open a blocked app. Layer 2 runs in the background on a schedule, checking if your timer has expired. Layer 3 checks the moment you open Habit Doom itself.

Three systems. All doing the same job. Because any single one can fail silently, and if the lock fails even once, the entire app loses its purpose.

Belt and suspenders and duct tape.

21 Things That Broke

I kept a list. Here is every major bug I hit while building this app. Some of them took hours. Some took days. Some took weeks.

The Screen Time API (1–8): Apps would not re-lock at midnight. Background schedules would not fire if set more than 45 minutes in the future. One API call would silently trigger another, which would re-lock ALL apps in the middle of the night, while users were supposed to have them unlocked. A flag that tracks whether apps are locked would go stale when the app was in the background, causing the whole system to make wrong decisions. Timestamps with second precision would not match schedules with minute precision, causing off-by-one errors. A function designed to restore blocking would, if it hit a data error, permanently destroy its own data instead. And the re-locking code could get suspended halfway through if the user switched to another app, leaving apps in a half-locked state.

The communication problem (9–10): The three locking systems run as separate processes on your phone. They cannot share a database. Everything has to be communicated through a tiny shared storage space, with data manually packed and unpacked. One system used the label "quota_expired" for when your time runs out. Another used "reblock_expired." Same event, different names. They could not understand each other. A typo-level problem that took hours to find.

The interface (11–15): Animations would flash and glitch when you checked off a habit. The progress bar on the lock screen timer would freeze. Buttons would appear and disappear at the wrong times. The app's new programming language update broke one of my fixes because it considered the fix a safety violation.

Apple's own tools (16–20): This one deserves its own section.

When Apple's Tools Break

These were not bugs in my code. These were bugs in the tools Apple gives developers to submit apps.

I renamed a version of my app in App Store Connect (Apple's developer portal) and the entire section for managing in-app purchases vanished. No error. No warning. Just gone.

I created a fresh version. Still missing. I tried again. And again. Four versions (v1.5, v1.6, v1.7) and the section never came back. A week of going in circles.

I eventually had to bypass Apple's broken website entirely and use their programming interface (API) to submit my in-app purchase manually. The API worked. The website was broken. This is Apple's own tool.

Meanwhile, the EU compliance form got stuck on a loading spinner. My subscription plans were blocked because they needed the missing section. One UI bug cascaded into three blocked revenue streams.

Update (March 21, 2026): The IAP saga got worse before it got better. After the API workaround, I discovered a product ID mismatch that forced me to recreate all three products from scratch. The full ordeal took over two weeks. All IAPs are now approved and live. Full story here.

Bug 21 was not a code bug at all: 75 downloads, one review (one star), and 20 people had already deleted the app, all while I was fighting infrastructure instead of improving the product.

The Bug That Almost Ended Everything

There was one bug that nearly made me quit for good.

The automatic re-locking (the entire reason the app exists) worked perfectly when connected to my development tools. The moment I disconnected and ran it on my actual phone: nothing. The timer would expire and apps would stay unlocked.

This is the worst kind of bug. It works when you are watching it. It breaks when you are not. And you cannot even investigate it properly because the act of investigating changes the behavior.

I spent days on this. I could not figure it out.

I gave up. Not dramatically. Just quietly. I stopped opening the project. I told myself I would come back to it. "Later" started stretching into weeks.

The AI That Did Not Give Up

I had been using Cursor for building the interface, and it was great for that. But these bugs were different. They were not "make this screen look right" problems. They were "why do three invisible background systems disagree about whether your apps should be locked" problems.

I decided to try Claude Code, an AI coding assistant that runs in your terminal. Not because I expected it to magically fix everything. I was out of ideas and had nothing to lose.

It struggled too. I want to be honest about that. The Screen Time API is so poorly documented that even an AI trained on the entire internet did not have clean answers. We would try something. It would fail. We would try something else. The sessions were long.

But here is what made the difference: it never got frustrated, and it could see everything at once.

When I was trying to figure out why the locking failed at midnight, Claude Code could look at all three locking systems simultaneously. It could trace a piece of data from where it was saved in one system to where it was read in another. It could spot that a flag was being set in one place but going stale in another.

We debugged together. That is the most accurate way to describe it. I knew what the app was supposed to do. Claude Code could reason about
what was actually happening across the entire codebase. Together, we were more effective than either of us alone.

I tried to find our exact conversation to share here. Claude Code does not save session transcripts by default. But I asked it to look at my code history, and the story it found was better than any screenshot.

97 Days Told Through Code

I asked Claude Code to look at my code history and tell me the story. Here is what 97 days of building an app actually looks like:

December 13. Initial Commit. Day zero. An empty project with a dream.

December 18–23. Home screen, habit creation, streaks, archive, vacation mode, onboarding. Ten days in and moving fast. Everything felt possible.

December 29. Tested ScreenTime feature but failed.

The first wall. Apple's Screen Time API does not just work. That single line in my code history hides days of confusion.

December 31 – January 4. New Year's Eve, still coding. Added Hard Mode. Widgets land four days later. I was building around the wall I could not get through.

January 19. I gave up on the hardest feature.

Removed progressive unlocking and did general clean up
Remove background processes for progressive unlocking
Release 1.0.2

I ripped out the automatic re-locking entirely and shipped without it. The app was live, but missing its core promise.

January 23–26. I went back in. Four "fixed app locking" entries across four days:

Fixed all issues with app locking incorrectly
Fixed all issues with Automatic App Locking
Fixed auto app blocking
Fixed some edge cases with automatic app locking

"Fixed ALL issues." Then two days later: "Fixed some edge cases." The quiet, exhausted version.

January 28. I tried progressive unlocking again. The feature I had ripped out nine days earlier.

January 30:

MILESTONE 1: Progressive unlocking + Midnight unlocking Acheved

48 days from first commit. The core loop finally works. The typo in "Acheved" is still there. I am never fixing it.

February 3. Rewrote the entire app. Not a refactor. A rewrite. To support global app blocking instead of per-habit blocking. Brave or insane, probably both.

February 5. Live Activity support. Your unlock timer now shows on the lock screen with a real-time countdown in the Dynamic Island.

February 17. Discovered Apple's background scheduling is unreliable past 45 minutes. Built a workaround that chains shorter checks together.

February 22:

MILESTONE 2: Rebuild entire app with single timer quota

Second full rewrite in three weeks. One shared timer across all habits instead of separate timers for each one.

February 28 – March 8. Payment screens, in-app purchases, milestone celebrations, widgets, weekly summary. The app is feature-complete.

March 10–14. Polish. Massive onboarding improvements. iPad layout. Making the first impression count.

March 17. Fixed midnight blocking when active session.

Still fixing the blocking system. 94 days in. It never stops fighting back.

97 days. Around 100 code entries. 2 full rewrites. 5 milestones. 1 indie dev.

What Building With AI Actually Looks Like

I want to be honest about this because there is a lot of hype around AI tools right now.

Claude Code did not build Habit Doom for me. It built Habit Doom with me. I brought the knowledge of what the app should do, the product decisions, and the gut feeling for when something was wrong. It brought tireless patience, the ability to hold the entire project in its head, and a willingness to try one more thing when I was ready to quit.

If you are considering using AI to help build something: it is not a replacement for understanding what you are building. It is a multiplier on the understanding you already have. The more you know, the more useful it becomes.

Where I Am Now

As I write this, Habit Doom has about 75 downloads. One review. One star. Twenty deletions.

The blocking works. All three layers, the midnight resets, the timer-based re-locking. The foundation is solid. But there is a long distance between "the technology works" and "people love this."

I shipped 4 failed apps before this one. The difference this time is that I am not interpreting small numbers as a verdict. I am interpreting them as day one.

Twenty-one bugs nearly killed this app. I am still here. The app is still here. And every night at midnight, the triple-locking system fires, resets everything, and waits for me to earn my screen time tomorrow.

That is the whole story. Not the polished version. The real one.

Habit Doom is free on the App Store. It takes 30 seconds to set up. And yes, the automatic re-locking works now. I checked.

2 Weeks to Ship 3 Buttons on iOS

Richard Andrews — Mon, 23 Mar 2026 13:00:00 +0000

Three buttons. Monthly, Yearly, Lifetime. That is all I needed to add to Habit Doom, an iOS app that [locks your distracting apps until you do your habits (https://habitdoom.com/blog/how-habit-doom-works).

The code took two days. Getting those buttons live on the App Store took two weeks.

The Bug

I had version 1.4 live on the App Store. I renamed it to v1.5 in App Store Connect to submit it with in-app purchases. The rename went through fine.

Except the “In-App Purchases and Subscriptions” section was gone. Not collapsed. Not behind a toggle. Gone. The entire section where you attach IAPs to a version for review had vanished from the page.

IAP section: gone The entire section vanished from App Store Connect
I assumed I had done something wrong. So I created a fresh version, v1.6, via “+ Version or Platform.” New version, clean slate.
Still missing.

v1.7. Missing. v1.8. Missing. v1.9. Missing.

Different browsers. Cache cleared. Different Apple IDs. Nothing worked. Four versions, same hole in the page.

## Apple Support

I was about to file a support case. But by that time a new bug showed up.

The EU Digital Services Act compliance form had its own bug, an infinite loading spinner that never resolved. A separate support case. A separate wait.

One UI bug was now blocking three revenue streams: Monthly, Yearly, and Lifetime. My app was live. Users were downloading it. And I could not charge money because Apple’s website was broken.

Then this email landed:

This is what they saw: the paywall loaded, but there were no purchase buttons. Just an infinite spinner where the pricing should be.

The API Detour

After a week of dead ends, I tried bypassing the web UI entirely using the App Store Connect REST API. I generated an API key, looked up my Lifetime purchase’s inAppPurchaseV2 ID, and submitted it programmatically.

The API accepted it. The Lifetime IAP went into review alongside v1.7. I thought I had found the fix.

I was wrong.

The Real Problem

When v1.7 shipped and I tested the live purchase flow, nothing worked. StoreKit returned zero products. The paywall was empty.
The reason: my code used com.unmanagedboy.habitdoom.monthly but App Store Connect had com.unmanagedboy.habitdoom.pro.monthly. An extra .pro. in the path. A typo I made when creating the products two weeks earlier.
Here is the thing about product IDs in App Store Connect: you cannot change them. Ever. Once created, they are permanent. The only option is to create entirely new products.
So the API workaround had submitted the wrong product. The Monthly and Yearly API submissions had also failed with DEVELOPER_ACTION_NEEDED. A week of work on the API, wasted.
Product IDs are forever You cannot change them in App Store Connect. Get them right the first time.

What Actually Fixed It

I created three brand new products with the correct IDs:

Each one needed pricing across 175 territories, localization, review screenshots, subscription group setup, and a 14-day free trial offer for Yearly.

Then I created a fresh version (v1.10) and the IAP section appeared. Just like that. The section that had been missing for a week across four different versions was suddenly there, working perfectly.
I attached all three IAPs through the UI. Submitted for review. Approved in less than 24 hours.

The old v1 products sit abandoned in App Store Connect with “Developer Action Needed” status. A monument to a two-week detour caused by one misplaced .pro. in a product ID.

Lessons

Product IDs are permanent. Copy-paste them from your code into App Store Connect. Do not type them.
One typo means recreating everything from scratch.
The first IAP submission must be linked to a binary. When you submit IAPs or subscriptions for the
very first time, they need to be attached to an app version with a binary. After that first approval, they
can be managed separately. This is easy to miss and not obvious from the UI.
Do not remove your app submission after attaching IAPs. If you have already submitted a version
with IAPs attached and you pull or remove the app submission, the IAPs get detached and you are back to
square one. Submit once and leave it alone.
Local StoreKit testing hides ID mismatches. Your .storekit config file has its own product IDs.
Tests pass perfectly while the live configuration is completely wrong. Test against the sandbox, not just
the local config.
Do not rename versions in ASC. Always create fresh ones via "+ Version or Platform." Renaming
triggered the vanishing IAP section for me.
If the IAP section is missing, try creating new products. In my case, creating fresh products with
new IDs made the section reappear. No API workaround needed.
The code is the easy part. StoreKit 2 is genuinely well-designed. The App Store Connect
configuration, agreements, tax forms, and UI bugs are what eat your time.
Budget two weeks for IAP integration, not two days. The code is fast. Everything around it is slow,
broken, or both.

For a company that makes $100 billion a year from the App Store, a broken IAP section is a rounding error. For a solo developer with82 downloads and $0 in revenue](https://habitdoom.com/blog/what-82-ios-downloads-taught-me), it was a gut punch.

Habit Doom is live on the App
Store. All three buttons work. It
just took two weeks to ship them.

Apple's Screen Time API Broke Me

Richard Andrews — Mon, 23 Mar 2026 12:07:00 +0000

I spent 97 days building Habit Doom, an iOS app that locks your distracting apps until you complete your daily habits. The hardest part was not the UI, the business logic, or the App Store review process. It was Apple's Screen Time API.

This is everything I learned: the stuff Apple's documentation does not tell you, the behaviors that will break your app silently, and the architecture I ended up with after 21 bugs nearly killed the project.

If you are building anything that locks or monitors apps on iOS, this might save you weeks.

The Three Frameworks

Apple's "Screen Time API" is actually three separate frameworks that work together:

FamilyControls handles authorization. Your app requests permission from the user to monitor and restrict their device activity. This is the gatekeeper.

ManagedSettings handles the actual blocking. You create a ManagedSettingsStore and set store.shield.applications to a set of app tokens. Those apps are now locked at the OS level. Users see a shield screen when they try to open them.

DeviceActivity handles scheduling. You can set up monitoring schedules that trigger your code when intervals start or end. This is how you schedule re-blocking events.

The documentation for all three is thin. Some classes have one-line descriptions. Some behaviors are not documented at all. Here is what I learned the hard way.

Lesson 1: One Blocking Mechanism Is Never Enough

This is the most important lesson in this entire post.

If your app blocks other apps, the blocking has to survive the user closing your app, force-quitting it, restarting their phone, or ignoring it for 12 hours. A single blocking mechanism cannot handle all of these scenarios.

I ended up with three independent systems that all enforce the same lock:

Shield Extension runs synchronously whenever the user tries to open a blocked app. It checks if it is a new day or if the unlock timer has expired, and re-blocks if needed. This is your first line of defense because it fires before the app can even open.

DeviceActivity Monitor runs on a schedule in the background. It proactively checks whether the unlock timer has expired and re-blocks apps even when the user is not trying to open them.

Main App fires when your app comes to the foreground, immediately checks the shared state, and re-blocks if needed. This runs before the database initializes, before the UI renders: a synchronous check with zero async calls.

Why all three? Because each one covers the gaps of the others. The Shield Extension only fires when the user opens a blocked app. The DeviceActivity Monitor only fires on schedule (and schedules can be unreliable, more on that below). The Main App only fires when the user opens your app. Together, they cover every scenario.

Lesson 2: DeviceActivity Schedules Are Unreliable Beyond 45 Minutes

This one took weeks to figure out and there is no documentation about it anywhere.

If you schedule a DeviceActivity monitoring event for 90 minutes in the future, it might fire at 60 minutes. Or it might not fire at all. Apple's scheduling system simply is not reliable for events far in the future.

The workaround: chain shorter schedules together. Schedule checks at 15, 30, and 44 minutes. When each check fires, it looks at the shared state to see if the unlock timer has expired. If it has not expired yet, it chains the next check, scheduling another event 16 minutes out (or targeting 1 minute past the expected expiry if that is closer).

Why 44 minutes and not 45? Because you want to stay safely within the reliable window with a margin of error.

Why rotate through multiple schedule names? Because if two schedules try to use the same DeviceActivityName, the second one overwrites the first. Use rotating slot names like habitDoomReblockChain_0 through habitDoomReblockChain_4 so they do not clobber each other.

Lesson 3: startMonitoring() Has a Devastating Side Effect

When you call center.startMonitoring() for a DeviceActivityName that is already being monitored, it first calls stopMonitoring() internally. This triggers intervalDidEnd on your DeviceActivity Monitor extension.

If your intervalDidEnd handler re-blocks all apps (which is a reasonable thing for it to do), then calling startMonitoring() to update a schedule will re-block all apps as a side effect, even in the middle of an active unlock session.

I discovered this when users reported their apps getting locked at 1 AM for no reason. The cause: a scheduled re-check was calling startMonitoring() to chain the next check, which triggered intervalDidEnd, which re-blocked everything.

The fix: add a guard in your intervalDidEnd handler that checks whether the current unlock session is still active before re-blocking. Do not assume that intervalDidEnd means "the user's time is up."

Lesson 4: Extensions Cannot Share a Database

Your Shield Extension, DeviceActivity Monitor, and main app all run as separate processes. They cannot share a SwiftData or Core Data database.

The only reliable way to share state between them is UserDefaults via App Groups. This means manually serializing everything (app tokens, category tokens, web domain tokens, timestamps, flags) into UserDefaults keys.

Here is the minimum shared state I ended up needing:

isCurrentlyUnlocked: whether an unlock session is active
quotaEndTimestamp: when the unlock timer expires
globalSerializedTokens: the app tokens to re-block (base64 JSON)
globalSerializedCategoryTokens: same for categories
globalSerializedWebDomainTokens: same for web domains
lastShieldDayCheck: when the Shield Extension last checked for a new day

Serialize carefully. If the token data fails to decode and you write an empty set back to UserDefaults, you have permanently destroyed your blocking data. Always validate before overwriting.

Lesson 5: You Must Block Apps, Categories, AND Web Domains

When you apply a shield, you need to set three properties on your ManagedSettingsStore:

store.shield.applications: blocks individual apps
store.shield.applicationCategories: blocks app categories
store.shield.webDomains: blocks web domains

If you forget web domains, users can access Instagram through Safari. If you forget categories, entire groups of apps slip through. I missed this across three different extension files and had to fix it in all of them.

Lesson 6: The Stale Flag Problem

Your main app sets isCurrentlyUnlocked = true when the user starts an unlock session. It starts a timer to set it back to false when the session expires.

But if the user backgrounds your app, that timer stops. The flag stays true indefinitely. Your extensions read the flag and think apps should still be unlocked, even though the timestamp says the session expired 2 hours ago.

The fix: ** ManagedSettingsStore**. Always check the timestamp. If isCurrentlyUnlocked is true but quotaEndTimestamp is in the past, the session has expired regardless of what the flag says. Check both in every extension.

Lesson 7: Make Your First Check Synchronous

When your app comes to the foreground after a long background period, there is a race condition. The UI starts rendering, async tasks kick off, and the database begins initializing, all before you have had a chance to check whether the unlock session has expired.

The fix: run a synchronous, zero-async check before anything else. Before your SwiftData model container is created, before ContentView renders, read the UserDefaults state and re-block if needed. No await. No Task. Just a direct read and a direct write to ManagedSettingsStore.

This also means your re-blocking function cannot depend on the database. It has to work entirely from UserDefaults.

Lesson 8: Minute vs Second Precision

DeviceActivity uses DateComponents(hour:, minute:) for scheduling. Your unlock timestamps use TimeInterval (seconds since epoch).

An unlock session that expires at 10:30:45 will not be caught by a DeviceActivity check scheduled for 10:30. The check fires at 10:30:00, reads the timestamp, sees that 10:30:45 is still in the future, and does nothing. The next check might not come for 15 minutes.

The fix: when scheduling checks near the expected expiry, add a 1-minute buffer. Schedule for 10:31 or 10:32, not 10:30.

Lesson 9: Async Re-blocking Gets Suspended

If your re-blocking function uses async/await and has multiple await points, iOS can suspend the Task if the user switches to another app. The function stops mid-execution. Apps might be partially blocked: some locked, some not.

The fix: write a synchronous version of your re-blocking function that runs first, before any async work. It does not need to be perfect. It just needs to apply the shield immediately. The async version can clean up state afterward.

The Architecture That Actually Works

After 97 days, 21 bugs, and two full rewrites of the app, here is the architecture I would recommend to anyone building on the Screen Time API:

Three independent blocking systems. Shield Extension, DeviceActivity Monitor, Main App. All three
check and re-block independently.
Shared state via App Groups UserDefaults. Serialize everything carefully. Validate before
overwriting. Always check timestamps alongside boolean flags.
Chained DeviceActivity schedules. Never schedule more than 44 minutes out. Chain checks that each
schedule the next one.
Synchronous first check on foreground. Before database, before UI, before async. Read UserDefaults,
re-block if expired.
Block apps, categories, AND web domains. In every extension that applies a shield.
Guard intervalDidEnd. Do not assume it means the user's time is up. Check the actual state before
re-blocking.

This is not elegant. It is defensive to the point of paranoia. But app locking is a feature where one failure destroys the user's trust in your entire product. Being paranoid is the right call.

One More Thing

The emulator lies. My app blocking worked perfectly in Xcode's simulator. It failed completely on a real device when Xcode was not attached. The debugging environment changes the behavior of background extensions.

Always test app blocking on a real device, disconnected from Xcode, with the app backgrounded or killed. That is the only environment that matches what your users will experience.

I hope this saves you some of the 97 days it took me. If you are building something with the Screen Time API and hit a wall, I have probably hit the same wall, so feel free to reach out.

Habit Doom is the app I built with all of this. It locks your apps until your
habits are done. Free on the App
Store.

Two AI Agents Told Me My App Was Impossible. One Shipped It.

Richard Andrews — Mon, 23 Mar 2026 10:38:00 +0000

In December 2025, I asked ChatGPT how to automatically block apps after a timer expires in iOS. The response was clear:

"Programmatic auto-blocking after a certain time is not supported by the Screen Time API. The
DeviceActivity token is opaque and cannot be used once your app is closed or in the background."

Claude said the same thing. So did Cursor’s AI. Three tools, same answer: your app is impossible.

Four months later, Habit Doom is on the App Store. It auto-blocks apps. It works in the background. It does exactly what three AI agents told me could not be done.
Here is what happened.

What I Was Building

Before I get into the AI tools, let me explain what made this app so hard to build.
Habit Doom locks your distracting apps (Instagram, TikTok, YouTube) until you complete your daily habits. Not a timer. Not a gentle reminder. A hard lock at the operating system level. You physically cannot open Instagram until you have done your morning routine.

To build this on iOS, you need Apple’s Screen Time API. And the Screen Time API is not one thing. It is three separate frameworks that need to work together:

FamilyControls. Asks the user for permission to monitor and block apps.
ManagedSettings. Applies the actual blocks (called "shields") to selected apps.
DeviceActivityMonitor. Watches for time-based events and triggers actions.

Here is the catch: these frameworks do not all run inside your app. The DeviceActivityMonitor runs as a separate process called an “extension.” Think of it as a tiny background program that iOS manages independently. Your main app and this extension need to share data through something called “App Groups,” a shared storage space that both can access.

If that sounds complicated, it is. And it is where every AI tool I tried started to break.

I had just finished an iOS development course. I knew Swift and SwiftUI. I had never shipped an app. Here is how each AI tool performed across four months of building.

Cursor (Nov–Dec 2025)

Cursor was my first AI coding tool. I used it to build the first version of Habit Doom.

What Cursor did well:

Cursor was fast. It scaffolded the entire UI in days: habit creation screens, settings, navigation, the data model. For standard SwiftUI code, it was significantly faster than writing everything by hand.

  // Cursor generated clean SwiftUI views like this quickly
  struct HabitRow: View {
      let habit: Habit

      var body: some View {
          HStack {
              Image(systemName: habit.icon)
                  .foregroundColor(.purple)
              VStack(alignment: .leading) {
                  Text(habit.name)
                      .font(.headline)
                  Text("Current Streak: \(habit.streak) days")
                      .font(.caption)
                      .foregroundColor(.secondary)
              }
          }
      }
  }

For lists, navigation stacks, forms, animations, and state management, Cursor handled it. If you are building a standard iOS app without complex system integrations, Cursor is a genuinely good tool.

Where Cursor broke down:

The Screen Time API. Cursor works by predicting the next line of code based on your current file. But the Screen Time API requires understanding how three separate targets (your app, the Shield extension, and the Monitor extension) coordinate through shared state.

Cursor could not hold that in its head. It would suggest API calls that looked right but used wrong types:

  // What Cursor suggested (does not compile)
  let store = ManagedSettingsStore()
  store.shield.applications = selectedApps  // Wrong — needs Set<ApplicationToken>
  store.shield.applicationCategories = .all  // Wrong — needs .specific(tokens)

  // What actually works
  let store = ManagedSettingsStore()
  store.shield.applications = selection.applicationTokens
  store.shield.applicationCategories = .specific(selection.categoryTokens)

On December 29, 2025, I committed: “Tested ScreenTime feature but failed. Cleaned the rest of the code.” That commit included two troubleshooting documents I had written ( CRITICAL_FIX_NEEDED.md and EXTENSION_NOT_TRIGGERING_ISSUE.md) cataloging everything that was broken.

The extension was built. The code compiled. But iOS never triggered it. Cursor could not figure out why.

ChatGPT and Claude in the Browser (Dec 2025)
After Cursor hit a wall, I tried a different approach. I copied my Swift files into ChatGPT and Claude, explained the problem, and asked for solutions.

What they did well:
Both were better than Cursor at explaining iOS architecture. They understood the privacy model, the concept of opaque tokens, why Apple designed the API the way they did. If I needed to learn why something worked a certain way, ChatGPT and Claude were helpful teachers.

Where they broke down:
Three specific failures that cost me weeks.

Problem 1: The extension never triggers.
My DeviceActivityMonitor extension was built and embedded correctly. But iOS never called it. I wrote up the issue in detail:

▎ "DeviceActivityReport extensions are NOT automatically triggered by iOS. There is no public API to
request a DeviceActivityReport from the main app. The extension only runs for custom contexts."

ChatGPT suggested checking build phases and embedding settings. Claude suggested verifying the extension’s Info.plist. Both were reasonable debugging steps, but neither identified the actual issue, which was that I was using the wrong type of extension for what I needed. I needed a DeviceActivityMonitor (which watches schedules), not a DeviceActivityReport (which generates usage reports).

Problem 2: App icons.

I needed to show the icons of apps the user selected for blocking. The Screen Time API returns opaque ApplicationToken objects. You cannot extract the app name, bundle ID, or icon from them directly. Apple designed it this way for privacy.

I asked both tools how to get the icons. Both said: you cannot. They suggested that other app-blocking apps maintain a pre-built library of app icons that they fall back to.

This was wrong. Apple provides a Label view that renders the token's icon and name natively. Neither ChatGPT nor Claude knew about this because there are very few examples of it online.

Problem 3: Auto-blocking after timer expires.

This was the big one. When a user’s earned screen time runs out, Habit Doom needs to automatically re-block their apps, even if the app is closed.

Both ChatGPT and Claude told me this was impossible. The token is opaque. The main app cannot run in the background indefinitely. There is no push notification trigger for re-blocking. Their conclusion: you cannot programmatically re-block apps after a timer expires.

They were describing real constraints. But the conclusion was wrong.

Claude Code (Jan 2026–Present)

In January 2026, I switched to Claude Code, Anthropic’s CLI tool that works directly in your project directory.

The difference was immediate. And it came down to one thing: Claude Code reads your entire project, not just the file you paste into a chat window.

Solving the extension trigger problem:

Claude Code read the main app, the extension code, the entitlements files, and the project.pbxproj all at once. It identified that I had set up a DeviceActivityReport extension (for generating usage reports) when I actually needed a DeviceActivityMonitor extension (for watching time-based schedules). It restructured the extension, updated the entitlements, and fixed the App Group configuration in one session.

Solving the app icons problem:
On January 5, 2026, exactly one week after the “failed” commit, I committed: “Fixed the locked app icon issue and removed all code for screentime report.”

Claude Code found that Apple’s Label view accepts an ApplicationToken and renders its icon and name. It built helper classes ( AppIconExtractor, AppIconCaptureHelper, AppIconHelper) that capture and cache these icons for use throughout the app. Three files that ChatGPT and Claude said were impossible to write.

Solving auto-blocking:
This was Claude Code’s biggest contribution. It designed a pattern called schedule-chaining:

When the user earns screen time, start a DeviceActivityMonitor schedule that ends when the time expires
When the schedule ends, the intervalDidEnd callback fires (in the extension, not the main app)
The extension re-applies shields (blocks) to all selected apps
The extension chains the next schedule for the next check

The key insight that the other tools missed: DeviceActivityMonitor extensions are separate processes. They run independently of your main app. iOS keeps them alive. So you do not need your app to be open to re-block apps. The extension does it.

  // The schedule-chaining pattern for auto-blocking
  // This runs in the DeviceActivityMonitor extension — NOT the main app
  class HabitDoomMonitor: DeviceActivityMonitor {

      override func intervalDidEnd(for activity: DeviceActivityName) {
          // Timer expired — re-block all apps
          let store = ManagedSettingsStore()
          let tokens = loadTokensFromAppGroup()  // Shared storage
          store.shield.applications = tokens

          // Schedule the next check
          chainNextSchedule()
      }

      func chainNextSchedule() {
          let center = DeviceActivityCenter()

          // Rotate slot names so schedules don't overwrite each other
          let slot = currentSlot % 5
          let name = DeviceActivityName("reblockChain_\(slot)")

          let schedule = DeviceActivitySchedule(
              intervalStart: nowComponents(),
              intervalEnd: nextCheckComponents(),
              repeats: false
          )

          try? center.startMonitoring(name, during: schedule)
      }
  }

Beyond the core features, Claude Code helped debug 21 critical bugs: race conditions between extensions, midnight re-blocking failures, shield conflicts. Problems that only appear when three separate processes share mutable state.
I am still using Claude Code today for every feature and bug fix.

Tools I Have Not Tried

Two other AI coding agents worth knowing about:

OpenAI Codex
OpenAI’s cloud-based coding agent. It reads your repository, writes code, and runs tests in a sandboxed Linux environment. The iOS limitation: it cannot compile Swift for iOS, run the simulator, or test against Apple’s frameworks. You would need to take its output and integrate it yourself. Potentially useful for pure logic (data models, algorithms, networking code), but untested for anything involving Apple’s restricted APIs.

Google Gemini / Jules
Google’s Gemini powers the Jules coding agent, which focuses on async GitHub tasks like fixing bugs and opening PRs. Gemini has strong reasoning and a large context window. For iOS development, the tooling is less mature than Claude Code’s interactive CLI. Jules works on isolated tasks rather than real-time development sessions. Could be worth trying for well-defined bug fixes, but I have not tested it against Screen Time API challenges.

Why iOS Is Uniquely Hard for AI
If you are building a web app or a standard mobile app, most AI tools work fine. iOS with system-level APIs is a different story. Here is why:

Multi-target projects. A Screen Time app is three separate programs (app + two extensions) sharing state. Most AI tools reason about one file at a time.
Opaque APIs. Apple hides information deliberately for privacy. Tokens do not contain human-readable data. The "obvious" solution (extract the app name from the token) is intentionally impossible.
Almost no documentation. The Screen Time API has sparse official docs and very few community examples. AI models trained on Stack Overflow have almost nothing to learn from.
Silent failures. One wrong entitlement and the app compiles, installs, and runs, but the extension never triggers. No error. No crash. Just silence.
Extension lifecycle. Extensions are separate processes that iOS can kill and restart at any time. Code that works when the app is open can fail completely in the background.

What I Recommend

Here is my honest recommendation for building an iOS app with AI in 2026:

If your app uses standard iOS APIs (UIKit, SwiftUI, Core Data, networking), Cursor and ChatGPT will get you far. But the moment you touch Apple’s restricted frameworks (Screen Time, HealthKit, FamilyControls, DeviceActivity), you need a tool that understands your entire project, not just the file you are looking at.
For me, that tool is Claude Code. Two AI agents told me the core feature of my app was impossible. Claude Code shipped it.

Habit Doom is live on the App Store. The auto-blocking works. The app icons display correctly. All because
one AI agent understood what the others could not.

I Shipped 4 Failed iOS Apps. Then One Finally Worked. OR DID IT?

Richard Andrews — Wed, 18 Mar 2026 21:00:55 +0000

Open my App Store Connect right now and you will see a graveyard.

UnManaged Tasks: a task management app. Still live. Zero traction. One Diary: a journaling app. Shipped it, nobody cared. Artizan App: I do not even remember what this one did. It says “Removed from App Store.” That about sums it up.

Before Habit Doom, I had built close to a dozen web and mobile apps. Every single one followed the same pattern: exciting idea, burst of energy, weeks of building, launch into silence, slow death. Some had a brief spark (a few interested testers, a moment of validation), but I could never keep the fire alive.

. . .

4 failed apps

Shipped before one finally worked

. . .

I was, by every objective measure, a serial failure at shipping products.

This is a story about what changed. Not because I suddenly became more talented. Not because I had a breakthrough idea that was obviously better. But because I changed how I thought about failure itself. That shift, backed by decades of research from psychologist Carol Dweck, is the reason Habit Doom exists today.

This is Part 2 of a series on the science behind Habit Doom, inspired by Professor Jiang’s lecture on the PredictiveHistory YouTube channel. Part 1 covers the Marshmallow Test and delayed gratification.

## The Research: Why Most People Quit

In the 1990s, Stanford psychologist Carol Dweck conducted a series of experiments that fundamentally changed how we understand achievement. She gave children a set of puzzles, easy ones at first, then progressively harder ones designed to be unsolvable.

What she observed was not about intelligence. It was about how the children responded to failure.

One group, when they hit the impossible puzzles, said things like: “I’m not smart enough.” “I can’t do this.” They became frustrated, gave up quickly, and (here is the striking part) their performance on the easy puzzles dropped. Failure on the hard problems made them worse at problems they had already solved.

The other group responded differently. They said things like: “This is tricky, I need a new strategy.” “I love a challenge.” They leaned in. They tried different approaches. Some of them actually improved their performance even though the puzzles were designed to be unsolvable.

Dweck identified two distinct mindsets:

Fixed mindset: "My abilities are set. Failure means I've hit my ceiling. If I have to try hard, it means I'm not naturally good at this."
Growth mindset: "My abilities can be developed. Failure is information. Effort is the path to mastery."

The implications were massive. Dweck tracked students, athletes, and professionals across decades. The pattern held everywhere:

Students with a growth mindset recovered from bad grades faster and ended up with higher GPAs
Athletes who believed skill was trainable practiced more deliberately and improved faster
Professionals with a growth mindset sought feedback instead of avoiding it, and advanced further in their careers

The critical insight was this: mindset is not about positive thinking. It is about how you interpret failure. Fixed mindset treats failure as evidence of who you are. Growth mindset treats failure as evidence of what to try next.

## My Fixed Mindset Years

I did not know about Dweck’s research when I was shipping my first apps. But looking back, I was a textbook case of fixed mindset in action.

Here is what my inner monologue sounded like:

After UnManaged Tasks got zero traction: "Maybe I'm just not good at product design. Real founders know what people want. I clearly don't."
After Artizan App died: "I should stick to my day job. Building products is for people who have the instinct for it."
After the fifth or sixth failure: "I've tried enough times. If I were going to succeed at this, it would have happened by now."

Every failure felt like a verdict. Not on the product, but on me. Each abandoned project reinforced the belief that I was not the kind of person who ships successful products. That I lacked something fundamental that real founders have.

And because I believed that, I acted accordingly. I stopped doing user research. I stopped iterating past the first version. I would build what I thought was good, ship it, and when people did not care, I took it as confirmation that the problem was me, not the approach. Why iterate on something if the underlying issue is that you are not talented enough?

That screenshot is real. That is my actual App Store Connect. Zero units. Zero proceeds. “Removed from App Store.” A graveyard of ideas I believed in and then abandoned because I interpreted silence as a final answer.

## The Moment Everything Shifted

Habit Doom almost died the same way.

The first version of the app was, honestly, bad. Not technically broken (it worked). But the onboarding was confusing. The core concept, lock your apps until you do your habits, made perfect sense to me but was nearly incomprehensible to people seeing it for the first time.

I shared it with friends, family, anyone who would look at it. The feedback was brutal:

"I don't understand what this does."
"Why would I want to lock my own apps?"
"I would never pay for this."
"The onboarding lost me after the second screen."

They were right. Every single piece of feedback was valid. The app was not clear. The value proposition was not obvious. The onboarding assumed too much context.

Here is where the old me would have quit. In fact, I felt the pull. That familiar voice: “See? Another one. People don’t want this. Move on to the next idea.”

But something was different this time. I am not sure I can pinpoint exactly why — maybe it was the accumulated frustration of too many abandoned projects, maybe I was just tired of the pattern. But instead of interpreting the feedback as “this idea is bad and you should stop,” I heard it as “ this execution needs work and you need to fix it.”

That distinction, between “I failed” and “this approach failed,” is exactly what Dweck’s research describes. And it changed everything.

## Iteration as a Mindset Practice

I threw out the entire onboarding and rebuilt it from scratch. Not a tweak. A complete rethink of how a new user encounters the app for the first time.

Then I tested it again. Different people this time, because the original testers already knew the concept and could not represent new users anymore. Fresh eyes. Honest reactions.

It was better. But not good enough. So I rebuilt it again.

And again.

I went through so many rounds of this that I literally exhausted my inner circle. Every friend, every family member, every colleague, every friend-of-a-friend. They had all seen the app at some point during testing. I even recruited my girlfriend as an unpaid market research department, which mostly meant she had to casually bring up “so how do you feel about your screen time?” to every friend she met for coffee. She was thrilled (or at least took enough pity on my distressed face to pretend she was). I had no one left within two degrees of separation who had not been a test user.

And that was actually the moment I knew I was ready. Not because the app was perfect — it was not. But because I had iterated so many times, with so many different people, incorporating so much real feedback, that the only way to continue improving was to show it to the world.

Here is what the growth mindset actually looks like in practice:

Build something, knowing it will be imperfect.
Show it to people, not to get validation, but to get data.
Listen without defending. Their confusion is your product's problem, not their problem.
Rebuild based on what you learned, not what you assumed.
Repeat with new people, because previous testers cannot unsee what they have seen.

That loop is the entire game. And the only thing that makes it possible is believing that iteration leads somewhere, that you are not just rearranging deck chairs on a sinking ship, but actually building something better with each cycle.

## Why Habits Are Growth Mindset Training

Here is the connection that Professor Jiang's lecture made click for me: daily habits are the most practical growth mindset training available.

Think about what happens when you commit to a daily habit:

Day 1: You are terrible at it. Your guitar playing sounds awful. Your writing is stiff. Your meditation lasts 90 seconds before your mind wanders.

Day 7: Slightly less terrible. You can almost play a chord change without pausing. Your writing flows a bit. You can sit for 3 minutes.

Day 30: You can hear the difference. Other people can hear the difference. The thing you were bad at is becoming the thing you do.

Every single day of that progression is a micro-dose of growth mindset. You are proving to yourself, with evidence you can see and hear and feel, that ability is not fixed. That effort produces results. That the person you were on Day 1 is not the person you have to be on Day 30.

This is not abstract psychology. This is literally what happens when you track your habits in an app and watch the numbers climb. My guitar practice went from 0 to 23 check-ins. My reading streak hit 11 days. My habit completion rate climbed to 82%. Each of those numbers is concrete proof that I am not the same person I was a month ago.

. . .

10% → 85%

Habit completion improvement in 4 weeks

. . .

And that proof compounds. The more evidence you accumulate that you can improve, the easier it becomes to face the next failure with a growth mindset instead of a fixed one. Because you have data. Not hope — data.

Download Habit Doom For Free

## The Part Nobody Talks About: Zero Downloads Is Not the End

I want to be transparent about where Habit Doom is right now, because I think the honest version of this story matters more than the polished version.

As I write this, Habit Doom has 36 downloads over two weeks. No revenue — in-app purchases are not even integrated yet. The App Store trend chart shows days with zero downloads. The proceeds chart is a flat line at $0.00.

By every conventional startup metric, this is not a success story. It is a story in progress. I am writing blog posts at midnight after my day job. I am testing the app on strangers because I have used up everyone I know. I am staring at download numbers that would make most people quit.

But here is what is different from every other project I have shipped: I am not interpreting the numbers as a verdict. Zero downloads this week does not mean the app is bad. It means nobody knows about it yet. Low engagement does not mean the concept fails. It means the onboarding might need another pass, or the messaging is not clear enough, or I have not found my audience yet.

Every one of those is a solvable problem. A growth mindset problem. Not a “you are not cut out for this” problem.

I have already iterated through more versions of this app than all my previous projects combined. I rebuilt the onboarding from scratch three times. I rewrote the App Store description. I redesigned the screenshots. I started this blog. Each iteration makes the product slightly better and my understanding slightly deeper.

Is this going to work? I genuinely do not know. But for the first time in a dozen projects, I am still here. Still iterating. Still showing up. And that, according to Dweck’s research, is the only variable that actually matters.

## How to Apply This to Your Own Habits

You do not need to build an app to benefit from growth mindset. You just need to change how you talk to yourself when things go wrong. Here is the practical framework:
### Reframe the Identity Statement

Fixed: "I'm not a morning person" Growth: "I haven't found a morning routine that works for me yet"

Fixed: "I can't focus for more than 10 minutes" Growth: "My focus muscle needs training — I'll start with 5 minutes"

Fixed: "I always fail at habits" Growth: "My previous systems didn't work — I need a different approach"

Fixed: "I'm addicted to my phone" Growth: "My environment makes it easy to scroll — I need to change the environment"

The word "yet" is the most powerful word in the growth mindset vocabulary. "I can't do this yet" is a fundamentally different statement from "I can't do this." One is a status update. The other is a life sentence.

### Build the Evidence Base

Start tracking something. Anything. The reason apps like Habit Doom work is not the lock mechanic (though that helps). It is the visible evidence of growth. When you can see your streak climbing, your check-ins accumulating, your completion rate rising, you are building an evidence base against the fixed mindset voice.

That voice says "you can't change." Your habit data says "you already have."

### Expect the Dip and Plan for It

Every habit has a dip. The excitement of Day 1 fades. The streak breaks. You miss a day and the fixed mindset voice screams: "See? I told you. You always quit."

Plan for it in advance. Decide now what you will do when you miss a day. Not if — when. The growth mindset response is not "I failed." It is "I missed one day. My 14-day streak becomes a 1-day streak. Time to build the next one."

Habit Doom's streak system is designed around this. When you break a streak, the counter resets — but your total check-ins and earned screen time stay. You can see that even with broken streaks, the overall trajectory is upward. That is growth mindset built into the data model.

## Your Mindset Is a Habit Too

Carol Dweck's most important finding was not that growth mindset is better. It was that mindset itself is changeable. You are not born with a fixed or growth mindset. You practice one or the other, every day, through the stories you tell yourself about what your failures mean.

Every time you miss a habit and try again the next day, you are practicing growth mindset. Every time you look at a bad week and ask "what can I change?" instead of "what is wrong with me?", you are rewiring how your brain processes failure.

I shipped four failed apps before Habit Doom. Maybe Habit Doom will be the fifth failure. I genuinely do not know. But I know that I am no longer the person who interprets silence as a verdict. I am the person who interprets silence as "iterate and try again."

That shift — from fixed to growth — is not something I read in a book and suddenly believed. It is something I trained, one habit at a time, one iteration at a time, one rebuilt onboarding at a time.

You can train it too. Start with one habit. Track it. Watch the numbers. When the streak breaks — and it will — notice the voice that says "you always quit." Then open the app, check off the habit, and start a new streak.

That is growth mindset. Not as theory. As practice.

Habit Doom is free on the App
Store. It takes 30 seconds to set up.
Your first streak starts today.