App Development Invoice: Line Items for iOS and Android Work

A blank invoice grid has columns for description, quantity, rate and amount. That works for a logo. It does not tell you what to do when Apple rejects the first submission, when the client wants Android added after the iOS build is done, or when a new iOS release breaks a screen you shipped six weeks ago and nobody has said who pays for the fix.

Mobile projects have costs and delays that web projects don't: review queues you don't control, accounts that have to be registered to a legal identity, a spread of physical devices to test on, and an operating system that changes under you every year. This post covers the line items, who pays the store fees, how to word each phase, and a full sample invoice for a made-up app at three milestones. It's general information about how freelance work is commonly structured, not tax or legal advice.

What line items belong on an app development invoice?

Start from the phases of an app project and give each one its own line. A client who can see "Beta build" and "Store submission" as separate rows understands what they are paying for and when. A single row reading "App development, 120 hrs" invites questions about all 120.

The rows that most app invoices need:

• Design implementation. Turning approved screens into working UI. If the client supplied the designs, say so in the line ("per Figma file v3"), which also fixes the scope.
• Feature build. One line per feature or screen group, worded like the agreement: "Onboarding, sign-in and saved places (iOS and Android)". Keep the same wording the statement of work used.
• Backend and API work. A separate section, covered below.
• Device and OS testing. Real hardware testing is real time. List it as its own line with the number of devices or the test matrix you agreed on.
• Build and release configuration. Signing, build variants, environment setup, crash reporting hookup, analytics setup.
• Store listing and submission. Screenshots in the required sizes, descriptions, privacy answers, age-rating questionnaire, and the submit itself.
• Review handling. Responding to reviewer questions and resubmitting, with the number of included rounds stated.
• Project management and client communication. Only if you agreed to bill it. If it's built into your rate, leave it off.
• Post-launch support. Monitoring, defect fixes inside the warranty, and anything after it as a separate row.
• Reimbursable costs. Third-party fees paid on the client's behalf, at cost, with receipts.

Each row also needs a basis. Say "fixed" or "42 hrs at $95" on the line itself. The same rule that applies to a web invoice applies here, and the web development invoice line items guide covers the wording patterns in more detail. App work just adds the store, device and platform rows on top.

One more thing worth deciding up front is cross-platform. If you build with a single codebase for iOS and Android, bill the build once and add a small per-platform line for the platform-specific work: push notification setup, store-specific builds, platform-specific bugs. If you build two native apps, two build lines is honest, and it keeps the conversation clean when the client wants to launch one platform first.

How do you bill App Store and Play Store review cycles?

Review is the part of an app project that you can't schedule. Neither store promises you a date, so a milestone that depends on "approved and live" can slip for reasons that have nothing to do with the quality of your work. Handle it in two ways: contract language and invoice structure.

In the contract, separate what you control from what you don't. Your obligation is to submit a build that meets the store's published rules. The store's decision is theirs. Apple publishes its App Store Review Guidelines, and they are the reference for what a reviewer checks, including that apps are submitted by the person or legal entity that owns or has licensed the rights. Point to them in your scope so "compliant with the current guidelines" has a concrete meaning.

On the invoice, split the review work into pieces that can be priced:

1. Store listing and metadata preparation. A fixed fee or hours. This happens before submission and is fully in your hands.
2. First submission and review handling. Includes submitting the build, answering the first round of reviewer questions, and packaging the response.
3. Resubmissions. State how many rounds are included. "One resubmission included, further rounds at $95 per hour" is a sentence that prevents an argument later.

A rejection is not automatically your fault or the client's. Sort it into one of two buckets. If the rejection is about something you built or configured wrong against the stated rules, treat the fix as a defect and fix it inside the included round. If it's about something the client controls, such as a missing privacy policy URL, content they supplied, a demo account they didn't provide, or a business model decision, the fix and the resubmission are billable. Writing that distinction into the agreement is the cleanest approach. It's also why the sample invoice below shows a resubmission as a zero-dollar included line, so the client sees what they got for free.

Android has its own wrinkle. Google states that developers with personal accounts must complete specific app testing requirements before making their app available on Google Play, and that personal account owners must verify access to an Android device. If the client registers as an individual, that testing step affects your launch date and your time. Raise it before you quote, and list the coordination as its own line if it takes real effort.

Who pays the developer program fees?

The cleanest answer is that the client pays, from accounts they own, and you never invoice the fee at all.

Two reasons. First, ownership: the developer account is where the app lives. Whoever holds the account holds the listing, the reviews, the update channel and the seller identity. A contractor who publishes under their own account becomes a hostage-taker by accident, and the client becomes dependent on you for every update. Second, liability: apps published under your name put your name in the store and your legal identity on the hook.

