# Change Hosting Without Breaking Your Native App

You built a web app, shipped it to the App Store and Google Play, and it works. Now you want to move it to a different host: Vercel, Netlify, Cloudflare Pages, Render, or a different no-code builder entirely. The fear is reasonable. If the migration breaks the published app, every user who opens it hits a blank screen, and fixing that means a new store review. The good news is that whether this breaks anything comes down to one thing, and it is not the host.

## Your native app points at a URL, not a host

When your web app is shipped as a native binary, the app does not know or care which host serves your code. It loads a URL. Behind that URL you can run Vercel today, Netlify tomorrow, and Cloudflare Pages next month, and the app on someone's phone never notices, because the address it opens did not change.

This is true across the board. It does not matter if your web app is Next.js, React, Vue, or a project built in Lovable, Base44, or Replit. The native shell resolves a domain, the domain resolves to whatever host you point it at, and the host is a commodity you can swap.

So the real question is never "am I allowed to change hosts." You are. The question is "does my app's URL change when I do."

## The one thing that actually breaks: the URL changing

There is exactly one way a host migration breaks your published app, and it is being on a platform-branded subdomain.

If your app currently loads from something like `yourapp.builder.app`, `yourapp.netlify.app`, or `yourapp.pages.dev`, that URL belongs to the platform, not to you. The moment you leave that platform, the subdomain stops serving your app. Your native build is still pointing at it, and now it points at nothing.

A custom domain you own, like `app.yourcompany.com`, has no such problem. You control the DNS. You point it at the new host, and every device that opens the app follows the domain to wherever you moved it. Nothing in the native build changed, because nothing needed to.

## The safe migration path

Start by finding out which situation you are in. Look at the URL your app loads on launch. That single fact decides how much work this is.

**If you are on a custom domain**, the migration is a DNS change and nothing more:

1.  Deploy your app to the new host.
    
2.  Point your domain's DNS at the new host.
    
3.  Wait for DNS to propagate.
    

That is the whole job. No new build, no version bump, no store resubmission. The app on every phone keeps loading the same domain, which now happens to be served by a different machine. Over-the-air content updates keep flowing the way they always did.

**If you are on a platform-branded subdomain**, there is more to it, and one step people skip and regret:

1.  Set up a custom domain and point it at your app on the new host.
    
2.  Update the app's start URL to the custom domain.
    
3.  Rebuild the app, bump the version and build number, and submit for review.
    
4.  Keep the old deployment alive until the new version is approved and rolled out.
    

That last point matters. Until the new build clears review and reaches your users, everyone is still running the old build that points at the old subdomain. If you tear down the old deployment early, you break the live app for every existing user during the review window. Leave it running until the new version has actually shipped.

Here is the difference at a glance.

|  | Custom domain | Branded subdomain |
| --- | --- | --- |
| DNS change | Yes | Yes |
| Update start URL | No | Yes |
| New build and version bump | No | Yes |
| New store review | No | Yes |
| Risk to live users | None | Existing users until new build ships |

The takeaway is blunt: a custom domain turns a host migration into a DNS change. A branded subdomain turns it into a rebuild and a store review.

## When you actually need a new app review

It helps to be precise about what triggers a store review, because the answer surprises people.

Changing your content does not. If you push a new version of your web app to your host, that content ships to every user over the air through remote hydration. No rebuild, no review, no waiting on Apple or Google. That is the point of shipping a web app natively: the web part updates like the web.

Changing the native shell does. The start URL your app opens on launch lives in the native build. Change it, and you need a new binary, a higher build number, and a fresh review. Moving from a branded subdomain to a custom domain is a start-URL change, which is why it costs a review and a plain DNS migration does not.

So the two are cleanly separated. Content is over the air. The URL the shell points at is in the binary. Know which one you are touching and you know whether a review is coming.

## Own your domain and the host becomes disposable

The reason we suggest custom domains from day one is exactly this moment. When you own the domain, your host is a decision you can reverse in an afternoon with no impact on anyone using the app. When you are renting a platform's subdomain, your host and your published app are welded together, and separating them costs a release cycle.

If you are early enough to still be on a branded subdomain, moving to a custom domain now, while your user base is small, is the cheapest this migration will ever be. Do it before the next host decision, not during it.

## Get it on the stores

Take the app you already built, on whatever host and stack you use, and ship it to iOS and Android without a CLI or a Mac. Point it at your own domain, update content over the air, and swap hosts whenever you want without touching the store listing.

[See the setup docs at setup.despia.com](https://setup.despia.com)