Ordo is a social iOS app where people rank a daily topic and compare their choices. I built it with SwiftUI and Supabase and took it into external testing through TestFlight.
The main interaction is easy to explain: arrange a short list, submit it, and see how your order compares with other people’s. Building the app meant working out what happens around that interaction, including the days someone skips it.
Make room for missing days
An archive built only from completed rankings leaves out useful information. Someone who missed a topic should be able to tell what appeared that day and whether they can still participate.
That changes both the query and the interface. A date with a topic and no submission has a meaning of its own. The app needs to represent it deliberately, alongside completed days and dates with no published content.
I like working through those cases early because they affect the shape of the product. It is harder to add them cleanly once every screen assumes a completed ranking exists.
Let content change on its own schedule
A daily topic may need a correction before the next app release. Hosted content lets the app pick up that correction while the binary keeps responsibility for displaying and validating a ranking.
That split needs clear rules. Topics need stable identities and publication states. The resolver needs to consider what has already appeared. A local content edit also needs verification against the source the app actually reads.
It is a small editorial system inside a small social product. Keeping it understandable matters when I need to return to it after spending time on another part of the app.
Work through the account lifecycle
Trying the app, joining a group, restoring access, and deleting an account each need a complete path. Account linking is particularly important when an anonymous person later signs in with Apple. Their activity should remain attached to the right identity.
Privacy choices belong in those flows. They affect what gets stored, who can read it, and what needs to be removed when an account is deleted. I prefer to make those decisions while the data model is still easy to change.
Test the build someone will install
I use deterministic tests for ranking and state transitions, then review the screens on different device sizes. A passing state test can coexist with a cramped sheet or a long label that obscures an action.
TestFlight adds another set of checks: signing, entitlements, build numbers, privacy information, and a review path that someone else can follow. An uploaded build still needs to finish processing and reach the intended testers.
Working through that release path has made me more attentive to the surrounding details in other projects. A feature is ready when someone can reach it, understand it, and recover if part of the process fails.