Blog
All posts
Adam Cooper
Edited on 1/10
Created on January 9 at 11:37 pm
Edited on January 10 at 5:35 pm
·
threads-blog
threads-blog
How we made it to the app store: advice and lessons learned
Hello! 
I'm Adam, an iOS engineer at Threads.
:wave
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:
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:
Setting expectations
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:
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:
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. 

:zany_face
Moving forward
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! 

:partying_face
After going through these steps ourselves, we're excited to once again share that .Threads is available on the Apple App Store for all users who've been granted early access.
We're looking forward to learning, growing, and empowering you to communicate even more effectively with your team! And if you aren't yet on Threads, sign up for early access today at .threads.com. 

:cat-wave
©2022 Threads, Inc.