The stack that made it possible

Python was less a choice than the only realistic option. There is no Android Studio for Android, no Gradle you can comfortably drive from a touchscreen. But there is a working Python environment.

• Pydroid 3 — a full Python 3.13 interpreter with a usable editor. This is where code gets written and tested first.

• Kivy 2.3.0 + KivyMD 1.2.0 — the UI layer. Renders identically in Pydroid and in the final APK, which matters enormously when you can't debug on a desktop.

• GitHub Actions + Buildozer + python-for-android — the build pipeline. You cannot compile an APK on a phone. You push, CI builds, you download the artifact.

• SQLite — local storage, no server involved.

The critical insight: development and build are separated. The phone writes code, GitHub compiles it. Once you accept that split, a lot becomes possible.

What genuinely works better than expected

Iteration in Pydroid is fast. Faster than waiting on a Gradle sync, honestly. You edit, you run, you see the result. For UI work with Kivy this loop is tight.

GitHub Actions is a complete substitute for a local build machine. A push triggers Buildozer, which runs python-for-android with the sdl2 bootstrap and produces builds for arm64-v8a and armeabi-v7a. Twenty minutes later there's an APK waiting. You never touch a terminal.

Copy-paste is a legitimate workflow. Working with an AI assistant through a browser chat window, file by file, sounds primitive. It is primitive. It also works — the project reached 64+ files and roughly 26,600 lines this way. The constraint forces something useful: you have to actually understand the architecture, because nothing is auto-imported for you.

Where it breaks

Being honest about this matters more than the success story.

Native libraries are the hard wall. When Android 15 introduced the 16 KB page size requirement, the fix lived inside python-for-android's native build layer. That is not something you resolve by pasting files into a chat window. That single problem required a proper agentic coding tool with terminal access — the one genuine exception in the whole project.

p4a has constraints you must design around. Three that cost me real time:

• SQLite ships without FTS5. No MATCH, no bm25(). Full-text search has to be built on LIKE and manual fragmentation.

• requests must be imported inside methods, not at module level, or the app can fail to start on some devices.

• File paths are restricted to getExternalFilesDir. Writing to /storage/emulated/0/ directly is blocked by Scoped Storage. Every path in the codebase has to respect this.

Two environments, one codebase. Code must run in both Pydroid (Python 3.13) and the packaged APK (Python 3.11 via p4a). Version differences surface in irritating places.

Debugging a release build is painful. No adb logcat on hand, no breakpoints. You log to a file, read the file on the device, and reason backwards.

Practical advice if you try this

Set up CI before you write real code. If the pipeline isn't proven on day one, you'll discover packaging problems weeks later with hundreds of files already written.

Keep files small and single-purpose. When your entire code-transfer mechanism is copy-paste, a 2,000-line module is a genuine obstacle. Small modules are not a style preference here — they're a hard requirement.

Write the constraints down and re-read them. I keep a plain-text file listing every p4a limitation, path rule, and import quirk. It gets re-read constantly. Working without an IDE means the tooling won't catch mistakes for you.

Test on the weakest device you own. Kivy's performance ceiling is lower than native. Something smooth on a mid-range phone can stutter badly on an older one.

Was it worth it?

The app is on Google Play. It passed a 14-day closed beta with 19 testers. It runs on Android 7.0 and up.

The interesting part isn't that it's possible — it's that the barrier turned out to be far lower than assumed. A phone, a free CI runner, and a browser tab cover most of it. Not comfortably, and not for every kind of project. But the assumption that you need a desktop to build and ship real software is worth questioning.

If your only machine is the one in your pocket, that isn't automatically a dead end.