Building an iPhone Game in Unity From My Thrillers.

59 days in, this is what I have learned.

Building an iPhone game in Unity as a solo developer is mostly a memory problem, a testing problem and a discipline problem. Fifty-nine working days in, mine runs on my phone at 120 frames a second, a village keeps its own schedule without me, and a test rig plays the game overnight so I do not have to. I am building it alone, on a MacBook Air with 8 GB of memory, in the world of my thrillers. These are the notes, written for other builders, with the numbers left in.

Table of Contents

• Structure First, Art Last
• Buying a World on Fab
• Two AIs and a Constitution
• Building an iPhone Game in Unity on an 8 GB Laptop
• The Night iOS Killed the Game
• Proof Before Build
• 2.7 GB and Apple's 4 GB Ceiling
• What Comes Next
• Summary
• Frequently Asked Questions
• Related Reading

Structure First, Art Last

The decision that shaped everything came on day 48. I wish it had come on day one. Infrastructure first. Avatars, buildings, textures and sounds are placeholders, bought or replaced when there is money to spend. The sessions build the systems the assets drop into, not the assets.

It is the opposite of what a solo game developer wants to do. A beautiful screenshot on day three feels like progress. A loading system does not. But the loading system decides whether the game exists on a phone at all, and I found that out the hard way, below.

The practical rule: nothing is placed by hand. A tool surveys the ground, writes a plan, places the pieces from the plan, and verifies what it placed against the plan. My village was moved once, rebuilt three times and refurnished twice, and each time it was a re-run of a tool, not a week of dragging houses. When I move something by hand, the plan reads the scene back, so the tool never undoes my work.

Buying a World on Fab

I modelled nothing. The island, the city kit, the village houses, the pirate, the guards, the tiger, the dungeon kit and the masks all came from Fab. That is normal now. What matters is what you check before you pay, because the screenshots tell you nothing that bites later.

Engine and pipeline. Unity format, in the render pipeline you use. A pack built for another pipeline is a week of pink materials.

The rig. Humanoid takes any humanoid animation, which means thousands of free clips. Generic takes only what it ships with. One of my guards came with a generic rig and no avatar, and stood still until we gave him one.

LODs and triangle counts. One palm tree carried 107,000 triangles on its third level of detail, heavier than most models' first. Eight wine bottles cost 1.1 million triangles between them. You find these with a census tool, not by looking.

The animation list, read literally. Idle, walk and run is not a character that can sit, carry or talk. Count the clips you need before the ones you like.

What the pack does not seat. My character pack shipped weapons and seated none of them in a hand. My ladder mesh had its rungs modelled along an axis no tool expected. That one comes back below.

Two AIs and a Constitution

I write the novels without AI. I build the game with two of them, and the split between them is the most useful thing in this post.

The architect is Claude in the app. One chat is one working day. It reads a handover file from the day before, we go through what the phone showed, it gives verdicts on design and feel, and it writes the day's briefs. It never touches the project.

The builder is Claude Code in the terminal, in the project folder, with a bridge into the live Unity Editor. It runs the tools, writes the scripts, runs the tests and makes the build. It never decides what the game is.

I sit between them. I read the reports, I walk the phone, I say what is wrong and what I want, and the calls that are mine stay mine: names, feel, what the world means.

Between the two sits a constitution: a file in the project root the builder reads before every task, holding the laws it may not break. Three, so you can see the shape:

"Disabled is not unloaded." A scene loads every asset it references, active or not. Retired content leaves the scene.

"Missions add, never edit." A mission is a scene loaded on top of the world and unloaded when done. Anything permanent is a flag the world reads.

"Every control works, always." Nothing a guard, an alarm, a load or a camera blend does may lock the stick or a button.

Every law was paid for. The first by a memory kill, the second by the day I nearly had two versions of the same street, the third by an afternoon when every button died the moment a guard noticed me. The file holds 28 laws and a page of working rules now, and the builder has not broken one since it was written down.

Building an iPhone Game in Unity on an 8 GB Laptop

A MacBook Air M2 with 8 GB is not a game development machine. It is the machine I have. Three rules keep it alive.

One heavy app at a time. Unity, Xcode and the builder never run together. When the phone needs a build, Unity closes first.

Build headless. The builder runs the Unity Editor from the command line with no window: a tool, a save, an exit, twenty to sixty seconds. Two lessons that cost a day each: a headless build without a graphics device gives you a player that launches on the phone and never draws its first frame, and a headless Editor that hangs on exit holds the project lock for hours. Both have a rule and a watchdog now.

The Mac must not sleep. It slept three times mid-task in one week and the builder stopped mid-sentence each time. One command in a spare Terminal tab, caffeinate. Not once since.

The Night iOS Killed the Game

