5 Things I Do Before Publishing an App

Added: 2026-05-18

[00:00:00]They warned of my app launch. Apple approved it. They even boosted it. But then, I got an email nobody wants to get. A bug in production was blocking every paying customer from unlocking the application. I shipped a fix immediately, but Apple review took 2 days. By the time the update went live, the boost was gone. Zero downloads, and that mistake cost me thousands. So, here are the five things I now do before launching an application so it never happens again.

[00:00:26]Number one, research a unique and searchable name.

[00:00:30]When I first launched my AI Tattoo application, I was so excited about getting it into the App Store that when Apple asked me for my app name, I came up with it on the spot. AI Tattoo Generator. I thought, "I'm a genius.

[00:00:42]Everyone is searching for that. I'll definitely get downloads for free."

[00:00:46]Wrong. After the app was approved, it was almost impossible to find it. I had to scroll past 100 competitor apps with basically the same name. The name made my application invisible. Your app name can be the difference between success and failure. When you tell people, "Go search my application," they should be able to find it as the first result. So, I renamed to Inkigo. Coming up with the name took about a day. My rules are now simple. Make it short, ideally three to 10 letters. Make it easy to remember, pronounce, and type. Google it first to make sure that nobody else is using it, and check if a domain is available.

[00:01:24]Also, keep the searchable keywords in the subtitle of your application. So, the final name became Inkigo AI Tattoo Try On. That gives me the best of both worlds. People searching for an AI Tattoo Generator can still find the application, but most importantly, when I tell someone to download it, they can search for Inkigo, and it's going to be the first result. Number two, set up OTA updates. OTA stands for over-the-air updates. Because I built my applications with React Native, I can ship certain bug fixes directly to users without waiting for the apps to review. My app checks for new updates. It downloads them in the background and applies them next time the user opens the application. That is a huge advantage.

[00:02:07]After the launch incident I mentioned at the beginning, I don't ship any app unless it supports over-the-air updates.

[00:02:13]Waiting 2 days for review while your application is broken in production is painful, but waiting 2 days while Apple is actively boosting your application, it's even worse. I have a video on the channel explaining how to use OTA updates. I'll leave the link in the description in case you're curious. It's also worth mentioning that you can also request an expedited review from Apple.

[00:02:34]I honestly didn't know about that at the time and I've been requesting a couple of expedited reviews since then and in my experience, they were usually approved in around 5 minutes, which is surprising, but I still don't want my entire launch depending on that. Number three, track analytics and onboarding.

[00:02:51]Analytics are crucial when you are building an application. They show you how people are actually using your application. You can't just launch an app and wait for someone to email [music] you saying, "Hey, you should add this feature." Most people won't do that. You need to track what users are actually doing inside your application both with standard analytics and with [music] custom events. So, at minimum, I want to know how many people start onboarding, how many people finish onboarding, where users drop off, how many people sign up, how many people hit the paywall, how many people purchase, and whether paying users can actually access what they pay for. Analytics give you conversion data in a concrete way to improve [music] the application instead of guessing. So, I personally use Vexor for analytics. They are not sponsoring this video, by the way. It works well for me, but there are plenty of other options like Posthog or Firebase Analytics. The tool matters less than the habit. So, track the crucial flow from the first session to the first successful paid action. Number four, build a landing page. A landing page is crucial because the app store page is limited. A landing page gives you more room to show people why your application exists and why they should care. It gives visitors one clear action, which is download the application, but most importantly, it builds trust. People are more likely to download and pay when they can see the screenshots, when they can see a video demo, testimonials, pricing, frequently asked [music] questions, privacy information, who made the application, and a clear explanation of what problem the app solves. A landing page is also useful before the app is even ready. [music] You can start collecting email, validate demand, and start building an audience even before spending months building the product.

[00:04:37]Honestly, I always recommend you start validating your app idea before you even finish building it. That's why I use Lovable, today's sponsor, to build beautiful landing pages for my applications before they launch. It builds momentum, it builds urgency, and once the app is ready, you can just email everyone on the list and tell them where to download. I'm using the new Lovable desktop application. I'm rebuilding the Inkigo landing page.

[00:05:02]Here's a section, the main pitch, and an email wait list form. Lovable builds the whole thing, front end, back end, including the database for the sign-ups.

[00:05:10]No code, no setup. And here's the final page. Real working product, deployed, ready to collect emails. So, if you have an idea sitting on your notes, Lovable is built for non-technical builders and founders who want to move faster from [music] day one. Link is in the description, go check it out. Number five, create a strong logo and brand.

[00:05:30]First impressions matter. Don't let anyone tell you otherwise.

[00:05:34]>> [music] >> People are used to using the polished applications from huge companies and huge budgets. So, your application doesn't need to look like it came from Apple, but it does need to feel real.

[00:05:45]That is why I always launch with a clean logo, [music] a a consistent branding, a good icon makes the application feel more trustworthy before the user even opens it. Here are the rules I use when designing logos and branding for my applications. Number one, pick a small set of colors and use them across the icon, landing page, and the application itself. Number two, keep the icon minimal and clean [music] because it will be displayed very small. So, don't add too much detail. Number three, if your icon feels similar to other high-quality applications, that's okay because you want people to actually associate your application with quality.

[00:06:26]So, if you don't have a designer or you are new to branding, study successful apps in your niche and use them as inspiration. Not as an exact copy, just inspiration. Number four, keep everything consistent and simple. And finally, before going live, I always walk through the entire user journey with a fresh user mindset. Search for the app on Google, click on the landing page, evaluate the offer, click download, watch the video demo on the store, look at the screenshots, download application, complete the onboarding, pay, and confirm the paid feature actually works. That flow reveals a lot.

[00:07:00]So, if something feels confusing, low quality, or broken, users will feel it, too. And here's a bonus, add a contact support button. This is one almost didn't make it to the list because it seems obvious, but it has saved me multiple times. So, no matter how much you test, once your application is in production, you don't really know what's going to happen. You know, I still remember my first paying user from Inkigo. I got the push notification that someone just paid me $20 to use my application. It was a great moment, but about 5 minutes later, I got an email from the same customer saying that they couldn't generate tattoos. That is a tough spot to be. You get a ticket with almost no context, you don't know what's wrong yet, but you know you need to fix it as soon as possible. So, in that case, the quick fix was to update the database so the user could access the feature they were paying for, but the long-term fix was actually shipping a proper update. But, the only reason I could save the situation was because the user was able to contact me. So, without a support button, I probably would have lost the customer, issued a refund, and gotten a bad [music] review. So, a contact button won't fix your bugs, but it gives users a way to tell you when something is wrong before they leave a one-star review.

[00:08:13]Launching an app is not just about submitting it to the App Store and hope for the best. You need to make sure people can actually find it, trust it, use it, pay for it, and contact you when something goes wrong. Before I wrap, quick thanks to Lovable for sponsoring this video. If you want to hit start on a lot of these, payments, branding, and store assets are already wired up in Platinum. It's a launch-ready React Native template I built so you can ship a real application in a weekend instead of spending months on the [music] boring infra. One command to start, link in the description. And if you want to keep learning about shipping applications, this video right here is a great next watch. I'll see you there.