Mobile Plan

Recommendation

Validate the daily mobile habit before paying the store-distribution tax.

Build a mobile product now; defer a store app.

Make the Lab’s reading and comparison loop excellent as an installable mobile web app. Move to a native shell only after people repeatedly choose it over the Bluesky client.

The bottleneck is retention, then review.

Enrollment is procedural. The harder test is whether Hyperblues offers durable mobile utility beyond a repackaged website or another Bluesky reader.

Delivery sequence

Each phase buys evidence needed by the next; none requires rebuilding the feed algorithms.

Phase	Ship	Learn	Promotion gate	Avoid
1 · Mobile web	Responsive reader, swipe between feeds, feedback, install prompt, share targets.	Repeat opens, reading depth, feed switches, explicit preference.	A small cohort returns weekly without prompting.	Desktop controls squeezed onto a phone.
2 · Private native beta	One cross-platform client; secure OAuth, native navigation, haptics, cached session, deep links.	Does app-like interaction improve retention?	Native-specific value beats the mobile web baseline.	A thin WebView; Apple explicitly rejects repackaged sites.
3 · Store readiness	Privacy policy, moderation/reporting, account deletion, support, reviewer demo, screenshots, crash telemetry.	Operational and policy gaps.	Complete review packet and stable on-device release candidate.	Submitting before login and review access are reproducible.
4 · Public launch	TestFlight then App Store; Play internal then required closed test and production application.	Acquisition, activation, retention, store rejection causes.	Retention justifies ongoing native release work.	Simultaneous platform scope before one path works.

One system, three clients

The mobile app is another API consumer—not another feed implementation.

Hyperblues clients

Web, installable web app, then native iOS/Android UI. Own navigation, reading, comparison, and feedback.

Hyperblues API

Own experiments, feed recipes, evidence, user preferences, deadlines, and terminal errors.

AT Protocol services

OAuth identity, Bluesky AppView data, and independently hosted feed generators.

Store constraints

Known gates to schedule early, not reasons to start with store submission.

Apple

Enrollment: $99/year; identity or organization verification.
Beta: TestFlight is included with membership.
Review risk: Guideline 4.2 requires useful, app-like functionality beyond a repackaged website.
Proof packet: Working backend, reviewer account or approved demo mode, specific review notes, privacy/support URLs.

Google Play

Enrollment: Developer verification and registration.
Beta: Internal testing first.
Production gate: New personal accounts require 12 opted-in closed testers for 14 continuous days, then an application for production access.
Planning implication: Recruit the Android cohort before the release candidate is finished.

Current sources: Apple enrollment · Apple review guideline 4.2 · Google Play testing requirements

First implementation slice

A bounded release that makes current work useful on phones and produces a go/no-go signal.

Reading loop

One-handed feed switching
Full-height post cards
Fast preference feedback
Open original in Bluesky

Platform foundation

AT Protocol OAuth
Shared API contracts
Installable manifest and icons
Offline shell, explicit data failures

Decision instrumentation

First useful feed viewed
Return within seven days
Feed chosen over control
Feedback supplied per session