How to Make an App Like Candy Crush

Building a match-three puzzle game sounds deceptively simple until you're staring at a cascade animation bug that only appears on level 847. This post covers the architecture, tooling, and trade-offs involved in shipping a Candy Crush-style game at scale.

What Actually Makes Candy Crush Work Under the Hood

Most people think the hard part is the candy graphics. It isn't. The hard part is the game loop: the rules engine that evaluates matches, cascades, and special tile interactions hundreds of times per second, consistently, on a Samsung Galaxy A14 running Android 11 and a five-year-old iPhone SE.

The core loop looks like this:

1. Player makes a swap
2. Engine checks for matches (three or more in a row/column)
3. Matched tiles are removed
4. Gravity pulls tiles down
5. New tiles fill from the top
6. Engine re-checks for cascades
7. Repeat until the board is stable

That loop needs to run in under 16ms per frame to hit 60fps. On mobile, that's a real constraint, not a theoretical one.

The Rules Engine

Model your board as a 2D array. Each cell holds a tile type, a state (idle, matched, falling, locked), and optional modifiers (striped, wrapped, colour bomb equivalents). Keep the rules engine as pure logic with no rendering dependencies. This makes it unit-testable and means you can run simulations server-side for level validation.

Special tiles are where complexity multiplies. A striped tile clears a row or column. A wrapped tile explodes a 3x3 area twice. When two specials interact, the rules branch. Candy Crush has around 20+ special tile types in its current build. Model each interaction explicitly in a lookup table rather than writing nested conditional logic. It scales better and QA can read it.

Physics and Animation

Tile falling isn't physics simulation, it's tweened animation driven by the rules engine output. The engine decides where tiles end up; the renderer interpolates position over time. Use a fixed timestep for the engine (typically 50ms) and decouple the render loop from it. Unity's FixedUpdate handles this cleanly. In Godot 4, you'd use _physics_process for logic and _process for rendering.

Avoid animating in-place. Move tiles via transform offsets, not by changing their grid position mid-animation. Otherwise, your input handler picks up the visual position rather than the logical one, and players tap tiles that don't exist yet.

What Tech Stack Should You Build With?

This is the decision most teams get wrong by defaulting to what they know rather than what fits.

Engine	Best for	Avoid if
Unity (2022 LTS)	Large team, C#, complex shaders	You want a small binary or web-first
Godot 4	Indie/small team, open source, GDScript or C#	You need AAA-quality particle effects out of the box
Cocos Creator 3.x	Mobile-first, web deployment, JavaScript/TypeScript	You need strong console support
Custom (Pixi.js + matter.js)	Web-only, full control	You're underestimating scope

Candy Crush was originally built on Marmalade SDK, then migrated. King now runs a custom engine internally. You won't do that on a first build. Unity 2022 LTS is the pragmatic choice for most teams: large community, solid mobile export pipeline, and IL2CPP compilation gives you acceptable performance on mid-range Android.

If your target is casual mobile with a hard cap on APK size (under 30MB is a common store optimisation target), Cocos Creator is worth evaluating seriously. The binary footprint is smaller than Unity's runtime.

How Do You Design Levels That Players Actually Finish?

Level design is a product problem disguised as a content problem. Candy Crush has over 15,000 levels as of 2024. You won't build that many on launch, but you need a system that makes authoring and balancing tractable.

The Level Editor

Build your level editor before you build levels. It should output a declarative JSON or binary format that the game engine reads at runtime. Decoupling content from code means a designer can ship new levels without an engineer touching the build pipeline.

A minimal level definition includes: grid dimensions, tile layout, obstacles (blockers, locked tiles, jelly layers), objectives (clear X tiles, collect Y ingredients, reach score Z), move count, and the random seed range for tile generation.

Solving and Simulation

Before any level goes to players, run it through a solver. A Monte Carlo simulation with 1,000 random playthroughs gives you a completion rate estimate. Aim for roughly 50-70% completion on first attempt for early levels, dropping to 20-35% at mid-game difficulty. Levels below 5% completion rate are frustrating, not challenging. Levels above 80% are skipped mentally and reduce session length.

