Stop Bundling Defold Win32 After the 1.14 Cut - 2026

If you searched defold win32 after Defold 1.14.0, you already have a breaking-change bullet. You need a refusal.

Stop bundling Defold Win32 after the 1.14 cut. The Defold release 1.14.0 post and the forum thread Defold 1.14.0 has been released state that Defold no longer builds or distributes 32-bit Windows runtime, editor, Bob, native-extension, or dependency artifacts. Windows development and bundling use x86_64. Bob’s legacy win32 lookup remains only as a compatibility alias for x86_64-win32. That alias is not a 32-bit lifeline.

The live what-changed map already covers Xbox access, shared Lua, generational handles, cubemaps, and the full break list. This URL does not repeat that map. It refuses the next sentence: “keep the old x86-win32 Steam depot / CI job / Bob line because win32 still appears in the docs.”

This is not the queued twelve-check upgrade listicle. It is not an Xbox access lab. Those own numbered gates and fill-in evenings. This URL owns the 32-bit Windows bundle refusal.

Why this matters now

CI greps still match win32. Bob still accepts a win32 token. Someone on Discord says “nothing changed for Windows.” A producer asks why the 32-bit Steam depot vanished. The honest answer is in the release notes: 32-bit artifacts are gone. Shipping a pipeline that still means 32-bit is cargo-cult. Shipping a pipeline that uses the Bob alias without documenting that it is 64-bit is how partners get the wrong binary story.

Direct answer: Grep for x86-win32. Retarget to x86_64-win32. Treat Bob win32 as 64-bit only. Latch NO_32BIT_BUNDLE. Do not promise a 32-bit Windows build on Defold 1.14+.

Who this refusal is for

Time: 20 minutes for the ladder + grep. Bundle evening separate.
Honest limit: Official posts are authority. If your audience truly needs 32-bit Windows, you are off Defold’s supported Windows matrix for 1.14+ — that is a product decision, not a Bob flag.

Non-repetition

Pair the paste with 25 free game development Discord servers. For Steam desktop save-path discipline on Defold, keep Your First Defold Steam Desktop Collection and Save Audit in the same reading list when the depot story changes — different problem, same “do not invent a depot.”

The claim I am refusing

Claim (false): “Bob still has win32, our CI job is named win32, and Windows players still exist, so we should keep shipping a 32-bit Defold Windows bundle after 1.14.0. The alias means 32-bit is fine. Steam can keep the old depot.”

Counter-claim: Defold removed 32-bit Windows artifacts. The Bob win32 name is documented as an alias for x86_64-win32. Keeping a 32-bit intent after the cut is BUNDLE_32BIT_AFTER_CUT. That is the refusal.

What the cut actually authorizes

From 1.14.0 and the forum notes:

If your plan is “leave the job named win32 and hope,” you skipped the migration sentence.

Target-string cheat sheet (working-dev path)

One command mindset: search the monorepo for x86-win32 and platform.*win32 before the next release candidate.

Excuse ladder

Decision labels (body only)

Monday rule: if the pipeline still contains x86-win32 without an EXCEPTION_1_13 document, you are in violation of NO_32BIT_BUNDLE.

Beginner path — first thirty minutes

1. Open the project remote / CI config.
2. Search for x86-win32.
3. If found, replace with x86_64-win32 on a branch.
4. Search for bare win32 in Bob invoke lines — add a comment: alias → x86_64-win32.
5. Check Steam / itch / partner docs for “32-bit Windows” claims.
6. Paste the Discord four-liner.
7. Do not run a “quick 32-bit smoke” on 1.14 artifacts — there is nothing honest to smoke.

Common mistakes

• Changing only the display name of the CI job.
• Assuming win32 in Bob output logs means ia32.
• Mixing a 1.13 32-bit Bob with a 1.14 project without a written exception.
• Celebrating Xbox while the Windows matrix still lies.

Working-dev preflight before Bob

Discord paste (creators)

STOP — do not ship a 32-bit Defold Windows bundle on 1.14+.
Defold removed 32-bit Windows artifacts (runtime/editor/Bob/NE).
Use x86_64-win32. Bob “win32” is an alias for 64-bit only.
Owner: ________  Gate: NO_32BIT_BUNDLE

Quotable refusal table

Worked example — wrong Friday Bob

Setup: Game ships Steam Windows. CI job bundle-win32 still passes --platform=x86-win32. Engineer upgrades editor to 1.14.0 for cubemaps. Bob fails or silently diverges. Someone switches the flag to win32 “because the notes said alias” and marks the depot unchanged.

What should happen: Job becomes bundle-win64 with x86_64-win32. Depot description updated. NO_32BIT_BUNDLE posted. Optional: EXCEPTION_1_13 only if you truly keep an old build for ia32 — separate pipeline, separate owner.

What happens when people skip the Stop: Failed night builds, confused QA (“Windows is Windows”), partner QA on ancient hardware filing “won’t launch” against an x64 binary labeled win32, and a week lost to naming.

Receipt:

Date:
Engine: 1.14.0 (or newer)
Grep x86-win32: clean? Y/N
Bob platform string:
Artifact arch verified: Y/N
Store copy updated: Y/N
EXCEPTION_1_13?: Y/N (link)
Signer:

RACI

Failure modes

EXCEPTION_1_13 — when it is honest

You may keep a 1.13.x (or earlier) pipeline solely to serve a documented 32-bit Windows audience only if:

1. A named owner exists.
2. The engine version is pinned and not casually mixed with 1.14 content.
3. Store copy says which build is 32-bit and which is 64-bit.
4. Security/update policy accepts a frozen older engine.
5. The exception is time-boxed or reviewed quarterly.

Anything less is not an exception — it is denial.

Grep recipes (copy into the ticket)

