Starlift: a five-second first launch, found in player data and fixed

Starlift is a block puzzle game made with Godot 4, on the App Store and Google Play. It's made by the people who make Glitchless, so read this as our own notes, not an independent review.

Glitchless went into the game on 22 October 2026, in its default anonymous mode. Over the next five days about 400 player sessions came in across versions 1.1, 1.1.1 and 1.1.2. The game is built with Claude Code, which read the same data through Glitchless's MCP server: glitchless_triage for findings, glitchless_performance for frame times and their causes, glitchless_compare_versions for before and after, and single sessions' timelines. This is what it found, what changed, and what the numbers did, including where they didn't help.

The first launch took five seconds

On 26 October the first finding glitchless_triage returned, rated high, was "Slow start: p95 time-to-first-frame is 10.0s". Over the previous three days 62% of sessions had waited more than 4 seconds for the first frame. The split by launch said why: the first launch of a version took a median 6.2 s, and later launches 0.7 s.

A gap like that means something done once and cached, and the slowest hitches at startup said what: shader compiles of 355 ms and 242 ms right after the game opened. Godot compiles a shader the first time it's drawn and keeps the result, so the first launch after an install or an update pays for all of them. The finding's own suggestion was Godot's Shader Baker, which compiles shaders when you export the game. None of Starlift's export presets had it on.

The fix, and the --headless catch

The fix was one setting in the iOS, Android and Google Play export presets. The catch: Godot's Shader Baker only runs when the editor has a renderer, so an export with --headless, the usual way to export from a script, bakes nothing and logs no error. The headless build had 0 baked shaders; exporting with a window gave 240 on iOS (4 MB more) and 38 on Android (1 MB more). Starlift's five export scripts now run without --headless, and a Godot window shows for about 40 seconds during each export.

[preset.0.options]
shader_baker/enabled=true

# Export without --headless: a headless export has no renderer, so nothing is baked.
# godot --export-release "iOS" build/Starlift.ipa

Measured on devices by uninstalling, installing and launching three times each, then reading each launch's time to first frame from Glitchless: an iPhone 16 Pro Max went from 5.25 s to 1.79 s, and a Galaxy A15 from 5.56 s to 4.97 s. The baker helped much less on the Galaxy, whose Vulkan driver still compiles pipelines on first launch. The change shipped in 1.1.2, sent for review on 26 October.

First launch with real players

Here is the time to first frame for players' sessions, 1.1.1 against 1.1.2. 1.1.2's numbers are from its first day, and almost all of its sessions so far are on iPhone, where the baker helped most.

Some compiles are still there: one 1.1.2 session had a 0.78 s shader compile just after opening. Shaders the baker can't see ahead of time still compile on first use, so warming those up behind the splash screen is next.

Android players got half the frame rate

Split by platform, Android's 95th percentile frame was 55.7 ms against iPhone's 18.9 ms, with 21.8 hitches a minute against 2.5. About half of those Android sessions turned out to be Google's test phones (next section). Without them, 19 real Android sessions had a median 95th percentile frame of 35 ms against 17.5 ms on iPhone, and 11 of 18 were over 33 ms, which is under 30 fps.

A session from a Galaxy A15 showed the Home screen at a steady 17 fps. Glitchless showed that it was slow; a GPU timing flag in the game's debug build showed why. The animated sky shader took about 38 ms of a 56 ms GPU frame, the glow 6 to 8 ms and Home's 254 draw calls about 6 ms.

The fix is a light look for slow GPUs: the sky drawn at half size, its stars drawn separately and no glow. It switches on when the median frame in the first seconds is over 24 ms. On the Galaxy A15 the Home screen went from 17 to 53 fps, and the GPU frame from 56 to 12.5 ms. The 24 ms line was checked against the previous eight days of sessions in Glitchless: it would have switched 11 of 18 real Android sessions and 2 of 179 iPhone sessions. It shipped in 1.1.2, which so far has two real Android sessions, too few to say what it did for players.

The error that wasn't players

The top error was a shader that failed to link: "Fragment shader active uniforms exceed GL_MAX_FRAGMENT_UNIFORM_VECTORS", in about 6% of sessions on 1.1 and 1.1.1. The sessions looked odd: 24 of 43 Android sessions from 23 to 25 October came in bursts of about seven, within minutes of each upload to Google Play. Each one had 12 to 16 of these errors, started no level, lasted under two minutes and reported no known GPU.

