How I Speed Up My Asset Store Publishing Process

Source: Dev.to

The Problem: Waiting on Unity

The traditional way to create a .unitypackage is through the Unity Editor and the Asset Store Publisher tools. While it works, it comes with a lot of waiting.

• Unity can take minutes just to start and prepare a project.
• After that it refreshes assets, recompiles scripts, and finally lets you open the export window.
• Only then can you select your assets and pack them.

If you release frequent updates or maintain multiple assets, this waiting time adds up fast. I realized I was spending more time waiting for Unity than actually improving my assets.

A Faster Approach: Automated Packaging

Instead of relying on the Unity Editor, I analyzed how Unity packages are built and automated the process. The tool runs from the command line and can be fully scripted.

Process comparison

With Unity, even a small change can cost multiple minutes to create a package. With the automated approach, the same task takes about 10 seconds. There’s no editor startup, no script compilation, and no UI interaction. Because everything is automated, the process is reliable and easy to integrate into build servers or CI pipelines. Once I switched to this workflow, packaging stopped being something I had to plan around—it just happens.

What Is a .unitypackage, Really?

A .unitypackage file is, at its core, a gzipped tarball (.tar.gz): a compressed archive with a very specific structure.

When you unpack a .unitypackage you won’t see folders like Assets/Scripts/Player.cs. Instead you’ll find a list of folders named after Unity GUIDs, where each GUID represents one asset.

root/
├── [GUID_1]/
│   ├── asset
│   ├── asset.meta
│   └── pathname
├── [GUID_2]/
│   ├── asset
│   ├── asset.meta
│   └── pathname
└── …

Each folder contains

• asset – the raw binary or text data of the asset
• asset.meta – the metadata Unity uses for import settings and references
• pathname – a text file that tells Unity where the asset should be placed when imported

When Unity imports the package, it reads this data and rebuilds the original folder structure. As long as the format is correct, Unity doesn’t care how the package was created.

The Packing Process: Finding the Right Assets

Packaging is not just about copying files. Unity assets are heavily interconnected, and missing a dependency can easily break a package.

Asset Discovery

1. Discover which assets should be included (e.g., from a folder or pattern like Assets/MyTool).
2. For each asset, check for a .meta file—Unity relies on meta files to assign and track GUIDs.

A GUID is defined at the top of the meta file:

guid: a1b2c3d4e5f6...

All GUIDs are collected to build the folder structure and later matched during dependency analysis.

Dependency Analysis

Many Unity assets (prefabs, materials, scenes, etc.) are stored as YAML text files. Inside these files, references appear as fileID‑GUID pairs, for example:

fileID: 123456, guid: a1b2c3d4e5f6...

To find these efficiently I use a regular expression:

var regex = new Regex(@"fileID: ([\-0-9]+), guid: ([a-z0-9]+)", RegexOptions.Compiled);

RegexOptions.Compiled compiles the pattern to MSIL code, maximizing runtime performance at the cost of a one‑time initialization overhead. When used frequently, compiled regexes are extremely fast.

Every referenced GUID is then matched against the GUIDs defined in .meta files.

Packaging

After analysis, build a dependency graph. Any asset that is referenced—directly or indirectly—is automatically included in the package. This ensures that prefabs keep their materials, scripts keep their dependencies, and the package works out of the box.

The actual packing step is simple:

1. Iterate over all discovered GUIDs.
2. Create a directory for each GUID.
3. Add the required asset, asset.meta, and pathname files.
4. Gzip the whole structure.

Resulting archive layout:

root/
├── [GUID_1]/
│   ├── asset
│   ├── asset.meta
│   └── pathname
├── [GUID_2]/
│   ├── asset
│   ├── asset.meta
│   └── pathname
└── …

How Much Time I Saved

I reduced my publishing process by more than 90 %.

I build different assets, mostly cybersecurity solutions.
For example, my Obfuscator is released for Unity 2021, 2023, and 6000—three Unity versions. For each version there are three tiers: Free, Pro, and Source. That’s 9 uploads total.

Using the Unity Editor, each package takes about 5 minutes. With the automated tool, each package is ready in ≈10 seconds, turning a 45‑minute manual chore into a matter of seconds.

TL;DR

• Unity packages are just gzipped tarballs of GUID‑named folders.
• By parsing .meta files and YAML asset files you can discover all required GUIDs.
• A small command‑line tool can build the correct folder structure and gzip it in seconds, eliminating the need to launch the Unity Editor for packaging.

Give it a try and reclaim the time you spend waiting on Unity!

Result: Roughly 45 minutes total. Using the automated process I described, I reduced the entire workflow to around 30 seconds.

PowerShell script

# Export-UnityPackages.ps1
param (
    [Parameter(Mandatory = $true)]
    [string]$OutputDirectory,

    [Parameter(Mandatory = $true)]
    [string[]]$Versions
)

# Ensure output directory exists
if (!(Test-Path $OutputDirectory)) {
    New-Item -ItemType Directory -Path $OutputDirectory | Out-Null
}

foreach ($version in $Versions) {
    $sourcePath   = "..\$version"
    $outputPackage = Join-Path $OutputDirectory "$version.unitypackage"

    Write-Host "Exporting Unity package for version $version..."

    dotnet UnityPackageExporter.dll `
        $sourcePath `
        $outputPackage `
        --assets "Assets/MyTool/**.*" `
        --skip-dependency-check
}

Run the script:

.\Export-UnityPackages.ps1 -OutputDirectory "..\packed" -Versions "1.0.0","1.1.0","2.0.0"

The result:

packed/
 ├─ 1.0.0.unitypackage
 ├─ 1.1.0.unitypackage
 └─ 2.0.0.unitypackage

Give It a Try Yourself

If you’re building assets for Unity, packaging shouldn’t be the slowest part of your workflow. By skipping the Unity Editor entirely, asset exporting becomes fast, repeatable, and easy to automate.

I’ve made the tool free, open‑source, and MIT‑licensed. You can try it, inspect how it works, or adapt it to your own needs.

👉 Learn more and give it a try here:
https://www.guardingpearsoftware.com/tool/package-export

Hopefully, this helps you spend less time waiting on Unity and more time creating great assets.

Read more on my blog: www.guardingpearsoftware.com