How to Make a Mobile Game and Actually Publish It

Most guides on how to make a mobile game skip the part that actually trips people up, and it isn't the code. Here's the blunt version up front. Building the game is the same work as building any small game, a loop, a bit of art, a way to win and a way to lose. What turns it into a mobile game is everything that happens after you finish, and that after is where the real cost hides. You need at least one store account, which costs money. You need to rebuild your controls for thumbs. And you have to sit through app review before a single stranger can tap install.

I build and ship small games in Godot, mostly on the web, and I'll be honest that I'm not sitting on a mobile hit. But I've mapped the mobile path closely enough to tell you where the money and the friction actually go, which is more than the top results managed the day I checked. The cheap, sane way to start is a tiny game in a free engine, published to Android first, because Android is a one-time twenty-five dollars and Apple wants ninety-nine every single year. More on that in a minute.

What Mobile Actually Adds Over a Normal Game

I checked the top ten before writing, same as always. Reddit was sitting at position two, somebody in a game dev sub asking this exact question and getting the usual scattered answers. Quora a few slots down. A Facebook group after that, then a forum thread. When forums outrank the polished articles, it usually means the articles dodged the real question, and the real question here was never "which engine." It's "what does mobile cost me that a desktop game didn't."

So here's that list, the stuff nobody bothered to put in a table. A desktop or web game, you finish it, you upload it to itch.io for free, and you're done. Mobile bolts four extra things onto the end. A paid developer account, sometimes two of them. Controls rebuilt for a touchscreen with no keyboard anywhere. A signed build, which is its own little headache the first time you meet it. And a review queue, where a reviewer or a bot at Apple or Google decides whether your thing goes live, on their schedule and not yours. None of it is hard, exactly. It's just work the "build a game in a weekend" videos pretend isn't there.

The Two Store Accounts, and What They Really Cost

Let me put the fees where you can actually see them, because I had to open both official pages myself to get straight numbers, and not one ranking page carried them.

Apple charges ninety-nine dollars a year for the Apple Developer Program, and I confirmed that on their enrollment page the day I wrote this. A year, recurring. Which means if your game sits on the store earning nothing, you're still paying that 99 every twelve months just to keep it listed. Google Play is a one-time twenty-five dollar registration fee. Pay it once, and the account is yours after that, no renewal, same official-page check. That difference is small in dollars and big in what it does to a beginner's head.

The gap matters more than it looks on the page. For a first tiny game that might make zero, a recurring ninety-nine a year is a slow leak you'll resent, and a one-time twenty-five is basically a coffee tab you forget you paid. That's the whole reason I'd point a beginner at Android first and only add Apple once there's an actual reason to. Both stores also take a cut of any sales on top of the account fee, commonly cited around 30 percent and dropping to roughly 15 percent for small developers who qualify for the reduced programs, though I'd check their current terms rather than trust a blog, this one included.

Pick a Beginner Engine, Then Quit Shopping

Engine threads will eat your first week if you let them, so I'll keep this short and then tell you to move along.

Godot is the one I use. Free, open source under the MIT license, no royalty ever, and it exports to both Android and iOS straight out of the editor. That's the practical reason it's my default. You own the whole thing and nobody takes a cut on the way up. If you'd rather not touch code at all, GDevelop actually runs on an Android phone or tablet directly, so you can build a simple game on the same device you'll play it on, which is kind of wild and genuinely fine for something small. Scratch is the other no-syntax option, block based, free, perfect if you or a kid just wants to watch a thing move on a screen. You'll hear Unity and Unreal named constantly, and they're powerful, but they're a heavier lift than a first tiny mobile game needs, and both attach revenue thresholds and royalties you can read up on later, once you have revenue to worry about.

Making a mobile game without coding is a real path, by the way, not a fib the marketing tells. GDevelop and Scratch both get you there. You trade away some ceiling for a much shorter runway, and for game one that's the right trade every time.

A First Mobile Game, Scoped Honestly

How long does the mobile version really take? Longer than a web build, and the extra hours nearly all live in the publishing tail, not the game.

Build the same tiny thing I'd tell anybody to build. One screen, one thing you control with a thumb, one way to win, one way to lose. A block you drag to dodge falling blocks. A tap-to-flap bird knockoff. Ten minutes of play, tops. Here's roughly where the hours went when I scoped a mobile release, with the desktop rows squashed together since I've written about those before, and the mobile-only rows spelled out, because those are the ones no guide ever times for you.

