# How to Build a Base44 Mobile App You Own

There are two ways to get a Base44 app onto the App Store and Google Play, and they differ less in how hard they are than in what you end up holding afterwards. This is a guide to the decisions that determine whether the app is an asset you control or an output of a platform you rent.

## What does owning a mobile app actually mean?

**Five things, and they are separable. The developer accounts, the app identifier, the address the app loads, the backend behind that address, and the native project itself.**

You can own all five, some of them, or effectively none, and most people never notice which until they want to change something.

Taken one at a time:

**The developer accounts.** Your Apple Developer Program membership and your Google Play Console account, in your name or your company's, paid for by you. This one is easy and both paths get it right. Base44's documentation is explicit that you are responsible for creating and managing these accounts and that you submit through them.

**The app identifier.** The bundle ID on iOS and the package name on Android. This is the permanent, public key both stores use for your app, and it cannot be renamed later on either platform.

**The address the app loads.** Every wrapped app points at a URL. Whoever controls that URL controls what the installed app shows.

**The backend.** Where your data lives and what happens to it if you stop paying the platform.

**The binary.** Whether you can open the actual Xcode and Android Studio projects, or whether the compiled file is the only artifact you will ever see.

## Which of those does the built-in path give you?

**The accounts, and the submission.**

Base44 documents the rest as fixed: the bundle ID and signing key are set automatically and cannot be changed in the generated IPA or AAB, the package name follows a set format, and the entry URL comes from your published app rather than from you.

The package name format is documented as `com.base[app-id].app`, where the app ID comes from your editor URL. It is a functional identifier and it works. It is also permanent and publicly visible in the Play Store URL, and it names the platform that generated it. Whether that matters depends entirely on who ends up reading it: invisible for an internal tool, a detail that gets noticed in an enterprise security review or an acquisition diligence pass.

The entry URL constraint is the one with longer consequences. If the installed binary is bound to a Base44-controlled address, then moving off Base44 later means the shipped app no longer points at your product. That is not a criticism of the design. It is a straightforward consequence of the platform generating the build.

## What does the ownership decision cost?

**Almost nothing at the start and almost everything later, which is exactly why it gets skipped. A domain is a few dollars a year. Choosing an identifier takes 30 seconds. Neither is recoverable once the app is live.**

The asymmetry is worth stating plainly. If you take the defaults and never need to move, you lost nothing. If you take the defaults and do need to move, you abandon the listing, and with it the reviews, the ratings, the install base and whatever store ranking you earned. There is no partial version of that outcome and no support ticket that fixes it, because the constraint belongs to Apple and Google rather than to any vendor.

That makes it a straightforward asymmetric bet. The downside of owning your identifier and domain is a rounding error. The downside of not owning them is the only asset a small app really has.

## How do you keep all five?

**Own the domain first, then choose the identifier yourself, then ship through a runtime that hands you the native projects. In that order, because each one constrains the next and only the first is free to change later.**

**1\. Point the app at a domain you own.** A custom domain is not required to submit, and Base44 says so directly. It is required for portability. The domain is the indirection layer between the installed binary and whatever is serving your app this year. Buy it before you build the app, not after you have 5,000 installs.

**2\. Publish the Base44 app to that domain.** Publishing is a separate action from editing. The binary should be built against the published app on your custom domain, never against an editor preview URL, because a preview URL can show App Review a different state from the one you meant to submit.

**3\. Choose your own bundle ID and package name.** With Despia you set these when you create the project, in reverse domain form from the domain you just bought, for example `com.yourcompany.yourapp`. After the first signed build they lock, because Apple and Google treat the identifier as immutable, so this is a decision to make deliberately at the start.

**4\. Add the native capabilities your app needs.** From the same Base44 codebase, through one JavaScript function. Environment detection uses the user agent, and native calls go inside that gate:

```javascript
import despia from 'despia-native'

const isDespia = navigator.userAgent.toLowerCase().includes('despia')

if (isDespia) {
    despia('successhaptic://')
}
```

**5\. Ship it, and keep the projects.** Code signing and store submission run from a browser, with no CLI and no Mac. The full Xcode and Android Studio projects export whenever you want them, which is what turns the runtime into a choice rather than a dependency.

## What do you actually need for a first submission?

**Less than most guides suggest. A published app on your own domain, both developer accounts, an icon, a privacy policy and terms reachable before signup, store screenshots, and demo credentials if anything sits behind a login.**

