Back
Publish to App Stores

How publishing works

The technical pipeline VULK runs to turn your generated web app into a signed, submitted store app.

How publishing works

VULK generates web apps (React / Vite). Stores ship native apps, so VULK wraps your built web app in a native shell and then builds, signs, and submits it — using your own developer credentials.

The pipeline

generate (VULK)
  → build web (vite build → dist/)
  → wrap native (Capacitor 8 → ios/ + android/ projects)
  → iOS:     xcodebuild archive → sign → .ipa → upload → submit
  → Android: gradle bundleRelease → sign → .aab → upload → release track

1. Wrap — Capacitor 8

Your compiled SPA is wrapped with Capacitor 8 (appId = reverse-DNS bundle id, webDir = dist). This produces a real Xcode project and a real Gradle project that VULK fully controls — assets are bundled to work offline, and native capabilities (push, haptics, share, status-bar, deep links) are added so the app is a real app, not a thin web view (this matters for review — see Limitations).

2a. iOS build & sign — on macOS

xcodebuild archive + -exportArchive produce a signed .ipa. Signing uses App Store Connect API-managed signing (-allowProvisioningUpdates with your API key): VULK creates/fetches the distribution certificate and provisioning profile via the API automatically — no manual portal work.

iOS archiving and signing must run on macOS — Apple's xcodebuild does not exist on Linux/Windows. This is an Apple constraint, true for every tool that ships to the App Store. VULK runs this on macOS build infrastructure for you.

2b. Android build & sign — on Linux

./gradlew bundleRelease produces an .aab. Signing uses an upload key with Play App Signing (Google holds the real distribution key; the upload key is recoverable via Play support if lost). VULK generates and securely stores the per-app upload keystore.

3. Upload & submit

  • iOS: the .ipa is uploaded to App Store Connect, VULK waits for Apple build processing, attaches the build to an App Store version, fills metadata/screenshots, then submits for review — all via the App Store Connect API with your key. TestFlight first is recommended.
  • Android: the .aab is uploaded via the Google Play Developer API (edits.insert → bundles.upload → tracks.update → commit) to the track you choose (internal → closed → open → production).

Who is the publisher

Every API call is signed with your key and runs against your developer account. VULK is your automation — exactly the model EAS Submit, Codemagic and fastlane use. You remain the developer of record and the responsible submitter (required by Apple Guideline 4.2.6 and the Google Play API terms).

Publish to TestFlight (iOS) / the internal track (Android) before production. These validate the entire build+sign+upload pipeline on a real device without going through public App Review, so you can confirm everything works end-to-end safely. See Limitations for the review gates that apply to a public release.

On this page

VULK Support

Online

Hi! How can I help you today?

Popular topics

AI support • support.vulk.dev