Add it up and a genuinely tiny first mobile game lands somewhere near 18 to 25 hours for a first-timer, and notice a solid third of that is publishing, not making. Those are honest guesses, not a promise, and yours will wander depending on what you already know. But the shape is the point. The game was a weekend. Getting it onto the store ate most of a second one.

Touch Controls Are the Part You'll Underestimate

Thumbs are not a keyboard. That's the whole lesson, and I still relearn it on every build.

A keyboard hands you dozens of precise inputs. A phone hands you a fingertip that covers a chunk of the screen, no hover, no right-click, and a hand that's busy blocking the very thing you're trying to look at. So the control scheme has to shrink down to almost nothing. One tap. A drag. Maybe a swipe if you're feeling fancy. If your game needs more than about two kinds of input, it probably isn't a mobile game yet, or it needs rethinking until it is. Budget real time here, because it reliably takes longer than the two hours you'll assume it will.

Where AI Helps, and Where It Won't Save You

I lean on AI for the boring middle of all this, and I run most of it locally. On my MacBook with an M4 Pro, a placeholder sprite or a rough app icon lands in something like fifty seconds and costs me basically nothing past the electricity, so I'll roll forty icon ideas and bin thirty-nine of them without thinking twice. A coding assistant handles the plumbing too, the touch input handler, the save system, the ad-SDK wiring that's near identical across ten thousand apps.

What it won't do is the judgment. It can't tell you the tap target is too small for a real thumb, because it has never missed one. It can't tell you the game is boring, because it has never once been bored. And it will not carry you through app review or the grind of screenshots, because it has no stake in your thing ever shipping. If you want the long version of that split, I laid it out in the pillar on how to make a game with AI without letting it build the game for you, and the specific tools I keep open are in the AI game dev tools a solo dev actually uses. For mobile, just hold onto this. The help front-loads into the making and then evaporates, right about when the publishing slog begins.

The Money Question, Answered Honestly

People keep asking whether you can pull a hundred bucks a day from ads in a mobile game. I get why, the search box is stuffed with it. Here's the honest read. It's possible, and it's rare, and it's almost never a first game.

There's a brutally honest write-up from a solo dev who quit his job to make one, and I keep coming back to it. Around four thousand installs, roughly a thousand dollars in total revenue, against about twenty-five hundred spent on marketing. Underwater, in other words, after a genuine effort. Ad revenue on small games tends to run a few dollars per thousand full-screen views, so a hundred a day means tens of thousands of daily impressions, which means a real audience you simply do not have yet. Make the first game to learn how to ship a mobile game at all. Money is a later game, and mostly a distribution problem rather than a making one. And no, before the search box asks, your first game does not cost a billion dollars. Those numbers belong to AAA studios with hundreds of staff, not you and a couple of weekends.

Straight Answers to What Google Autofills

A handful of these autofill under every search, so here are plain answers.

Can I make my own game right on my phone? For something simple, yes. GDevelop runs on Android and lets you build and export from the device itself, and Scratch works in a mobile browser. You'll hit a wall fast for anything ambitious, but a first tiny game, genuinely, you can do on the phone in your hand.

Is making a mobile game easy? The game part is as easy or as hard as any small game, which is to say the first week is rough and then something clicks. The publishing part is the new difficulty, and it's less "hard" than tedious and full of forms.

How do I make a mobile game for free? Free engine, Godot or GDevelop or Scratch. Free placeholder art you generate or draw yourself. The one thing that isn't free is the store, twenty-five once for Google, ninety-nine a year for Apple. You can build and even test the entire game without paying a cent, and only pay when you're truly ready to publish.

iPhone or Android first? Android, for most beginners, purely on the fee. A one-time 25 to reach the Play Store beats 99 every year to reach the App Store back when you don't even know if anyone wants the game. Add iOS later if it earns the ninety-nine.

How do I publish it to the Play Store? Once the account is paid for, you upload a signed release build, fill in the listing with an icon and screenshots and a privacy policy, set it to a release track, and submit for review. Google's review tends to move quicker than Apple's, though both run on their own clock and neither one hurries for you.

Just Ship the Small One

If you keep one thing from all this, keep the scope, same as with any game.

Mobile doesn't change the real lesson, it just adds a toll booth at the exit. So build something almost embarrassingly small, get the touch controls feeling right on an actual phone rather than in the editor, pay the one-time twenty-five to put it on Android, and drag it through review until a stranger can tap install. That whole loop, done once, teaches you more than reading another ten engine comparisons ever will. Your first mobile game won't make money, and it probably won't be good. Ship it anyway. Finishing is the part that carries to the next one, and the store, annoying as it is, is really just the last few steps of finishing.