Why Build Quality Matters for Playables
Publishing a game on YouTube Playables is not the same as uploading it to other web portals. YouTube runs its own certification process, a mandatory technical review that every build must pass before going live. If the build fails, it goes back to the developer for fixes, resubmission, and another round of review. Every cycle costs time and effort.
At Mediacube, we run pre-certification testing on every build before it ever reaches YouTube. Our QA team has reviewed hundreds of builds across Unity, Cocos, Phaser, Construct, and other engines. The errors listed in this article are the ones we see most consistently across studios of all sizes, engines, and game genres.
Most of them are quickly fixable once you know what to look for. Read this before you build, not after.
Error #1: The Pause Doesn’t Pause the Game
What it looks like
When a player switches to another tab, minimizes the app, or the system requests a pause, YouTube Playables sends a pause signal to the game via the SDK. Many games respond to this signal by showing their internal pause menu, but the underlying game loop continues to run. Physics ticks, countdown timers count down, animations keep going. Some interactive elements are still clickable in the pause state.
Another variant: The game visually freezes, but queues up input during the freeze. When the game gets back to it, it executes all those buffered actions in one go — and a character suddenly jumps three times in rapid succession, or shoots a weapon that was pressed during the pause screen.
Third variant (quite often reported in our QA pipeline): The game correctly displays the internal pause menu, but the buttons on that menu are fully clickable. The official Playables pause is in effect and the player can use this time to navigate menus, change settings or even restart the game.
Why it fails certification
The Playables SDK pause contract is strict: when ytgame.system.onPause() is triggered, the game must fully stop and run no animation, no physics, no input processing, and no timers. Any deviation from this is flagged during YouTube’s certification process.
The Playables SDK pause contract is strict: when ytgame.system.onPause() is triggered, the game must fully stop and run no animation, no physics, no input processing, and no timers. Any deviation from this is flagged during YouTube’s certification process.
onPause callback and ensure it stops the game loop, mutes all animations, disables input handling, and clears any pending action queues. On onResume, restore state from where it was frozen: do not replay buffered inputs. Test this explicitly by triggering pause via the Playables Test Suite, not just your own in-game pause button.
Error #2: The Mute State Is Not Persistent
What it looks like
YouTube can mute a game’s audio at any time through the SDK, for example, when the player is watching an ad, switches contexts, or has their device on silent. The game should respect this mute state and keep audio off until YouTube explicitly unmutes it.
The failure modes we see most often:
Mute resets on internal events. The game mutes correctly in response to the SDK signal, but if the player opens the in-game settings menu, clicks a restart button, or transitions to a new level, the mute is lifted. The audio comes back, even though YouTube still has the mute active.
Mute does not survive a page reload. If the page is refreshed while the game is muted (via SDK), the game relaunches with audio on. The mute state was stored in memory, not persisted, so the reload wipes it.
Internal mute button overrides SDK mute. The SDK mutes the game but the player can press the in-game audio toggle to get the sound back. It is the in-game control that is bypassing the external SDK command.
Why it fails certification
The Playables SDK provides ytgame.system.isAudioEnabled() to check the current audio state, and ytgame.system.onAudioEnabledChange() to listen for changes. Games have to rely on these instead of managing their own parallel audio state that can get out of sync.
ytgame.system.isAudioEnabled() at game launch, before playing any sound. Register onAudioEnabledChange and apply the new state immediately and globally when it fires. Persist the SDK’s mute state so it survives page reloads: write it to ytgame.game.saveData() so the game reads it back on the next launch. Do not allow in-game audio toggles to override the SDK state; your internal button should only work when the SDK has audio enabled.
Ready to Launch on YouTube Playables?
Create your account and get everything you need to publish, monetize, and grow your game globally.
Get StartedError #3: Progress Is Not Saved Between Sessions
What it looks like
The player completes levels 1 through 5, closes the browser, reopens the game — and starts back at level 1, or worse, the tutorial. No progress was saved. The game was storing state in localStorage or a session variable, both of which are wiped on close or unavailable in the Playables environment.
Why it fails certification
YouTube Playables does not allow games to use browser localStorage or external save servers. All persistent game data must go through the Playables SDK: ytgame.game.saveData() and ytgame.game.loadData(). Games that do not implement this will lose player progress on every session, which is an immediate rejection flag.
localStorage.setItem() / getItem() calls with ytgame.game.saveData() and ytgame.game.loadData(). These accept a serialized string up to 3MB — serialize your save state as JSON, load it at startup, and write it whenever meaningful progress is made (level completion, checkpoint, significant achievement). Do not wait until the session ends to save and use onPause as an additional save trigger, since the game may be closed from pause.
Error #4: The Game Tries to Load Assets From External URLs
What it looks like
The game fails to load or loads partially with missing music, missing visual assets, or silent audio when run in the Playables environment. In the browser console, you see network errors: requests to external CDNs, asset servers, streaming music APIs, or third-party font providers that are being blocked.
Sometimes this is obvious (the game was built to stream its soundtrack from an external service), and sometimes it is subtle (a web font loaded from Google Fonts, an analytics pixel, a single sprite atlas hosted on a CDN that was never bundled into the build).
Why it fails certification
YouTube Playables operates in a sandboxed environment. External API calls and requests to outside domains are not permitted. Everything the game needs to run must be bundled into the build itself. This includes: audio files, texture atlases, fonts, localization strings, configuration files, and any third-party scripts.
Network tab and run through the game fully: loading screen, main menu, gameplay, death/game-over, and level transitions. Filter for any requests going to external domains. Bundle those assets locally, or if they are third-party services (analytics, ads other than YouTube’s SDK), remove them entirely. Run the same check after every build update.
Error #5: Rewarded Ad Buttons Are Wired Up Incorrectly
What it looks like
The developer added a rewarded ad button, often as a late addition specifically for Playables, because the original game had no reward mechanic. The button appears in the UI, it looks correct, but pressing it does nothing. No ad is requested and no reward is granted. Sometimes the button triggers visually (a tap animation) but the requestRewardedAd() call is either missing, placed in the wrong lifecycle point, or the promise is not handled.
A related failure: the rewarded ad fires, the user watches the ad, but the reward is never actually delivered — the isRewardEarned return value is not checked, or the reward delivery code is written but never connected to the button handler.
Why it fails certification
The Playables certification test suite explicitly verifies that rewarded ad requests complete their full cycle: the ad is requested, shown, and the reward is conditionally granted based on the return value. A button that does not produce an ad when pressed is a certification failure.
Publish your Game on YouTube
Publish games faster, manage monetization, receive fast and secure payouts worldwide, and get premium tech support from a team that helps developers grow globally.
Apply NowError #6: Orientation Changes Break the Layout
What it looks like — two variants
Variant A: content gets cropped. The game rotates correctly when the device switches between portrait and landscape, but elements near the edges are cut off. The game canvas scales, but the UI layer does not reposition to match, so buttons end up behind the safe area, text is partially hidden, or the game viewport clips content that was inside the bounds before the rotation.
Variant B: the canvas rotates, the UI does not. The game adapts its canvas to the new orientation correctly, but icons, HUD elements, and buttons stay at their original pixel positions which are now wrong for the new screen dimensions. On a small mobile screen switching to portrait mode, a button that was comfortably sized in landscape becomes a tiny unresponsive tap target.
Why it matters
YouTube Playables runs across a wide range of devices and screen ratios. Players move between orientations fluidly. A game that breaks on orientation change creates a frustrating experience and will receive a lower engagement score from the algorithm which directly affects discovery.
Error #7: The Game Keeps Running During Interstitial Ads
What it looks like
An interstitial ad fires, the ad overlay appears on screen, but the game continues running in the background. The player cannot see what is happening, but the game loop is still active. In a puzzle game, this is mildly annoying (the timer ticks while the player watches an ad). In an action game or survival game, it is a session-ending bug: the character takes damage, enemies advance, and by the time the ad finishes, the player is dead with no ability to have reacted.
Why it matters
Interstitial ads require player attention to be on the ad, not the game. A game that does not pause during an ad is penalizing the player for the monetization event which is exactly the opposite of a good player experience. YouTube expects games to pause during all ad events.
requestInterstitialAd(), save the game state and suspend the game loop. After the promise resolves (whether or not an ad was shown), resume. Handle errors with the same resume logic — the game should never be left in a suspended state due to an ad error.
The implementation pattern:
pauseGame(); //stop game loop and inputstry { await ytgame.ads.requestInterstitialAd(); } catch (e) { /* handle gracefully */ }resumeGame(); //always resume, regardless of outcome
Error #8: The Game Only Works in Fullscreen Mode
What it looks like
The game renders a black screen, a loading loop that never completes, or a distorted layout when launched in the standard Playables embedded player. Opening the same build in fullscreen mode makes everything work correctly. The game was built assuming fullscreen availability, and the Playables player does not guarantee it.
This is common in builds ported from mobile apps that used a fullscreen-forced launch, or from desktop games where the developer always tested in a maximized browser window.
Why it fails certification
YouTube Playables runs games in an embedded container within the YouTube interface. The game must render correctly at whatever dimensions and aspect ratio the container provides. Fullscreen mode may or may not be available depending on the device, platform, and user context. A game that requires fullscreen to function cannot pass certification.
Pre-Submission Checklist
Before sending your build to us for pre-certification, run through this list:
How We Help You Get Through Certification Faster
When you publish through Mediacube, we run a full pre-certification pass using our internal MC Play platform before your build ever reaches YouTube. Our QA team checks every item on the list above and catches issues before they become rejection cycles.
Our fastest build-to-live timeline is 2 business days. A well-prepared build with no QA issues typically goes live within one week. If issues are found during pre-certification, we give you a detailed report (specific bugs, reproduction steps, and recommended fixes) so your team knows exactly what to address.
We have been an official YouTube partner since 2015 and have been publishing on Playables since September 2025. Every game in our portfolio has been through this process. We know what YouTube’s certification team looks for, and we know how to get builds through.
Start the conversation and apply here.
