Guide · XApp Factory
More than generating page code: connect logic tables, user files, AI, multimodality, agents, resource entitlements and an app backend. Finish Preview on a real platform XApp, then decide whether to release to Run.
A Real App, Not A Mockup
"Create XApp" produces a real app, a real app_key code and a remote workspace on the platform — not a local file on the host machine. The app can call agents it is bound to or that are explicitly public; each user's conversation context is isolated by platform identity and subthread.
Continue To WeChat
Finish the XApp business and permissions first, then register and bind the mini program in the Operations Centre. Accounts, logic tables and the text agent carry over; mini-program pages use a separate native project and SDK, and binding does not convert web pages automatically.
Go to the mini-program setup guide →Install & Enter
Codex, WorkBuddy and the web workbench share one platform boundary; pick whichever entry suits you.
When it finishes, load the server-side dynamic skill as step one of this guide xapp_dev
The web side needs no plugin. Open webchat and use the app list, file management, data management, Preview / Run and the app settings drawer on the right; the conversation on the left can help with code, and every code or admin action should be explicitly confirmed.
Open the webchat workbench →First Success
Confirm which XApps you may build or manage first; create and change nothing at this point.
Agree the mobile layout, real data tables, fields, permissions and interactions before confirming creation.
After creation, have the host report the app name,app_keycode, target files and logic tables; never treat local HTML as a created platform app.
Use the platform parent container, not localhost, a file address or a private OSS URL.
Check at least missing permission, network failure, empty state, restore after refresh and the scope of user data access. Runtime reads and writes existing logic tables; table structure and permissions are set by the developer / administrator side.
Release is a high-impact action. The host should first report the target app, changed files and release method, then wait for your confirmation. Run reads a release and does not update just because code was saved.
Build With Boundaries
Preview reads the private workspace; Run reads a published release. Acceptance must record "code saved / Preview verified / Run released" separately. One-click release updates latest; a new release produces an immutable version snapshot.
asset is public material, usable through pub:/ code or a public URL, and is not billable by itself; resource is private and needs gateway authorisation. Charging also goes through resource objects, products, release and a user grant.
Prepare the private resource first, then create or reuse the exact resource object and a product draft; check price, duration and resource, and let the user confirm release. An account binding is usually a prerequisite for payment and entitlements, but does not automatically grant payment capability.
See products and operations →Use platform logic tables, not localStorage as primary storage. Runtime only touches existing tables and records; fields andpublic_read, rpm_limit code are designed by administrators, so user data is not exposed by accident.
The management entry is admin/index.htmlcode, still an XApp iframe page using XAUI, bridge and admin capability. Show only what the admin task needs, and never present runtime-visible data as the full dataset.
xapp.thread.entry.insert code is a silent record written with user consent;xapp.webchat.send code sends a message to the main webchat and triggers a reply;xapp.charagent.chat code gets an agent reply inside the XApp in an isolated subthread.
Through xapp.ai.* code asynchronous jobs you can use chat, ASR, AIR, AVR, TTS, image or video generation; poll job status and show progress, timeout, error and cancellable states. Private uploads must use controlled short-lived access and never go straight to the provider.
Use xapp.charagent.chat 与 xapp.charagent.job_getcode. The target must be an existing wxoa/wxcw bound agent that allows public calls; a shared URL must not carry someone else's private key. thread_key
The app icon uses settings.icon_urlcode (public HTTPS or pub:/code); the WeChat share title, description and image are configured through share metadata. These are different fields, and only a real WeChat test confirms what the card shows.
XApp runtime uses XAUI and targets portrait mobile first. Design input, loading, error, cancel and success states completely before adding visual detail; slow networks must never block basic interaction feedback.
Before You Release
Go to the Operations Centre guide →
