Release engineering for mobile: beyond feature-complete
Feature-complete is roughly halfway.
The gap nobody schedules
A mobile feature that works on a development machine is not a product. Between that and something a person can install there is a body of work that rarely appears on a roadmap, and it is the stretch where otherwise finished products quietly stall.
It is worth naming, because none of it is difficult — it is just unbudgeted, and it does not compress.
Build pipelines
We build in the cloud for both platforms, which removes the requirement to own a Mac for iOS and makes the build reproducible rather than dependent on one machine's state. Signing credentials are generated and held by the build service; they never live in the repository.
That last point is worth stating plainly. Keystores, provisioning profiles, service account keys and API secrets do not belong in version control, and a repository that has ever contained one has to be treated as compromised rather than cleaned. It is much cheaper to set the ignore rules up front.
Shrinking, and verifying the shrink
Android release builds run code shrinking and obfuscation, which cuts download size and makes the shipped bundle meaningfully harder to read. The store reports an optimisation percentage, and a low one is a real signal rather than a nag.
The trap is that shrinking is exactly the kind of change that passes every test and breaks in production. Reflection-based libraries — advertising SDKs, sign-in flows, anything resolving classes by name — can lose the symbols they depend on. Nothing catches this except installing the shrunk build on a real device and exercising the paths that use those libraries.
Test the artefact you are shipping. A debug build and a shrunk release build are different programs. Verifying the first tells you very little about the second, and the difference only shows up on a device, in the release configuration, doing the thing the reflection-based library was there to do.
Consent and compliance
Advertising and analytics bring consent management, and on iOS an explicit tracking-transparency prompt. These are not checkboxes at the end; they change the interface, they change first-run flow, and getting them wrong is a review rejection or worse.
They also interact with your own privacy policy, which is a document that has to remain true. Adding any analytics to a product whose policy states it collects none is not a technical change with a documentation follow-up — it makes a published statement false the moment it ships.
Store submission is its own discipline
Listings, screenshots per device class, content ratings, data safety declarations, subscription products with their own pricing and grace periods, tax categories. Each is small. Together they are days, and several of them block on external review with no way to hurry it.
Small mechanical rules will also cost you a submission cycle if you meet them for the first time at the end. Release notes, for instance, must sit entirely inside their language tags — a single character outside them is rejected with an error that reads like a validation bug rather than a formatting rule.
Ship in stages
Internal, then closed, then staged production. Not because the build is expected to fail, but because the first real-device install is the first time the shrunk artefact, the store's own delivery, and the production configuration have ever run together.
Shipping is not the end of engineering. It is the part of engineering with the shortest feedback loop and the highest cost of being wrong, which is a good argument for treating it as engineering rather than as paperwork.
The next generation of software will be intelligent.
ScentID Solutions is building toward that future — one platform, one integration, and one intelligent solution at a time.
Work With Us