Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.hiveku.com/llms.txt

Use this file to discover all available pages before exploring further.

Hiveku Native Mobile is a project type that lets you build a real React Native app from an AI chat — and then ship that app to TestFlight and Google Play without ever opening a terminal. The code is real Expo + Expo Router. The build runs on real EAS infrastructure. The app you submit is the same one that runs on a real phone.

​
Who it’s for

Mobile is built for anyone who needs an actual mobile app — not a mobile-friendly website, not a PWA, but the thing that goes in the App Store. Typical fit:
  • Founders who need an iOS + Android app to validate a product idea before hiring engineers
  • Agencies who already build websites on Hiveku and want to add “mobile app” to their offering
  • Teams who tried React Native, got stuck on the EAS Build setup, and bounced
  • SaaS companies who want a thin mobile companion to their existing web product
If you only need a mobile-responsive website, build a regular Hiveku project instead and let the responsive layout handle phones. Native Mobile is the right tool when you specifically need: notifications that wake the device, an icon on the home screen, App Store discovery, or native APIs (camera, biometrics, haptics, file system).

​
What you get

  • A working app on day one. The starter scaffold ships with Supabase auth, protected routes, an items CRUD screen, and a small set of shadcn-style RN components. Run it in the phone-frame preview, sign up a test user, create an item — all working end-to-end before you write a line of code.
  • A device emulator inside the editor. Phone-frame iframe with 11 device presets (iPhone SE through iPhone 15 Pro Max, Pixel 8, Galaxy Fold, iPad mini, iPad Pro), portrait/landscape toggle, and per-device color variants. Your edits render live; no real phone required for layout work.
  • One-click EAS Build + auto-submit. Click Build & ship on the Builds page, wait 20-30 minutes, your app is in TestFlight (iOS) and the configured Google Play track (Android). Auto-submit works because Hiveku stores your encrypted ASC API key + Google service account JSON.
  • Fast OTA updates. JS-only changes (screens, styles, logic) publish to your testers in ~30 seconds via EAS Update — no native rebuild needed. Preview channel for QA, production channel for live users.
  • AI that knows mobile. The AI chat is trained on Expo Router conventions, NativeWind, the items pattern in your starter, and the difference between a JS edit (OTA Publish) and a native dependency (full Build & ship).
  • AI-fixed build failures. When Apple rejects your build with a cryptic ITMS-90013 or your Android keystore mismatch hits, the AI sees the error in context and proposes a fix in the same chat session.
  • AI-generated App Store listing. App icon, description, subtitle, keywords, and promotional text generated from your app name + tagline + accent color. Saves the icon to your project; you copy the text into App Store Connect.

​
What you give up vs. building manually

  • Hiveku-namespaced bundle ID. Apps are published as com.hiveku.<12-hex> for collision-free namespacing. If you migrate off Hiveku later you’d register a new bundle ID under your own namespace and migrate users (App Store treats a new bundle as a new app). For most apps this is fine; for established brands that need a vanity bundle ID it’s a tradeoff.
  • Expo managed workflow. You can’t drop in arbitrary native iOS/Android code, only use existing Expo modules and packages with config plugins. Most apps never need to leave managed workflow.
  • Shared EAS organization. Your EAS project lives under Hiveku’s Expo organization and shares the build-credit meter with other Hiveku customers. Per-tenant Expo orgs are on the roadmap for enterprise customers who need their own EAS billing.
  • No real-device emulator. The preview is React Native Web in a phone-frame iframe. Native APIs (camera, push notifications, haptics, biometric auth, file system) won’t fire in preview. You test those by deploying via EAS Update and opening on a real phone with Expo Go.

​
Prerequisites

You need two paid developer accounts to ship to actual app stores. Hiveku doesn’t provide these — they’re owned by you:
  • Apple Developer Program — $99/year. Required for iOS builds and TestFlight distribution. Allow ~24 hours for Apple to verify.
  • Google Play Developer — $25 one-time. Required for Android builds and Play Console distribution.
