Mobile
Mobile is a core supported Virex path, with its own continuation flow
Virex supports both web and mobile product generation where relevant. Mobile should be understood as a real supported product path with Expo-ready continuation, app-oriented testing, and honest setup guidance — not as a side note hidden behind web-first docs.
Core support
What mobile app generation means inside Virex
A mobile result should feel like a serious baseline app structure with believable screen groupings, app-style flow naming, and a continuation path that respects mobile-specific setup.
The simple version
- Virex supports mobile output where the product request fits a mobile app path.
- Mobile is not positioned as a hidden side lane or an internal experiment users should ignore.
- The output should feel like a real continuation-ready app repo, while still being honest about setup that depends on the real product owner.
What the docs deliberately avoid
The docs do not pretend mobile means magically store-ready on day one. Mobile is positioned as serious now, honest about setup, and clear about what belongs later in the release path.
Starting with a mobile app?
Use this path first when your generated project is mobile
This is the fast entry point beginners and regular builders should see quickly. The point is to stop users from assuming a mobile repo behaves exactly like a web repo.
- 1Open the generated mobile repo and read the README
Mobile projects can have setup notes that differ from a web app. Start with the project README before you assume the commands or testing path are identical to localhost web workflows.
- 2Use Expo when the project is a mobile app
Expo is the practical continuation and testing layer for many Virex mobile projects. It is what helps you keep moving after the first generated output.
- 3Expect testing to differ from a web app
A mobile repo does not always mean you only run npm run dev and open localhost:3000 in a browser. The mobile continuation path is more app-oriented and depends on the project README and Expo flow.
- 4Keep store accounts as a later step
Apple and Google developer accounts matter later when an app is moving toward release work. They are not the first thing you need when simply opening and testing the generated mobile project.
Quick mobile mental model
Use Expo for the practical mobile continuation layer, keep the README close, and treat Apple or Google store accounts as later release concerns rather than first-step requirements.
Expo and testing
Expo is the practical mobile testing and continuation layer
Expo gives mobile repos a path that makes sense after generation: local continuation, app config, setup guidance, and a cleaner road toward later release preparation.
What changes compared with web testing
- Open the generated mobile repo and follow the project README before changing anything else.
- Use Expo when the project is a mobile app and you want the practical testing and continuation layer.
- Expect mobile testing to differ from a web repo: you are not always only opening localhost:3000 in a browser.
- Keep Apple and Google developer accounts as later release steps, not first-day requirements.
# mobile projects follow their own README and Expo flow
# do not assume every mobile repo starts with localhost:3000Expectation alignment
What mobile output includes now, what still needs your setup, and what belongs later
The mobile lane should feel strong enough to use seriously while still staying honest about project-specific setup and later release work.
Already included
Core app structure, mobile-oriented flow grouping, and a repo you can continue with the right mobile tooling.
Still needs your setup
Project-specific services, keys, app identity details, and real product decisions that depend on the actual owner and product context.
Later continuation
Release prep, additional polish, and deeper app-specific work that belongs after the baseline repo and setup path are already understood.