Cocos Creator Mini-Game Launch Checklist: Performance, Package Size, Compatibility, and Review

On the day of my first review submission, I stared at the “Rejected” popup, my mind buzzing. Package size exceeded - main package was 6.8MB, but WeChat’s hard limit is 4MB. I spent three days optimizing, from texture compression to audio transcoding to engine module pruning, finally squeezing it down to 3.2MB before it passed.

That experience taught me that pre-launch checks follow a clear pattern. It’s not about luck - there are specific metrics and clear testing methods. Later, I compiled the pitfalls I encountered into a checklist, ticking off each item before every submission. This checklist has been iterated over a dozen times now, covering 15 items across four modules: performance, package size, compatibility, and review.

This article shares that checklist with you. Each item includes specific metric standards, testing tools, and the most common pitfalls. After reading, you can use this checklist to self-check item by item, significantly improving your first-time approval rate.

1. Performance Check: Don’t Let Lag Ruin the Experience

Performance issues are a leading cause of player churn. You might think your game runs smoothly on your phone, but remember - your test device is likely a newer model, while real users might be on three-year-old phones. The performance gap between iOS high-end and low-end devices can reach 3-4x. This is no joke.

1. FPS Stability Check

Standard: High-end devices (iPhone X and above) target 60 FPS, low-end devices (iPhone 6s/7/8) target 30 FPS. Minimum peaks should not fall below 80% of the target, meaning high-end minimum 48 FPS, low-end minimum 24 FPS.

Detection Method: Cocos Creator has built-in FPS display, enable it in cc.macro:

// Show FPS during development
cc.macro.SHOW_FPS = true;

Or use Stats.js for a more visual display. The WeChat DevTools “Performance Panel” also shows real-time FPS curves.

Quantitative Metrics:

• High-end devices stable 55-60 FPS
• Low-end devices stable 28-32 FPS
• Peak fluctuations under 20%

Common Issues: Too many DrawCalls, lag during complex scene transitions, large numbers of particles triggering simultaneously. In one project, the boss death animation spawned 200 particles, dropping low-end devices to 15 FPS. I reduced it to 50 particles with tween animations - the effect was actually better.

Self-Test Tip: Find an iPhone 7, run it on the real device for 10 minutes. If the FPS line hovers around 30, you’re fine. If it frequently drops below 20, you need to investigate.

2. Memory Peak Check

Standard: iOS has hard memory limits. Low-end devices (iPhone 6s/7/8) cap at 1GB, high-end devices (iPhone X/XR/11) cap at 1.4GB. Peaks should not exceed 70% of device limits - keep low-end devices under 700MB, high-end devices under 1GB.

Detection Method:

• WeChat DevTools: Open “Debugger-Memory” panel to see memory curves
• Safari Remote Debugging: Connect real device to Mac, select device from Safari Developer menu

// Periodically log memory usage
const memoryInfo = cc.sys.getMemoryInfo();
console.log('Current memory: ' + memoryInfo.used + 'MB');

Quantitative Metrics:

• Low-end peak ≤700MB
• High-end peak ≤1000MB
• Crash rate under 2% (one project reduced from 15% to 2% after optimization)

Common Issues: Double texture problem (same resource loaded twice), resources not released in time, large atlases not split. Cocos official docs recommend keeping atlases under 1024x1024 - larger atlases easily exceed memory on low-end devices.

Self-Test Tip: On a low-end device, repeatedly enter and exit the same scene 20 times. If the memory curve keeps rising without dropping, there’s a resource leak.

3. DrawCall Count Check

Standard: DrawCall directly affects rendering performance. The more DrawCalls in a single frame, the greater the GPU pressure. First screen (the initial game view) should not exceed 100, during gameplay should not exceed 200.

Detection Method: Cocos Creator’s “Build Publish” panel has a render statistics option - check it to see DrawCall counts at runtime.

// View current DrawCall count
const stats = cc.game._renderStats;
console.log('DrawCall: ' + stats.drawCalls);

Quantitative Metrics:

• First screen ≤100
• In-game ≤200
• Peak under 350 (can be relaxed for extreme scenes)

