Cross-Platform Development in a Vibe Coded World

For fifteen years the cross-platform debate was an argument about headcount. Native meant two teams, two codebases and two release trains. React Native or Flutter meant one team shipping everywhere, at the price of some platform polish. Every framework choice was really a budget choice.

Then writing code got cheap. In February 2025 Andrej Karpathy named the practice of building software by describing it to an AI and, in his words, forgetting that the code even exists. By November, Collins Dictionary had made vibe coding its word of the year. A founder can now generate an iOS app, an Android app and a web app in an afternoon. So does the cross-platform question still matter when the code writes itself?

It matters more, for a reason almost nobody pricing these builds has noticed. The cost did not disappear. It moved.

The core position

Vibe coding made generating code nearly free and verifying it more expensive than ever. Cross-platform still wins in that world, but not because it saves typing. It wins because one codebase is one thing to review, secure and maintain, on a stack the models actually know.

What vibe coding changed, and what it did not

Adoption is no longer the question. In the Stack Overflow Developer Survey 2025, 84 percent of developers said they use or plan to use AI tools, up from 76 percent a year earlier, and 51 percent of professionals use them every day. Trust moved the other way: 46 percent said they do not trust the accuracy of AI output, up from 31 percent. The most cited frustration, named by two thirds of respondents, is output that is almost right, but not quite.

The most rigorous productivity data is more uncomfortable still. METR ran a randomised controlled trial with 16 experienced open source developers across 246 real tasks in their own repositories. With AI tools allowed, they were 19 percent slower. Afterwards, they estimated AI had made them 20 percent faster. The tools have improved since that early 2025 study, and the slowdown will not hold forever. The perception gap is the finding that should worry anyone budgeting a build, because teams that feel fast stop checking.

The cost moved from writing to verifying

The expensive parts of software were never the typing. They were deciding, checking, securing and maintaining. Vibe coding compressed the first and left the rest untouched, and in one way it made them harder: the author of the code is no longer someone you can ask why.

Apply that to the old cross-platform question. Two native codebases used to mean paying two teams to type. The typing is now nearly free, but you still have two codebases to review, two security surfaces, two dependency trees to upgrade, and a new failure mode: an AI that will cheerfully generate two slightly different implementations of the same feature, one per platform, which then drift apart without anyone noticing. The case for one codebase is stronger than it was, not weaker. It is simply a different argument: not fewer keystrokes, but fewer things to verify.

The training data advantage: pick a stack the models know

Models write best in the languages and frameworks with the most public code behind them, and that effect is now visible at the scale of the whole industry. GitHub’s Octoverse report found that in August 2025 TypeScript overtook Python and JavaScript to become the most used language on GitHub by monthly contributors, and GitHub credited part of the jump to typed languages making agent assisted coding more reliable. The loop feeds itself: developers pick what the AI writes well, which produces more public code in it, which makes the AI better at it.

For cross-platform work, that points to a TypeScript stack: React Native with Expo for iOS and Android, and a server-rendered web framework for the browser, sharing types, validation and business logic across all three. Flutter is an excellent framework, and it and React Native dominate cross-platform usage in developer surveys, but Dart is a much smaller share of public code, and in our experience AI output in it needs more correction. Kotlin Multiplatform is a strong choice for teams with deep Android expertise, and native Swift and Kotlin still win where a product lives or dies on platform feel. In a vibe coded team, though, the question is not only which framework is best. It is which framework the model is best at, and whether your people can check its work.

Where vibe coded cross-platform apps break

The prototype always works. It works on the founder’s phone, on the happy path, with test data. These are the five places we see vibe coded apps fail between that demo and a product people pay for.

1. Security, because the client is public

