App maintenance for the iOS or Android app you already ship

Work on an app that already ships

The usual reasons are concrete. A crash after an operating-system update. A screen that fails on a phone you already support. A purchase that never finishes. A signing key that left with the last developer. We do that work on code we wrote and on code we are seeing for the first time.

We first match the source to the store build and investigate the failure. Build-tool, dependency or signing repairs may be sufficient. Missing source or ownership needs its own recovery investigation before a rebuild is proposed.

Requests we can price

To investigate an app crash, send the device, OS version, steps and available crash logs. For an update, name the workflows that must remain usable, including launch, sign-in and purchases where relevant.

OS update work reviews build tools, dependencies and affected platform APIs, then rechecks launch, sign-in, the main task and purchases where relevant. If a dependency changes the minimum supported OS, we explain the options and device impact before changing that target. Store review time is separate from producing and testing the build.

• A blank launch, or a crash that began on a newer system version.
• A spinning purchase, a restore that does nothing, or a subscription left locked.
• An archive broken by Xcode, Swift, Gradle, or a dependency update.
• A stale Home Screen widget, or a Safari extension that no longer runs.
• One named edit: a setting, an API field, another language, or an offline screen.
• A release stopped because the signing key is on a laptop you cannot open.

From the first email to handoff

Say whether it is iOS, Android, or both, and what changed. A review note, a season, or a demo is a date. A target date helps us scope the release work. Do not put passwords in the email.

Keep developer and store accounts under your control and invite us with suitable permissions. We identify missing source, signing or account access before estimating release work, then document the next build and submission steps.

A crash we can reproduce is hourly. A named list, such as the new system version plus two screens, is fixed-price. If nobody can describe a release, paid discovery comes first, and you keep the notes if you stop. You install TestFlight, or an internal Android track, before review. Handoff is the branch, what changed, and how to archive the next build. We take a small number of projects at a time, so you write to the people doing the work.

The stack already in the repository

We continue whatever the repo already is, if it is a stack we work in: Swift and SwiftUI, Kotlin and Jetpack Compose, or React Native or Flutter when you already share one codebase. iPad, Mac, and Apple TV stay included when the project already targets them. UIKit stays in files that are already UIKit.

Purchase maintenance covers the configured products, restore, failed payment and expired access. Other providers are scoped against the app’s actual purchase model. We also check the affected local data and accessibility behaviour. The review identifies required repairs and remaining dependencies; it does not certify legal compliance.

Who should email, and with what

Email if you own an app that is already out, if you can show the broken step, or if you are an agency placing the upkeep as a sub-project, white-label or credited.

A retainer covers the maintenance tasks and response arrangements written into it. Larger feature changes or a rebuild receive a separate scope. Include the current release process and the access you control when requesting a developer handover.

• What the app does, and whether it is iOS, Android, or both.
• Steps, device, OS version, when it last worked, plus a crash log if you have one.
• Who can invite us to Git, the Apple Developer team, and the Play Console.
• Where the signing keys are, and whether someone else still commits.

Apps we already keep current

We maintain nine App Store apps of our own. Rain includes on-device ad and tracker blocking, Moonflower is a Safari extension on iPhone, iPad and Mac, and ICD Atlas stores reference data offline. These products give us direct experience with OS updates, extensions, StoreKit and release preparation. Your maintenance plan still starts with the state of your repository and the devices it supports.

This website is ours too. Your quote starts from your repository.