Common Issues: No atlas merging, dynamic atlas not enabled, too many BMFonts. One project had DrawCalls as high as 350. After packing scattered images into atlases and replacing BMFont with TTF, it dropped to 120.

Optimization Tips:

• Static atlas: Pack with TexturePacker to reduce image fragments
• Dynamic atlas: Cocos Creator enables by default, but ensure texture size under 2048
• BMFont: Use TTF when possible - each BMFont char is a DrawCall

4. First Screen Load Time Check

Standard: First screen load over 3 seconds increases user churn by 7%. This isn’t made up - it’s industry data. WeChat cloud testing platform data shows games with 3.5MB packages have first screen times of 4500-9000ms, where churn rates significantly increase.

Detection Method:

• WeChat DevTools: “Details-Local Code” shows package size
• WeChat Cloud Testing Platform: Real device network simulation, get actual first screen time

// Record first screen load time
const startTime = Date.now();
cc.director.loadScene('game', () => {
  const loadTime = Date.now() - startTime;
  console.log('First screen time: ' + loadTime + 'ms');
});

Quantitative Metrics:

• First screen render ≤3000ms (ideal ≤1500ms)
• Progress bar display ratio ≥80% (users are more patient when they see a progress bar)

Common Issues: Too many resources in first scene, initial scene not subpackaged, all resources directory files loaded. My first scene had 3 characters, 2 backgrounds, and tons of UI - first screen took 5 seconds. Changed to one loading image + subpackage loading, reduced to 2 seconds.

Optimization Tips:

• First scene only has one background image + progress bar
• Initial scene checked for subpackaging
• Non-essential resources loaded remotely

2. Package Size Check: You Must Cross the 4MB Threshold

WeChat mini-game main package hard limit is 4MB, total package (including subpackages) cannot exceed 16MB. This is a red line - exceed it and you’ll be rejected immediately, no negotiation. I stepped into this trap - main package 6.8MB, rejected, spent three days getting it down to 3.2MB.

5. Main Package Size Check

Standard: Main package ≤3.8MB. Why leave 200KB buffer? Because build-time might generate dynamic files, and WeChat’s measurement sometimes has slight variations. Leave yourself some breathing room.

Detection Method: After building, click “Details-Local Code” in WeChat DevTools to see precise package size statistics.

Quantitative Metrics:

• Main package ≤3.8MB (safety line)
• Main package ≤4.0MB (red line, must compress)

Common Issues:

• Too many resources in resources directory: All files here get packaged into main package
• Unpruned engine modules: Cocos packages all modules by default, but you may only need a few
• Large dependency libraries: Imported npm packages without checking size

Self-Test Tip: Before building, check the resources directory, move non-essential resources elsewhere. Then in Cocos “Project Settings-Module Settings”, uncheck unused modules.

// Module pruning config example (project.json)
{
  "modules": [
    "base",
    "2d",
    "ui",
    "audio"
  ],
  // Don't check modules you don't need, for example:
  // "physics" - don't need physics engine
  // "tween" - don't need tween system
}

6. Total Package Size Check

Standard: Total package (main + subpackages) cannot exceed 16MB. Subpackages can be loaded remotely, but download speed depends on network, so core content should be in main package and first screen subpackage.

Detection Method: Build output logs show each subpackage size - add them up for total.

Quantitative Metrics:

• Total package ≤15MB (safety line)
• Total package ≤16MB (red line)

Subpackage Strategy Recommendations:

• Core package (main + first screen subpackage) <10MB
• Feature packages (secondary gameplay) 20-50MB
• Scene packages (remote load) 30-100MB

Common Issues: Unreasonable subpackage division, first screen subpackage too large, users wait too long to download. One project put all character models in first screen subpackage - users had to wait 8 seconds to enter the game.

7. Resource Compression Rate Check

Standard: Textures, audio, and fonts are the three main contributors to package size. Real data: textures 45%, audio 25%, fonts 15%. Compress these three well, package size can be cut in half.

Detection Method: Compare original file size with built size.

Quantitative Metrics:

• PNG → JPG (images without transparency): 50-70% reduction
• WAV → OGG: 65-70% reduction
• Font extraction (fontmin): 80-90% reduction

Recommended Tools:

