How to Build a Mobile App with Claude Code and Huxly MCP
Contents
Claude Code can work directly inside a Huxly mobile project through MCP. You give Claude Code the product brief; it can read project files, change code, run the Huxly sandbox, inspect build output, and return a preview link. Huxly supplies the project and build environment. Claude Code supplies the coding agent.
This guide builds a small job tracker: a worker creates a job, updates its status, and checks the list on a phone. The workflow also applies to a booking app, inventory tool, or client portal. We'll use the documented connection and show exactly where to stop and test before adding more features.
- Claude Code uses a Huxly API key and Huxly's HTTP MCP endpoint; the Claude.ai directory connection is a different setup. - Start with one user journey and ask Claude to inspect the Huxly project before changing files. - Preview each meaningful change, inspect build and runtime logs, and test the app on a device. - Keep your MCP key private because it grants access to your Huxly projects.
What you need before connecting
You need a Huxly account on a plan that includes the AI Connector, Claude Code installed and signed in, and a short description of the app. Huxly's AI Connector documentation currently lists Developer, Business, and Max as eligible plans. Check that page when you set up, since plans can change.
Write down the first journey before you open Claude Code. For our example: a worker opens the app, creates a job with a title and customer, sees it in the job list, then marks it done. Name the data that must persist and who can change it.
Generate a Huxly API key
In Huxly, open Settings, go to the MCP tab, and generate an API key. Copy it when shown and store it somewhere private. The Huxly docs say the key is shown once and has broad access to your projects.
Use a separate key for each AI tool so you can revoke one connection without breaking another. Never paste a real key into a public prompt, screenshot, or repository.
Connect Claude Code to Huxly
Claude Code uses the Huxly MCP endpoint at https://huxly.app/api/mcp with an Authorization bearer header. The Huxly setup guide shows the server configuration. If you prefer the Claude Code command line, Anthropic's MCP instructions describe the HTTP transport and header option.
A setup example looks like this:
Replace YOUR_API_KEY locally. Your shell may record commands in history, so use the Huxly-documented configuration route or another secure credential method if that matters for your setup. Restart Claude Code if needed and run /mcp to confirm Huxly appears.
Do not use the Claude.ai directory instructions for Claude Code. Huxly documents those as separate connection methods.
Verify access with a harmless request
Ask: "List my Huxly projects and tell me the framework for each. Don't edit anything."
If Claude can list the projects, the connection is working. If you see an authentication error, check the key and the Authorization header. If no Huxly tools appear, check the MCP configuration and restart Claude Code before debugging the app itself.
This first request is read only. It tells you whether you have an MCP connection or just a coding assistant with no access to the actual project.
Pick Expo, Flutter, or SwiftUI
Huxly's MCP tools can create a project in Expo, Flutter, or SwiftUI. Choose the framework that fits the release plan. Expo is a useful first choice for the iOS and Android job tracker; SwiftUI suits an iOS-focused app; Flutter is another route for a shared mobile codebase.
Decide before asking Claude to create files. A prompt that leaves the framework ambiguous can produce code for the wrong environment. Huxly's framework guide can help, but check the live project setting if a project already exists.
Give Claude a build brief
Use a brief with the user, journey, screens, states, and boundaries. For example:
Create a Huxly Expo project for a small field team. A signed-in worker can create a job with a title, customer name, and notes. Show jobs in a list grouped by status: open, in progress, done. A worker can update only jobs assigned to them. Start with the create, list, and detail screens. Explain the data model before writing code. After each change, rebuild and show me the preview.
This prompt prevents an impressive home screen from hiding a missing workflow. If roles are not needed in your app, remove them and keep the first version smaller.
For more on scope, see Huxly's product brief guide.
Ask Claude to inspect the project first
For an existing project, have Claude use list_projects, list_files, and read_file before writing. These are Huxly MCP tools described in its docs. This protects navigation, state handling, and existing conventions from an unnecessary rewrite.
A good instruction is: "Read the relevant files and tell me which ones you will change. Preserve existing navigation and auth unless the new journey requires a change."
For a new project, ask Claude to create it, return the project ID and framework, then inspect the generated files before adding features.
Build one complete path
Have Claude implement create job, list jobs, open details, and change status. Make it persist data rather than displaying three hard-coded sample jobs.
Define states explicitly:
| State | What the user should see |
|---|---|
| No jobs | A short explanation and a Create job button |
| Saving | The action is in progress and cannot be submitted twice |
| Save failed | Existing form values remain and Retry is available |
| No connection | A clear message about what can wait |
| Access denied | The user cannot view another worker's private job |
The saved record should include an owner or assignment ID, creation time, and status. Ask Claude to confirm which service owns those records and what protects access on the backend. A hidden button is not a permission check.
Run the Huxly preview loop
The documented MCP workflow uses start_sandbox to start the preview, update_sandbox after changes, get_build_logs and get_runtime_logs for errors, and get_project_url for the dashboard link.
Tell Claude: "Update the sandbox, read the build result, fix any build error, then return the Huxly preview URL. Tell me what you verified and what still needs testing."
A green build means the code compiled. It does not prove that saving, sign-in, permissions, or the UI work as intended. Open the preview and do the full journey yourself.
Diagnose failures from evidence
If the preview is blank, ask for the build logs and runtime logs before requesting a new screen. If saving fails, inspect the network or backend response and the stored data. If a button works only on one device, test touch targets and navigation on the other platform.
Keep requests specific: "Create job saves, but the new job does not appear in the list until restart. Read the relevant state and fetch logic, fix that behavior, rebuild, and report the files changed."
That is more actionable than "make the app work."
Add backend and privacy checks
Before adding customer names or files, decide where records live and who can read them. Huxly's connector handles project files, backend operations, and deploys, but its docs say it does not read your database by itself. If Claude needs to inspect a live Supabase schema, Huxly suggests connecting Supabase MCP alongside it.
Do not give a coding agent unrestricted database access just to complete a UI task. Check authentication, access rules, secrets, and error messages for the specific journey. If the worker can change a URL or request to see another worker's job, the authorization rule needs work.
Test on a real device
After the preview works, check:
- Create a job, close the app, and reopen it.
- Enter empty or unusually long text.
- Tap Save twice quickly.
- Try an account that should not see the job.
- Interrupt the network during Save.
- Open the list on a smaller screen.
- Repeat the main path on each platform you plan to release.
Expo's AI agent tutorial also emphasizes prompting, previewing, verifying, and correcting on a phone. That loop matters even if Huxly handles the sandbox.
Prepare the store release
When the workflow works, decide the app name, icon, bundle identifier, privacy details, and test accounts. Then create a release build, test the signed build, and follow the Huxly publishing steps for App Store submission or Google Play.
Do not let Claude call the app "production ready" based only on a sandbox screenshot. Check sign-in, data access, crashes, and the exact build you plan to distribute. A TestFlight or internal test is useful before a public launch.
Build through Huxly from Claude Code
Huxly lets Claude Code work against the real mobile project through MCP: read files, edit code, rebuild in the sandbox, inspect logs, and hand back the preview. Start with a narrow brief, connect the API key, and build one working journey you can test. The Huxly MCP guide has the current setup steps.
FAQ
Can Claude Code build directly in Huxly?
Yes. After you connect the Huxly MCP server, Claude Code can use its project and file tools, start or update the sandbox, inspect logs, and return the project URL. Access depends on your Huxly plan and key.
Is Claude Code the same as Claude.ai for this setup?
No. Huxly documents a directory sign-in for Claude.ai and an API key connection for Claude Code. Follow the Claude Code section when using the coding tool.
Does the MCP key use Huxly AI credits per message?
Huxly says the AI inference runs on your own AI subscription; its MCP documentation says it does not consume Huxly credits per message. Check the current Huxly plan for infrastructure and build limits.
Can Claude Code edit an existing Huxly app?
Yes. Ask it to list and read the relevant project files first, then make targeted changes. Test the rebuilt preview before accepting a larger refactor.
Does a working preview mean the app is ready for the App Store?
No. Test a release build, permissions, privacy, failures, and store information. The preview is a fast feedback loop, not the final release review.
Do I need to set up Expo locally?
The Huxly MCP workflow can create and update a Huxly project and run its sandbox through Claude Code. Local Expo setup is optional for this workflow; follow the project's needs if you also want to work with the code locally.
Conclusion
Connect Claude Code to Huxly, choose the project framework, and describe a single complete user journey. Let the agent inspect files, make focused edits, and rebuild. You check the result on a phone and ask for fixes grounded in logs and actual behavior. That is how an idea becomes a mobile app you can test, rather than just a screen that looks finished.
