Cross-Platform Tools Are Worth Considering

Not everyone needs to write native Kotlin. Flutter, Google’s own cross-platform framework, lets you write once in Dart and ship to both Android and iOS, rendering its own UI components for consistency across platforms. React Native, built by Meta, takes a JavaScript-based approach that appeals heavily to web developers who already know React and want to apply that skill to mobile.

The honest tradeoff is this: cross-platform tools save development time and let smaller teams cover more ground, but you sometimes give up a bit of that fully native feel or access to certain hardware-specific features. For a simple business app or an MVP you’re trying to validate quickly, that tradeoff is often worth it. For something performance-heavy or deeply tied to platform-specific capabilities, native usually wins.

Backend Matters More Than People Expect

A lot of the apps people love aren’t actually doing much locally — they’re talking to a server constantly. Firebase has become the default starting point for a huge number of developers, bundling authentication, a real-time database, cloud storage, and push notifications into something that connects easily with Android Studio. It’s a genuinely good fit for solo developers or small teams who don’t want to manage their own infrastructure.

Bigger projects often build custom backends instead, using something like Node.js or Django, communicating through REST APIs. That gives more control but also a lot more to maintain. Either way, figuring out what data lives locally on the device versus what syncs with a server is one of those decisions that seems small early on but really shapes how the app feels to use, especially when someone’s connection is spotty.

Building Games: A Different Kind of Challenge

Engines Do the Heavy Lifting

Almost nobody builds a real mobile game from raw Android graphics code. It’s possible, technically, but it means solving rendering and physics problems that other people have already solved extremely well. That’s what game engines are for.

Unity remains the dominant choice for mobile, by a wide margin. It handles both 2D and 3D, runs on C#, and has a massive library of pre-built assets that can save weeks of work. A huge share of what’s actually sitting on the Play Store right now, from tiny casual time-killers to genuinely ambitious titles, was built in Unity.

Unreal Engine is the other major player, known for pushing visual fidelity further than almost anything else available, using C++ alongside a visual scripting system called Blueprints that lets people build game logic without writing traditional code line by line. It’s a strong choice when graphics are the priority, though it asks more of beginners than Unity does.

Godot has been gaining real momentum too, particularly among indie developers, mostly because it’s free and open-source with no royalty cut once your game starts making money — unlike Unity and Unreal, which have historically taken a percentage past certain thresholds. It’s especially friendly for 2D projects.

Mobile Games Live by Different Rules

Console and PC games get long, focused play sessions and precise physical controls. Mobile games get neither. People play in short bursts — waiting for a bus, killing five minutes before a meeting — and they’re doing it with their thumbs on a flat sheet of glass instead of a controller with actual buttons. Mechanics that feel great with a joystick can feel mushy and imprecise on a touchscreen, so a lot of mobile game design is really about translating intent into something that works with taps and swipes.

Battery life and heat are real constraints too, in a way that rarely comes up on PC. A game that turns someone’s phone into a hand warmer in fifteen minutes is going to collect bad reviews no matter how fun it actually is underneath. That pushes developers toward genuine optimization discipline rather than just throwing more visual effects at the screen.

Connectivity adds another wrinkle. Players lose signal on the subway. They switch from Wi-Fi to cellular mid-session. A game that leans hard on constant online connectivity needs a real plan for what happens when that connection drops, because eventually, it will.

Genres That Actually Work on a Phone

Some types of games just fit the mobile context better than others. Puzzle games are practically mobile’s home turf — easy to pick up, naturally suited to short sessions, and they translate beautifully to touch input. Idle and incremental games are a sneaky good fit too, since progress keeps ticking along in the background, perfect for someone who checks in periodically rather than committing to a long session.

Hyper-casual games — extremely simple, often built around a single mechanic — are cheap and fast to produce, which is why studios often release a bunch of them at once, betting on volume rather than any single hit. On the more ambitious end, battle royale and competitive multiplayer games have proven that complex, high-stakes gameplay absolutely can work on a touchscreen when the controls are thoughtfully designed, though they demand far more development resources and ongoing support than a simple puzzle game ever would.