A mobile app ships its code to the user. Every key, endpoint and query in the bundle is effectively published. Veracode tested more than 100 models on 80 coding tasks and found AI generated code introduced OWASP Top 10 vulnerabilities in 45 percent of cases, with newer and larger models doing no better than smaller ones. The defining vibe coding incident made it concrete: a scan of 1,645 apps built on one popular AI app builder found 170 of them, about one in ten, exposing their databases (CVE-2025-48757) through missing or broken row level security, because the public key embedded in the client could query tables directly. Nobody wrote a bad line on purpose. Nobody checked the policies either. The rule: treat every key in the client as published, enforce authorisation on the server or in tested database policies, and review AI generated auth code the way you would review a stranger’s pull request.

2. Platform feel, because models default to generic

AI generates the median app: the same card layouts and the same tab bar on every platform. Users notice what it misses. The iOS back swipe, Android’s system back behaviour, safe areas around the notch, keyboard avoidance on long forms, haptics, dynamic type, screen reader labels. None of these are hard. All of them get skipped when nobody who knows the platforms is looking.

3. App review, because the stores have seen this before

Apple reviewed about 7.7 million submissions in 2024 and rejected more than 1.9 million, including over 320,000 for spam, copying or misleading content. A vibe coded wrapper around a website runs straight into guideline 4.2 on minimum functionality. A templated clone of an existing app runs into guideline 4.3 on spam. Speed to build is worth nothing if the build cannot ship.

4. The last 20 percent, because it lives outside the happy path

Screens are easy to generate. The work that decides whether an app survives lives where it touches the operating system: push notifications, deep links, offline sync and conflict resolution, in app purchases and subscriptions, background tasks, permission flows. This is where generated code most often looks right and fails on a real device, and where the survey’s top frustration, output that is almost right, gets expensive.

5. Maintenance, because nobody remembers why

A vibe coded app is written by a collaborator that does not remember writing it. Eight months later an operating system release or a framework upgrade breaks a dependency, and someone has to understand code nobody on the team actually wrote. This is where the METR perception gap bites: teams that feel fast skip the tests and documentation that make an app maintainable, and pay for it in the upgrade cycle.

Do not forget the web half

A cross-platform product is rarely just an app. It has a marketing site, pricing, documentation and help pages: the surfaces search engines and answer engines read. Vibe coding tools love to scaffold those as client rendered single page apps, which is the one architecture the crawlers behind ChatGPT, Claude and Perplexity cannot read, as we set out in our look at server-side rendering and SEO. Share the design system and the types with the app, by all means. Render the public web surface on the server.

The playbook we use

1. Choose the stack for the model and the team. TypeScript end to end: Expo for mobile, a server-rendered framework for the web, and one shared package for types, validation and API clients.
2. Draw the line before the first prompt. Humans define the data model, authentication and security rules. The AI generates screens and boilerplate inside those boundaries, never across them.
3. Gate every merge. Secrets scanning, a dependency audit, tested database policies, and a human review of anything that touches auth, payments or personal data.
4. Budget for platform polish. A fixed pass per platform for gestures, safe areas, accessibility and performance on low end Android devices, not only the newest iPhone. Speed on real hardware is a product feature, the same discipline we applied when we brought LCP under 1.5 seconds for a Shopify Plus store.
5. Instrument identically everywhere. One event schema across iOS, Android and web, so the product team compares like with like.
6. Ship to the stores deliberately. Real functionality beyond a web view, a clear privacy story, and review notes that make approval boring. Most of the pre-launch discipline in our website launch checklist applies to apps word for word.

So, does cross-platform still matter?

More than ever, for a new reason. When writing code was expensive, cross-platform saved you typing. Now that typing is nearly free, it saves you verification, which is exactly the part vibe coding made scarce. The winning setup in 2026 is one TypeScript codebase the models know well, humans owning the boundaries where mistakes are expensive, and AI moving fast everywhere else.

That is how we build inside our Tech engine, and the same principles run through every website and product build we take on: fast where speed is safe, careful where it is not, and measured on what ships rather than on what demos.

Vibe coded a prototype and not sure it is ready for the stores? Book 15 minutes and we’ll pressure test it with you.