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

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:

• TestFlight → daily turnaround time
• App Store → 1-2 day turnaround time

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:

1. Submit the app as early as possible
2. Expect some back-and-forth with your designated point of contact at Apple
3. 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.

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!