Most app contracts get read once, quickly, by someone who is mainly looking at the price and the delivery date. That’s understandable. It’s also where a lot of expensive trouble starts.
Apps have a few problems, websites don’t. Two app stores with their own rules sit between you and your customers. Apple and Google both release big updates every year. And there’s a file called a signing key that, if you lose it, means you can never update your Android app again. Ever. You’d have to publish a new one and ask every user to download it from scratch.
None of that is in the standard contract template. So before you sign with any iOS and Android app development company, here’s what to look for and what to ask them to add.
Is the Platform Decision Written Down, Along With the Reasoning?
The contract should say what’s being built and how. One codebase serving both stores, or two separate apps built natively for iOS and Android.
Both approaches are fine. Cross-platform tools like Flutter and React Native usually cost less and get you to both stores faster, which is why most business apps are built that way now. Native builds make more sense when you need heavy graphics, tight performance or deep access to phone hardware. What matters is that somebody made an actual decision rather than defaulting to whatever the team already knows.
Ask them to explain the choice in plain terms. If you’re quoting several firms, some will propose cross-platform mobile app developers and others will push native, and the prices won’t be comparable until you understand why each one chose what they chose.
Who Owns the Store Accounts and the Signing Keys?
This is the one that causes real damage, and it’s usually missing from the contract entirely.
Your Apple Developer account and your Google Play Console account should be registered to your company, paid for on your card, with your developer added as a user. Not the other way round. If the app sits in their account, you can’t move it easily, and getting it transferred later depends entirely on their goodwill.
The same goes for the signing keys, along with any push notification certificates. These are the files that prove to Apple and Google that an update genuinely comes from you. Ask for them to be handed over, in writing, and store a copy somewhere your business controls. A developer who shrugs at this question hasn’t been burned yet, which isn’t reassuring.
What Exactly Counts as Finished?
“Delivery of the application” means very little on its own. Finished should mean the app is live in both stores and working, not that the code has been emailed to you.
Get acceptance criteria written down. A list of what the app must do, on which phones and which operating system versions, for you to sign it off. Include the devices your customers actually use. If a good chunk of your audience is on older, cheaper Android phones, put that in the document, because an app tested only on recent flagships will disappoint them.
Tie your final payment to that milestone rather than to a date. Dates slip for all sorts of reasons. Working software in the store is a much harder thing to argue about.
Who Deals with the App Stores, Including Rejections?
Which raises the next question, because getting into the stores isn’t guaranteed.
Apple reviews every app and every update, and rejections are routine. Common reasons include missing privacy details, sign-in requirements, payment rules and features the reviewer thinks are too thin. Google’s process is lighter but still catches plenty.
The contract should say who prepares and submits the store listing, who responds to reviewers, and importantly, who pays for the rework when a rejection means changing something. If that isn’t stated, you’ll be having the argument at the worst possible moment, with a launch date already promised to your customers.
What Happens When iOS and Android Update?
Every September or so, Apple ships a new version of iOS. Google does the same with Android. Things break. A login screen or a camera feature that worked fine last month stops working, and your reviews take the hit before anyone on your side notices.
Ask what happens then. Is there a warranty period where bugs get fixed free, and how long is it? Ninety days is common, but check whether an operating system update counts as a bug or as new chargeable work, because those are very different answers. Then ask what ongoing maintenance costs per month, and how quickly they respond when something breaks.
An app is not a one-off purchase. If nobody has mentioned ongoing costs by the time you’re reading the contract, that’s the question to ask before you sign it.
What Third-Party Code is in There, and Who Pays for It?
Modern apps are built partly from other people’s components. Analytics, crash reporting, maps, payments, chat, push notifications. Most are fine. Some carry licence conditions, and some carry monthly fees that grow with your user numbers.
Ask for a list of every third-party service the app will depend on, what it costs, and whose account it sits in. Accounts in your name, with your card. You want to know now if your app quietly depends on a service that charges more once you pass ten thousand users.
Who Handles Privacy, Permissions and the Store Forms?
Both stores make you declare what data your app collects. Apple calls them privacy labels, Google calls it the data safety form. Get them wrong and you get rejected, or worse, you end up making a public statement about your data handling that isn’t accurate.
Depending on where your customers are, you may also have obligations under GDPR in Europe or India’s data protection rules. The contract should say who drafts the privacy policy, who completes the store declarations, and who is responsible if the app collects something it shouldn’t. Most developers will help with the forms. Very few will take legal responsibility for them, and you should know which you’re getting.
What Happens if it All Goes Wrong?
Finally, the part nobody enjoys discussing in a first meeting.
Link payments to milestones rather than the calendar, so you’re never far ahead of the work. Make sure the contract says the source code, the design files and the documentation become yours once paid for, and that the code lives in a repository owned by your business throughout, not just at the end. Check the notice period, and check what a handover actually involves if you part ways halfway through.
A good iOS and Android app development company won’t flinch at any of this. They’ve been on the wrong end of a messy handover too and would rather it was written down.
Two Things to Sort Before You Sign
Ask where the app store accounts will be registered, and ask what happens when iOS and Android release their next big update. Those two answers will tell you more about how a firm works than the rest of the proposal combined.
If you want someone to look over a contract or a proposal before you commit, get in touch with our team. We’re happy to point out what’s missing, even if you end up going with someone else.Â
FAQs
What should be included in a mobile app development contract?
At minimum: what’s being built and on which platforms, acceptance criteria including test devices and operating system versions, who owns the code and design files, who holds the store accounts and signing keys, payment tied to milestones, a warranty period for bugs, ongoing maintenance terms, and what happens if either side wants to end the agreement.
Who owns the app and the source code?
Whoever the contract says owns it. Many templates leave ownership with the developer by default, and in some countries that’s the legal starting point unless the agreement says otherwise. Make sure yours clearly transfers all rights to your business on final payment, including design files and any custom artwork.
Should we build native or use cross-platform mobile app developers?
Cross-platform suits most business apps. One codebase covers both stores, which usually means lower cost and a faster launch. Native is the better choice for games, apps that lean heavily on the camera or sensors, or anything where performance is the product. Ask any firm to justify their recommendation against your specific requirements rather than in general.
Who should own the Apple and Google developer accounts?
Your business, always. Register both accounts in the company name, pay with a company card, and add your developer as a user with the access they need. Moving an app out of someone else’s account later is possible but slow, and it depends on their cooperation at a point when you may not have much.
What happens if the app gets rejected by the App Store?
Rejections are normal and usually fixable within a few days. The thing to settle in advance is who handles the response and who pays for any changes. If the rejection is down to how the app was built, it should sit with the developer. If it’s down to your business model or your content, it will sit with you. Write that split into the contract rather than assuming it.