How to reuse code across apps: one foundation for my games, with real cases

Reusing code across apps means building a shared foundation (sign-in, users, payments, ads, design, sync) and writing from scratch only what makes each app unique. Done right, the second app costs a fraction of the first: Killer Sudoku Play reused most of Sudoku Play’s code, and the only new work was what makes it different.

Here’s how I built that foundation for my games, what can and can’t be shared, and what went wrong when I copied too much. If you run several brands, several products, or want a version of your app for each industry, the logic is the same.

How much was reused in each app?

The more different the mechanic, the less you reuse.

What can be reused, and what can’t?

My rule: share everything users don’t perceive as "the product"; build custom what sets it apart.

• Reused: Google and Apple sign-in, user profiles, friends system, offline sync, ads, subscriptions, base stores, design system, crash reporting, and languages (Spanish and English).
• Reused with adaptation: screens that show similar data, like stats, leaderboards, or the theme shop.
• Not reused: the game engine (or, for a business, each industry’s own logic) and the main screen’s components.
• Never copied: the identity. Name, icon, screenshots, ad unit IDs, and product codes must belong to each app.

How do you reuse without breaking what already works?

The risk with shared components is that, to fit the new app, you end up modifying the originals and breaking the previous app. In Killer Sudoku Play I used a bridge pattern: an adapter layer translates Killer’s data into the format Sudoku Play’s components expect, without touching them. That’s how I reused almost everything while writing very little new code.

Content worked the same way. Generating thousands of Killer puzzles with a single valid answer from scratch is expensive, so a script built the cages on top of Sudoku Play’s already-verified grids and graded difficulty automatically. Reuse isn’t just code: it’s also data, content, and processes.

Can several apps share the same backend?

Yes, and that’s where the biggest savings are. All my games use one server with a single database. Users and friendships live in a common space, and each game has its own space with its own tables, views, and functions, isolated from the rest. Users sign up once and use the same account across every app; in Block Drop Merge and Color Match Drop, the friends list is the same as in Block Drop Play.

And you choose what to share: Killer Sudoku Play shares XP and levels with Sudoku Play, but coins and streaks are separate. I planned this from the first app: Sudoku Play’s common space was already designed for multiple games. How to choose where an app’s data lives is in which backend fits a mobile app.

What goes wrong when you copy too much?

Three things happened to me. First, in Block Drop Play the reused code carried storage keys and purchase codes from other games: two apps on the same phone could overwrite each other’s data. I went through every affected file and renamed everything with its own prefix.

Second, Block Drop Merge kept Block Drop Play’s ad unit IDs and a generic icon, and Apple rejected it as "spam". Third, Color Sudoku Play shared so much with Sudoku Play that Apple found it too similar, and I had to redesign it completely. All three cases, and how I fixed them, are in why Apple rejects apps. The lesson: reuse the code, never the identity.

What does this mean for your business?

If you run several brands, a franchise whose locations want their own app, or a product you want to offer to different industries, think of it as a foundation plus layers. The foundation (users, payments, notifications, admin panel) is built once; each brand or industry adds its own visual identity and features.

That has two budget consequences. The first app costs a bit more, because it has to be built with reuse in mind. The next ones cost considerably less, because most of the work already exists. General price ranges are in how much a mobile app costs and timelines in how long it takes to build an app. And watch out for the stores: Apple scrutinizes mass-produced apps, so each version needs its own identity and content.

When is reuse a bad idea?

When apps only look alike on the surface. Color Match Drop reused little of Block Drop Play: forcing more would have meant bending components designed for a different mechanic. Also when reuse forces you to maintain features the new app doesn’t need. The shared foundation has to be small and stable; if every new app forces you to change it, it’s no longer a foundation.

Where’s the full story?

How I chained my first apps together, and how long it took, is in how I published my apps as a solo developer. The technical decisions behind each game engine are in how to build a mobile game.

Frequently asked questions