I build my ideas #9 - 08/09/20

Building Airport: The TestFlight App Store from idea to app

Jordan Singer

Aug 9, 2020

Airport: The TestFlight App Store

What is it?

Airport is an app store for TestFlight apps. ✈️ It’s the missing directory to browse apps for testing on TestFlight.

Why does it exist?

It all kinda started with a Tweet:

Jordan Singer @jsngr

who’s interested in an App Store-esque directory for all of these TestFlight apps?

I’ve been fascinated by the recent uptick in TestFlight apps, waitlists, exclusivity, and experimentation. People are building new things and teasing them with TestFlight’s. They’ll post a screenshot of their home screen with the yellow dot 🟡 (signifying it’s a TestFlight app) and people go crazy.

There are a few ways to distribute a brand new TestFlight today: you’ve got the option to share a public link to download your beta, or make your beta invite-only via email. But there’s no way to casually browse public (or private) TestFlight’s in one place.

I’ve got 16 apps on TestFlight. That’s a lot to manage! They’re mostly lil apps, and my attempt at distributing them has been via sharing the link to lil.software, basically a directory for lil apps. It needs to exist in order to link out to download and install the lil app betas in one place. With something like Airport, there’s now a way to discover TestFlight apps for testing in beta without the need to figure out distribution entirely on your own.

The perpetual TestFlight

I think we’re seeing this trend where some apps might just end up being forever TestFlight apps. The review process from Apple is more laid back for TestFlight, and in some cases you can achieve exactly what you want without the need to go to the App Store. TestFlight apps have the exact same capabilities as App Store apps, but with a smaller reach, the intent for “testing,” and no way to browse them. Airport hopes to change that.

All lil apps except for three (lil weather, lil draw, and lil calculator) are what I would call “forever TestFlight” apps. These are the ones that didn’t make it through to App Store review, or frankly didn’t feel need to get them on the App Store. And that’s perfectly fine with me. Others can still use them via TestFlight.

Naming is hard

A text exchange with Eli

Jordan Singer @jsngr

flightstore.app registered ✅

I first called it “Flight Store” but decided to get a little more creative thanks to everyone who helped brainstorm the name.

Some ideas:

Earhart (Amelia Earhart)
Flight School
Wingspan
Flight Club
Air Support
Flite
Runway
Hangar
Propeller

I registered five domains in the process as I was thinking through names:

flightstore.app
earhart.app
airstore.app
airborne.app
airport.community

“Airborne” was a close second, but Airport ultimately felt the most fitting:

a place from which aircraft operate that usually has paved runways and maintenance facilities and often serves as a terminal

How to use it

You can claim your boarding pass for Airport here → (inviting testers in waves)

You can submit your TestFlight app to Airport here→ (actively publishing new apps)

You can join the Slack community of developers and testers here →

Follow Airport @AppAirport

How it’s made

This was a fun one to put together.

Airtable

I absolutely adore Airtable. I’ve used it to build entire websites that run on it as a CMS. It’s a database as a spreadsheet and it’s really powerful. When I’m working on something that needs a database, I give deep consideration to Airtable before deciding whether or not it’s right to build a custom API. In this case, I chose Airtable for a few key reasons:

A lightweight way to get a “backend” up and running quickly
A really easy way to visually manage your data
A way for others to submit their own data via a form
An API built automatically and tailored to your tables

Airport takes app submissions via Airtable form. Once an app is submitted, I take a look to make sure we’ve got everything we need, and mark the row in the table as published. Boom, the app is now on Airport.

A custom API

I built a custom API as an intermediary between the Airtable API and the Airport app. This was for a number of reasons:

More granular control over data sanitization
Slight workarounds for the Airtable API rate-limit of 5 calls per second
The ability to easily swap out Airtable with a custom backend in the future for scale

SwiftUI

What else would I have built it with? 😉

The app simply talks to the custom API to render all of the views. It targets iOS 14 and makes use of some of the cool new API’s that SwiftUI introduced like .redacted(reason: .placeholder) for loading states, the PageTabViewStyle tab view for the featured app carousels, and Link for linking out to TestFlight URL’s.

Plans

Airport is for the app developer community. It’s really special that I’ve been able to become a part of it, and I wanted to give back in the best way I knew how: building stuff.

I want to make sure that Airport scales responsibly and doesn’t cater towards my own TestFlight apps. Some ideas include making the Airtable publicly accessible with viewing rights so you can see exactly how it’s organized, and eventually open-sourcing the Airplane app code itself. More on this soon.

My promise: to always keep Airport open and free.

Apple

Back to the “forever TestFlight” app point, I hope that as Airport plans to exist only on TestFlight, it won’t run into the same review process or scrutiny that the App Store faces. We’ll see what happens, but I haven’t had too much luck in the past related to this topic.

Drake

A special shoutout to Drake for being the soundtrack to building Airport. For those that know me, you know I’m the world’s biggest Drake fan. I’ve listened to ALL I NEED 184 times on repeat while building Airport. 🙈