• TinyPNG: PNG compression, web-based, drag and drop
• TexturePacker: Pack atlases + compress, all in one
• Audacity: Audio transcoding, WAV to OGG is easy
• fontmin: Font subset extraction, only keep characters used in game

Common Issues:

• Background images using PNG: No transparency, use JPG
• Audio using WAV: Much larger, switch to OGG
• Fonts not extracted: Complete font file 10MB+, extracted characters may only be 100KB

Self-Test Tip: Compress one PNG with TinyPNG, compare sizes before and after. You’ll be surprised. A 500KB background image might compress to 150KB.

8. Subpackage Configuration Check

Standard: Subpackage loading strategy should be reasonable, not affecting launch experience. First scene must have subpackage checked, non-essential resources should not be in main package.

Detection Method: Check subpackage loading order and first scene dependencies.

Quantitative Metrics:

• First scene subpackage checked: Yes
• First scene load time: ≤3000ms
• Non-essential resources not in main package: Check resources directory

Common Issues:

• First scene references resources outside main package: Requires downloading subpackage before entering scene
• Subpackages not divided by business logic: User enters a game mode only to find subpackage not downloaded
• Wrong subpackage loading timing: Should start downloading subsequent subpackages during loading screen

// Subpackage loading example
cc.assetManager.loadBundle('level-pack', (err, bundle) => {
  if (err) {
    console.error('Subpackage load failed', err);
    return;
  }
  bundle.loadScene('level-1', (err, scene) => {
    cc.director.runScene(scene);
  });
});

Self-Test Tip: Test subpackage loading speed in 4G network environment. If first screen subpackage download exceeds 5 seconds, reconsider your subpackage strategy.

3. Compatibility Check: Don’t Fail on Specific Devices

Compatibility issues are the most easily overlooked. Your game might run fine on your test device, but after launch you receive a flood of user complaints: UI blocked, ugly black bars, orientation switch misalignment. Device compatibility is a systemic issue - you can’t just test one device.

9. Screen Adaptation Check

Standard: Design resolution, adaptation strategy, black bar handling. Portrait games recommend design resolution 720x1280 (9:16) or 750x1334, landscape games the reverse.

Detection Method: Real device testing covering at least 3 screen ratios:

• 16:9 (traditional ratio, most Android devices)
• 18:9 (modern ratio, newer Xiaomi and Huawei devices)
• 19.5:9 (iPhone X series, notch screens)

Quantitative Metrics:

• Design resolution: 720x1280 or 750x1334
• Adaptation strategy: Portrait adapt height, landscape adapt width
• Black bars: None, or evenly distributed

Key Code:

// Portrait adapt height
cc.view.setDesignResolutionSize(720, 1280, cc.ResolutionPolicy.FIXED_HEIGHT);

// Landscape adapt width
cc.view.setDesignResolutionSize(1280, 720, cc.ResolutionPolicy.FIXED_WIDTH);

// Get actual visible area
const visibleSize = cc.view.getVisibleSize();
console.log('Visible area: ' + visibleSize.width + 'x' + visibleSize.height);

Common Issues:

• Wrong adaptation strategy: Portrait game adapting width causes top/bottom black bars
• Widget component not used properly: Nodes don’t automatically follow screen edges
• Design resolution too wide: Some devices can’t display everything

Self-Test Tip: Use Widget component to anchor key UI to screen edges. For example, the coin count in the top right corner - use Widget to fix it to top right, and it won’t shift regardless of screen ratio.

10. Notch/Drop-Notch Screen Check

Standard: Safe area handling, key UI not blocked. iPhone X series notch, Android drop-notches, and punch-hole screens all occupy the top screen area.

Detection Method: Real device testing on iPhone X/XR/11 series, Android notched devices (Huawei Mate series, high-end Xiaomi).

Quantitative Metrics:

• Key UI distance from top ≥50px
• Key UI distance from bottom ≥50px (virtual Home button area)
• Safe area detection: Use SafeArea API

Adaptation Tips:

// iOS SafeArea retrieval
const safeArea = cc.sys.getSafeArea();
const topPadding = safeArea.top;
const bottomPadding = safeArea.bottom;

