Earlier this year, Paul Hudson asked me to answer a few questions about app marketing for a book he was writing called Everything But the Code.

The book is finished now, and it’s full of great advice from Paul and a long list of indie developers whose apps are some of MacStories’ favorites. Paul covers the entire process of making apps, from validating an idea to selling your app and beyond. The only thing he doesn’t cover, as the book’s title makes clear, is building apps, which is the subject of other books and courses he’s created.

Paul was kind enough to ask me to share some insights on marketing apps to the press. You’ll find my contributions in the Prelaunch and Publicity and Aftermath and Evolution chapters, and now that the book is final, I thought I’d share extended versions of my responses with readers. Although the focus is on apps, I expect there are a few lessons here for anyone pitching their creative work to the world. So, here you go.

Paul Hudson: What common mistakes do developers make when pitching their app to the press?

Me: Most developers do a great job thinking through what they’re pitching but don’t spend enough time thinking about who they’re pitching to. I’d love to be able to tell developers do these five things, and you’ll have a pitch you can send to anyone, but it doesn’t work that way. Developers need to think about things like who at a publication typically covers certain types of apps.

For example, if you know a publication has a musician on staff who has covered music apps before, that person should be at the top of your list if you’ve built a guitar tab app. However, that doesn’t mean you shouldn’t contact anyone else at the publication. People get busy, so don’t limit yourself. However, focus your efforts on the people who are most likely to be receptive to your app.

It also pays to make things easy for the person you’re pitching to. Keep your pitch short and to the point, link to a press kit, beta, and other materials, and follow up closer to launch.

A few other pitch pointers:

• Don’t wait to send your pitches until the last minute. Personally, I prefer getting pitches at least a couple of weeks in advance of a launch, so I can make the time for testing and writing about them.
• Don’t send pitches during WWDC, on Apple event days, or major holidays. Your pitch is much more likely to get lost in the shuffle on those days.
• You don’t need to ask if it’s okay to send a TestFlight link. If the person you’re pitching to isn’t interested, they won’t use it.
• It’s okay to copy multiple people at a publication if you’re unsure who to contact.
• Try to understand where a writer likes to be contacted. Email is probably the safest bet, but social media DMs might be better for some people.
• It’s okay to send follow-up reminders about your app launch. I personally appreciate them.
• Don’t expect app feedback from most press contacts. I let developers know when I find the kind of bug I’d mention in a review, but unfortunately, I usually don’t have time for much more than that.
• Don’t take it personally if you don’t get a response to a pitch. Remember, the people you contact are getting a lot of pitches.
• Don’t close down your TestFlight beta immediately after you launch your app. If a publication can’t get a story out to coincide with your launch, closing down your beta immediately so it can no longer be downloaded makes it less likely they’ll cover it post-launch.
• Don’t forget to include the name of your app in your pitch – yes, that happens.

Paul: What makes you personally excited to write about an app? What kind of thing catches your attention?

Me: Creativity and novelty are what get me excited about an app. Even after so many years of the App Store’s existence, I’m still surprised by what developers create. Sometimes the novelty is expressed through design. Other times, it’s a new approach to an old problem or the application of a new API in a novel way that gets me excited.

I’m also always excited to see someone new pop up on our app radar at MacStories. We have long-time favorite apps, but what keeps what we do interesting and fun is seeing newcomers enter the indie developer ranks and getting to know them through their work.

Paul: Have you ever seen an app where the idea was excellent, but the execution or onboarding let it down? What can developers learn from that?

Me: Apps that have a great core idea but are ultimately a letdown often seem to be rushed onto the App Store either out of excitement about the idea or concern that someone else will build something similar first. There’s a lot to be said for shipping a tightly focused 1.0 of an app to test whether there’s an audience for it. But that sort of classic minimum viable product thinking can also be a trap. It doesn’t mean it’s okay to ship buggy apps or something so basic that it doesn’t distinguish the app from others on the App Store. It’s a tricky balance, but from trying thousands of apps over the years, I can tell almost immediately what level of care and attention has gone into an app.

Paul: What kind of press kit (if any!) makes your job easier and raises the odds of coverage?

Me: I think press kits coupled with a focused email pitch are a great combination. Writers get a lot of app pitches, so it helps to keep the email short and tailored to the recipient. If you’re corresponding with someone who knows you, you don’t need to provide as much context, but if it’s your first contact, it helps to provide a little background about yourself for context.

However, the focus of the email message should always be on your app and what makes it unique. The email should also serve as a pre-launch roadmap with links to TestFlight and your website, and if you’re getting close to launch, information about your release timeline.

Then, create a separate press kit that you can link in the email. That way, whoever you’re pitching has access to more information if they want it. Plus, a separate press kit means not having to attach a bunch of screenshots and other files to the email, which turns your pitch into a file management exercise for the recipient. Instead, include all those assets alongside a detailed breakdown of your app on a simple webpage that can serve as your press kit.

There’s an open-source press kit template that the indie videogame industry has used for years called presskit(), which strikes a nice balance between being comprehensive and readable. It’s the sort of thing that you can set up as a static page linked to your app’s website and host just about anywhere or even build and publish using something like Notion.

Paul: From where you sit, what are indie developers not doing enough of when trying to build an audience?

Me: A lot of indie developers do a good job of building an audience within the indie developer community and among people who follow Apple closely. What deserves more attention is thinking about where the audience for your app is online. The more specialized and focused an app is, the more important this is.

For example, if your app tracks car maintenance, it’s important to find the subreddit and other online spaces where people with that interest gather. Also, if a community doesn’t exist, consider building one yourself. Being part of those communities builds a familiarity and trust that will ultimately help the discovery of your app.

Advertising can also be a good way to build an audience, but it’s often not a financially viable one for someone just starting out as an app developer. Instead, budget a certain number of apps or subscriptions to give away to people who you think might help spread the word about your app. This sort of ‘influencer’ marketing can broaden your reach within communities and has the benefit of not requiring any upfront out-of-pocket costs.

---

Reading back through my responses has me excited for 2026. I can’t wait to see what developers send our way.

Happy New Year!