Can Hostinger Horizons Publish to Google Play? Turning Your Horizons App into an Android App
No — Hostinger Horizons cannot publish your app to Google Play, and Hostinger says so itself. Their own documentation states that Horizons cannot create native mobile applications for the App Store (iOS) or Google Play (Android). What Horizons gives you is a live web app at a URL — and that URL is exactly what you need: paste it into a wrapper service like ours and you get a signed Android APK/AAB, ready for Google Play, usually in about three minutes.
That's the whole answer. The rest of this post is the honest version of how that works, what it costs, and where the real limitations are — including the ones on our side.
What Hostinger actually says about native apps
Hostinger Horizons is an AI builder: you describe your app in plain language, it generates a working web application, and one click publishes it to a live URL on Hostinger's hosting — with a custom domain if you want one. For getting from idea to something people can use in a browser, it's genuinely fast.
But on the question this post is about, Hostinger's product documentation is refreshingly direct. As of mid-2026 it reads: “Currently, Hostinger Horizons cannot create 3D games, browser extensions, trading or banking applications, as well as native mobile applications for the App Store (iOS) or Google Play (Android).” There is no export-to-APK button, no store submission flow, and no roadmap promise we could find. I actually respect that they say it plainly instead of burying it.
Why the gap exists: Google Play doesn't accept URLs. It accepts a compiled, cryptographically signed Android package — and it strongly prefers the AAB format for new apps. A Horizons project is a web app: HTML, JavaScript, a backend, a URL. Even if you install it to a home screen as a PWA, a PWA is not itself something you can upload to the Play Console. That last mile — from live URL to signed, store-acceptable binary — is the specific gap a wrapper closes. It's the same story we've written about for Bolt and other AI builders: they all stop at the URL, because shipping store binaries is a different business than generating web apps.
From Horizons URL to signed Android app, step by step
Here's the actual process, with nothing skipped:
- Publish your Horizons app. In the Horizons editor, hit Publish so your app is live on its Hostinger URL. If you plan to keep this app long-term, connect a custom domain first — your Android app will load whatever URL you wrap, and a domain you own is the safer thing to build on.
- Check it on a phone browser.The wrapped app renders your live site, so if something is awkward on mobile, fix it in Horizons now — a native shell doesn't make a cramped layout less cramped.
- Paste the URL into Code2Native. Set your app name, choose a package ID (something like
com.yourapp.mobile— it's permanent once published, so choose carefully), and upload one 512×512 icon. Every density variant gets generated; no logo yet and a clean monogram icon is generated from your app name. - Build. About three minutes later you have a signed APK (install directly on any Android phone) and a signed AAB (the format Google Play wants), both signed with a release keystore we generate and reuse per project — so update five installs cleanly over update one. Push notifications via OneSignal, hardware back button, offline screen, and
mailto:/tel:handling are included. - Test the APK on a real device. Your first build is free (one credit, watermark on the splash screen), specifically so you can do this step before paying anything.
- Upload the AAB to Google Play.This part is yours: a one-time $25 Google developer fee, store listing, screenshots, and — if you registered a personal account recently — Google's closed-testing requirement before production. Our docs walk through it, and there's a $249 add-on if you want the closed-testing requirement handled for you.
One property of this route matters more for Horizons users than anyone: the app loads your live site. Every edit you make in Horizons — a reworded page, a new feature, a bug fix — reaches every installed phone instantly. No rebuild, no store review. For an app you're still iterating on with AI prompts, that's the strongest argument for wrapping over compiling.
Your options, honestly compared
| Option | Play-ready Android app | Time & effort | Rough cost |
|---|---|---|---|
| Keep sharing the URL (or install as PWA) | None | Free (your Horizons plan) | |
| Rebuild natively (Flutter / hire a developer) | Weeks to months | Thousands, or a lot of your time | |
| DIY WebView wrapper in Android Studio | A weekend, plus the Android toolchain | Free, plus your hours | |
| Wrap the URL with Code2Native | About 3 minutes | First build free; then 1 credit per build |
The DIY row is real, and if you want to learn the Android toolchain it's a fine weekend. We've written a full walkthrough of the free do-it-yourself path in how to convert a website to an Android app for free— read it before deciding; some people genuinely enjoy Gradle. Most Horizons users, who chose an AI builder precisely to avoid toolchains, don't.
The caveats a sales page would skip
- The app is your hosted Horizons site. The wrapper renders your live URL, which means your app depends on that site staying up. If your Horizons subscription lapses and the site goes offline, installed apps show an offline screen until it's back. Owning a custom domain gives you an escape hatch — you can rehost elsewhere later without breaking installed apps.
- iOS is not the same deal.On the Apple side we build an unsigned .ipa on real Apple silicon (Pro tier), which you re-sign with your own Apple Developer certificate and submit yourself — we never need your Apple ID, and we do not submit to the App Store for you. There's also a zero-signing Web Clip for home-screen installs without any certificate. If someone promises hands-off App Store publishing without involving your own Apple account, be suspicious.
- Google Play's quality bar still applies. Play accepts WebView-based apps, but a thin wrapper around a one-page site can be rejected as low-value. A working product — accounts, features, something people actually do in it — is fine, and most real Horizons projects clear this easily.
- No code export needed, but also no code builds for this stack. We only need your URL. Our separate source-build pipeline compiles Flutter, native Android (Gradle), and Capacitor projects that include an
android/folder — React Native, Ionic, and Expo are waitlist-only today, not a live path.
Who should do what
Wrap your URL if:your Horizons app works well in a phone browser today, you iterate often, and you want a Play Store listing, home-screen icon, and push notifications without touching a toolchain. This is most people reading this post, and it's the same play that works for Glide and every other builder that stops at a URL.
Stay web-only if:your users are fine with a browser tab, you don't need push or a store presence, and the app is still changing shape daily. There's no shame in shipping a URL — wrap it when someone asks “can I install it?”
Rebuild natively if:you need heavy offline behavior, camera-level performance, or deep native integrations. That's a real engineering project and no wrapper — ours included — substitutes for it.
FAQ
Can Hostinger Horizons publish directly to Google Play or the App Store?
No. As of mid-2026, Hostinger's own documentation states that Horizons cannot create native mobile applications for the App Store (iOS) or Google Play (Android). Horizons builds and hosts web apps at a URL. Getting on Google Play requires a signed AAB, which is what wrapping that URL produces.
Is a wrapped Horizons app allowed on Google Play?
Yes — Google Play accepts WebView-based apps, delivered as a signed AAB, which is exactly what you get. The bar Play does enforce is value: an app that's just a wrapped brochure page can be rejected as low-quality, while a functional product with real features passes. Rebuilds reuse the same per-project signing key, so every update installs cleanly over the last.
Will my Android app update when I change my app in Horizons?
Yes, instantly. The wrapper loads your live site, so every published Horizons edit reaches installed phones with no rebuild and no store review. You only rebuild when you change the native shell itself — the icon, the app name, or the package ID.
What does each side cost?
On the Horizons side, as of mid-2026 plans span four tiers — roughly $7 to $80 per month, from Explorer (30 AI credits) to Hustler (400) — with credits consumed per AI request; check Hostinger's pricing page for current numbers, since promotional pricing moves. On our side: the first Android build is free with a watermark. Starter is $29/month for 10 build credits, Pro $99/month for 30 (priority queue plus cloud iOS IPA), Agency $199/month for 100 (adds Windows EXE and white-label). Annual: $290, $990, $1,690. One Android build costs one credit, a $49 urgent option targets under an hour, and you can pay by card via Stripe or in USDT.
Can I get an iOS App Store app from my Horizons project?
Partially, and we'll be precise: we build an unsigned .ipa in the cloud on real Apple silicon, and you re-sign it with your own Apple Developer certificate ($99/year to Apple) and submit it yourself. We never ask for your Apple ID and we don't do the submission. If you just want tap-to-install on iPhones without any certificate, an iOS Web Clip does that with zero signing — but it's a home-screen install, not an App Store listing.
Do I need to export any code from Horizons?
No. The wrapper route needs only your live URL — no code export, no Hostinger login, no GitHub. Our source-build pipeline is a separate thing for people with actual Flutter, native Android, or Capacitor projects; a Horizons web app isn't one of those, and that's fine — the URL is the product.
Your Horizons app, on Google Play this week
Paste your published Horizons URL and get a signed APK to test on a real phone — the first build is free, and the AAB for Google Play comes with it. If the build fails, the credit comes back automatically.
Code2Native Engineering
Engineering team
Written by the Code2Native engineering team — the people who build and operate the cloud build pipeline.