Dodo Pizza · iOS

iOS Engineering

Beta builds, open source, tech radar and a live look at the dodobrands/dodo-mobile-ios codebase

Updated 2026-09-20

Roadmap

Backlog4
In Progress5
Done4
Loading…

Beta

Stable beta builds land in a public TestFlight every two weeks—the critical path is fully tested, we’re hunting the rare crashes. Turn on auto-update.

Open source

Tech radar

Our map of technologies—adopt, trial, assess, hold. Refreshed once a year.

Telegram

Codegen for analytics events

Today both iOS and Android describe events by hand. Problems: human error (easy to misname a field or send the wrong format) and plain fatigue from doing it manually.

We’ll describe events with an OpenAPI spec and generate request models via Swift OpenAPI Generator. We won’t use the rest of its networking—we have our own persistence and send in batches.

Move to a UDF architecture

Our current screen architecture no longer works for us. Main problems:

Leading candidate — The Composable Architecture:

Codegen for the network layer

Today all network requests are written by hand—human error and fatigue.

Our network layer is also dated: it survived several half-finished core migrations and the async/await migration (a third of requests are still on completion handlers).

We’ll describe every endpoint and model with an OpenAPI spec and generate the entire network layer via Swift OpenAPI Generator.

Move to String Catalogs

Localization lives in legacy .strings and .stringsdict files: verbose, easy to leave untranslated, plurals in a separate file, and no signal when a translation drifts from the source. String Catalogs — .xcstrings — fix that:

Migrate the Core layer from our DI to Swift Dependencies

Problems with our DI:

  1. Poor concurrency behavior—we even had incidents.
  2. Misuse of the approach: huge assemblies, dependency hell, and we register even non-dependencies under DI.

Moving to Swift Dependencies:

  1. Great concurrency support.
  2. Few registrations—only truly external dependencies.
  3. Works with parallel Swift Testing—mock per test.

First we move the core pieces: networking, analytics, notifications, feature service.

Remove leftover storyboards & xibs

We’ve described views in code for years, and since January 2024 almost everything is SwiftUI—but legacy remains: 50 storyboards and 35 xibs.

Why:

First we move everything from xibs to code without converting to SwiftUI—it’s faster. Steps: add snapshot tests → move views to code.

Migrate from UIKit to SwiftUI

Since January 2024 new screens are SwiftUI, but a large UIKit surface remains—view controllers, custom views, manual layout. We’re moving the rest to SwiftUI because it:

Migrate unit tests from XCTest to Swift Testing

Our unit suite is on XCTest—verbose, class-based, and awkward with async code. We’re moving to Swift Testing for:

Move to design-system components

UI is built from ad-hoc, screen-local components—the same button or cell reimplemented many times, drifting in style and behavior. We’re consolidating onto a shared design-system component library:

Move from our own repositories to Swift Sharing

Problems with our current repositories:

  1. Awkward change subscriptions.
  2. Misuse: storing [Item] in a SingleRepository instead of a CollectionRepository.
  3. Singleton repositories don’t fit parallelized Swift Testing.
  4. Simple but verbose repository boilerplate.
  5. It’s all code that could just not exist.

Moving to Swift Sharing:

  1. Built-in change subscriptions, including from SwiftUI.
  2. Can’t be misused.
  3. Built on @TaskLocal — plays nicely with parallel Swift Testing.
  4. Super-simple setup.
  5. Nothing to maintain.

Drop iOS 16 support

  1. Wait for the full iOS 26 release.
  2. Wait another 2–3 weeks until iOS 16 usage drops to ~2–3%.
  3. Drop iOS 16 support in an upcoming release.

Unified routing

Routing is a free-for-all—anyone can present any screen anytime. Constraints:

We’re funneling all routing through a single router. It already exists, but only ~20–25% of navigations go through it—we need 100%.

Migrate to Swift 6 & Complete Strict Concurrency

We see big value in compile-time checks for data races and using the UI layer from the right thread.

We don’t expect a big impact on crash-free rate, but we hope it saves us from dumb issues that cause sudden incidents.