Monday, March 7, 2022

Solo iOS Developer Tips

Zach Shakked (via Peter Steinberger):

If you ever plan on selling your app, things will be a lot more complicated if you have an iCloud entitlement because then you can’t transfer an app. Try to avoid using iCloud or CloudKit

don’t make your app a paid up front app. If you can convince people to pay up front, you can probably convince them to pay for a subscription. Freemium will almost always net you more $ and paid up front is almost never worth it. Add lifetime instead

analytics are your eyes and ears, add firebase events at a minimum (free), and if you’re serious use Mixpanel or Amplitude. Otherwise, you’re flying blind and have no idea how people are using your app

do keyword research using Appfigures or another ASO tool to strategically pick app keywords/titles/subtitles that match what users are already searching for on the app store

[…]

don’t over engineer - use shitty code design patterns and be lazy. Get the app out ASAP, start collecting reviews & feedback, and iterate and improve. Better to sprint launch a crappily-coded version of your app in 2 weeks then spend 3 months building an app no one wants

optimize for learning speed - you want to be learning as much as possible about your market and users as fast as possible, so it’s better to update frequently in the beginning then spend months building the “perfect” version because perfection is elusive

NEVER offer iPad in the beginning - it makes your life hell. You can’t ever unsupport iPad, the market for iPad is much smaller than iOS, you always need extra screenshots, extra testing, and it just slows you down in the beginning which is exactly when you want speed

[…]

dont ever use apple search ads basic, watch a few videos and learn about advanced apple search ads, its not that hard, try bidding on competitor keywords (exact match) - this is where you can find cheap, high-intent installs

Previously:

9 Comments RSS · Twitter

Joshua Ochs

While as a solo developer you really need to focus your effort as much as possible where it counts (not supporting iPad, focusing your idea to critical features first then iterate), there's a lot here that's also going to bite you - it seems like an extremely user-hostile manifesto.

Technical debt from starting fast and sloppy never gets addressed. You start on a sloppy foundation and it will be with you forever. Likewise if you don't polish the edges then unless your idea is truly novel and groundbreaking, you're going to get lost in the crowd (or worse, copycatted). As a user why am I going to use a shoddy app full of analytics? Much less pay a subscription? Until an app has a strong track record of quality and updates I'm not even going to *consider* a subscription, no matter how cheap.

I'm not a professional developer; I have the luxury of not dealing with these trade-offs. But as a user I'd never want to use an app written or sold this way.

@Joshua You don’t actually want to write bad code, but it’s important not to over engineer. Small amounts of technical debt in the beginning can be good and can be paid off better once you have more information about what you actually want to build.

Tons of iOS apps have analytics these days, and most users don’t know about it and can’t do anything about it. As a user, I have mixed feels about this becoming the norm (is there a privacy concern vs. in theory making the app better).

Part of his advice is to start out free, to get exposure, and then add the subscription later. So that’s not necessarily at odds with your advice.

“analytics are your eyes and ears, add firebase events at a minimum (free), and if you’re serious use Mixpanel or Amplitude. Otherwise, you’re flying blind and have no idea how people are using your app”

Am I the only one who would rather be flying blind than spy on how my customers use my app?

Or I could just ask them - but the App Store makes it virtually impossible to have any kind of relationship with your customers. Yet another reason I am happy to be locked out of it.

"Technical debt from starting fast and sloppy never gets addressed. You start on a sloppy foundation and it will be with you forever."

If you're one developer, and you've written the terrible code, you're probably okay. This only truly turns into a problem if you have a team of developers, and the person who wrote the shitty code leaves, and now you can't fix it because nobody understands what the hell is going on, so now you have to rewrite.

For a single dev trying to get something out, you can put out literally 10x more stuff if you just don't care about proper architecture and unit tests and all of that stuff, and focus on banging out as much code as possible in as little time as possible.

Does that mean you should do it? I guess it depends.

I don't know anything about analytics in apps, but on the webb it's data rather than anecdotes that are interesting. E.g, "80% give up halfway through our onboarding" instead of "Peter N Lewis has username 'DocAwesome' and owns two cats".

The former is useful and will make the service better for the majority of users, the latter is mildly amusing at best.

I also suspect that most people collecting data don't do much with it. And then there's Goodhart's Law.

>If you're one developer, and you've written the terrible code, you're probably okay. This only truly turns into a problem if you have a team of developers, and the person who wrote the shitty code leaves, and now you can't fix it because nobody understands what the hell is going on, so now you have to rewrite.

Note that this is true even in a single-person team: that other developer looking at your code could be you, in twelve months, no longer remembering the original purpose of the code.

Christina Warren

I can't read the whole thing b/c the author blocked me on Twitter for making fun of him for claiming he was "canceled" over Wordle, but I'll give him credit, this is largely probably very good advice for a solo dev.

It's also -- and I say this with genuinely no-disrespect to this guy -- pretty sad advice because it makes it clear that if you want to do well in App Store, you need to focus not on building the best possible app/experience, but on optimizing for the conditions of the store and the market the store has created.

Now, I think this is a guy who has probably gone way to the extreme of these sorts of tactics (by his own metrics [https://www.zach.so/dashboard] he's spending $120k a month on ads to drive downloads/subs), but there are probably lessons to glean from this that don't require succumbing to the true bottom-of-the-barrel shit. But it's still sad that this is probably what it takes, to a certain degree, to make a profit in the App Store as an indie dev, especially if you are introducing a new product.

@Christina Yes, that’s a great point. A lot of us said at the beginning of the App Store that the way it was structured was going to disincentivize the kind of apps/experiences that we want to see, and unfortunately that continues to happen.

Leave a Comment