How we made it to the app store: advice and lessons learned
Hello! I'm Adam, an iOS engineer at Threads.
I'm here to chat about our journey to the Apple App Store—from how we started on TestFlight all the way to gaining approval, this post will dive into how we approached the process, what we looked for, and some of the key takeaways for any team looking to do the same.
Starting with TestFlight
TestFlight, like its name, is great for testing.
At Threads, we use TestFlight for rapid iterations, feature improvements, and bug fixes to our app. With user-driven development at the forefront of our ethos, it was important for us to remain malleable to user feedback while we worked with the beta community to fine tune the product and user experience.
These were a few of the key benefits we enjoyed while using TestFlight:
Immediate validation that we're heading in the right direction
The ability to release internally for a gut-check prior to releasing to the larger beta community
Close-knit feedback loops with customers
Quick turnaround for new versions landing on the daily
Understanding how to evolve
While these benefits of TestFlight were undeniably useful throughout various updates, we started to come to a tipping point for when it would make sense to switch over to the App Store.
There are a few benefits to the switch:
Customers are typically more trusting of apps on the App Store vs. TestFlight
Apps are more searchable and available via a method that is common
Your app name is committed and locked in
Given where we were in our development process, we knew it was time to come up with a plan to proceed with our App Store submission. For teams in a similar boat, here are some pieces of advice on how to effectively communicate:
1. Write a proposal
Share a general proposal for why you want to make the change, and back it up with any customer research or feedback you've received.
For example, we have a mobile-proposals channel in Threads where all key stakeholders—PMs, eng, marketing—can review content as needed and get the necessary context they need to discuss and make decisions.
2. SET THE SCOPE
Understanding the scope of any project is important, and this is no different. That being said, when your team is used to rapidly iterating and pushing changes viaTestFlight, it's important to remind them how said changes may affect the launch date.
A key thing to communicate is turnaround time for addressing customer bugs / feedback:
TestFlight → daily turnaround time
App Store → 1-2 day turnaround time
With this expectation set, you're able to confidently determine a burndown list of what you'd like the initial App Store version to look like, providing your team with a finite list of updates and fixes that need to get done.
3. DETERMINE A TIMELINE
With your proposal and expectations in place, it's now time to determine a timeframe.
My key piece of advice? Submit early & submit often
The main mistake I've seen developers make is that they have a date in mind, submit the app for approval the day before, and are surprised when they get rejected for X reason. This is a common occurrence and one that should be expected!
In order to avoid this:
Submit the app as early as possible
Expect some back-and-forth with your designated point of contact at Apple
Ensure manual release is enabled (this will avoid your app automatically releasing to the store as soon as it's approved)
This keeps things on track while also ensuring that you're not the one to tell the marketing team their campaign needs to get pushed back.
With your proposal, expectations, and timeframe in place, you're near-ready to move forward in the process. Be sure to finalize any additional testing that needs to take place, determine language and assets needed for the submission, and be prepared for some potential back-and-forth with your designated point of contact should the app get rejected (harsh term but to be expected!).
If all goes well, you have an app that's ready for the App Store!