Platform Limitations
The platform gives apps powerful building blocks while keeping security, privacy, reliability, and user control at the center of the experience.
Why Limits Exist
Some platform boundaries are intentional. They protect user data, keep apps installable and shareable, and make sure features such as AI credits, visibility, and notifications behave predictably for every user.
Distribution and Portability
Apps live on the platform and are accessed through shareable links. You can publish and sell apps through the built-in platform flows, but apps cannot be exported as standalone products or distributed outside the platform.
The generated app code is accessible to you as frontend React code, but it uses platform-specific hooks and APIs. You cannot directly export an app to GitHub or run it outside the platform. You can copy the code as a prototype or starting point for other app builders or AI coding assistants.
Apps are web apps that can be installed on phones from the browser as Progressive Web Apps. The platform does not support native iOS or Android development, and apps cannot be published to app stores.
Data, Accounts, and Collaboration
Each user has their own private database for each app. When someone else uses your app, they see and manage their own data, not yours.
User accounts, login, and authentication are handled by the platform. Apps do not need, and cannot replace, the platform auth system with a custom login system.
Apps are built for individual use. Real-time collaboration, shared editing, and multi-user shared workspaces are not currently supported.
App visibility controls who can access the app, but it never exposes private user data.
Development and Integrations
AI capabilities are built into the platform. Apps cannot connect custom third-party APIs or services.
Apps use the platform's curated component library instead of arbitrary external packages. This keeps apps stable, secure, and consistent across the platform.
Apps run in a secure sandbox. External links open as copyable text instead of opening new browser windows directly.
Google Maps embeds can display locations, but interactive mapping libraries are not available.
QR code generation and scanning are not currently supported.
Apps cannot bypass browser notification permissions or per-app notification settings. Push notifications are scheduled deliveries, not a replacement for instant in-app feedback.
AI model access is limited by the user's plan. Pinning a specific AI model disables automatic fallback for that request.
Publishing and Monetization
You can sell apps through the built-in monetization system with no platform commission. Third-party payment processors, custom checkout flows, e-commerce integrations, and external subscription billing are not supported.
Buying an app gives someone access to use that app. It does not give them access to view, modify, fork, duplicate, or export the app's source code.
Designing Around Limits
Build apps that explain disabled states clearly. If notifications are off, point users to the Notifications button. If an AI model is unavailable for a user's plan, offer a lower-tier option or explain that an upgrade is required.
For major updates, publish smaller changes when possible so data migrations stay easier to reason about.
When You Need More
If your app needs a capability that is not available yet, describe the desired user outcome in the editor. The AI can often suggest a supported pattern or alternative design.
For implementation details on supported capabilities, start with the Reference.