Apple lists the Apple Developer Program at $99 per year, and its enrollment page says you can enroll as an individual or enroll an organization. Google's Play Console help page says there is a US$25 one-time registration fee, and that Google Play has two account types, personal and organization. Fees can change, and they're charged in local currencies in some regions, so check both pages on the day you quote.

That gives you three workable setups:

Setup	Who pays	What goes on your invoice
Client-owned accounts (recommended)	Client pays Apple and Google directly	Nothing for the fees. You bill your time to help with enrollment, if any.
You pay on the client's behalf, in the client's account	You front it, client reimburses	A reimbursement line at cost, with the receipt attached and no markup.
Your own account (avoid)	You	Bad idea. If a client insists, use a written transfer agreement and bill a clear handover fee.

If you pay on the client's behalf, keep the line honest and boring: "Reimbursement: Apple Developer Program, 1 year, at cost" and the amount from the receipt. Don't add a handling fee unless the contract names one, and don't fold it into an hourly line. Clients accept pass-throughs at cost without a second thought. They push back when the fee is tucked inside your rate.

Also bill your own time for the enrollment help. Walking a non-technical client through identity verification, organization details and two-factor setup takes real hours, and it's work you can predict. A fixed "Developer account setup assistance" line of two or three hours covers it.

How do you invoice backend and API work alongside the app?

An app with a server behind it is two projects wearing one name, and the invoice should show that. Put backend work in its own section, with its own subtotal. There are three reasons.

It has a different lifecycle. The backend keeps running after the app ships. Hosting, database, and API keys need an owner, and the client should know what they are paying for and what they will pay for next month.

It has different pricing logic. App screens are easy to scope by screen. Backend work is easier to scope by endpoint or capability: authentication, saved data sync, push notifications, a data feed from a third-party API. Bill each as a named capability.

It has third-party costs. Hosting, database tiers, email or push providers and map or data APIs are recurring costs. Those belong on the client's own accounts, ideally, with the client holding the billing relationship. If you carry them for a while, list them as reimbursements at cost with a clear end date, and move them to the client's accounts at launch.

Wording that works:

• "Authentication and account endpoints: sign-up, sign-in, password reset (fixed)"
• "Saved-places sync API with offline conflict handling (18 hrs at $95)"
• "Third-party tide-data integration and response caching (fixed)"
• "Staging environment setup and deployment pipeline (4 hrs at $95)"

The point of each line is that the client can read it and tell which feature of the app depends on it. If you later get a bug report that the app can't save a place, the backend section of the invoice tells you and the client where to look.

For the hours-versus-fixed decision on each section, the hourly vs fixed-price guide works through the trade-offs. In practice many app projects mix the two: fixed for the well-defined build, hourly for review handling and testing, where the effort is unknown.

How do you bill fixes after an OS update?

Operating systems ship new versions on a yearly cycle, and every release can change behavior your app relied on. A screen that rendered correctly in September can have a spacing issue in October because of a change you didn't make. Who pays?

Use the same line the web world uses for warranties: a defect is a place where your delivered work didn't meet the agreement; a platform change is a new condition after delivery. If your contract has a warranty window, the warranty period post lays out the clause. For apps, add two sentences to it:

1. The warranty covers the OS versions and devices named in the scope at the time of delivery.
2. Changes needed because of a later OS release, SDK deprecation or store policy change are billed as separate work, or covered by a maintenance retainer.

On the invoice, show the cause on the line so nobody has to ask. "iOS point-release layout fix: tide chart spacing (3 hrs at $95). Platform change after delivery, outside warranty" tells the client why they are being billed and why it is not a mistake. Compare that with "Bug fixes, 3 hrs", which reads like you're charging for your own errors.

For clients who want to avoid surprise bills each autumn, offer a small recurring plan that covers OS compatibility checks, dependency updates and monitoring. The maintenance retainer packages post has structures you can adapt to apps. A retainer turns an unpredictable annual bill into a predictable monthly one, and clients usually prefer that.

What does a sample app development invoice look like at three milestones?

Here's a full example for a clearly fictional app. Tidewalk is a made-up app that shows tide times for saved beaches. The client, Harbor Light Studio, is also made up, as are all the numbers. The developer bills at $95 an hour, mixes fixed fees with hourly lines, and the client owns its Apple and Google accounts. Adapt the wording and amounts to your own agreement.

Invoice 1: beta build

INV-2026-014. Tidewalk (fictional example). Milestone 1 of 3: beta build delivered to testers.

Line	Basis	Amount
Beta build: onboarding, tide list and saved-places screens, iOS and Android (single codebase), per scope v2	Fixed	$6,200.00
Backend: tide-data integration, response caching, saved-places sync API	18 hrs at $95	$1,710.00
Device testing: 3 iPhones, 3 Android phones, agreed test matrix	7 hrs at $95	$665.00
TestFlight and Play internal testing setup, tester invitations	3 hrs at $95	$285.00
Subtotal		$8,860.00
Less: deposit received on INV-2026-013		-$3,000.00
Amount due		$5,860.00