King reportedly runs automated solvers across their entire level catalogue before each release. You can build a basic version of this in Python using your rules engine exported as a library, or by running headless Unity builds.

Procedural vs. Hand-Authored

Some studios use procedural generation to produce level skeletons that designers then tune. This works for scale but produces samey levels if the generator isn't sophisticated. For a first product, hand-author your first 100-200 levels. Use the solver data to balance them. Introduce procedural generation once you understand your own difficulty curve empirically.

Monetisation Architecture Without Wrecking Retention

Candy Crush generates over $1 billion annually. The monetisation model is lives (energy system), boosters (power-ups), and extra moves. You're not going to replicate that revenue on launch, but you need the architecture in place from day one because retrofitting it is painful.

Lives regenerate at one per 30 minutes. That's a backend timer, not a client timer. Never trust the client for anything that has monetary value. Store lives server-side, validate on the server, and treat the client as a display layer. Players will manipulate device clocks otherwise.

Boosters are consumable items. Model them as a wallet with item types and quantities. Every deduction and addition to the wallet should be a logged transaction, not an in-place update. This gives you an audit trail and makes refund handling tractable.

For payments, use Google Play Billing Library 6+ on Android and StoreKit 2 on iOS. Both SDKs handle receipt validation. For server-side validation, use RevenueCat if you want to move fast, or build your own receipt verification service if you need custom entitlement logic.

Multiplayer and Social Features: When to Add Them

Candy Crush's tournament and team features came years after launch. Don't build them at v1 unless your differentiation depends on them.

The one social feature worth shipping early is a leaderboard. It's low infrastructure cost (a sorted set in Redis works fine at most scales), drives retention through competition, and gives you data on which levels correlate with churn.

Real-time multiplayer in a match-three game is technically possible but architecturally expensive. You'd need a WebSocket server, conflict resolution for board state, and latency compensation. The design payoff is rarely worth the engineering cost unless the multiplayer mechanic is genuinely core to the concept.

Conclusion

The rules engine and level editor are the two systems that will define your project's velocity. Get those right first. Everything else, monetisation, social, analytics, can be layered on top of a solid core.

If you're at the stage of scoping this project, the most useful next step is to prototype the rules engine in isolation: a headless module that takes a board state and a move, and returns the resulting board state with a list of events. Get that tested and performant before you touch a renderer. It will tell you more about your actual complexity than any amount of planning.

---

FAQ

How long does it take to build a match-three game like Candy Crush? A playable prototype with core mechanics takes 2-4 months for a small team. A shippable v1 with 50 levels, monetisation, and analytics is realistically 9-14 months. King has been iterating on Candy Crush since 2012. Scope your first release to what a 3-5 person team can validate in under a year.

What programming language should I use for a match-three game? C# in Unity is the most pragmatic choice for mobile. The tooling, community, and asset ecosystem are mature. GDScript in Godot 4 is viable for smaller teams comfortable with a Python-like syntax. Avoid JavaScript for the game engine itself; it works in Cocos Creator but adds garbage collection unpredictability that affects frame timing.

How do I prevent players from cheating in a puzzle game? Authoritative server-side state for anything with monetary value: lives, boosters, scores. Validate move sequences server-side if leaderboard integrity matters. Obfuscate client binaries using IL2CPP (Unity) or ProGuard/R8 (Android). Accept that determined cheaters will find workarounds; focus protection on the monetisation layer, not the puzzle layer.

How much does it cost to develop a Candy Crush-style game? A lean build with a team of 4-5 (1 lead engineer, 1 game designer, 1 artist, 1 backend engineer, part-time QA) runs roughly $150,000-$350,000 over 12 months, depending on location and seniority. This excludes user acquisition costs, which dwarf development spend at scale.

Do I need a backend server for a match-three game? Not for the core puzzle mechanics, which run entirely client-side. You need a backend the moment you add lives regeneration, leaderboards, cloud save, or in-app purchases. Build a thin API from the start even if it does very little. Migrating from no-backend to backend mid-product is significantly more disruptive than having a lightweight server from day one.

Have a project in mind? Contact Sodio Technologies to discuss your requirements and explore the right technology solution for your business.