Mobile App Builder

Paid pluginsize XLplanned, not built

Indicative price, not an offer: EUR 500-1500/year or EUR 2000-3000 one-off

Generated from docs/plan/paid/mobile-app-builder/PLAN.md in the AstroBaaS repository. Nothing described below is implemented — it is the written plan for it.

A paid premium module to generate native iOS/Android apps for merchants’ storefronts, handling app store submission, push notifications, offline mode, and ongoing OS compatibility updates. Core provides JSON APIs; this pack owns app scaffolding, app store submission, and platform support SLA.

The problem

Merchants expect app store presence but iOS/Android development costs €5000+. App builder generates a native app from the storefront, handles app store submission, and maintains compatibility with new OS versions (iOS 18, Android 15).

What it does

• App scaffolding: generate iOS (Swift) + Android (Kotlin) projects from storefront config (colors, logo, menu structure)
• Product browsing: app displays products, categories, search (reads from JSON API)
• Shopping cart & checkout: full checkout flow in app, tokenized payment (Stripe, Apple Pay, Google Pay)
• Push notifications: send order status updates, promotions to app users
• Offline mode: cache product list, allow browsing offline (read-only, checkout requires online)
• App store submission: support team manages Apple App Store and Google Play listings, handles rejections
• OS compatibility updates: maintain app compatibility with new iOS/Android versions (quarterly releases)

What it deliberately does NOT do

Each boundary carries its reason. A boundary without a reason gets crossed by the next person who reads this.

• Custom native features (AR, geolocation, camera)—too niche; merchants request via support
• App analytics (downloads, crashes, user retention)—use Firebase/App Center, not built-in
• A/B testing in app—owned by experimentation module
• Subscription management in app—uses same Stripe Billing as web
• Offline checkout—requires complex sync logic; read-only offline only

Data model

New entities: MobileApp (id, merchantId, appName, appVersion, iosAppId, androidAppId, status[pending|approved|rejected|live], submittedAt, approvedAt, rejectionReason); AppConfig (id, appId, themeColor, logoUrl, menuStructure, pushNotificationsEnabled); AppRelease (id, appId, version, releaseNotes, osVersion[ios|android], submittedAt, approvedAt). Links: MobileApp.merchantId → Shop. Migration: none (new data).

API

• POST /api/v1/mobile-apps — initiate app generation (merchant provides name, colors, logo) (staff only)
• GET /api/v1/mobile-apps/{id} — fetch app status (staff only)
• PATCH /api/v1/mobile-apps/{id} — update app config (theme, logo, menus) (staff only)
• POST /api/v1/mobile-apps/{id}/submit-appstore — submit app to Apple App Store / Google Play (staff only, async)
• GET /api/v1/mobile-apps/{id}/submission-status — check App Store submission status (staff only)
• POST /api/v1/mobile-apps/{id}/push-notification — send push to app users (staff only)
• GET /api/v1/mobile-apps/{id}/analytics — app downloads, active users, crashes (read from Firebase) (staff only)

Every route added here must also appear in src/pages/openapi.json.ts — a test fails the build if it does not.

Admin

Mobile apps page: list apps per merchant (app name, status, app store link if live). App detail: config form (theme color, logo upload, menu editor). Submission section: status (pending review, rejected with reason, approved, live). Push notification form: message, target audience (all users, recent buyers, etc.), send. Analytics card (if live): downloads count, active users (last 7 days), crash rate.

The seam — why this is paid

Core owns: JSON APIs (products, orders, checkout), payment tokenization. Paid pack owns: iOS/Android app scaffolding, app store submission (credentials, guidelines), push notification infrastructure, OS compatibility testing/updates, support SLA. Seam drawn here because app store submission requires legal review (privacy policy, merchant terms)—support team handles Apple/Google compliance.

Requires platform integration (Apple App Store, Google Play), push notifications, and ongoing mobile OS support.

Dependencies

• core:products-api — app fetches products via JSON
• core:checkout-api — app submits orders via API
• core:authentication — app users authenticate with shop account
• core:payment-tokenization — app uses tokenized payments (Stripe, Apple Pay, Google Pay)
• external:Firebase or App Center — push notifications, crash reporting

Acceptance checks

Each of these must be able to fail. Before claiming this is done, break the code deliberately and watch each one go red.

• Merchant initiates app generation (app name: ‘My Shop’, theme color: #FF5733, logo uploaded). App scaffolding is generated (iOS project + Android project), ready for testing
• App displays products from JSON API; browsing category ‘Electronics’ shows all products in that category with images, prices, descriptions
• User adds product to cart, proceeds to checkout; payment is tokenized via Stripe, order is created in shop system, confirmation is shown in app
• Push notification is sent to app users: ‘Your order #123 has shipped’; users receive notification on device (iOS and Android)
• App is submitted to Apple App Store; status shows ‘pending review’; after 24-48 hours, Apple responds (approved or rejected with reason)
• New iOS version (iOS 18) is released; support team updates app SDK, tests compatibility, submits update to App Store within 2 weeks
• Offline mode: user opens app offline, product list is shown (cached), clicking ‘Checkout’ shows ‘Go online to complete purchase’
• Two merchants have separate apps; each app displays only their respective products and orders

Risks

App store guidelines are strict—privacy policy, terms of service, data handling must comply. Review times vary (1-7 days)—merchants need patience. Push notification fatigue can annoy users—merchants must choose frequency wisely. App size (iOS/Android) must be < 100 MB—monitor dependencies. Offline cache sync is complex—test edge cases (user makes purchase offline then comes online). OS updates (iOS 18, Android 15) require quarterly maintenance—budget support time.

Commercial context

The anchor is what the nearest equivalent charges on Shopify or Magento today. It is context for a pricing decision, not the decision.

---

Generated from the commerce plan. See docs/COMMERCE-PLAN.md for the full catalogue and ../../AI-GUIDE.md for how to work on this repository.