Isometric cartoon illustration of a solo developer workstation showing SwiftUI code on a monitor, with a developer building a digital block bridge toward a launching rocket ship to represent building in public.

Building in Public: Behind the Scenes of a Solo iOS Developer

If you look at the App Store today, it’s easy to feel a sense of fatigue. The charts are dominated by corporate giants, hyper-monetized utilities, and clones of clones wrapped in heavy subscriptions. The “craft” of app development—the joy of building something native, beautiful, fast, and intensely focused on user experience—often feels like a relic of the past.

When I started my journey as an independent developer under the softDev23 brand, I made a commitment: I didn’t want to build generic tools. I wanted to build apps that feel like premium, crafted software. Apps with “soul.”

To push myself, I took on one of the most intense learning structures in the developer community: building and launching in public.

Here is what it’s actually like to build native iOS apps as a solo developer, the lessons I’ve learned about design and code, and why building in public has changed my entire philosophy of software.


The “10 Apps in 365 Days” Crucible

For a solo developer, the biggest enemy is not a lack of technical knowledge—it’s inertia. It’s incredibly easy to get stuck in “tutorial purgatory” or spend three years building a massive, over-engineered project that never actually launches.

To break that cycle, I challenged myself to build in public. By sharing my daily progress, code snippets, visual designs, and raw struggles on platforms like Substack, Reddit, and Twitter, I created a feedback loop of real-time accountability.

But building quickly doesn’t mean building poorly.

When you build in public, your code and design are on display. It forces you to maintain high standards from day one. Instead of relying on web-view wrappers or cross-platform frameworks that feel sluggish and generic, I committed to building strictly native iOS software using modern SwiftUI, SwiftData, and standard system frameworks.


Crafting the “Juice”: Why Native Details Matter

As a solo developer, your superpower is speed and care. You don’t have a board of directors or a committee approving features; you can spend four hours perfecting a single haptic feedback pattern or an entry transition because you know it makes the experience premium.

In game design, they call these tiny, satisfying interactions the “juice.” When you tap a button and it scales down slightly under your thumb, triggers a crisp, localized haptic click, and plays a fluid spring animation—that is the juice.

Here is how I tried to inject native craft into my projects:

  • Mana: My focus and productivity timer is built around a heavy cyberpunk aesthetic. I spent days perfecting a custom retro-sci-fi starfield background and a seamless glitch text animation. When you start a focus session, the screen feels alive and immersive, creating an immediate mental boundary for focus.
  • Think Drink: For this hydration assistant, I wanted to eliminate the chore-like feeling of logging water intake. I designed a gorgeous, fluid dark-to-sunset gradient background that covers the screen, paired with a frosted glass CTA button. Tapping it triggers a heavy, satisfying wave animation that makes logging water a micro-moment of delight.
  • Habitual: In this habit RPG, we created a custom HapticManager and physical long-press interactions. Instead of a basic tap, checking off a habit requires you to hold down the button. As you hold the button, it fills with your habit’s custom color, culminating in a heavy tactile “pop” and a burst of particles as your avatar moves across the map.

These are details that a massive, bloated development team might cut to save time. But as an indie developer, these details are your product.


The Tech Stack: SwiftData and Modern SwiftUI

From a technical perspective, building in public requires you to adopt robust foundations that allow you to move fast without breaking things.

Transitioning from standard Core Data to SwiftData (introduced in iOS 17) has been a game-changer. The declarative nature of SwiftData integrates perfectly with SwiftUI’s @Observable macro.

For example, in Habitual, representing complex structures like a user’s backpack, equippable relics, earned companion eggs, and daily streaks requires a highly relational data model. SwiftData allowed me to define these models in pure Swift code without manually managing complex database schemas, drastically shortening my development cycles.


What “Building in Public” Really Means

Ultimately, building in public isn’t just a marketing strategy. It’s a vulnerability exercise.

It means sharing the moments when your database container gets corrupted, when your App Store submission is rejected for a minor metadata issue, or when a design you spent a week on just doesn’t align with user expectations.

But it also means that when a user tells you that your habit RPG finally helped them manage their ADHD executive dysfunction, or that your hydration app’s design inspired them to drink water daily, you get to celebrate that win directly with the community that helped you build it.


Join the Journey

I’m still building, still learning, and still sharing every step of the way. If you are a creator, developer, or someone who simply appreciates premium, high-craft software, I invite you to follow along.

Check out the apps I’ve built so far:

  • 🧭 Habitual: The Grand Journey — Turn your daily habits into an epic exploration RPG.
  • 💧 Think Drink — The beautiful, sunset-gradient hydration assistant.
  • Mana — A cyberpunk focus timer designed to block out distractions.

Want to see behind the scenes? Subscribe to my newsletter and watch how we take these apps from local codebases to global App Store launches.

Leave a Reply

Your email address will not be published. Required fields are marked *