Why Fulldive Ships Many Small Apps Instead of One Mega App

Written by the Fulldive product engineering team, based on direct inspection of the repositories listed below.

Fulldive does not ship a single mega app. The Fulldive apps page lists more than a dozen separate Android apps: a browser, a VPN-style ad blocker, a no-root firewall, a game console emulator (free and Pro), an SMS forwarding utility, a VR video player, a storage cleaner, and a new AI agent. Each one is its own Google Play listing, its own package ID, and its own git repository. This post explains why, using evidence from the repositories themselves.

This is the long version of the short explainer in What are Fulldive extensions?.

The extensions model in one sentence

A Fulldive extension is a standalone Android app that carries the Fulldive brand, lives under the com.fulldive.extension.* package namespace, integrates with a main Fulldive app where it makes sense, and routes support back to a shared Discord community plus support@fulldive.com. The ecosystem is a set of small, focused apps rather than one bloated client.

The Fulldive company story walks through the history of that choice. This post looks at what it costs and what it buys, per repository.

Evidence 1: Full Cleaner’s content-provider wiring

The clearest artifact of the “extensions that cooperate with a main app” design is in fulldiveVR/FulldiveExtension.JunkRemover (Full Cleaner, package com.fulldive.extension.cleaner).

In June 2021, two commits encode the pattern:

6a42c35 adds content provider permissions so the cleaner can be queried by another Fulldive process.
bb1523b adds a permission check so the cleaner can be launched from the main app.
fde533f ties it all together: app ID change, content provider permissions, launch from main app, and handling for the Android SDK 30 permission model.

A monolithic app would not need any of this. You only need content-provider permissions and cross-app launch paths when the cleaner is deliberately a separate APK that still wants to light up when the user opens the main Fulldive experience. That is the model — and the release series continued through c2a9d6c (1.0.1) and on to 52c307f (1.0.8).

Evidence 2: Dive SMS rebranding out of the main app

Full Cleaner was extracted once. WizeSMS went through the same move. In the Dive SMS repository (fulldiveVR/DiveSMS, package com.fulldive.extension.divesms), commit ee815c80 — pinned in our notes as ee81 / ee815c80 — is the Dive SMS rename itself, with fd5a1ae9 immediately after removing payments and bumping to 1.0.1, and a97c5069 bumping to 1.0.3 with copyright updates.

The point is not the rename. The point is that an SMS app with 2,474 commits of history, much of it pre-dating Fulldive, became a Fulldive extension by changing its identity (ee815c80 / internally tagged ee815c80 on our side) rather than being absorbed into a single giant Fulldive client. The reliability work that followed — 68ecf707 on MMS/SMS fixes, 3838a63b on the default SMS warning banner, 0f382e4a on SMS/MMS debugging — stayed in one focused codebase. (See WizeSMS history: messenger to forwarding for a lighter overview.)

The SMS app is a single-responsibility app. It does SMS and MMS and forwarding. It does not carry a browser or a firewall with it.

Evidence 3: One Emulator keeps its own branding

The emulator followed the same approach. In FulldiveExtension.FullRoid (packages com.fulldive.extension.fullroid and com.fulldive.extension.fullroid.pro), commit 8a356db8 is the Fulldroid branding and multilingual string update that aligned the app’s internal name with the extension family while keeping it a standalone product. Version 1.8.3 (3f31c74f) shipped shortly after, version 1.9.5 (5e265141) followed in early 2026, and the free game catalog (809ab678) was pushed out via a separate repository, fulldiveVR/FullRoid.Games, to keep the emulator APK itself small.

Shipping the game catalog from a second repo is the same idea one layer deeper: even inside a single product, Fulldive prefers splitting concerns over bundling. The emulator does not have to ship a games index built-in; the catalog can evolve without forcing an APK update.

Evidence 4: Support lives in one place, linked from each app

A catalog of small apps could be a usability disaster if support were fragmented. Fulldive’s answer is to centralize it. In late 2025 through early 2026, the same pattern appears in three separate repositories:

DataGuard: 60546414 added the Fulldive Discord community link to the app.
One Emulator: c8952402 added the same Discord link.
WizeSMS: dfc606b3 added the Discord link too.

Three apps, three repos, one support destination. The same rule applies to email: every Fulldive extension routes to support@fulldive.com. We wrote this up in more detail in the ecosystem post on Fulldive support and Discord routing. If you install four Fulldive apps, you do not end up with four support contacts.

Why not just build one app

We get this question often, so here are the tradeoffs we actually weigh.

The case for one mega app: simpler installs, one update channel, shared code loaded once, one icon on the home screen, easier brand recognition.

The case for many extensions (what we picked):

Google Play treats each listing independently. An SMS app must request default-SMS status and SMS permissions. An ad blocker runs as a local VPN. A firewall also runs as a local VPN. A browser is a browser. Bundling those into one app would require asking for every permission up front, which is a worse privacy experience and a harder Play Store review.
Two local-VPN apps cannot run at once. Android only allows one app to hold the VPN service. That means Wize AdBlock VPN and DataGuard cannot share a process. Shipping them as separate apps is not a design preference; it is a platform reality.
Users only install what they want. Someone who wants the emulator does not need the firewall. Someone who wants SMS forwarding does not need VR.
Platform changes hit smaller blast radius. When Android required 16 KB page alignment and SDK 35/36 in 2025, each extension did its own upgrade — AdBlock VPN’s ead5d3b1 and SDK 36 bump b8315876, DataGuard’s 2821d5e0 and b2af3518, One Emulator’s acf79d78 target SDK bump — and a problem in one did not block releases on the others. See 16 KB page size, SDK 35/36, and the Android platform changes Fulldive absorbed for the full cross-repo sprint.
Independent codebases can move at different speeds. LikeClaw shipped from first commit to TestFlight in about seven weeks. That pace is only possible because the AI agent is not welded to the browser release train.

The cost: more app listings to maintain, more repositories to keep green, and more support paths that have to be kept consistent. Those are the exact things the commits above are working on.

What counts as a Fulldive extension

If you are trying to read the catalog, here is the practical rule we use internally:

Package starts with com.fulldive.extension.* (with a few historical exceptions like com.fulldive.mobile for WizeUp and in.fulldive.shell for Fulldive VR, since those predate the extension namespace).
Repository sits under fulldiveVR/ on GitHub.
App links to the shared Discord and to support@fulldive.com.
Release notes and version history trace back to the Fulldive team.

That covers every app on the projects list today. Short reads on a couple of individual extensions: Wize AdBlock VPN, One Emulator for Game Consoles, Fulldive VR, and the browser now known as WizeUp.

Limits and caveats

This post describes an engineering and distribution pattern, not a privacy or security guarantee. The fact that apps are separate processes does not by itself mean any given Fulldive app blocks all ads, protects all traffic, or is safer than a competitor; each app has its own limitations that we cover in its own post. Some older apps in website/data/apps.yaml still need package-level repository confirmation, and a few (Full Cleaner being the main one we flagged) have had store-listing availability issues on 2026-04-13 that we are tracking separately in Full Cleaner availability and transparency. Commit hashes are abbreviated and may resolve to different full SHAs if repository history is ever rewritten.

External references: Android Developers — target API level requirements and Android Developers — 16 KB page size.

Last updated: 2026-04-16. Commit hashes and version numbers are drawn from Fulldive repositories inspected on 2026-04-13.