A rename feels free because the visible part is free. You pick a better name, you change a title field, you swap a logo, and the app in the store reads differently the next morning. What that tidy story hides is that a shipped app is not a name — it is a web of identifiers, half of which you chose and can move, and half of which the platforms chose for you and will never let you move again. This is a first-hand account of renaming Iron Swarm, our top-down tank game, from its original name Iron Blitz. Our own records date the change to 2026-05-04. Months later the old name is still load-bearing in places we are contractually and technically forbidden to clean up — and that permanence, not the new name, is the real story of a rename.
The rename that was mostly not a rename
Start with the thing nobody tells you: most of what an app
‘is,’ to a computer, cannot be renamed at all. Open our repo and the game’s
source folder is still tank-game — a working title from before it had
any public name, never once touched by either rebrand. Read the Android build and its
package is com.wizuslabs.iron_swarm. Look at the App Store and the record is a
number, id6764359993, that has never meant anything human at all. One app,
three machine-facing names, and not one of them says ‘Iron Blitz’ or reads the way
the marketing does. The only place the words ‘Iron Blitz’ ever really lived was the
surfaces built for people to read: the store listing, the URLs, the copy. So the rename
was, precisely, a rename of the human-readable layer — and a hard stop everywhere
underneath it.
That split is not a quirk of our project; it is how both stores
are built. A package name on Android and a bundle identifier on iOS are the app’s
permanent primary key — publish once under com.wizuslabs.iron_swarm and
you are that string forever, because the store, every installed device, and every purchase
receipt key off it. The App Store’s numeric ID is the same kind of permanence wearing a
different face. You can change the display name above these identifiers as often as you
like; you cannot change the identifiers, and a rename that assumes you can is a rename that
breaks its own users. The practical consequence is blunt: a rename is never a move. It is a
move of the labels and a redirect of everything else.
The URLs you can never take back
Every app we ship depends on live, public URLs for its privacy
policy, support page, and terms — the store submission will not clear without them, and
those exact strings get baked into the binary and into the store listing at submission time. Iron
Blitz shipped with its legal URLs under /iron-blitz/. When we moved the canonical
pages to /iron-swarm/, every copy of the app already installed on a phone kept
pointing at the old paths, because a binary in the field does not get the memo that the studio
picked a new slug. You cannot recall those builds. So /iron-blitz/privacy-policy,
/iron-blitz/support, and /iron-blitz/terms-of-use must resolve for as
long as a single pre-rename install might tap ‘Privacy Policy’ in its settings screen.
Our answer is three redirect stubs that will outlive most of the
code around them. Each old page is now a tiny document that does one job: a
meta refresh to its /iron-swarm/ equivalent, a
rel="canonical" pointing at the new URL so search engines consolidate on it, and a
robots noindex so the duplicate never competes in results. They carry a one-line
human fallback link for the rare client that ignores the refresh. In our project docs they are
marked, in plain words, do not remove — and it is worth being honest that
this is not tidy. It is a graveyard we are obligated to keep mowed. The rename created files whose
entire purpose is to apologise for the rename, and whose retirement date is not ‘when we feel
like it’ but ‘when the last old binary stops phoning home,’ which is a date only
the field can tell us.
There is a discipline hiding in the boredom of those stubs, and it is
the same one we wrote about in writing the
canonical form: a redirect only saves you if everything new points at the destination, not the
stub. The moment a fresh store listing, a new in-app link, or a sitemap entry references
/iron-blitz/ again, you have re-created the debt you were paying down. So the stubs
are deliberately excluded from our sitemap and marked noindex — they exist for old
clients, not for crawlers — and everything authored after the rename is required to speak only
the new name. The old name is allowed to be an off-ramp. It is never again allowed to be a
destination.
The manifest that has to answer to both names
Redirects handle the web. They do nothing for the app talking to itself.
Iron Swarm checks for updates by fetching a version manifest we host — a small JSON file that
says, per app, what the latest version is and what the oldest still-supported build is, so an out-of-date
install can prompt the player to update. The catch is that a pre-rename binary looks itself up in that
file under the key it was born with. If the manifest only knows iron-swarm, an old Iron
Blitz install asks for iron-blitz, finds nothing, and silently loses its update prompt —
the one channel you most want working for the users who are furthest behind.
So the manifest now carries the app twice: an
iron-blitz entry and an iron-swarm entry, byte-for-byte identical — same
version, same build number, the same App Store and Google Play links — committed under the honest
label of an alias dual-write, transitional. It looks like duplication because it is duplication, and it is
correct: the old key and the new key describe the same app, so they must return the same answer until the
old key has no callers left. This is the quiet tax of a rename that a spreadsheet of ‘rebrand tasks’
never predicts — not a big migration, just a second copy of a fact you now have to keep in sync forever,
or until you can prove nobody is reading the old copy. Every duplicated fact is a place two truths can drift
apart; the only thing keeping them honest is the rule that you edit both or neither.
The names underneath the name
Below the store and the web sits a layer users never see and engineers cannot
escape: the internal namespace. Iron Blitz littered our build and config with its own prefix. Renaming meant
picking a canonical namespace — IRON_SWARM_* for the app’s keys and credentials —
while keeping the legacy IRON_BLITZ_* names (and an even older TANK_GAME_* working-title
prefix) alive as fallbacks, because a build script that suddenly cannot find a credential under its old
IRON_BLITZ_* key does not rename gracefully; it fails a release. The same shows up in the marker strings we bake into binaries to verify a
build is what we think it is, and in the hostname the web build is allowed to serve ads from,
ironswarm.wizuslabs.com. None of this is player-facing. All of it had to change, or be dual-named,
for the rename to be real rather than cosmetic-plus-broken.
The honest lesson from this layer is that a rename is a search-and-replace with a
blast radius you cannot fully see from any one file. A prefix leaks into environment variables, CI-free local
build lanes, hardcoded verification strings, ad-domain allowlists, and the folder names that outlive every one of
them. You do not finish this work; you decide how much of it is worth doing now versus carrying as documented
legacy. We kept the source folder tank-game untouched precisely because renaming a directory that
nothing user-facing depends on buys nothing and risks breaking every path that references it — a good
reminder that the goal is a correct product, not a repo that reads like a press release.
The honest close: a rename is debt, so keep it small and permanent
We do not regret renaming Iron Blitz to Iron Swarm — the new name is better, and a better name is worth real cost. But the cost is real, and pretending it is a text-field edit is how teams ship a rename that quietly strands their oldest users. The durable takeaway is a division: figure out, before you touch anything, which of your app’s names are cosmetic and which are permanent primary keys, because you can change the first freely and can only ever redirect the second. Then treat every old public string — URLs, manifest keys, namespaces — as an off-ramp you maintain, never a destination you author toward again, and write down its retirement condition so future-you knows when the graveyard can finally be cleared. A rename is not an event you complete; it is a compatibility layer you agree to carry, and the mark of doing it well is that no user ever finds out you did it at all. That same ‘the field is the source of truth’ instinct is why we make a habit of trusting real conditions over tidy theories — the sibling lesson to the day two stores forced one codebase to fork in ways no diagram predicted. The rest of how we build, and where it costs us, is on the WizusLabs Engineering blog.
Notes
This is a first-hand devlog about renaming our own shipped game from Iron Blitz to
Iron Swarm. It contains no download figures, revenue, or engagement metrics, and it makes no claim about how the
rename affected the app’s performance — we are not going to invent a number to look rigorous. Every
concrete detail is drawn from artifacts in our own repositories, verified before writing: the rename is dated
2026-05-04 in our project records; the redirect stubs at /iron-blitz/privacy-policy,
/iron-blitz/support, and /iron-blitz/terms-of-use are live meta-refresh documents with a
rel="canonical" to their /iron-swarm/ equivalents and a noindex robots tag,
marked ‘do not remove’ in our docs and deliberately absent from our sitemap; the version manifest carries
identical iron-blitz and iron-swarm entries (same version, build number, and store links) as
a transitional alias dual-write; the canonical internal namespace is IRON_SWARM_* with
IRON_BLITZ_* retained as a fallback; the source folder remains tank-game; the Android package
is com.wizuslabs.iron_swarm; and the App Store record is id6764359993. A separate,
overlapping migration — moving the site’s canonical host from a legacy GitHub Pages domain to
wizuslabs.com, completed 2026-06-28 — created its own redirect obligations and is referenced only to make the
point that redirect debt compounds; it is not the subject of this piece. The two platform facts that are not our own
observation — that an Android application ID and an iOS bundle identifier are effectively permanent once an app
is published — are documented by the platforms and cited below.
Sources
- Android Developers — Set the application ID (the application ID uniquely identifies your app on the device and in Google Play, and you should not change it once the app is published).
- Apple Developer — CFBundleIdentifier (the bundle identifier is the string that uniquely identifies an app across the system and the App Store — the permanent primary key a display-name change never touches).
These references support only the general platform mechanics named above — that the package / bundle identifier is the app’s permanent identity. The specific rename, the redirect stubs, the dual-written manifest, and the namespace work are our own first-hand account, drawn from artifacts in our repositories, and the piece deliberately reports no performance metrics.
Keep reading: all posts on the WizusLabs Engineering blog.