Publishing an app is a relationship with two companies

Shipping an app is mostly an administrative act with a software component attached. An app reaches users through two stores: two agreements, two accounts, two review processes, and the developer controls none. The build is the part you can plan; the accounts and signatures decide whether the app is still yours, and still installable, in three years.

Whose name should the developer accounts be in?

The company's, from the first day, before the first build — never "temporarily". Each store account is a legal agreement with a payment instrument, a recovery path and a name on the listing.

If the account sits in the developer's personal name, the listing, the install base and the app's identity belong to that account, not to you. Moving an app between accounts is a request the store processes, and it can be refused or take weeks; while it is pending, you cannot ship a fix. If the relationship ends badly, the person holding the account is holding your app.

The same rule covers what the app depends on: the domain its links use, the mailbox that recovers the account, the analytics and the signing key. The studio should hold a role inside your account, not the account, removable on the day the work ends. Ask before signing: if we stop tomorrow, what do you take with you? The right answer is the code, and nothing else.

What can a review reject in an app that works?

A review is not a test of whether the app runs. It checks the build against a rulebook the store writes and revises, and that rulebook covers more than the binary: what the listing claims, what the app declares about the data it handles, what happens when someone asks for their account to be removed, and whether a requested permission serves a purpose.

So a build that passes every internal test can be turned back over a screenshot, a sentence in the description, a declaration that does not match behaviour, or a feature the reviewer could not reach behind a login nobody supplied. Reviewers work in a queue you do not control; a fix for a wrong price on Monday may not reach users on Monday.

The rules are the store's. They change, and they are published on the store's own pages. Read them for your category before a launch date is promised, and again before each release. Do not take a policy's wording from an article, this one included, or from a forum post written last year.

Which version must you keep for phones that cannot update?

The long tail decides it. Phones that stopped receiving system updates years ago are still in daily use, and their owners never appear in your analytics: the app will not install for them. Two things follow, and both belong in writing.

A floor — the oldest system version you support. That is a business decision: raising it drops people who were customers, silently, and no chart records them.

An artefact — the last build that runs on that floor, with the server still answering it. The server matters more than the binary: if an old install calls an endpoint you removed, the app breaks for exactly the users least able to update. Version the interface, and keep the old response shape until the floor moves.

What expires without anyone touching it?

Signing certificates, push credentials, tokens for the services the app calls, and the domain its links point at: each carries a validity period. An expired certificate produces no warning screen; it produces a build nobody can install, usually the evening you needed to publish it.

What it is	Who should hold it	If it lapses or is lost
Store account	The company	The listing cannot be updated
Signing key	The company	No build can be published
Push credentials	The company	Notifications stop silently
Link domain	The company	Links open the site, not the app

The other expiring asset is a person. One laptop, one password, one employee is a single point of failure, discovered during an incident rather than before it.

How often does an app need to be updated?

Both stores set a minimum platform version they accept, and they move it over time; the current numbers and dates are on their pages, not here. An app built against a version that has moved can eventually no longer be submitted, so that date belongs on your calendar, not in a release week.

Above that minimum, the cadence is yours. One release a quarter keeps the pipeline exercised. The first release after eighteen months of silence is not a patch but a project: the toolchain has moved, the certificate may have expired, and whoever set it up has to relearn it.

In what order do you set this up?

1. Register both accounts in the company's legal name, with a company payment method and a company mailbox for recovery, before any code leaves a laptop.
2. Write one page listing every account, key and credential, who owns it, and where recovery codes are kept. Two people should be able to act on it alone.
3. Decide the oldest phone you support, in writing: it fixes the floor for code and server.
4. Move the signing key off the developer's machine into a place the company controls, with a documented password and a second holder.
5. Read the store's current rules for your category, then write the listing, screenshots and declarations from what the app actually does.
6. Ship one small release through the whole path — build, submit, review, publish — before you need a fix, and put a quarterly check of the floor and certificate in the calendar.

Where this goes wrong

• The account stays in the developer's name "for now". Two years later it is still there and the company has no lever.
• A dispute freezes the listing. The transfer is pending, the fix is ready, nobody can publish it.
• One laptop holds the only signing key. The laptop is replaced, and the key goes with it.
• Declarations describe the app you planned, not the app you shipped. It surfaces during a release that had a date.
• The floor is raised without announcement. Users on older phones see a compatibility message and leave, and no chart records them.

What this does not cover

This is not legal advice on a developer agreement, nor on the tax treatment of revenue a store collects. It quotes no fees: they differ by programme, region and revenue, the store publishes them, and a figure copied into an article is wrong before the article is old. It does not decide whether an app is the right format. The policies are the store's; read them at the source, for your category, before anyone promises a date.

We build the app and put the accounts, the keys and the release path in the company's name, then hand them over with the code.