Mobile game development

A game is a different discipline from business software

In business software the specification is close to the truth. Someone books an appointment, the record changes state, and the record tells you whether it worked. A game cannot be judged that way. It can be built exactly as written and still be dull, and the only way to find out is to play it. So the budget has to include iteration on how it feels, not just finishing the features.

The second difference is the content pipeline. Art, audio, animation, level data and the tooling that gets them into the build are a production line staffed by people who do not write code, and on most small games it costs more than the engineering. A feature list hides that, which is why game budgets tend to be wrong in the same direction.

A word on fit before the advice. Cross-platform React Native is our default for apps, which suits business software and is not a game engine. What we can evidence is the other half of a game: accounts, records, rules, permissions, admin tooling and the systems a business already runs on. The playable half is a craft we would not claim without showing you something playable.

Make the first playable loop complete before anything else

A loop is complete when four things exist. One action the player takes. A response they can read without instructions. A goal that ends the attempt. And a recovery path when a move is invalid or play is interrupted. Until all four exist there is nothing to test and nothing to price, because the rest of the project is content wrapped around that loop.

Genre decides session length, and session length decides most of the rest. A ninety-second puzzle attempt wants instant restart, forgiving saves and short notifications. A twenty-minute strategy session wants resumable state, a clear pause and a reason to return. Settle both, then build one level that plays properly on a mid-range phone. One level that feels right is worth more than ten that do not.

Offline, social and real-time are three different projects

Offline play is the cheapest thing to run. Progress lives on the device, there is no server, and the decisions are the save format, what happens to old saves when you ship an update, and whether progress follows someone to a new phone. Deferring cloud saves is usually right, and easy to add later if the save format allowed for it.

Social play adds identity: accounts, invitations, leaderboards and shared scores, which means a backend and the account work described in accounts and portals. It also adds a duty. Once players can display or send anything to each other you have user-generated content, and Apple's guidelines require such apps to filter objectionable material, provide a way to report offensive content with timely responses, block abusive users and publish contact details. A leaderboard with free-text names counts, and it is where most small games meet that rule first.

Real-time multiplayer is a different product again. Someone must be authoritative about what happened, latency and reconnection become gameplay problems rather than technical ones, cheating starts the moment the device is trusted, and servers cost money whether or not anyone plays. Unless the game is not a game without it, defer it.

Art, engines, devices and the phones that run hot

Choosing 2D or 3D sets the size of the content team and the performance budget in one decision. After that the constraints are physical, starting with a download size that decides whether people install at all. Android's game documentation points developers at Play Asset Delivery for large assets, Vulkan for graphics performance and its adaptive performance framework for thermal changes, the polite description of a phone getting hot and quietly slowing down mid session. Test on the phones your players hold, including cheap ones.

Engine choice follows requirements, not preference. Unity's Android manual is organised as platform concepts, project setup, Android-specific development such as input, asset management and debugging, then building and publishing, which is a fair map of the work whichever engine you pick. Our position is the honest one: we will not claim depth in a game engine we cannot evidence. If your game needs a full engine pipeline with 3D content and an art team behind it, the better partner is a studio that already lives in that toolchain.

Release evidence, money and the work that starts at launch

Release is a set of evidence rather than a date. A rights record for every piece of art, audio and font, including what the licence permits. Performance results per device tier. Store metadata that matches the real experience, since Apple requires the description, screenshots and previews to reflect it. An honestly answered age rating. If players can create accounts, Apple requires account deletion inside the app, and Google Play requires an in-app deletion path plus a web route to request it.

Money has platform rules before it has a business model. Apple requires unlocking features or content inside an app to go through in-app purchase, and requires odds to be disclosed before purchase for loot boxes or anything else selling randomised virtual items. Auto-renewing subscriptions must provide ongoing value and run at least seven days. Real-money gaming needs licensing where the app is used and must be geo-restricted, one reason we do not build gambling products. Nobody can promise downloads or revenue.

Then the part people forget to budget: a game that stops getting new content usually stops being played. Add operating-system updates, new devices, dependency upgrades, store policy changes, player support and moderation, and live operations is continuing work rather than a launch expense.

When a specialist studio is the better call

If the game is the business, you want a studio: retention and monetisation design, art direction at scale, 3D or animation pipelines, live multiplayer, a content roadmap that keeps producing for years. Ask any candidate to let you play three things they shipped and to talk about the ones that failed. We would be the wrong partner for that, and saying so early is cheaper than finding out in month four.

Where a software team fits is a contained game inside a business product. A loyalty mini-game tied to a real account and reward. A training module scored against a curriculum. A branded promotion with a leaderboard behind it. There the difficult parts are ones ordinary software is good at: rules, state, accounts, permissions, admin tooling, anti-abuse and integration with the system that already runs the business.

What to bring to a scoping conversation

Bring the player task in one sentence, the loop as you imagine it, whether play is offline, social or real time, what content exists and who owns the rights, the devices your players hold, how you expect it to make money, and who keeps it running. The gaps are usually the useful part of the conversation.

Send a scoped enquiry and we will tell you which parts are defined well enough to price, which need deciding first, and whether the honest answer is a studio rather than us. Mobile app development covers the platform, backend and ownership decisions that apply to any app, and the core systems we build shows the accounts and admin work that sits behind one.