Imposter Syndrome, Featuritis and Just Shipping Something

I think everyone who does indie development harbors the dream of shipping an app or two that can earn them a living. The reality is that’s probably not going to happen and even if it does it’s going to take a lucky break and be a long term project. 

I tend to be the type to add too many features (featuritis) and be too picky when planning my own apps. This comes from wanting to build a great product as well as making it compelling for users to spend their cash.

There is also the constant worry that I will embarrass myself with a less than amazing app. Classic imposter syndrome. I’ve shipped dozens of successful apps and I still feel like I have no idea what I’m doing or how I accomplished that. For me, this all leads to paralysis and difficulty shipping. 

As an example, several of my apps make heavy use of maps and Apple's MapKit has been a moving target since the advent of SwiftUI. The app(s) in question have been in development for a while and I’ve gone back and forth between interfacing with MapKit via UIViewRepresentable, using MapKit for SwiftUI and MapBox for some time. 

I’ve recently learned that Mapbox now has “experimental” support for native SwiftUI frameworks so I experimented with that as well. It works fine.

The point is I’ve redone the map support in my apps at least five times and this app is yet to ship.

I have been working on these apps a long time, rearchitecting/redesigning them over the past 18 months. I’ve been looking to create an awesome map experience when the map in my app is a secondary feature.

Over the past few days I decided to step back and rethink my assumptions around app features considering the possibility I am overthinking things and maybe, just maybe, I can get by with a simpler approach. I really want to use the latest SwiftUI based stuff as much as possible. Working with the new SwiftUI frameworks is so much simpler than most of the older frameworks. That’s not saying SwiftUI is perfect. Far from it.

I think the SwiftUI route may lead to shipping something quicker. The key will be in not fighting the frameworks. Yes, SwiftUI is incomplete in areas and may not lend itself to all the customization we enjoyed in the UIKit/AppKit days. It’s best to stop fighting SwiftUI and make use of what’s there.

A clean, working app that has shipped should be better than a fancy custom app that never sees the light of day.

Using the most recent SwiftUI frameworks also limits an app to the latest iOS release. Just accept it and get on with the work. It’s just not worth fighting to provide last gen support for an app that doesn’t yet exist. If a market develops and cries for older OS support that’s a good problem to have and something to be dealt with in the future.

Single device support is good enough for a version 1.0. It’s not necessary to work with CoreData or SwiftData to sync data across devices. When creating a new app just ship on one platform and worry about adding sync support later. It’s likely that in creating a multi-device app you will need to do extra work to make a real iOS/iPad/Mac app anyway. The goal should be to ship first and iterate. Don’t worry about multi-platform and syncing support in the first version.

When the average app price is probably nothing, is it worth building all these features? I got into software development because it was fun. It’s always worth remembering that and reassessing what brings you joy and focusing on that.

My current app project using maps is a project that scratches a personal itch. It started out as a fun project to build something I want to use. Over time it’s become a bit of a chore. It’s time to bring the fun back and let the rest sort itself out.

Thanks for coming to my inner monolog indie app dev pep talk.

Patrick McConnell @pmcconnell
🐘 Reply on Mastodon