Mobile App Developer Contract (2026): App Store Rework

A freelance mobile developer whose iOS app was rejected at App Store review, and whose client is demanding the rework at no extra cost because the contract said "delivery on TestFlight," has hit the gap that generic software contracts never address. A mobile app does not ship directly to users. It passes through Apple and Google, two reviewers the developer does not control, and "delivered" can mean three different things depending on which gate you measure from. When the contract does not say which one, every rejection becomes an argument about free work.

The base contract layer is in freelance contract essentials, and the general IP framework is in the freelancer IP ownership guide. The scope you lock should mirror the mobile app developer proposal, the platform fees flow into the mobile app developer invoice guide, and the same scope-lock pattern appears in the web developer contract.

Why delivery is the trap · The delivery boundary and rejection rework · Platform fee pass-through · App IP transfer: the full bundle · Transferring the app at the end

Why Delivery Is the Trap in App Contracts

A web project is "delivered" when it is live on the client's server. A mobile app has no such single moment, because two of the three milestones are controlled by Apple and Google. The three stages are: a TestFlight (or internal) build the client can install for review, a submission accepted into the App Store or Play Store, and a version live and downloadable by the public.

The trap is that even TestFlight involves Apple review. Per Apple's TestFlight page, to invite external testers you must have your "first build already approved by App Review for TestFlight," and "your builds are automatically sent for review once they're added to a group." So "delivery on TestFlight" is not a private handoff between developer and client; it still passes an Apple gate, and App Store approval is a separate, later gate with its own review. A contract that names "TestFlight" as the delivery milestone has quietly agreed to one review pass while leaving the second, harder one undefined. That undefined gap is where the unpaid rework lives.

The Delivery Boundary and Rejection Rework

The fix is a delivery-boundary clause that ties each payment milestone to a specific, named stage, and that splits rejection rework by cause.

Define the milestones explicitly:

• Build delivery: a TestFlight or internal build the client can install and review. This is developer-controlled and is the right gate for a build-acceptance milestone.
• Store submission: the app submitted and accepted into App Store or Play Store review. Acceptance into review is partly outside the developer's control.
• Store release: the app approved and live for download. This is gated entirely by Apple and Google.

Then split who pays for rework after a rejection. Apple rejects for both developer-caused and platform-caused reasons. Per Apple's App Review Guidelines, "we will reject incomplete app bundles and binaries that crash or exhibit obvious technical problems." A crash from the developer's own code is a defect, corrected under the bug warranty at no charge. A rejection driven by a guideline the client's requested feature triggers, or by a policy that changed after the scope was set, is a platform-caused event and is billed as a change order at the agreed rate.

This is the mobile version of standard scope control. The sibling pattern for web work is in the web developer contract, and the client-conversation side of asserting a change order is in how to handle scope creep. The distinctive line for mobile is that the third-party reviewer, not the client, is often the one forcing the change, and the contract should never treat a platform rejection as automatically the developer's unpaid problem.

Platform Fee Pass-Through

A mobile app runs on paid platform accounts, and those fees should pass through to the client rather than disappear into the developer's overhead, the same way a web developer passes through domain and hosting costs.

The fees are fixed and public:

• Apple Developer Program: per Apple, "the Apple Developer Program is 99 USD per membership year."
• Google Play Console: per Google, there is a "US$25 one-time registration fee."

Put both on the invoice as reimbursable lines, and disclose the store commission in writing so the client understands the post-launch economics. Per Google Play Console, the service fee is "15% for the first $1M (USD) revenue earned by the developer each year" and "30% for earnings in excess of $1M," with "99% [of developers] eligible for a fee of 15% or less." On the Apple side, per the App Store Small Business Program, developers who "made up to 1 million USD in proceeds in the prior calendar year" qualify for "a reduced commission rate of 15%," with the standard rate applying above that threshold.

Disclosing the commission is not the developer's fee, but stating it prevents a later dispute where the client believes the developer pocketed the store's cut. How the $99 and $25 become invoice line items is covered in the mobile app developer invoice guide, and rework rates should track the 2026 mobile app developer rate report.

App IP Transfer: The Full Bundle

A generic contract assigns "all code" and stops. A mobile app is a bundle of separable assets, and the transfer language has to do two things: use words that actually transfer ownership, and list everything in the bundle.

The words matter. Per Willcox Savage, the reliable construction is "the Developer agrees to assign, and hereby does assign," because "phrases like agrees to assign or will assign merely promise future action without completing the transfer now." The Federal Circuit has enforced that distinction: in "Advanced Video Technologies LLC v. HTC Corp.," the court held that "will assign to the Company invoked a promise to do something in the future and did not effect a present assignment," and in "Omni MedSci, Inc. v. Apple Inc.," a clause that IP "shall be the property of a party was an agreement to assign, and not a present assignment." Pair the present-grant language with a payment condition so the assignment vests on cleared final payment.

The bundle should be enumerated, because each asset is a separate handoff:

• Source code and build configuration, delivered via repository access.
• Signing certificates and provisioning profiles, without which the client cannot ship updates.
• App Store Connect and Play Console listing assets: screenshots, description, keywords, and metadata.
• The developer account, or written instructions and rights to transfer it.

Keep a pre-existing-IP carve-out for reusable components, SDKs, and framework code the developer brings to every project, so the assignment covers the app without sweeping up the developer's reusable toolkit. The general assignment-versus-license framework is in the freelancer IP ownership guide.

Transferring the App at the End

One platform rule can block the IP handoff if the contract ignores it. Per Apple's app transfer criteria, "the app must have at least one version that was released to the App Store" before it can be transferred between developer accounts. An app that never shipped cannot be transferred through Apple's standard process.

The cleaner arrangement for many engagements is for the client to own the developer account from the start, with the developer working under delegated access rather than holding the account. Whichever model the contract uses, state who holds the developer account, who holds the signing certificates, and how the account or app transfers at the end, so the handoff is not blocked by a rule discovered at the last minute.

Copy-Paste Clause Checklist

Build the full contract with these clauses in the free FreelanceDesk contract generator, or start from the best free contract templates roundup and add the delivery-boundary and fee-pass-through language.

References

• Apple Developer Program Enrollment
• App Store Small Business Program, Apple
• App Review Guidelines, Apple Developer
• TestFlight, Apple Developer
• App Transfer Criteria, App Store Connect Help
• Get Started With Play Console (Registration Fee), Google Play Console Help
• Service Fees, Google Play Console Help
• Use the Magic Words: Ownership of Code Developed Under a Software Development Agreement, Willcox Savage