Startup

Full story: the six-part startup deep dive.

What it used to be

The old splash awaited five network calls in a chain — /v2/settings, a DNS probe, /user/profiles, the home feed, continue-watching — each waiting on the one before, each on a brand-new TCP connection, with no connectTimeout and nothing cached anywhere. On a dead network that was the OS socket timeout, five times over. The app could sit on the looping splash GIF apparently forever.

What it is now

Cache-first: a returning user’s session, settings, nav items and home feed are restored from disk, the app routes straight to home, and the network refresh runs behind the user, swapping fresh content in when it lands. Only a genuine first install waits on the network — and that wait is parallel and capped.

Key pieces:

Piece	Where
The shared Dio client + timeouts	lib/core/network/api_client.dart
The disk cache and the cache-first repository pattern	see deep dive 3
The three bootstrap phases and what each may block	deep dive 4
The splash as a router decision, not a loader	same
The profile gate — asked once per launch, never again	same

Rules when touching startup

• Don’t add sequential network waits before the first frame; anything that can start behind runApp should.
• The splash route is decided from restored state — don’t turn it back into a loading screen.
• Measure before and after: Before and after documents how.