They were Google Play's pre-launch test phones, which draw with a software GPU. The error never appeared in a player session that played a level, so nothing in the game changed. Glitchless changed instead: the Godot and Unity SDKs (0.5.1) mark sessions on a software GPU as tests, and the server marks Google's test addresses. The next eight such sessions arrived marked as tests.

The lesson for any game: separate test devices from players before reading an error rate or a frame time. It also means 1.1.2 looks better partly because those phones left the players' numbers, so the comparison below sticks to what that doesn't explain.

Where players left the tutorial

The board said 65 to 70% of players finished the tutorial, but it compared finishing with skipping and left out sessions that simply closed the app. Reading the timelines of 1.1.1's first launches told a fuller story. Of 81 first launches, 11 were existing players opening the update, who never see the tutorial. Of the other 70, 36 finished the tutorial, 19 skipped it, 11 closed the app partway through, and 4 left in the first 4 seconds, before the first frame had appeared. Four is a small number, but it's the slow start costing players directly.

In build 17 each lesson became its own level in Glitchless, a skip records which lesson it came from, and skipping on the first run goes straight into a Quick Play game. In 1.1.2's first two days (33 sessions, all on iPhone), the whole drop is at the first lesson: 18 started it, 14 cleared it, and all 4 skips were there. Lessons two to eight went 14 for 14, and all 3 sessions that skipped went on to a Quick Play game.

1.1.1 and 1.1.2 side by side

Players' sessions only. 1.1.2 is one day old and mostly iPhone, so the iPhone rows are the fairer comparison.

Rage quits went the wrong way: 3 of 61 sessions against 3 of 197. That's too few to call, and it's the next thing to watch.

What didn't pan out

• Two levels glitchless_triage called walls weren't. "daily" counted running out of time in a Time Attack as a fail, and "quick" is the online Royale, which a player wins one time in eight. Nothing was changed for either.
• Home's Online card was tapped in 6 of 20 sessions, but 5 of those 6 left the Online menu within 18 seconds without a match. The card now starts a Quick Match search directly; there isn't enough data yet to say whether that helped.
• Of 30 sessions that saw the unlock sheet, 4 tapped buy and all 4 cancelled in the store's sheet. Noted, not changed.
• Checking a fix took patience: Glitchless's stored data lags 10 to 20 minutes behind the game, so each check waited.

Try it on your game

The first launch is the one every new player sees, and it's where a five-second wait costs the most. Glitchless measures it, with every frame after it, on your players' devices, and gives your coding agent the same data. The Godot stuttering guide covers shader compilation and the other usual causes, and what the SDK costs is measured too.

Use Glitchless to check my game's first launch: compare time to first frame on first and later launches, list the slowest hitches at startup with their causes, and fix the biggest one.

Frequently asked questions

Does Godot's Shader Baker fix slow first launches?

It did on iPhone, where Starlift's first launch went from 5.25 s to 1.79 s on the same phone. It helped much less on a Galaxy A15 (5.56 s to 4.97 s), whose Vulkan driver still compiles pipelines on first launch. Export with a window: a --headless export bakes nothing and says nothing.

Why is the first launch slower than the rest?

The first launch after an install or an update compiles shaders and reads files the system hasn't cached yet. Compare first and later launches separately; an average of both hides the problem.

Is this an independent case study?

No. Starlift is made by the team behind Glitchless. The numbers are the game's real player sessions, read with the same tools any Glitchless user has, and the parts that didn't work are here too.

How do I keep test devices out of my players' numbers?

Mark them. Glitchless keeps testers (TestFlight and other test builds) and bots, playtests and store test devices apart from players, and its Godot and Unity SDKs spot a software GPU. In your own analytics, at least filter out sessions that never start a level and arrive in bursts after each upload.

Sources

• Godot docs: Reducing stutter from shader (pipeline) compilations
• Google Play Console help: pre-launch reports
• Glitchless's Godot SDK

Something wrong or out of date? Email support@glitchless.gg and we'll fix it. Glitchless isn't affiliated with the Godot Engine authors, Apple and Google; product names are their owners' trademarks.