# The Next Wave of Mobile Apps is The Instant Prototype

*By Amrit Saluja, Technical Content Writer at GeekyAnts.* [*Originally published on GeekyAnts*](https://geekyants.com/blog/the-next-wave-of-mobile-apps-is-the-instant-prototype)*.*

Is the local IDE becoming optional? Sanket Sahu discusses the rise of vibe-coding and how browser-native tools such as RapidNative are reshaping mobile app development.

## Editor's note

[Sanket Sahu, co-founder of GeekyAnts](https://geekyants.com/sanket) and creator of gluestack, recently explored how to build an entire development server inside the browser. The engineering is interesting, but the larger question is what this architecture means for founders, product managers, and the future of [enterprise AI](https://geekyants.com/blog/modernize-your-enterprise-systems-how-generative-ai-revolutionizes-integration).

We spoke with Sanket about the reasons behind the build, the browser-native technologies that make it possible, and the product opportunities created by near-instant feedback. The conversation below has been edited for clarity.

## Is the local IDE becoming optional?

Amrit Saluja: We hear a great deal about vibe-coding. Does browser-native architecture make the local IDE optional, or are we moving toward a hybrid future?

Sanket Sahu: [Vibe-coding](https://vibecode-db.geekyants.com/?utm_medium=referral&utm_source=geekyants.com) is growing because browser-based tools remove setup friction and make [building apps](https://geekyants.com/service/hire-mobile-app-development-services) more accessible. Development is moving toward a hybrid model rather than abandoning local tools altogether.

## What did RapidNative change?

AS: For readers who have not seen the technical deep dive, what did you build?

SS: I rebuilt the development server inside the browser. RapidNative does not require `npm run dev`, a CLI, or an external server. A code change appears in the preview in under 100 milliseconds while preserving application state.

AS: Why replace the earlier approach?

SS: The previous version ran a sandbox in the cloud. That architecture worked, but an [AI tool](https://geekyants.com/blog/top-10-ai-tools-every-uiux-designer-should-master) that streams code in real time makes every network round-trip visible. The goal was not merely a fast response. It was an instant one.

## How can a development server run in a browser tab?

AS: A traditional development server handles a lot of work. How did you move those responsibilities into the browser?

SS: A server such as Metro watches the file system, transpiles code, bundles modules, and serves the result over HTTP. We replaced each responsibility with a browser-native capability. Service Workers take the place of the HTTP server. IndexedDB and a virtual file system replace the physical file system. Babel Standalone performs transpilation, while Import Maps remove the need to bundle modules during development.

AS: That sounds similar to Vite. Was it an influence?

SS: Yes. Both approaches begin with the same observation: modern browsers understand ES modules, so development does not always need a bundling step. Vite still relies on [Node.js](https://geekyants.com/hire-nodejs-developers) and a CLI. RapidNative extends the idea by moving the full development loop into the browser.

## Why use two virtual file systems?

AS: What makes the dual-VFS architecture necessary?

SS: The two file systems have separate responsibilities. The Source VFS holds the original [TypeScript](https://geekyants.com/blog/introduction-to-typescript) and JSX files. When a source file changes, the browser transforms it and writes plain JavaScript into the Destination VFS. The Service Worker serves only from that destination. Keeping source and output separate makes the pipeline predictable and fast.

## What does a sub-100ms preview mean for founders?

AS: How does that preview speed help a founder or a non-technical decision-maker?

SS: Fast iteration protects the creative flow. It helps teams produce [better MVPs](https://geekyants.com/service/mvp-development-service), test their thinking sooner, and reach a first paying user faster. For many people, seeing an app idea running on a phone in less than two minutes is the moment the product becomes real.

AS: How is RapidNative different from Expo Snack?

SS: The products serve different purposes. Snack is a browser-based REPL that helps developers test snippets and run them on devices. RapidNative focuses on [building full apps](https://geekyants.com/service/hire-mobile-app-development-services) with AI assistance and instant browser feedback. Its sub-100ms update loop matters when an AI is continuously streaming code changes.

## Who is RapidNative for today?

AS: Is the current product aimed at startups or enterprises?

SS: Today, it is best suited to individuals and startups that want to turn an idea into a working app. Customization, team features, and compliance capabilities are on the roadmap so that agencies and enterprises can adopt it as well.

## What comes next?

AS: What remains on the technical roadmap?

SS: Three major additions are planned: a TypeScript Language Server for editor autocomplete, browser-native Git operations through isomorphic-git, and native-device support through Expo Go. Together, they should combine instant browser feedback with the advantages of running an app on a real device.

AS: You have built NativeBase, gluestack, and now [RapidNative](https://www.rapidnative.com/?utm_medium=referral&utm_source=geekyants.com). Has AI changed your goal?

SS: The goal remains the same: remove friction for developers, designers, founders, and product managers. AI is an enabler and an accelerator. It shortens the distance between imagining an idea and seeing it work on a screen.