I still love opening an app I built on a real iPhone. That part never changed.
Apple did not make me stop loving apps.
Apple made me want a break from asking permission to ship them.
After months of building Breakify across React Native, Expo, Swift, native Screen Time frameworks, subscriptions, entitlements, and everything else an iOS product needs, I expected the hardest part to be engineering.
It was not.
The hardest part was finishing the product and discovering that finished did not mean shippable.
I could solve the technical problem in a day and still lose weeks to a review queue, a metadata mistake, or an explanation that the next reviewer interpreted differently.
The app worked. The waiting did not.
Breakify uses Apple's Screen Time capabilities to help people control distracting apps. That is sensitive access, so a careful approval process makes sense. The entitlement took some time, but it was relatively straightforward and much faster than what came afterward.
What I did not expect was how much time could disappear after the engineering was already done.
A rejection could arrive because of a small mistake in the App Store metadata rather than the app itself. Another round could focus on wording. A build could be technically correct while something around the build was not. Fixing the issue might take minutes. Returning to the front of the process did not.
Submit the build.
Wait for review.
Watch it move into review.
Receive a rejection. Correct the detail. Submit again. Return to waiting for review.
Apple's review process cost Breakify roughly two months. Not two months of building a better product. Two months of correcting, explaining, submitting, waiting, and wondering which small detail would become the next wall.
That is the part that screwed me
I understand why the App Store has rules. Users deserve privacy, safety, and products that do what they claim. Breakify asks for powerful permissions, and those permissions should never be handed out casually.
But there is a difference between meaningful product scrutiny and losing weeks to avoidable review friction.
The painful part was not being told that a real safety issue existed. It was watching momentum disappear because a minor metadata error could carry almost the same time penalty as a broken feature.
When I build, I work through fast loops. Make the change. Run it. Test the edge cases. Find what is weak. Improve it. Ship it. Listen. Repeat.
App review placed a locked door in the middle of that loop.
I could move quickly everywhere except the final metre.
I am taking a small break from building apps
Not forever.
I still love React Native and Expo. I love being able to build a real iOS experience, drop into Swift when the platform requires it, connect native services back to the application, and put a thoughtful product in somebody's pocket.
I already have exciting app ideas I intend to ship later this year.
But right now, I want to build without every release becoming a negotiation.
So, for a little while, my next chapter is web software.
I am going deeper into Next.js and building SaaS products that live on the web. Products where I can ship a fix when it is ready. Products where an onboarding experiment can reach users today. Products where changing one sentence does not send the entire release back through a gate.
The web gives the feedback loop back to me
With a web product, deployment is not the end of a long approval process. It is part of the development loop.
I can build the feature, verify it, deploy it, watch how it behaves, and improve it. If something is wrong, I can correct it. If users misunderstand a screen, I can rewrite it. If the product needs to pivot, I can move while the idea is still alive.
That speed matters more to me now because I am not only writing code. I am trying to discover products.
A new SaaS idea begins with uncertainty. The first version is a question, not an answer. Finding the answer requires short loops between building and reality. Every unnecessary delay makes that conversation slower.
Next.js gives me the kind of surface I want for this phase: interface, server logic, routing, data fetching, APIs, and deployment working as one product. I can concentrate on the problem instead of dividing every idea into separate platform battles before I know whether users even want it.
Breakify still taught me exactly what I needed
I am frustrated with the process, but I do not regret building the app.
Breakify pushed me beyond a comfortable JavaScript product. I had to understand native capabilities, Swift services, bridging, entitlements, provisioning, background behaviour, subscriptions, privacy, and the responsibility that comes with controlling access to applications on somebody else's device.
It also taught me that distribution is part of engineering.
A product is not finished when the code works on my phone. It is finished when a real person can get it, understand it, trust it, and use it. The path between those two points can determine what is practical to build.
That lesson is now changing what I build next.
This is not retreat. It is a change of terrain.
I am not moving to web SaaS because it is automatically easy. Payments still fail. Databases still need care. Authentication still has edge cases. Infrastructure still breaks. Distribution is still difficult, and nobody owes a new product attention.
But those are product and engineering problems I can act on.
That is the difference.
I want my next months to be spent building, testing, learning, and shipping. I want the difficult part to be making something useful, not waiting to learn whether a metadata field has cost me another review cycle.
I will build mobile apps again, and I expect to ship something exciting later this year.
For now, though, I am opening the browser, starting a new Next.js project, and enjoying the fact that when the product is ready, I can press deploy myself.
Apple took two months from Breakify. I am taking the next few months back.