InternalBeyond-Mobile: A Single-File Offline Personal Site You Can Install as an App

What InternalBeyond-Mobile actually is, and who it is for

The README describes InternalBeyond-Mobile (also written IB-Mobile or IB机) as the mobile same-origin version of Internal Beyond, an offline single-file personal website application whose stated purpose is maintaining emotional continuity. That phrasing is the whole design brief. This is not a productivity tool that happens to have a chat box. It is a personal site with a lock screen, a desk, a social circle, a diary, a post office, a memory library and a vinyl player, and the AI conversations run through it rather than the other way round.

The intended user is someone who already runs the desktop Internal Beyond and wants the same data on a phone. The README is explicit that the two share one backup format and can import and export to each other, and that group chats share data with the desktop version. If you have never used the desktop project, you are still the audience, but you are starting from a colder position: the mobile build is the companion, not the origin.

It is a poor fit for anyone expecting a download from an app store. The related searches around an APK or an Android build point at a demand the README does not answer. What the README offers instead is a ZIP download and a PWA install path, which is a browser mechanism, not a package.

The mechanism: one HTML file, a browser database, and your own API keys

Everything runs client-side. The README states that all data is stored in the local browser and that the project does not depend on any network server. The repository layout matches that claim: index.html, an apps/ folder, ib-sw.js, manifest.webmanifest and two icons at the top level. There is no server directory and no backend entry point.

The AI layer is not bundled. You configure API keys yourself on the API page, and each configured API automatically becomes a friend in Chat. That means the model calls go from your browser to whatever endpoint you configured. Online features such as AI chat, web search and GitHub access need a network connection; the rest is described as offline.

The module list is the architecture, more or less. Home, Lock, Chat, Call, Circle, Calendar, Blog, Letters, Memory, Music, Coread, Cinema, Helper, ICode, Visual, API and Data are separate surfaces over the same local store. Cinema is the only one shipped as a standalone desktop app file, apps/ib-app-cinema.js, installed from the Desk app grid. Helper (水水) opens from the ? in the top right of the GUIDE page and answers questions about where a feature lives by reading the manual text.

Two details show how seriously the local-only model is taken. The lock screen configuration is stored only on the phone and is not read or written by the desktop version, and the README says plainly that it guards against someone picking up your phone, not against an attacker. The password diary is isolated from public logs and invisible to all APIs. Those are boundaries drawn inside the app, not by a server.

Installing it from the ZIP and adding an API key

There is no package manager step. The README's getting-started section is four lines: download the repository as a ZIP, unzip it, keep index.html and the apps/ folder in the same directory, and open index.html in a phone or desktop browser, with Chrome recommended. Opening the local file gives you the full offline feature set.

If you would rather fetch it with git, the repository is public, but the README does not give a clone command, so the ZIP route is the documented one. After unzipping, the directory should look like this, because index.html loads the Cinema app from the apps/ folder at runtime:

ls
# COPYRIGHT.md  LICENSE  README.md  apps  ib-sw.js
# icon-192.png  icon-512.png  index.html  manifest.webmanifest

The next step is the API page. The README says to enter the API page, add your AI API key, and start using it. Each key you add becomes a friend in Chat, and per-friend settings such as nickname, relationship, prompt and per-item permissions live in the API configuration center alongside global settings for the voice call system, memory system, output and continuation, and advanced instructions.

To turn the page into something that behaves like an installed app (home screen icon, fullscreen, offline cache, system notifications), the README points to a PWA deployment and installation section. The repository carries the pieces that section relies on:

ls manifest.webmanifest ib-sw.js icon-192.png icon-512.png

The manifest and the service worker ib-sw.js are what make the install prompt and the offline cache possible. The README does not document a rollback path for the service worker, so if you update the files later, clear the site data or unregister the worker in your browser if you see stale content.

Where it breaks: storage, service workers and the absence of releases