You can build and run the preview without these accounts — you just won’t be able to ship to actual app stores until they’re set up.

​
Setup flow

1

Create the project

New Site → Native Mobile card → enter a name. Hiveku scaffolds the Expo Router project and provisions a per-project Supabase database in ~60 seconds.
2

Open Getting Started

The Getting Started tab is selected by default for new mobile projects. It walks the seven steps from “sign up for Apple Developer” through “your app is in TestFlight.” Each step shows its current state (done / ready / pending).
3

Connect Apple + Google credentials

On the Mobile Credentials page, paste your App Store Connect API key (.p8 + Issuer ID + Key ID) and Google Play service account JSON. Both inline guides walk the 5-step setup. Click Verify credentials now to confirm before your first build.
4

Iterate with AI in the editor

Open the editor, type into the AI chat. The phone-frame preview reflects your changes within ~1.5 seconds. Add screens, change styles, hook up Supabase tables — same loop as a Hiveku web project, just rendered as a mobile app.
5

Publish OTA updates while you iterate

From the Builds page, click Publish to preview for fast (~30s) JS-only updates. Open the resulting expo.dev/preview/... URL on a phone with Expo Go to see live changes.
6

Ship a native build to TestFlight + Play Console

Click Build & ship on the Builds page. Wait 20-30 minutes. The build auto-submits to TestFlight (iOS) and your configured Google Play track (Android). You’ll get an email when it lands.

​
Where to start

Quickstart

The full path from “create project” to “first TestFlight upload” in 60 minutes.

Connect Credentials

Apple Developer + Google Play credential setup with inline 5-step guides.

Phone-Frame Preview

11 device presets, landscape mode, device colors, and how to QA layouts at the extremes.

Builds & Submissions

OTA Update channels, native Build & Ship, cancel button, Fix-with-AI on failures.

App Store Assets

AI-generate your app icon, store description, keywords, and subtitle in one form.

Native Modules

Which packages need a Build & Ship, which work via OTA, and which to avoid.

​
How it fits with the rest of Hiveku

Mobile uses the same code editor, the same AI chat, the same GitHub integration, and the same Supabase database flow you already know from Hiveku web projects. The differences are scoped: a different project type, a different preview chrome, a different deploy path. Auto-commit on AI edits works identically. CRM bridge from Supabase auth users works identically. The AI agent knows it’s working on a mobile project and steers you toward Expo Router + NativeWind conventions instead of Next.js + web Tailwind. A few cross-module patterns:
  • Web project + mobile companion in the same workspace. Build the marketing site as one Hiveku project, the mobile app as a separate Native Mobile project, share the same Supabase database between them.
  • GitHub-backed mobile project. Connect the mobile project to a GitHub repo from Settings. AI edits auto-commit. .env is auto-excluded so your Supabase keys don’t leak. Auto-deploy on push is hidden for mobile (you trigger builds manually via the Builds page).
  • Workflow triggers from mobile-app events. Supabase row inserts (a user signs up, an item is created) can fire Hiveku workflows the same way Shopify orders do — same trigger architecture across web, commerce, and mobile.

​
Where the data lives

Mobile-specific configuration is stored in website_projects.expo_config (a JSON column):
  • bundle_identifier — the iOS bundle id (also used as Android package). Locked to com.hiveku.<12-hex> derived from the project id.
  • eas_project_id — registered with Expo on first build.
  • ios.* — Apple Developer Team ID, ASC Issuer ID, ASC App ID, auto-submit toggle.
  • android.* — Play Console application ID, Play track (internal / alpha / beta / production), auto-submit toggle.
  • webhook_build_registered_at / webhook_submit_registered_at — markers so EAS webhooks register only once per project.
The actual encrypted credentials (.p8 contents, Google service account JSON) live in AWS Secrets Manager keyed by project ID — never stored in plaintext on disk or in the database.
If you’re brand new, the Quickstart walks the entire path — create project, connect Apple + Google, first build, first TestFlight upload — in one sitting (~60 minutes if you already have developer accounts; +24 hours if you need to enroll in Apple Developer Program first).