Sprout Works
Start a project
← notes

September 29, 2026 · 3 min read

Your app, your accounts: how a studio works on an app you own

Who owns the code, how access works, and how an update gets from our screen to your users' phones, without handing anyone the keys.

If you've never hired someone to work on an app, the logistics can feel murky. Do they need your password? Where does the code live? Who can publish an update? What happens when the work is done?

Here's how it works at Sprout Works. The short version: you own everything, and we work inside your accounts as a guest you can remove at any time.

Who owns what

  • The code lives in a repository you own, usually on GitHub. If you don't have one yet, we'll create it in your name, not ours.
  • The app lives in your Apple Developer account. That account is the seller on the App Store, and it stays yours. The app never moves.
  • Your services (a database, analytics, a payment provider) stay in your accounts too.

Once an invoice is paid, the work is yours. There's nothing to hand back, because it never lived anywhere else.

How access works

You never share a password. Each service has a way to invite a collaborator with limited access:

  • GitHub: you add us as a collaborator on the one repository we're working in. Every change arrives on its own branch, as a pull request you can read, comment on and approve.
  • App Store Connect: under Users and Access, you invite us with a limited role, restricted to your app. That's enough to upload builds, run TestFlight and submit updates for review. It doesn't touch your bank details, contracts or other apps.
  • Everything else: anything that needs a key or a password, like a server or a payment provider, is shared through a password manager (1Password or Bitwarden both work), never over email. We use a test environment wherever there is one.

How an update reaches your users

  1. We build it on a branch, and you can see every change.
  2. You try it on your own phone through TestFlight, Apple's beta app. Nothing reaches your users until you've used it yourself.
  3. We submit it to Apple. App Review usually takes a day or two.
  4. You choose when it goes live: as soon as it's approved, on a date you pick, or as a phased release that reaches your users gradually over a week.

Web apps are simpler: changes go to a preview link first, then live when you say so.

What we need at the start

For an App Evaluation, very little: a link to your app (or a TestFlight invite), a test login if it needs one, and your goals. No code access at all.

For building, we ask for the repository invite, the App Store Connect invite and access to anything the app talks to, and we walk you through each one. It takes about fifteen minutes.

If your developer has moved on

This is common, and fixable. The first step is making sure you actually hold everything: the code, the Apple Developer account, and the accounts for any services the app uses. An App Evaluation covers exactly that: what can be recovered, what shape it's in, and what it would take to move forward.

When the work is done

You remove our access (we'll remind you, and show you where), and you get notes on what changed and how the pieces fit together. If you'd like us to keep an eye on things, that's what Care is for. If not, everything you need is already in your hands.