// Node adaptation
this.topNode.y = -topPadding;  // Offset downward
this.bottomNode.y = bottomPadding;  // Offset upward

Or use Widget component to directly set edge distance, with values set to dynamically retrieved safe area values.

Common Issues:

• Title blocked by notch: Users can’t see game name
• Bottom buttons blocked by virtual Home button: Click area overlaps
• Didn’t test Android punch-hole screens: Different brands have different punch positions

Self-Test Tip: In WeChat DevTools simulator select “iPhone X” device, check if UI is blocked by notch. Then test again on a real Android notched device.

11. Device Compatibility Check

Standard: Cover mainstream devices, low-end device performance meets standards. Cloud testing platforms can help batch test without buying a pile of phones.

Detection Method:

• WeChat Cloud Testing Platform: Free, covers WeChat mini-game mainstream devices
• Testin Cloud Testing: Paid, more comprehensive coverage

Recommended Device Coverage:

• iPhone 6s/7/8: Low-end baseline, test performance floor
• iPhone X/XR/11: Mid-high-end devices, test notch screen adaptation
• Huawei/Xiaomi/OPPO/vivo mainstream Android: Test device compatibility

Quantitative Metrics:

• Low-end device FPS ≥30
• Low-end device memory ≤70% of device limit
• Crash rate ≤2%
• Installation success rate ≥99%

Common Issues:

• Only tested iPhone: Android devices vary greatly, low-end Android is weaker than iPhone 6s
• Ignored older devices: In 2024, some users still use iPhone 7
• Didn’t test WebGL support: Some devices have older WebGL versions, certain effects don’t display

Self-Test Tip: Focus on 3 device types: your development device (high-end), iPhone 7 (iOS low-end), some 2019 mid-range Android. These three cover most scenarios.

12. Orientation Switch Check

Standard: Portrait/landscape adaptation solution, switching smoothness. Some games support orientation switching (like certain puzzle games), UI should automatically rearrange when switching.

Detection Method: Real device rotation testing, forced portrait/landscape scene testing.

Quantitative Metrics:

• Switch time ≤500ms
• UI rearrangement without misalignment
• Scene renders normally after switch

Common Issues:

• Node positions chaotic when switching: Widget not updated
• Black screen after switch: Scene reload failed
• Switch lag: Scene too large, re-render too slow

// Listen for screen rotation
cc.view.on('resize', () => {
  const isLandscape = cc.view.getFrameSize().width > cc.view.getFrameSize().height;
  this.updateUILayout(isLandscape);
});

// UI rearrangement logic
updateUILayout(isLandscape: boolean) {
  if (isLandscape) {
    // Landscape layout
    this.scoreLabel.x = -200;
    this.scoreLabel.y = 300;
  } else {
    // Portrait layout
    this.scoreLabel.x = 0;
    this.scoreLabel.y = 600;
  }
}

Self-Test Tip: If your game only supports portrait or landscape, force-lock the orientation in project settings to avoid screen rotation causing display chaos.

4. Review Check: Qualifications, Privacy, Content - Three Hurdles

The review process is the biggest headache for developers. Technical issues you can test yourself, but review guidelines are hard to know in advance. WeChat’s review guidelines are detailed, but actual enforcement has many details to note. Starting in 2026, WeChat introduced AI-assisted review - updates complete in 2-4 hours, but initial review still takes 1-2 business days.

13. Qualification Completeness Check

Standard: Software copyright, ICP filing, game license (required for in-app purchases). These three are mandatory - missing one means immediate rejection.

Detection Method: Check against official qualification list item by item, ensure names and entities match exactly.

Quantitative Metrics:

• Software copyright: Entity and name match account exactly (character-for-character)
• ICP filing: Approved (7-20 business days)
• Game license: Required for IAP games, optional for pure ad monetization

Common Issues:

• Software copyright name has extra characters: Copyright is “BetterLink Match”, game name is “BetterLink Match Mini-Game” - immediate rejection
• ICP filing not approved before submission: Review period is 7-20 days, submitting early gets rejected
• Game license entity mismatch: License is for Company A, game account is Company B - won’t pass

Self-Test Tip: Put copyright certificate, ICP filing screenshot, and game license (if applicable) together, verify names and entities character by character. One character more or less won’t work - this really requires attention.