Run these against the game repo, CI configs, and any build.py / GitHub Actions / GitLab YAML that invokes Bob:

x86-win32
x86_win32
platform=win32
--platform=win32
--platform win32
architectures.*x86[^_]

For each hit, classify:

Do not close the PR until the artifact arch assert exists. A green Bob that emits x64 while the job is still named win32 is fine only if the assert and the store copy agree.

Verification night (60 minutes)

1. Branch from main; bump is already on 1.14 or you are fixing CI for an imminent bump.
2. Run the grep recipes; paste hits into the PR description.
3. Change platforms to x86_64-win32.
4. Local or CI Bob once; download the .exe / zip.
5. Confirm 64-bit (Windows: dumpbin /headers, or any PE arch tool your team trusts).
6. Update Steamworks / itch / website strings that say 32-bit.
7. Post NO_32BIT_BUNDLE in Discord with the receipt block.
8. Merge only when QA initials the arch line.

PASS = grep clean of x86-win32 + arch assert + copy updated. FAIL = “Bob succeeded” with no arch check.

Partner / Steam email template

Subject: Windows build architecture update (Defold 1.14)

Defold 1.14.0 no longer distributes 32-bit Windows engine artifacts.
Our shipping Windows build is 64-bit (x86_64-win32).
Bob may still accept a legacy “win32” token as an alias for that 64-bit target;
it does not restore ia32.

Please treat any older “win32 depot” naming as historical unless we explicitly
maintain a separate pinned older-engine pipeline (we will say so in writing).

Sources:
https://defold.com/2026/10/12/Defold-1-14-0/
https://forum.defold.com/t/defold-1-14-0-has-been-released/83348

Contact:

Send this the same week you bump — not after a partner QA machine fails.

Steam / itch depot worksheet

If renaming a Steam depot is painful, you may keep the depot ID and change the human-facing description immediately — still better than lying about architecture. Plan a rename when you next touch Steamworks config.

Native extensions and Bob servers

32-bit Windows native-extension and dependency artifacts are part of what Defold stopped distributing. Practical fallout:

• Extension authors: drop x86-win32 from build matrices on 1.14 branches.
• Teams using a private build server: confirm the server image is 1.14-era and not still caching old 32-bit libs.
• “It linked last month” is not evidence — that was a different artifact set.

If an extension silently skips Windows x64 and only had a 32-bit path, 1.14 is when that extension becomes a blocker, not a footnote. Schedule the upstream issue or a fork before the marketing Xbox week.

Solo vs small studio

Solo: Grep once, fix the Bob line, rename the itch/Steam channel if needed. You are CI and producer. Put the partner email in your own sent folder so future-you remembers why the depot name changed.

Small team: CI owns the string; producer owns the store sentence the same day. Do not split “we’ll fix copy next week.” Contractors who copy-paste old Bob examples from 2024 blogs are a risk — pin an internal snippet that shows x86_64-win32 only.

Publisher relationship: If a publisher questionnaire still lists “32-bit Windows: Yes,” update it when you adopt 1.14. Diligence packets that lie about arch fail later under test, not sooner under marketing.

What this Stop is not

It is not a rewrite of what Defold 1.14 changed. It is not a shared-Lua rant, not an Xbox access guide, and not permission to freeze forever on 1.13 without saying so. It is the bundle-architecture refusal for Windows after the cut. When the upgrade-checks listicle ships, use it for the twelve-item evening; use this URL when someone proposes keeping ia32 “just in case.”

Free vs not free

Same-release context (do not merge refusals)

Clear Win32 even if you never request Xbox middleware.

Opinion spine (quotable)

Stop bundling Defold Win32 after the 1.14 cut. The word win32 in Bob is a 64-bit nickname now. If you still need ia32, you need an older engine on purpose — not a hopeful flag.

Key takeaways

1. Defold 1.14.0 removed 32-bit Windows artifacts.
2. Use x86_64-win32 for Windows bundles.
3. Bob win32 aliases x86_64-win32 — not ia32.
4. Grep and kill x86-win32.
5. Latch NO_32BIT_BUNDLE on 1.14+.
6. Relabel store/partner “win32” copy when it implies 32-bit.
7. EXCEPTION_1_13 only with a named owner and pinned engine.
8. Native 32-bit NE jobs are not a 1.14 path.
9. Xbox headlines do not excuse skipping this grep.
10. Pair facts with the what-changed map.
11. Verify artifact architecture in CI.
12. Primary keyword: defold win32.

FAQ

Can I still build a 32-bit Defold Windows game on 1.14?

Not with 1.14’s distributed Windows artifacts. Defold removed 32-bit Windows runtime, editor, Bob, and related artifacts. See release 1.14.0.

Why does Bob still mention win32?

As a compatibility alias for x86_64-win32. It does not restore 32-bit.

What should I put in CI?

Prefer --platform=x86_64-win32 (or your project’s equivalent explicit x64 Windows target). Annotate any remaining win32 Bob token as x64-only.

What if we must support 32-bit PCs?

Pin an older Defold with a written EXCEPTION_1_13, or drop the requirement. Do not pretend 1.14 ships ia32.

Is this the same as the 1.14 what-changed article?

No. What-changed is the full map. This URL is the Win32 bundle refusal only.

Where is the official migration line?

Release notes: review build scripts using x86-win32 and change them to x86_64-win32. Forum: 1.14.0 released.

Where to leave Windows bundling

Pin NO_32BIT_BUNDLE. Tell the channel x86-win32 is retired on 1.14+. Point curiosity at x86_64-win32 and at the what-changed map. For engine orientation, use the Defold guide. The 32-bit depot can wait in a museum branch — live Bob cannot. Re-run the grep the morning you cut a release candidate so a stale example script does not sneak back from a wiki paste. Architecture honesty beats a familiar job name.