There were nights when Breakify was just a half-working screen on my phone and a list of things I still did not understand.
Breakify took far longer to build than I expected.
Not because it began as a huge idea.
It began with a simple question:
Why do the devices that are so good at capturing our attention offer so little help when we seriously decide to take it back?
I built Breakify because “try harder” is not a product for people fighting habits designed to be difficult to escape.
I wanted to build real friction
Most habit trackers record what already happened.
You tap a box. The streak grows. If you relapse, the number returns to zero.
That can help, but it does not intervene at the moment when discipline is weakest.
Breakify was built to do more.
It combines habit and sobriety tracking with enforced alarms, app blocking, screen control, recovery tools, an AI coach, journals, challenges, and visible progress through a 60, 90, or 180-day reset.
The goal is not only to count better days.
It is to help create them.
For a better relationship with technology
I did not build Breakify because phones are evil.
I built it because many products are designed to keep people inside them for as long as possible.
Social feeds never finish. Games create another reward. Notifications manufacture urgency. Compulsive content is always one gesture away.
Individual willpower is competing against systems tested and optimised by enormous companies.
Breakify is my attempt to put some of that product design on the user’s side.
If somebody wants to quit a harmful habit, reduce social media, stop gaming through the night, rebuild sleep, or regain control of their attention, the software should make that decision easier to honour.
I studied the moment before the product
Onboarding mattered more than I first realised.
A person opening Breakify may be motivated, ashamed, doubtful, exhausted, or all four at once. A generic welcome carousel would waste the most important moment in the experience.
I studied how competing habit, recovery, and screen-time products introduced themselves. I looked at what they asked first, when they requested permissions, how they explained blocking, where they placed the paywall, how they visualised progress, and which screens created hope rather than pressure.
Then I handcrafted Breakify’s onboarding around its actual promise.
The user chooses what they want to change, the length of the transformation, the habits and apps involved, and the level of accountability they are willing to accept. Permissions arrive with context. The product explains why it needs access before iOS asks for it.
Good onboarding is not decoration.
It is the first act of trust.
The hardest feature lived outside React Native
Breakify is an Expo and React Native app, but meaningful screen-time control depends on native iOS frameworks.
Apple provides Family Controls, Managed Settings, and Device Activity so authorised apps can work with selected applications and apply privacy-preserving restrictions. Access also requires the Family Controls entitlement.
I generated the iOS project, opened it in Xcode, added the native capabilities, and wrote the Screen Time service in Swift. An Objective-C bridging layer connected that service back to the React Native application.
That bridge allowed the TypeScript side to request authorisation, receive the user’s private app selections, configure schedules, and ask the native layer to apply or remove restrictions.
The interface could remain React Native.
The enforcement had to speak iOS.
The entitlement was the first checkpoint
Screen Time access is intentionally protected.
Before an app using Family Controls can be distributed, Apple must approve the entitlement. If the app includes Screen Time extensions, those targets need the correct entitlement and provisioning as well.
This is a good privacy boundary for users.
For a developer, it also means the timeline is not entirely yours.
The entitlement approval was not instant, but it was relatively straightforward and much faster than the App Review process that followed.
Once the native capability and provisioning were ready, the application itself still had to make it through App Review.
Apple's review process cost me two months
Apple rejected one submission because of a small mistake in the App Store metadata, not because the product was broken or the Screen Time implementation was unsafe. Correcting the mistake was quick. Getting through another review cycle was not.
The build would sit as submitted, move to waiting for review, finally enter review, and then a small issue could send it all the way back to the beginning. Fix the detail. Resubmit. Wait again.
That pattern kept repeating in different forms. A wording issue, an explanation that needed more detail, or another piece of review friction could return the app to the queue. Some scrutiny was justified because Breakify uses sensitive capabilities. Some of it felt completely unnecessary.
App Review itself cost me roughly two months.
Those were not two months spent inventing better features. They were two months of submitting, waiting, answering, correcting small details, and submitting again.
The frustrating lesson was that I could finish the engineering and still have almost no control over when the product reached users.
I did not stop building, but Apple made the final part of shipping far slower and more painful than it needed to be.
“Working” was not enough
App blocking is powerful. It also creates sharp edges.
What happens if the schedule crosses midnight?
What happens after the phone restarts?
What if the user changes their selected apps?
What if authorisation is revoked?
What if the JavaScript application is not running when the restriction should begin?
A feature can work perfectly in a demo and fail the first time it meets a real week.
I had to test the bridge, native state, schedules, permissions, alarms, background behaviour, and the React Native interface as one system. Each layer could be correct by itself while the product still behaved incorrectly between them.
Why the app is more than a blocker
Blocking an application can interrupt a habit.
It cannot tell somebody what to do with the space that remains.
That is why Breakify grew into a broader recovery and discipline product. It includes goals, routines, enforced wake and sleep alarms, journals, challenges, coaching, relapse support, progress analytics, and a world that changes as the user changes.
The restriction creates a pause.
The rest of the product helps the user build something inside it.
Why I kept going
There were easier applications I could have shipped.
Products without protected entitlements. Products without native bridges. Products where a failed feature causes an ugly screen rather than accidentally blocking the wrong app.
Breakify was worth the difficulty to me because the problem was already present in my own life and in the lives of people I knew.
Attention becomes a life one hour at a time. Sleep, relationships, work, health, and self-respect are all shaped by what repeatedly receives it.
If Breakify helps somebody regain even part of that attention, the waiting, bridging, reviews, and rewrites were not wasted.
Breakify took a long time because real behavioural change deserved more than a streak counter, and real iOS enforcement demanded more than a JavaScript screen.