On a Tuesday in September the phone killed the game twice. Not a crash. A kill. iOS ran out of memory, looked for the largest process, found mine, and ended it. The report said 215 MB free, 2.1 GB in the compressor, my game the largest thing on the device.

My first diagnosis was wrong. I had demolished 18 million triangles of temples the day before and assumed the memory went with them. I had disabled them. A scene loads everything it references, active or not, so the demolished temples were still on the phone. That became the first law.

The second diagnosis was measured. A census tool walked every asset the world referenced and added them up: 1,099 MB of meshes, textures and terrain, resident at once, because the island was one scene. No single cut would get under the line. The island had to stop being one scene.

It became a shell and districts. The shell holds what you can see from anywhere: terrain, sea, sky, the temple as a landmark, the player. Each district holds its own detail. A loader around the player brings the next district in at 60 metres and drops the last one 20 metres after you leave it. At the camp, the city is not in memory. In the city, the coast is not.

After: 1,007 MB at the camp with 1,166 MB of headroom before a kill. 1,140 MB in the city with 558 MB. On a cool phone, 120 frames a second at the camp, 8.3 milliseconds a frame. Straight off the charger, 30 frames a second from the first second, because iOS throttles at thermal serious and no code changes that. Benchmark unplugged and cool, or the numbers mean nothing.

Proof Before Build

The builder can run the game headless and play it: spawn the player, load a district, walk a route, press every button, read what happened. So every system gets a scenario, and every scenario ever written runs before every build. A build with a failing scenario is not made. That is the gate, and it is a law.

The gate refused six builds in one night before it let one through. Every refusal was a real fault my thumbs would have found a day later.

Then it taught me something about proof. For weeks every ladder passed its climb test: hands within a centimetre of the rungs, no drift, mantle onto the deck. On the phone the man climbed with his back to the wall and his hands in the air. The rungs ran along an axis the tools never expected; every ladder had stood sideways since the first was placed, and the test had measured hands against numbers the tool assumed, not against the mesh. Every test had measured air.

The law that came out of it: a proof measures what the player sees. Facing, pose, animation state, camera, sound timing. Positions alone are not a pass. And the rule under it: when my phone contradicts the harness, the harness is wrong first.

2.7 GB and Apple's 4 GB Ceiling

The build is 2.7 GB on the phone. Apple's ceiling for an iOS app is 4 GB, so it ships, but it is a big download for a demo and a bad one on a 64 GB phone.

Most of it is textures at their shipped sizes and pack content the game references but never shows. It comes down mechanically: texture caps per district, packs stripped to what is used, audio compressed, later levels streamed in rather than shipped. None of it changes what is on screen. It waits until the game is a game, because shrinking a thing still changing shape is work you do twice.

What Comes Next

The foundation is in: a living village, a way underground, a stealth rule built on light, a fight that lands where the blade is, a map that reveals as you walk. What is not in is everything that makes it a story, and that part is not for this post, because it is the part you should play.

There will be a demo before there is a game. The next post comes when the phone tells me something worth telling.

Frequently Asked Questions

Can you build an iPhone game in Unity on a laptop with 8 GB of memory?

Yes, with rules. One heavy app at a time, headless builds from the command line, a machine that never sleeps mid-task. Slower than a proper machine, and it works.

Should a solo game developer buy assets or make them?

Buy. A solo builder's time goes to systems, and systems are what fail on a phone. I bought everything visible and built everything that moves it. The Fab checklist above is the difference between a pack that drops in and a pack that costs a week.

How do Claude and Claude Code split the work in a Unity project?

Claude in the app is the architect: it designs, judges feel and writes numbered briefs, a commit after every step and a proof at the end. Claude Code is the builder: it runs in the project with a bridge into the Unity Editor, executes the brief, runs the tests, makes the build. A constitution file holds the laws neither may break. I decide what the game is.

Why does iOS kill a Unity game, and how do you fix it?

Memory. The island was one scene, so everything it referenced was resident at once, including content I had disabled but not removed. iOS ended the process at 215 MB free. A shell plus districts, loaded and unloaded around the player, fixed it.

How do you test a mobile game without playing it all day?

A headless harness plays scenarios: spawn, load, walk, press every button, read what happened. Every scenario runs before every build, and a failing one blocks the build. I walk the phone once a day, on the evening build.

How big can an iOS game be?

Apple's ceiling is 4 GB. Mine is 2.7 GB today. Texture caps, stripped packs, compressed audio and streamed levels bring it down once the game stops changing shape.

When can I play it?

There will be a demo before there is a game. No date. The next post on building an iPhone game in Unity comes when there is something new to say.

Related Reading

• I Built a Shopify App Alone in Four Weeks. The Idea Took Three Months.
• AI Agents Just Went Mainstream. What It Means for Your Store.
• AI Commerce Is Live on Shopify. 33% of Stores Haven't Even Started.