14. Privacy Policy and Minor Protection Check

Standard: Privacy policy entry, real-name verification, anti-addiction system. These three are mandatory requirements for minor protection - 2026 reviews will focus on this.

Detection Method: Simulate minor user login flow, check if anti-addiction logic activates.

Quantitative Metrics:

• Privacy policy: Prominent entry on homepage (popup or button)
• Anti-addiction: Minors daily ≤1 hour, 22:00-8:00 play prohibited
• Age-appropriate notice: Healthy gaming advisory displayed on homepage

Common Issues:

• Privacy policy not shown as popup: User enters game and starts playing directly, no privacy policy popup
• Anti-addiction logic missing: No real-name verification entry, or verification doesn’t execute anti-addiction
• Healthy gaming advisory not displayed: Review will require adding it

Self-Test Tip: Use a minor ID number (under 18) to test login flow. Check if anti-addiction restrictions trigger, if login after 22:00 shows play prohibition message.

15. Content Compliance Check

Standard: Name compliance, ad compliance, content red lines. Name must match qualifications, ads cannot block core features, content cannot cross red lines.

Detection Method: Self-check against review guidelines, verify name, ads, and content elements item by item.

Quantitative Metrics:

• Name: No English/brand words, matches qualifications
• Ad ratio: ≤50%, doesn’t block core features
• Content: No violence, pornography, gambling, or politically sensitive elements

Common Issues:

• Name contains “Software”: Like “XX Software Mini-Game” - will be rejected
• Ads block critical buttons: User wants to click “Start Game”, clicks ad instead
• Forced sharing: “Share to friends to unlock level” - immediate review rejection
• Name contains English: Like “CocosGame” - must change to Chinese

Top 5 Rejection Reasons:

1. Package size exceeded (main package >4MB)
2. Name doesn’t match copyright
3. Privacy policy not shown as popup
4. Forced sharing/following
5. Ads blocking core features

Self-Test Tip: Self-check against this TOP 5 list item by item. These 5 reasons account for 80% of rejections - avoid these and you can likely pass on first try.

Quick Checklist: 15 Pre-Launch Items

Print this checklist and check each item before submitting for review:

Module	Check Item	Standard	Pass
Performance	FPS Stability	High-end ≥55, low-end ≥28	□
Performance	Memory Peak	Low-end ≤700MB, high-end ≤1000MB	□
Performance	DrawCall Count	First screen ≤100, in-game ≤200	□
Performance	First Screen Load Time	≤3000ms	□
Package Size	Main Package Size	≤3.8MB	□
Package Size	Total Package Size	≤15MB	□
Package Size	Resource Compression Rate	PNG reduced 50%+, audio 65%+	□
Package Size	Subpackage Config	First scene subpackage checked	□
Compatibility	Screen Adaptation	No black bars, no blocking	□
Compatibility	Notch Screen Handling	UI ≥50px from edges	□
Compatibility	Device Compatibility	Low-end FPS ≥28	□
Compatibility	Orientation Switch	≤500ms, no misalignment (if supported)	□
Review	Qualification Complete	Copyright + ICP filing + license (IAP)	□
Review	Privacy & Anti-Addiction	Policy entry + anti-addiction logic	□
Review	Content Compliance	Name/ads/content standards	□

Check off each item when it meets the standard. Submit for review only after all 15 are checked. Don’t take chances - any item failing could mean rejection and wasted time for revisions.

Summary

Pre-launch checks aren’t optional - they directly impact review approval rates. Performance issues cause user churn, package size exceeds means immediate rejection, compatibility problems lead to user complaints, and review non-compliance wastes a week on revisions.

This checklist’s core value: every item has specific metric standards, no guessing; every item has detection methods, no blind spots; every item has common pitfalls, helping you avoid mistakes others have made.

I recommend printing this checklist and posting it by your monitor. Before each review submission, check item by item. It might seem tedious, but compared to being rejected and spending three days fixing it, this time investment is absolutely worth it.

One final note: Being nervous for your first launch is normal. But with this checklist, you can systematically troubleshoot and launch with confidence. Wishing your mini-game passes review on the first try and launches smoothly.