Why a Godot prototype gets stuck before release
A Godot prototype comes together quickly: a scene, the core game loop, rough UI sketches — and within a few days there is something to play.
This is exactly where a project most often stalls: the demo on a debug rig and the working product on the client's device diverge more than it seems.
The first bottleneck is performance. Code that is convenient on a powerful machine produces frame drops and long scene loads on budget devices.
The cause is usually not the engine but the architecture: extra nodes in the scene tree, per-frame calculations in scripts, resources kept in memory in full.
The second is building for two platforms.
While there is only one version, export is done manually and “somehow.” As soon as Android and iOS appear, manual building turns into a separate job: signing keys, profiles, different sets of resources and settings, discrepancies between what was tested and what shipped.
Third is app store review. Moderation looks at the privacy policy, permissions, age rating, and store listing design; rejection at this step sets the project back by weeks, because some of the comments require changes in the code itself.
None of these areas is related to gameplay — that is why they are discovered late. Below we break down how this is addressed: from profiling on real devices to automated builds and preparation for app store review.
What changes after setting up the build pipeline
Before the pipeline was set up, the Godot project was built manually: a release build took from forty minutes to an hour and a half, signing keys were stored in chat messages, and some steps existed only in one engineer's head.
After moving to the pipeline, the same build takes 8–12 minutes with a single command, and the finished artifact gets a number by which it can be found and compared with the previous one.
The most noticeable change is in the share of failures after an update. Previously, roughly every fifth release brought an emergency patch or a re-release the next day.
Now cold start, scene loading, and progress saving checks are run before rollout; the build first goes to a closed channel and only then to the general one.
The speed of releasing updates drops from a week to one or two days, and release downtime drops to zero. Builds run on dedicated agents in parallel with the team's work, rollout is automatic, and rollback to the previous artifact takes minutes instead of a rebuild.
These are not one-off numbers for a specific release but a mode: each subsequent version goes through the same path in the same time, and release stops being an event the team prepares for separately.
Build modes in Godot: one codebase for two platforms
Godot builds one project for Android and iOS, but platform differences do not disappear: the stores have different payments, account sign-in, notifications, and review rules.
The build mode is how the differences are separated in the code, and it determines what release takes and how the system behaves when one store rejects a build.
Keeping everything in one branch is simpler at the start and riskier in operation: a failure on one platform surfaces in the build for the other. Below are three build schemes for app stores and the conditions under which each justifies itself.
| Option | When it fits | Limitations |
|---|---|---|
| Unified build with runtime platform checks | Differences are UI, payments, notifications; libraries are cross-platform | Platform code in the shared branch; tests are needed on both platforms for every release |
| Platform branches from a shared base | Dedicated store modules and different purchase logic | The base is synchronized manually, and divergence causes edit conflicts |
| Separate release lines | Platforms have their own cycles and review timelines | Double test and release step runs, and a process is needed for porting fixes |
The choice is determined not by the size of the game but by the number of differences: while there are fewer than ten, a unified build provides the shortest path to the stores.
When platform modules begin to interfere with each other, we move them into separate branches on top of the shared base — a fix is ported in one place rather than duplicated.
Work stages: from project review to release
A Godot project rarely starts from a blank slate: more often it is a playable prototype assembled to quickly validate an idea. Before release, it is necessary to understand what can be safely changed in it, how it is built, and where it breaks during release. Below is the work order that every project goes through.
- Project audit. We analyze the scene structure, external dependencies, repository state, and connected add-ons. The output is a map of bottlenecks: what we rewrite and what we leave as is.
- Build scheme. We fix the target platforms and configurations, and move keys and service addresses out of the code. The scheme must produce the same result on repeated runs.
- Release automation. The build is integrated into the shared pipeline: the version number is assigned automatically, the artifact is signed, and it goes to a closed testing channel without manual steps.
- Acceptance checks. We go through a checklist on target devices: launch, progress saving, in-app purchases, behavior when the network is lost and when the app is backgrounded.
- Upload to app stores. Store listing, descriptions, screenshots, privacy policy, declarations about collected data, and passing moderation.
- Project handover. Build archives, release scripts, access credentials, and instructions on how to repeat the build from scratch on a clean machine.
- Support. We triage crashes from reports, release updates for changing platform requirements, and keep releases reproducible.
The first three steps set the main thing — predictability of every subsequent release.
What we hand over with the release build
A build that is assembled on one developer's machine is not a handover artifact. That is why, together with the release, we provide a reproducible set: build configurations for each platform, signing keys, an access scheme, and an update release process.
Six months later, your team or ours builds the same version from the tag and gets a bit-for-bit predictable result, not “it worked until the system was reinstalled.”
- Build configurations: release and debug profiles, a list of connected plugins, export settings for each target platform, and separate variable sets for test and production environments.
- Build pipeline scheme: the build is launched from a tag, runs automated tests, packages the artifact, and puts it into storage — nothing is finished manually.
- Signing keys and certificate stores with a description of who accesses them and when, how a key is revoked and reissued.
- Release process: from code freeze to submission to store review — with approval points and an owner at each step.
- Access rights: roles for developers, the release manager, and the store account owner, including access to publishing dashboards, analytics, and crash logs.
- Project documentation: a map of scenes and subsystems, dependencies between them, the save scheme, and a table of third-party plugins with license terms.
- Rollback instructions: how to return the previous version in the store if review rejects an update or the crash rate grows after release.
- Version registry with release notes and a list of changes between builds — so support understands exactly what shipped to the store.
Case study: a game from prototype to release
The Godot prototype was already playable but never made it to the stores: the release build was assembled manually from a work machine, took more than an hour, and had to be repeated on failures. On some models, the game crashed immediately after the logo — every twelfth launch.
Heavy resources were pulled over the network at startup, so on a weak connection the first screen hung for a long time.
| Metric | Before | After |
|---|---|---|
| Release build | manual, 60–90 minutes, depended on the machine | automatically by release tag, 6–8 minutes |
| Launch failure rate | 1 in 12 launches | 1 in 200, all in the test branch |
| Update turnaround | 2–3 weeks from fix to store | 2–3 days including review |
| Store status | draft, moderation comments | stable releases without returns |
We fixed the cause, not the symptom: we separated game logic and data, moved heavy resources to on-demand loading by scene, and moved the build to a separate server with checks run on real devices.
Before release, the same set of scenarios now runs — from account sign-in to progress saving after a connection loss.
The build stopped being a bottleneck: a fix is verified the same day, not at the end of the cycle.
The failure rate dropped by an order of magnitude, updates ship without rollbacks to the previous version — the rollback mechanism is configured and remains available, but during the observation period it was never needed.
How does building for Android differ from iOS in one project?
In a Godot project, shared logic, scenes, and resources live in one repository, while platform differences are moved into the export layer.
The Android build and the iOS build are launched from the same source tree but take different export templates and different platform wrappers. That is why divergence starts not in the game code but in how the artifact is signed and how the store accepts it.
Build signing works differently. On Android, it is a key file and its password: the team stores them and hands them over to the client, and losing the key means an update cannot be released over an app that is already installed.
On iOS, signing is tied to the developer account and distribution profiles with an expiration date — they are renewed in advance, otherwise the release stalls long before the actual launch.
Store requirements also do not match. The Android app store is stricter about the permissions declaration and the description of data collection; the iOS store is stricter about privacy, store listing design, and in-app purchase rules.
Update review is separate: the same version can pass moderation on one platform in a day and get stuck on the other for a week, so release dates are planned independently.
The practical takeaway is separate build configurations and separate secrets in the continuous build system, not “one button for everything.” We set up automatic signing so that release does not depend on one developer and their laptop, and we plan staged rollout where rolling a version back is impossible.
Common technical objections before starting
Doubts before starting are usually the same, and almost all of them are resolved at the design stage, not after release. Briefly — on migrating an existing project, moderation, updates, and rights to the result.
We have a prototype on another engine — will everything have to be rewritten?
We transfer not code but rules: state logic, balance, movement math. Scenes and input handling are rebuilt for Godot, so we estimate the scope by the number of screens and connections between them — the decision is made before starting, not in the middle of the work.
Who is responsible for app store review?
We handle it: metadata, screenshots, privacy policy, declarations about collected data, and build signatures.
We analyze and rebuild after a moderation rejection, and we maintain a checklist of both stores' requirements in advance — so edits do not turn into a missed release date.
What happens after release — how are updates shipped?
We update the engine to the current branch and fix behavior on new device models and OS versions. Content moved into settings and tables can be changed without a new build — which means without repeated moderation and waiting.
Who owns the source code and rights to the game?
You do. We hand over the repository with change history, scenes, resources, signing keys, and build instructions — the project builds without our involvement.
The contract fixes the rights to the result, and third-party libraries are used under licenses suitable for commercial release.
Let's discuss your game and release plan
To come back with an estimate and release plan rather than general wording, we need a minimum set of inputs. Below is what to send: it will be enough to estimate the scope of work for builds, integrations, and store release.
- A link to the repository or project archive in the current branch: the scene structure, plugins, and export settings show how much remains before the build. We take on Godot projects at any level of readiness.
- Target platforms — Android, iOS, or both: this determines the scope of work for signing, building, and testing on real devices.
- Current project state: a sketch, a playable prototype, or a nearly finished build, and what exactly already works.
- Game description: genre, session length, core mechanic, and 2–3 references you are guided by.
- What content is ready — art, animations, sound, text — and in what form the source files are.
- Access: developer accounts in the stores, certificates and signing keys, test devices — or confirmation that we should set them up.
- Monetization model and analytics: in-game purchases, ad display, progress transfer between devices — this defines the list of integrations.
- Constraints: desired release timeline, tie-in to an event, requirements for privacy and processing of minors' data.
After that, we will come back with a release plan: stages, scope of work, review order, and points where your decisions are needed. Describe the task — we will prepare an estimate for your project.