How to Package a Build for Multiple Publishers at Once

Submitting to multiple publishers at the same time is normal and expected. Each publisher has slightly different requirements for the build package: different SDK integrations, different analytics setups, different metadata formats, and sometimes different build configurations. Managing these variants without confusion is a process problem, not a technical one, and a clean folder structure solves most of it.

Why this matters

Sending the wrong build to a publisher is embarrassing and sometimes disqualifying. Sending a build without their required SDK is a wasted submission. Sending a build with a competitor's SDK is worse.

The problem scales. Two publishers means two variants. Five publishers means five. Without a system, mistakes are inevitable, and each one costs a submission slot and a week of waiting.

What differs between publishers

Four things vary. Everything else is usually the same.

The game itself does not change. The mechanic, the content, and the art are the same across every submission. The differences are in the wrapper, not the product.

Understanding this separation is the key to managing variants efficiently. The game is one thing. The publisher package around it is another.

The folder structure

Keep the game in one place and the publisher-specific materials in another.

A clean example:

project/ game/ (the actual game, shared) publishers/ publisher-a/ (sdk-config, metadata, build-notes) publisher-b/ (sdk-config, metadata, build-notes)

Each publisher folder contains only what is specific to that publisher. The game folder contains everything that is shared.

The build-notes file is the most important file in each folder. It lists the specific requirements for that publisher: which SDK version, which build flags, which metadata format, and any special instructions.

Write the build-notes file when you first read the publisher's requirements, not when you are packaging the build. Reading requirements under deadline pressure produces mistakes.

Write the publisher's requirements into a file the day you read them. Package the build from that file, not from memory.

Automating the variants

If you are submitting to three or more publishers regularly, automate the packaging.

A build script that takes a publisher name and produces the correct variant saves time and prevents mistakes. The script reads the publisher's configuration, applies their SDK, sets the right build flags, and produces a labelled output file.

Three rules for the script.

1. Label every output. The filename should include the publisher name and the date. "build.apk" sent to the wrong publisher is a mistake. "publisher-a-2026-10-03.apk" is harder to confuse.
2. Never modify the shared game folder. The script copies what it needs, applies the publisher configuration, and outputs to the publisher's folder. The shared game stays clean.
3. Verify the SDK. After building, check that the correct SDK is present in the output. A one-line verification step catches the most common packaging error.

If automation feels heavy for your scale, the manual version works. Build once, copy the output to the publisher folder, and verify the SDK manually. The folder structure still prevents confusion even without automation.

The submission checklist

Run this for every submission, every time.

1. Correct publisher folder? Verify you are packaging from the right folder.
2. Correct SDK? Open the build configuration and confirm the SDK matches the publisher.
3. Build runs? Install and launch the packaged build on a device. A build that crashes on launch wastes the submission.
4. Metadata matches? Check that the description and screenshots match what the publisher expects.
5. File is labelled? Publisher name and date in the filename.
6. Submission format correct? Some want a file. Some want a link. Some want a zip with specific contents.

This takes five minutes per submission and prevents the mistakes that cost a week each.

Common mistakes

Five mistakes that happen when the process is informal.

1. Sending a build with the wrong SDK. The most common error and the most damaging. A competing publisher's SDK in the build is a disqualification.
2. Using the same metadata for every publisher. Some publishers want specific keywords or descriptions. Using a generic version misses optimisation opportunities.
3. Forgetting to test the packaged build. The build that works in the editor may not work after packaging. Test the actual file you are sending.
4. Losing track of which version was sent where. Without labels and a log, you cannot reconstruct what each publisher received. Keep a simple spreadsheet.
5. Reusing an old build. When iterating, it is easy to send the previous version by mistake. Build fresh for each submission round.

A simple tracking spreadsheet solves most of these. Columns for publisher, date, version, SDK, and status. Update it with every submission.

Managing feedback across publishers

When multiple publishers respond, their feedback may conflict.

One publisher says the opening is too slow. Another says it is the right pace. Both are valid observations from different perspectives shaped by their catalogue and their audience.

Keep feedback organised by publisher. Do not merge it into one list, because acting on conflicting feedback simultaneously produces a build that satisfies nobody.

Instead, address each publisher's feedback in their variant. If one wants a faster opening, build that variant with a faster opening and keep the other unchanged.

What we would do

Set up the folder structure before the first submission. Write the build-notes file for each publisher the day you read their requirements.

Label every output file with the publisher name and the date. Run the checklist for every submission, even when it feels redundant.

Then keep a tracking spreadsheet and update it after every submission and every response. The system is simple, and the simplicity is the point.

The short version

• Each publisher needs a slightly different build package. The game stays the same.
• Use a folder structure that separates the shared game from publisher-specific materials.
• Write each publisher's requirements into a file the day you read them.
• Label every output file with the publisher name and date.
• Run a six-item checklist before every submission.
• Keep feedback organised by publisher and do not merge conflicting notes.

Set up your publisher folders and write the first build-notes file today. If you want help packaging builds for submission, get in touch.