Two of those are worth extra attention because they cause avoidable rejections: **Privacy policy and terms have to be reachable before account creation.** If your app opens on a login screen, the links need to be on that screen or in a footer a reviewer can reach without an account.

**Demo credentials must work on the day you submit.** Tick "Sign-in required" in App Review Information, enter working credentials, verify them on a real device the same day, and name in the notes exactly where a reviewer should look for anything non-obvious. Guideline 2.3.1(a) requires new functionality to be described with specificity and explicitly rejects generic descriptions.

## What has to be true to migrate later?

**The identifier, the domain and the store listings have to be yours, and the app has to load from an address you can repoint. If all three hold, migration is a DNS change rather than a new app.**

This is the part worth thinking through before you need it, because the cost of getting it wrong is not paid at migration time, it is paid in the listing you have to abandon. Reviews, ratings, install base and store ranking all attach to the identifier. Start a new identifier and you start those at zero.

With the domain and the identifier in your hands, the paths out are all cheap:

*   **Rebuild the front end.** Move from Base44 to Next.js, Remix, or a team of developers writing whatever they prefer. Point the domain at the new build. Every installed app follows, with no resubmission.
    
*   **Move the backend.** Swap the managed services for your own Supabase project, or anything else. The mobile app never knew the difference.
    
*   **Leave the runtime.** Export the native projects and continue in Xcode and Android Studio, keeping the same identifier and the same store listings.
    

None of that is a prediction that you will leave Base44. Plenty of apps stay for years and should. It is insurance, and the premium is one domain registration plus 30 seconds of thought about an identifier.

## What else decides whether the app ships?

**Four things beyond ownership: whether the app looks like an app, whether it does something a browser tab does not, whether it sells digital content, and whether a reviewer can actually reach every feature.**

Those are the questions guideline 4.2 and the review process actually turn on, and none of them are about which tool built the app.

**Does it look like an app?** Guideline 4.2 asks for features, content and UI, and the UI half is where most resubmissions fail. Sidebars, hamburger menus, desktop top navigation, a visible sitemap footer and a cookie banner all read as website. What reviewers expect is a top bar with the current screen title, a content area, and a bottom navigation bar with icons.

**Does it do something the installed experience adds?** Not what a browser technically cannot do, since web push, geolocation and the Web Share API all exist. The credible answers are integrations: native purchases, a biometric flow tied to real credential storage, camera and picker flows, contacts and calendar, background location, haptics, background audio, offline that survives a cold start, and deep and universal links. Name 3 a reviewer will meet without hunting.

**Does it sell digital content?** If so, it has to go through StoreKit and Google Play Billing. Physical goods and services consumed outside the app are the opposite case, and guideline 3.1.3(e) requires a payment method other than in-app purchase for those.

**Can a reviewer reach everything?** Tick "Sign-in required" in App Review Information, verify the demo credentials on a real device the same day you submit, and describe new functionality with specificity in the notes, since guideline 2.3.1(a) explicitly rejects generic descriptions.

## How do you get it onto the stores?

**Take the Base44 app you already built and ship it under a bundle ID you chose, from a domain you own, with the native capabilities the stores expect.**

Code signing and submission run from the browser, and the full native projects export whenever you want them.

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

## FAQ

### What does owning a mobile app mean?

Owning a mobile app means controlling five components: developer accounts, app identifier, the app's URL, backend, and the native project. You can own all, some, or none of these.

### What does Base44's built-in path provide?

Base44's built-in path gives you the developer accounts and submission process. The bundle ID, signing key, package name, and entry URL are fixed and controlled by Base44.

### What is the cost of ownership decisions?

The initial cost is minimal, but the potential cost of not owning key components is high. Not owning them can lead to losing your app's listing, reviews, and rankings if you need to move.

### How can you keep all five ownership components?

To keep all five, own a domain, choose your identifier, ship through a runtime that gives you native projects, and ensure the app points to your domain.

### What is needed for a first app submission?

You need a published app on your domain, developer accounts, an icon, privacy policy, terms of service, store screenshots, and demo credentials. Privacy policy and terms must be accessible before signup.

### What factors affect app store approval?

Approval depends on the app looking like an app, offering something beyond a browser tab, handling digital content sales correctly, and ensuring a reviewer can access all features.