The first limitation is the storage model itself. All data lives in the browser. Browser storage is per-origin and can be evicted, and opening index.html as a local file versus serving it over HTTP can produce different origins with different storage. The README's answer to this is the Data page: one-click backup with a full-site JSON export and import, plus chat history management, a token usage dashboard and a storage overview. That is a manual safety net. There is no documented automatic sync, and no server-side copy exists by design.

The second is the PWA layer. A service worker caches assets, and the README does not describe a versioned update or rollback procedure. If you edit files under a registered worker, you may be served the cached copy. Nothing in the repository layout suggests a build step that would handle cache invalidation for you.

The third is maintenance signalling. The last push to the repository was on 2026-09-16, which is recent, and the repository is not archived. But no recent releases were retrieved, and the README carries no changelog or version table. The only version marker anywhere in the text is a prompt revision, v169-p, mentioned in the call section. If you need to know what changed between two points in time, there is no documented way to find out.

The fourth is the AI dependency. Offline use is real for the local modules, but Chat, Call, Circle, Letters, the memory summarisation and the Helper all lean on an external API you supply. Without a key, a large part of the feature list is inert. The README also notes that GitHub access from ICode uses a PAT directly from the browser, which puts a long-lived credential in local storage.

Finally, the licence file is present but the repository metadata reports NOASSERTION. You can read LICENSE and COPYRIGHT.md, but no recognised identifier is given, so treat redistribution as an open question rather than a settled one.

The real alternative is the desktop build, not another app

The obvious comparison is InternalBeyond, the desktop version linked from the README. The difference is not features, it is where the data sits and how you use it. The desktop build is the origin of the format; the mobile build is the same-origin companion that imports and exports the same backup file. The README states that the two share one prompt set (v169-p onwards is described as the reviewed version), one repository naming table, and normalised camera quality tiers, so a configuration moved across does not lose settings.

That symmetry cuts both ways. If you only ever use the phone, you are running the companion without the thing it is a companion to, and the cross-device continuity that justifies the shared format never gets exercised. If you use both, the mobile build is the better answer than any generic note-taking or chat app, because a generic app would not read the same JSON.

Against a self-hosted web app, the trade is different in kind. A self-hosted app puts the data on a machine you control and reaches it over the network; InternalBeyond-Mobile puts the data in one browser profile and reaches nothing. The first survives losing a phone. The second survives losing a server. Pick the failure you would rather have.

Maintenance, upgrades and what the licence does not say

Upgrade cost is low in the mechanical sense and high in the procedural sense. There is no package to update and no migration script. You replace files. The risk sits in the browser: a registered service worker can serve cached assets, and local storage holds everything the app knows. Before replacing index.html or anything under apps/, export from the Data page. That export is also the only documented way to move data between the phone and the desktop build.

Because there are no releases, there is no upgrade path documented anywhere in the README. You cannot diff versions, and you cannot tell from the repository listing whether a given change touches stored data. The README does describe one behaviour that matters for cross-version safety: deleting a call's end card removes the marker and returns the original transcript to context, and the README says both ends behave the same against the same database. That is the kind of guarantee you want more of, and it is stated for exactly one feature.

On licensing, LICENSE and COPYRIGHT.md are both at the top level, but the repository metadata reports NOASSERTION rather than a recognised identifier. Read those two files before you redistribute anything, and do not assume the project is permissively licensed just because the source is readable. This is not legal advice; it is a note that the identifier is missing.

Editorial conclusion

Adopt it if you want a personal, offline-first site whose data lives in your own browser and whose AI features you pay for through your own keys, and if you are willing to treat the JSON export as the only real backup. Do not adopt it if you need a hosted service, a native APK from a store, or a project with a documented release and upgrade process. Verify first that index.html and apps/ stay in the same directory after unzipping, that your browser supports PWA installation, and that you can complete one Data page export and re-import before you put anything you care about into it.

Frequently asked questions

Official sources

1. Issues
2. README
3. Sui-IB/InternalBeyond-Mobile on GitHub