Monetization Looks a Little Different in Games

Games have developed their own specific monetization habits beyond the general app playbook. Rewarded video ads — where a player chooses to watch a short ad in exchange for some in-game benefit — tend to be genuinely well-received, since the player opts in rather than having ads forced on them. Battle passes, which unlock tiered rewards through gameplay over a set period with an optional premium track, started in battle royale titles and have since spread into nearly every genre because they’re effective at encouraging both spending and sticking around.

Gacha mechanics, where players spend currency for randomized rewards, have proven extremely profitable in genres like collection games and RPGs, though they’ve also drawn real regulatory scrutiny in several countries over how closely they resemble gambling, particularly around disclosing the actual odds of getting something rare.

Whatever approach gets used, there’s a tension every game studio eventually runs into: push monetization too aggressively and you’ll spike short-term revenue while quietly damaging retention and reputation. The games that stick around tend to find a more measured balance between making money and respecting the player’s time and trust.

Testing and Publishing: Where Both Paths Meet Again

Once you’re building either an app or a game, you eventually run into the same wall: Android’s hardware diversity. Apple controls a tight, predictable lineup of devices. Android runs on a genuine zoo of hardware from dozens of manufacturers, spanning huge differences in processing power, screen size, and how recent the OS version is.

This makes testing more deliberate work than it might be on a more controlled platform. Android Studio’s built-in emulator covers a lot of ground, simulating different devices and OS versions without needing physical hardware. But it won’t catch everything — battery drain, camera quirks, and real-world performance on a budget device often only show up when you test on actual phones. Firebase Test Lab helps bridge that gap, letting developers run automated tests across a wide range of real physical devices hosted remotely, without needing a drawer full of old phones at home.

Publishing, when you’re ready, happens through the Google Play Console. It requires a one-time developer registration fee, some identity verification, and a store listing with screenshots, a description, and a content rating obtained through Google’s questionnaire. The review process checks for the obvious issues — misleading functionality, privacy violations, inappropriate content — and tends to move faster and feel less opaque than Apple’s equivalent process, though Google has tightened its policies considerably over the years around privacy and permissions, so it’s worth checking current guidelines rather than trusting outdated advice.

Mistakes Worth Avoiding Early

A few patterns show up again and again among people just starting out, whether they’re building apps or games. Trying to learn everything simultaneously — a language, a UI framework, a backend service, an entire game engine — without ever finishing a small project tends to slow people down rather than speed them up. Progress comes faster when learning is tied to something small and real that actually gets completed.

Relying entirely on the emulator and skipping real device testing is another common trap, one that usually surfaces painfully when an app or game behaves unexpectedly on an actual budget phone that the development machine never struggled to emulate convincingly. And starting with something too ambitious — an overly complex first app, or a game with five different mechanics — often means the project never actually gets finished, when a small, complete project would have taught far more in far less time.

Where to Actually Start

If you’re genuinely torn between apps and games, my honest suggestion is to pick whichever one you personally use more and care about more, because motivation matters more than most people give it credit for in the early, frustrating stages of learning anything technical.

If apps pull at you, spend a few weeks building small, complete projects in Kotlin with Jetpack Compose — a simple to-do list, a basic note-taking app, anything that lets you actually finish something and see it work. If games pull at you instead, pick Unity or Godot, work through a beginner tutorial, and build something tiny but complete, all the way through to publishing it on the Play Store.

Either direction, the same advice applies once the basics click: keep building things slightly beyond your current comfort level, get them in front of real people, and let their feedback push you forward. That’s genuinely how most working Android developers, on the app side or the game side, ended up good at what they do — not by reading more, but by shipping more.

Android isn’t shrinking anytime soon, and the tools available to build for it right now are more capable and more approachable than they’ve ever been. The platform’s there. The audience is enormous. The only thing left is deciding what you’re going to build first.