Notes on the wording: the build line quotes the scope version, so a "can you also add X" request has an anchor to be measured against. The backend line names the capability, and the testing line names the matrix. The deposit appears as a credit with its invoice number, so the books reconcile on the client's side.

Invoice 2: store approval

INV-2026-015. Tidewalk (fictional example). Milestone 2 of 3: approved on the App Store and Google Play.

Line	Basis	Amount
Store listing preparation: screenshots in required sizes, description, privacy answers, age-rating questionnaire	5 hrs at $95	$475.00
Release configuration: signing, production build variants, crash reporting	4 hrs at $95	$380.00
iOS submission and review handling, first round	2 hrs at $95	$190.00
Android production submission and review handling	2 hrs at $95	$190.00
iOS resubmission 1 of 1 included in agreement (metadata correction)	Included	$0.00
Reimbursement: Apple Developer Program, 1 year, paid on client's behalf, receipt attached	At cost	$99.00
Reimbursement: Google Play registration fee, one-time, receipt attached	At cost	$25.00
Amount due		$1,359.00

Notes: the zero-dollar line is deliberate. It shows the client that the included resubmission was used, which makes a second one easy to explain. The reimbursements are separate rows at cost, so they can be reconciled without touching your labor. If the client had enrolled themselves, those two rows would simply not exist.

Invoice 3: 30 days after launch

INV-2026-016. Tidewalk (fictional example). Milestone 3 of 3: launch monitoring and post-launch work.

Line	Basis	Amount
Launch monitoring: crash reports and store review triage, 30 days from release	6 hrs at $95	$570.00
Fix: Android saved-places sync crash (defect in delivered work), covered by 30-day warranty	Warranty	$0.00
iOS point-release layout fix: tide chart spacing. Platform change after delivery, outside warranty	3 hrs at $95	$285.00
Change request CR-01: share-a-tide card from the tide screen, per signed change order	Fixed	$900.00
Amount due		$1,755.00

Notes: each line says why it is billed or not billed. The warranty fix is shown at zero, so the client sees the value of the warranty. The OS fix is labelled with its cause. The change request cites the signed change order. If the client asks why a line exists, the answer is already on the page. Project total for this example: $8,860 + $1,359 + $1,755 = $11,974 across three invoices.

Which milestones suit an app project?

Three or four invoices tends to match how apps actually progress. The sample above uses beta, store approval and post-launch because each one produces a thing the client can touch: a build on their own phone, an app in the store, and a record of how it behaved in the wild. If your project is larger, add a milestone for a design sign-off or a mid-build demo. The milestone billing guide explains how to split the money and what to do when a milestone slips.

For store-dependent milestones, define "done" in terms you control: "submitted and passed internal testing" instead of "live in the store". Then add a separate line for review handling that completes when approval arrives. That keeps your invoice from being held up by a review queue.

If you're still working out the layout and numbering, the free invoice template for developers is a starting point you can edit to match any of the three tables above.

FAQ

Should the client own the App Store account?

Yes, in almost every case. The account holds the listing, the update channel, the reviews and the seller identity. When the client owns it, they keep control if you part ways, and you aren't legally attached to an app you don't run. Add yourself as a team member with the access you need to submit builds. If a client really wants you to publish under your account, put a transfer agreement in the contract and price the handover.

Do I charge for resubmissions after a rejection?

It depends on the cause, and your contract should say so. Fixing something you built against the published rules is part of delivery, so include a set number of rounds (one or two is common). Rejections caused by things the client controls, such as missing legal pages, content they supplied, or a feature they asked for that conflicts with the rules, are billable. Show the included round as a zero-dollar line, and state the hourly rate for any beyond it.

How do I invoice cross-platform work?

Bill the shared build once, then add separate lines for what is specific to each platform: store builds, native module setup, push notification configuration, platform-specific bug fixes and each store's submission. That way the client can see why Android takes more or less time than iOS on a given project, and it's easy to add the second platform later without redoing the first invoice.

Which milestones suit an app project?

A beta build delivered to testers, approval on the stores, and a post-launch period of around 30 days is a good default. Each has a visible result. For longer projects, add a design sign-off milestone and a mid-build demo. Avoid milestones that depend on a date the stores control. Define them by what you submit, and bill review handling as its own line.

---

Ready to put this together? Start from the free developer invoice template and add your app milestones as line items, or generate the invoice free at billable.dev, with no account and nothing leaving your browser. Pro ($4/mo billed as $24 every 6 months, or $79 once) adds saved clients and invoice history, which helps when you bill the same studio across several apps.