# How to turn a Hostinger Horizons app into an iOS and Android app

SEO title: Hostinger Horizons to Mobile App | WebNativeApp

Source: https://webnativeapp.com/hostinger-horizons-to-mobile-app

Description: Turn your Hostinger Horizons or AI Builder web app into an iOS and Android app. Compare packaging and code export, then prepare for both stores.

Yes, you can turn a compatible Hostinger Horizons web app into an iOS and Android app without rebuilding every screen. Publish the web app, verify its mobile behavior, add a native mobile project around it, and prepare signed builds for store review. WebNativeApp provides the packaging route for an existing production URL; Hostinger continues running the web product.

:::callout{type="note"}
Checked September 3, 2026: Hostinger now combines Horizons and Website Builder under the name **Hostinger AI Builder**. This guide covers Horizons projects and AI Builder's agentic mode, the prompt-based web app workflow. Your editor may show the new name. [Hostinger's product overview](https://www.hostinger.com/ai-builder).
:::

## Can Hostinger Horizons create native mobile apps?

Hostinger builds browser-based applications. Its current documentation explicitly excludes native applications for the Apple App Store and Google Play from AI Builder's agentic-mode capabilities. The mobile preview checks how a website fits a phone screen; it does not create an iOS or Android release. [Hostinger's supported features and limitations](https://www.hostinger.com/support/hostinger-ai-builder-agentic-mode-product-overview/).

There are three separate pieces in a store release:

- **The Hostinger web app:** Your screens, business logic, accounts, and hosted services.
- **The mobile project:** The installed app, its identity, native integrations, and release configuration.
- **The store submission:** Developer accounts, signed builds, screenshots, disclosures, testing, and review.

A packaging service connects those pieces. It does not turn Hostinger's Publish button into an automatic store approval.

## Choose the right route for your Horizons project.

| Route | What you keep | What you need to add | Best fit |
| --- | --- | --- | --- |
| Mobile website or PWA | The hosted web app | Responsive design; installation and caching features if building a PWA | Browser access is enough; no store listing required |
| Package the live URL with WebNativeApp | The Hostinger deployment and web editing workflow | Mobile configuration, testing, and store submission | A working web product needs iOS and Android distribution |
| Export and integrate Capacitor yourself | Exported web source, with backend dependencies assessed separately | Native projects, build tooling, integrations, and maintenance | A developer needs deeper control of the mobile code |
| Rebuild with native screens | Product requirements and any reusable backend services | A separate mobile interface and release workflow | Core workflows require extensive offline processing or native-only behavior |

For an existing, mobile-friendly Horizons app, start by checking the live-URL route. Exporting or rebuilding becomes useful when the product needs control that the hosted version cannot provide. A PWA is also a valid choice when store distribution is not the goal; do not assume every Horizons project already has PWA installation or offline support configured.

## How to turn a Hostinger Horizons app into a mobile app.

### 1. Publish the production app, not the editor preview

Open your project and use **Publish**. If you want a custom domain, Hostinger supports connecting it from the Websites list or the editor's publishing flow. Open the resulting public URL separately to confirm that you are looking at the live app. [Hostinger's domain and publishing instructions](https://www.hostinger.com/support/10672797-hostinger-ai-builder-agentic-mode-how-to-connect-a-domain/).

Use a stable HTTPS address that you control. It should load without requiring access to your Hostinger account, although the product itself can require a customer login. Avoid packaging an editor URL or a temporary preview session.

Before proceeding, open a nested page directly, reload it, and check that navigation still works. Choose the production domain before configuring authentication callbacks or mobile links so you do not have to redo that setup later.

### 2. Check the live accounts and data

For projects using Hostinger's integrated backend, **Test data** belongs to the preview environment and **Live data** belongs to the published website. Records created during preview do not automatically become production records. [Hostinger's test and live data guide](https://www.hostinger.com/support/hostinger-ai-builder-agentic-mode-how-to-use-test-and-live-data-in-the-integrated-backend/).

Create a dedicated reviewer account through the published app. Confirm that it can sign in, see appropriate sample content, and complete the main task. Do not give reviewers an account that exists only in the editor's test environment.

If your older Horizons project uses an external backend, verify that deployment instead. Packaging does not require moving the database, but it also does not repair a missing production environment.

### 3. Fix the phone experience in Hostinger

The mobile app inherits your web interface. A desktop dashboard with tiny buttons remains difficult to use after packaging.

Test these behaviors on an iPhone and an Android phone:

- Navigation stays reachable without horizontal scrolling.
- The keyboard does not hide the active field or submit button.
- Tables, dialogs, menus, and long account names fit narrow screens.
- Loading, empty, failed-request, and lost-connection states have useful messages.
- Important actions can be completed without hover interactions.

Here is a starting prompt you can adapt in Horizons or AI Builder:

> Audit the existing app at narrow phone widths. Preserve its current features and data model. Make navigation and forms usable with a touch keyboard, prevent horizontal overflow, and add clear loading and failed-request states. Explain the proposed changes before applying them, then list the screens I should test manually.

Review the result before publishing. An AI-generated layout change still needs human verification.

### 4. Verify authentication and external links in the installed app

Passing a Safari or Chrome test is only the first check. The packaged app has its own browsing context, so do not assume that a browser login session will already exist inside it.

Test signup, login, logout, password reset, email verification, and returning from any external sign-in flow. A reset link that opens the browser must still lead to a usable account recovery experience. Social login may need a supported native or system-browser flow and a configured return link.

Keep the existing account system where it is compatible, rather than creating a second user database just for mobile. Decide which links stay inside the app and which open externally. Do not give arbitrary external websites access to the app's native integrations.

### 5. Create the iOS and Android project with WebNativeApp

Start with the [web app compatibility checker](https://webnativeapp.com/tools/web-app-to-mobile-app-checker), then provide the production URL in WebNativeApp. The checker is an initial technical screen, not a substitute for testing authenticated workflows or obtaining store approval.

Prepare your app name, icon, launch appearance, and target platforms. WebNativeApp packages a compatible website in a Capacitor-based mobile project. The generated mobile source goes into your own repository, while your Hostinger project remains the web app you continue editing. See [what WebNativeApp includes](https://webnativeapp.com/what-is-webnativeapp).

Keep the app's bundle identifier and Android package name consistent once you start distributing builds. These identify the mobile app; they are not the same thing as your website domain.

### 6. Add native features for a specific user task

Choose integrations that improve the product you already built. For example:

- A booking app could let users save an appointment to their calendar.
- A field-reporting app could add camera capture or document scanning.
- A member portal could use biometric unlock where the authentication design supports it.
- A status-tracking app could add properly configured push notifications.

These are options to scope and integrate, not capabilities that every wrapped URL acquires automatically. Notifications need permission handling, device registration, and a sending system. Camera and biometric features also need working connections to your web flows. Review the [native feature guide](https://webnativeapp.com/documentation) before choosing the release scope.

### 7. Test signed builds on both platforms

Use TestFlight for the iOS build and an appropriate Google Play testing track for Android. Exercise the installed product on real devices, including after closing and reopening it.

Run one complete journey: install, create an account, perform the core task, leave the app, return, and sign out. Then repeat with denied permissions and a poor connection. On Android, check the system back action; on iOS, check screen edges and keyboard behavior.

If the website depends on a network connection, show a useful failure state. Packaging does not make server-backed workflows available offline.

### 8. Prepare the store submissions

Submit under your own developer accounts. Prepare the app description, screenshots of the actual mobile build, support and privacy URLs, access instructions, and accurate data disclosures.

For a new Google Play app, prepare an Android App Bundle, or AAB. It is the publishing artifact Google Play uses to generate device-specific APKs; the Hostinger export ZIP is not a substitute. [Android App Bundle documentation](https://developer.android.com/guide/app-bundle).

Use the [App Store submission checklist](https://webnativeapp.com/app-store-submission-checklist-web-apps) and [Google Play submission checklist](https://webnativeapp.com/google-play-store-submission-checklist-web-apps) for the current platform requirements. A successful build is a milestone, not the end of the release process.

## Do you need to export your Horizons code?

No, not for a compatible live-URL packaging workflow. Export is an alternative when a developer needs to change the web code outside Hostinger or build and maintain the native integration directly.

Hostinger currently documents **Code → Export code**, which downloads a React and Vite project using Node.js tooling. It also states that an externally edited export cannot be imported back into AI Builder to resume prompting. Treat that route as a separate maintenance workflow, not a round-trip editing feature. [Hostinger's code export instructions](https://www.hostinger.com/support/10771345-hostinger-ai-builder-agentic-mode-how-to-export-code/).

For a manual Capacitor integration, build the web assets, configure the output directory, add the iOS and Android platforms, and synchronize the built assets into the native projects. Native configuration, signing, and release testing remain separate tasks. [Capacitor's installation guide](https://capacitorjs.com/docs/getting-started).

:::callout{type="note"}
**A code export is not a database backup.** Hostinger currently says its integrated backend has no direct data export tool. Do not assume an exported ZIP includes a portable copy of customer accounts, submissions, or uploaded files. Verify data access and a migration plan before moving or canceling hosting. [Hostinger's integrated backend documentation](https://www.hostinger.com/support/what-is-the-integrated-backend-in-hostinger-ai-builder-agentic-mode/).
:::

## What can prevent a Horizons app from passing review?

The main risks are the finished experience and its behavior, not the name of the builder.

**Too little mobile value.** Apple's Guideline 4.2 requires more than a repackaged website. A marketing page with an icon is a weak submission; a well-designed tool with useful repeat workflows is a stronger starting point. Adding one native feature does not guarantee acceptance. [Apple's App Review Guidelines](https://developer.apple.com/app-store/review/guidelines/#minimum-functionality).

**Broken or minimal functionality.** Google Play requires a functional, responsive experience and prohibits certain low-value or unauthorized webview apps. Make sure you control the site and that the packaged version actually works. [Google Play's functionality policies](https://support.google.com/googleplay/android-developer/answer/17105854).

**An unreviewed payment flow.** Do not assume a checkout that works on your website is permitted unchanged inside a store app. Digital purchases, physical services, storefront rules, and applicable exceptions need separate assessment. Review [Apple's payment rules](https://developer.apple.com/app-store/review/guidelines/#payments) and [Google Play's Payments policy](https://support.google.com/googleplay/android-developer/answer/9858738) before implementing the mobile purchase path.

**Incomplete access or disclosures.** Reviewers need to reach the core experience. Check the demo account, privacy information, permission explanations, and any applicable account-deletion requirements before submission.

## What happens when you update the app in Hostinger?

With the live-URL route, the installed app continues loading your production deployment. That preserves the Hostinger editing workflow, but web changes and native releases are different operations.

| Change | Typical release action |
| --- | --- |
| Web copy, layout, or a compatible web bug fix | Publish in Hostinger, then verify the installed app loads the change |
| Backend fields or account behavior | Publish the relevant changes and test existing mobile sessions and data |
| Native plugins, permissions, or bundled resources | Create and distribute a new native build through the required store process |
| Store screenshots, descriptions, or privacy declarations | Update the relevant store listing or disclosures |

Hostinger also distinguishes database structure from stored records: publishing can synchronize structural changes, but preview records remain separate from live records. That distinction matters when a new screen works in the editor but fails against production data. [Hostinger's data synchronization guide](https://www.hostinger.com/support/hostinger-ai-builder-agenic-mode-how-to-troubleshoot-data-synchronization-in-hostinger-databases/).

Web delivery is not permission to bypass review or introduce prohibited behavior. Reassess significant product changes against store policies, and test before exposing them to installed-app users.

## What should you budget for?

Separate the web product from its mobile distribution costs:

- **Hostinger:** Your active hosting, domain, and applicable AI Builder plan or credits.
- **WebNativeApp:** Currently $29 one-time for one platform or $49 for both, with 10 or 20 cloud builds included respectively. Check the [current product and pricing details](https://webnativeapp.com/what-is-webnativeapp) before purchasing.
- **Developer accounts:** Apple and Google enrollment, verification, and any applicable fees.
- **Ongoing product work:** Backend services, notification delivery, additional build capacity, or custom native integration work when needed.

There is no recurring WebNativeApp converter plan, but that does not make hosting or future mobile maintenance free. Owning the mobile source also does not remove dependencies on the live Hostinger app.

## Hostinger Horizons to mobile app FAQ

### Can I publish a Hostinger Horizons app to the App Store?

Yes, if the finished app meets Apple's requirements. Publish the web product, package it into an iOS project, test the signed build, and submit it through your Apple developer account. Hostinger's web publishing button does not perform those mobile release steps.

### Can I turn a Hostinger Horizons app into an Android app?

Yes. A compatible production web app can be packaged into an Android project. Google Play distribution then requires the appropriate signed release, developer account, testing, listing details, and policy review.

### Does this guide also apply to Hostinger AI Builder?

Yes. It covers the prompt-based web app workflow now available in AI Builder's agentic mode, as well as existing Horizons projects. It does not assume that every Hostinger website has the functionality or mobile quality needed for a store app.

### Do I need to export the code before using WebNativeApp?

Not for the compatible live-URL route. You keep the Hostinger deployment and provide its production address. Exporting is a separate option for developers who need to maintain the web code and native integration themselves.

### Will my existing users keep their accounts and data?

They can continue using the same accounts and data when the mobile app connects to the same production backend. Existing browser sessions do not automatically carry into the installed app, and login, redirects, and recovery flows still need device testing.

### Will the app work offline?

Not automatically. A hosted app still needs connectivity for uncached pages and server-backed actions. Offline screens, cached content, and offline-first workflows require deliberate implementation and testing.

### Can I cancel Hostinger after creating the mobile app?

Not if the mobile app still depends on the Hostinger deployment. Keep the required hosting and services active unless you have migrated and verified every dependency. Generating a mobile project does not relocate your website or database.

### Are future Hostinger changes reflected in the mobile app?

Published web changes can appear in a live-URL app, subject to caching and compatibility. Native code, permissions, and bundled-resource changes require a new native release. Significant web changes must still comply with store policies.

## Continue your mobile release.

:::related
- [Web app to mobile app: compare the routes](https://webnativeapp.com/web-app-to-mobile-app)
- [Web app to Android: complete publishing guide](https://webnativeapp.com/web-app-to-android)
- [App Store submission checklist for web apps](https://webnativeapp.com/app-store-submission-checklist-web-apps)
- [Google Play submission checklist for web apps](https://webnativeapp.com/google-play-store-submission-checklist-web-apps)
- [AI app builder to App Store](https://webnativeapp.com/ai-app-builder-app-store)
- [Website-to-app cost guide](https://webnativeapp.com/how-much-does-it-cost-to-turn-a-website-into-an-app)
:::

## Turn your Hostinger Horizons app into a mobile app.

Keep the web product you already built. [Check your production URL](https://webnativeapp.com/tools/web-app-to-mobile-app-checker), define the mobile experience, and use WebNativeApp to prepare your iOS and Android project without rebuilding every screen.