Launching my first iOS app taught me that the hard part is not the code. The hard part is everything around the code: deciding what to cut, dealing with App Store Connect, writing a description that makes sense to a stranger, and accepting that the version you ship will not be the version you imagined.
I went into it expecting the build to be the wall I would hit. The build was fine. The wall was everything I had not planned for.
This is a write-up of what actually happened when I shipped my first app under softDev23, what surprised me, and what I would tell anyone sitting on a half-finished project, wondering if it is worth pushing it over the line.
I am still early in iOS development, so this is not advice from someone who has done it fifty times. It is notes from someone who just did it once and paid attention.
→RelatedThe Tools I Actually Use Every Day as an Indie iOS DeveloperThe build is the part you can control, so it feels safe
The code was the comfortable part because it was the part I could fully control. When I was writing SwiftUI views and fixing layout bugs, I always knew what the next step was. There was a problem, I worked on the problem, and the problem got smaller. That feedback loop is satisfying, and it is also a trap, because it can keep you polishing forever.
I noticed I kept finding reasons to stay in the code. One more refactor. One more animation. One more settings toggle nobody asked for. None of it was getting me closer to actually shipping. It was just the version of work that felt safe because it had no audience and no judgment attached to it.
What helped was being honest about why I was still in there. I was not improving the app for users. I was avoiding the uncomfortable parts that came after the build. Once I named that, it got easier to stop and move on to the steps I had been quietly dodging.
App Store Connect is a second project hiding behind the first
The biggest surprise of launching my first iOS app was how much work lives in App Store Connect, completely separate from the app itself. I had treated submission as a final button press. It is not. It is its own small project with its own learning curve.
There is the bundle identifier and signing setup, which I did not fully understand the first time and had to slow down and read about properly.
There are screenshots, which have specific sizes and which look worse than you expect when you actually see them in the store layout.
There is the privacy section, where Apple asks you to declare what data you collect, and you have to actually know the answer rather than guess. There is the description, the keywords, the support URL, the age rating questionnaire, and the review notes.
None of these are hard individually. The problem is that there are a lot of them, and no single one of them feels like progress, so they are easy to put off. If I were starting again, I would treat the store listing as a real task with its own time blocked off, not as paperwork I do in the last hour before submitting.
Scope is the decision that matters most
The single most useful thing I did was cut features instead of adding them. Every feature I kept in the first version was a feature I had to design, build, test, and support. Every feature I cut was a feature that could wait until I knew whether anyone wanted it.
This was hard because cutting a feature feels like admitting the app is less than you wanted. But shipping a smaller app that actually exists beats sitting on a bigger app that never leaves your machine.
My apps right now, like Habitual: The Grand Journey, Mana: Focus Evolved, and Think Drink: Water Tracker, are deliberately focused. They do a small number of things rather than trying to be everything.
The test I started using was simple. For each feature I asked: does the app make sense without this? If the answer was yes, the feature went on a list for later. That list is not a failure. It is the roadmap. It means version one ships, and version two has a reason to exist.
App review is less scary than the internet makes it sound
App review went more smoothly than I expected based on the horror stories I had read. The forums are full of rejection nightmares, and that noise made the whole thing feel like a coin flip. In practice, most rejections seem to come from a handful of avoidable issues rather than from reviewers being arbitrary.
The things that seem to actually matter are straightforward. The app should do what the description says. It should not crash on launch. It should not ask for permissions it does not use. If it has accounts or purchases, those need to work for the reviewer. If something in the app is not obvious, the review notes field is where you explain it so a reviewer is not left guessing.
I am not saying review is never frustrating, because it can be slow, and the feedback can be vague. But going in expecting a fair process that checks for obvious problems was closer to reality than going in braced for a fight. Lowering my own drama about it made the waiting easier.
Nothing dramatic happens on launch day, and that is fine
Launch day was quiet, and I had to make peace with that quickly. There was no spike, no flood of attention, no moment where the work paid off in an obvious way. The app went live, I told a few people, and the world continued exactly as before.
This is the part nobody warns you about, probably because it does not make a good story. As a solo developer with no existing audience, launching an app is not an event. It is a starting line. The app being available is necessary, but it is not the same as the app being found. Those are two different problems, and I had quietly assumed solving the first would solve the second.
What this changed for me was how I think about the work after launch. The build ends, but the actual job of getting the app in front of people is just beginning. That is where things like the store listing, writing about what I am building, and showing up consistently start to matter. None of that is glamorous, and all of it is slower than building.
What I would tell someone with a half-finished app
If you have a half-finished iOS app, the most useful thing you can do is decide what the smallest shippable version looks like and aim only at that. Not the impressive version. The done version. You can always add to something that exists. You cannot add to something that never shipped.
A few specific things I would pass on from launching my first iOS app:
Treat the App Store listing as real work, not an afterthought. Block time for it the same way you block time for code.
Cut features without guilt. A short feature list for version one is a sign of focus, not weakness. The cut features become your roadmap.
Read Apple’s guidelines before you submit, not after you get rejected. Most of the common rejection reasons are documented and avoidable.
Expect launch day to be quiet. Plan for what you do after launch, because that is the part that actually decides whether the app goes anywhere.
Pay attention to what surprised you and write it down. The second launch is easier, mostly because you are no longer surprised by the parts that are not code.
The real lesson from launching my first iOS app
The real lesson from launching my first iOS app is that shipping is a skill on its own, separate from building. I am still learning the building part, and I expected that. What I did not expect was that finishing, submitting, and releasing would be their own distinct skills that I also had to learn, and that those skills barely overlap with writing SwiftUI.
The good news is that those skills carry forward. The next app I prepared went more smoothly, not because I am a better coder, but because I already knew the shape of the work outside the code. App Store Connect was familiar. The store listing was a known task instead of a surprise. Launch day being quiet did not throw me.
If you are building toward your first launch, that is the thing worth knowing. The first one is slow and a little disorienting because you are learning two jobs at once. After that, one of those jobs becomes routine, and you get to spend more of your attention on the part you actually enjoy.
If you want to follow along as I keep shipping under softDev23, that is what I am doing in public, one small app at a time.
