PocketBuilder turns an Android phone into the working environment for an AI software-development agent. The agent can inspect and change a project, invoke build tools and help test the installed result. Its output is source code and a real Android APK, not only a screen mockup.
The architecture has an important split: the agent’s tools and compiler run on the phone; model inference uses online services through PocketBuilder’s server. Optional connected-app services also live on the server. Keeping these roles separate explains both the product’s differentiator and its internet requirements.
1. Describe an application and create the project
Start with a project name and optional description, then enter a request in the agent tab. Explain the screens, the data to retain and a few concrete things a user should be able to do. Images can provide visual feedback, but a screenshot alone rarely explains all the interaction rules.
A request can also be a question or a diagnosis. You do not have to ask for a rewrite whenever something is unclear. When implementing, the agent uses project context, memory and a feature checklist to organize work; those aids support the process rather than guarantee completeness.
2. The agent creates or changes files
The model proposes actions and the on-phone tools carry them out. These include inspecting files, writing source and resources, and reading diagnostics. You can view the generated files rather than treating the project as an opaque answer in a conversation.
Inference requests can contain prompts, relevant source and testing screenshots. They pass through the PocketBuilder server, which handles provider access and credit accounting. Local project storage should therefore not be confused with a promise that project information never leaves the device.
3. The phone compiles the project
The current generated-app pipeline processes the manifest and resources with AAPT2, compiles Java source with ECJ and converts bytecode to Android DEX using D8. Packaging and signing then produce an APK. Build diagnostics are available to the agent so it can attempt a targeted repair.
This is a custom on-device pipeline, not a full desktop Gradle installation. Kotlin source compilation is not currently available. Dependencies also have constraints, including incomplete AAR resource merging. A project needing an unsupported build plugin cannot be made compatible merely by asking the model more insistently.
The APK creation guide explains signing and installation separately from compilation. That separation is useful when deciding whether a failure belongs to the source code, the package or the runtime.
4. Install the APK and run it
Android, not the model, controls installation. PocketBuilder needs permission to request installation of unknown apps, and system confirmation may still be required. The generated application has its own permissions; installing it does not grant blanket access to sensitive data.
A build that installs can still contain logic errors. Open the actual application, check the main workflow and confirm that the expected version is running. Preserve package and signing identity when planning updates, rather than uninstalling an old version as a routine workaround.
5. Test behavior, not just appearance
PocketBuilder offers optional automated UI testing with the required device permissions. A dedicated testing session can inspect screenshots and interact with the app; the default Fast testing option separates routine checking from the selected coding intelligence level. You can disable automated testing when human feedback is more appropriate.
Manual checks remain important. Fast-paced gameplay, accessibility, hardware behavior and subjective usability are not proven by a few screenshots. Test empty inputs, permission denial, restarting and interrupted internet access. State what happened and what should have happened when reporting a defect.
6. Modify, rebuild and test again
Ask for one focused change or a clear set of related changes. The agent can use existing source and diagnostics rather than restarting from a blank prompt. Stop the agent if the direction is wrong, then clarify the requirement before resuming.
Keep a known working version before substantial changes. Source, resources and signing material matter for recovery; an installed app or an APK alone is not a complete editable backup. Check older features after a repair so that fixing one screen does not quietly break another.
What about multiplayer and AI-powered apps?
Generated applications can use optional PocketBuilder server functionality for lobbies, shared data and server-side rules. Runtime AI integrations are separate from the agent that builds the app and require their own authorization and spending controls. Do not embed a provider secret in distributed source.
A local utility need not acquire a server dependency just because AI helped create it. Conversely, an online game needs deliberate reconnection and state handling. Describe those requirements early, including what should happen when another player leaves.
Where to start
Read the first-project guide for a manageable starting point. Compare Google AI Studio’s cloud workflow if Kotlin/Compose generation matters to you. The PocketBuilder homepage and installation guide describe the current preview, device requirements and installation warnings.