SaaS Mobile App Strategy — SKILL.md

---
name: "SaaS Mobile App Strategy"
description: "Mobile apps for SaaS: native vs PWA vs hybrid (React Native, Flutter, Expo), white-label multi-app deployment, App Store review (common rejections), push notifications (APNs/FCM), offline-first, deep linking, in-app purchases (30% commission rules), and when NOT to build an app."
version: "1.0.0"
author: "skynet"
category: "dev"
agents: ["claude-code", "codex", "gemini"]
tags: ["saas", "mobile", "ios", "android", "react-native", "pwa"]
---

# SaaS Mobile App Strategy

---
name: "SaaS Mobile App Strategy"
description: "Mobile apps for SaaS: native vs PWA vs hybrid (React Native, Flutter, Expo), white-label multi-app deployment, App Store review (common rejections), push notifications (APNs/FCM), offline-first, deep "
version: "1.0.0"
author: "skynet"
category: "dev"
tags: ["saas", "mobile", "ios", "android", "react-native", "pwa"]
---

# SaaS Mobile Strategy: The Engineering & Product Reference

Building a mobile extension for a SaaS product is not just about shrinking the web UI. It is a strategic decision involving platform compliance, distribution friction, and high-stakes synchronization logic.

---

### 1. The Stack: Native vs. PWA vs. Hybrid
The "best" stack is determined by the intersection of hardware access and development velocity.

| Feature | PWA | Hybrid (Capacitor) | Cross-Platform (React Native/Expo/Flutter) | Native (Swift/Kotlin) |
| :--- | :--- | :--- | :--- | :--- |
| **Push Notifications** | Limited (iOS 16.4+) | Full | Full | Full |
| **Offline Performance** | Service Workers | Plugin-based | Native-grade | Best |
| **Dev Velocity** | Highest (Web) | High | Medium-High | Low (Two codebases) |
| **Hardware Access** | Sandbox limited | Via Plugins | Native Modules | Direct |

**Decision Framework:**
*   **Choose Expo (React Native):** For 90% of SaaS. It provides native performance with the speed of JS, excellent "Over-the-Air" (OTA) updates via EAS, and a massive library of config plugins.
*   **Choose PWA:** For internal tools or CRUD apps where users are already on desktop and need a "quick check" on mobile without App Store friction.
*   **Choose Native:** Only if your core value prop is high-performance GPU tasks (video editing), complex background processing, or bleeding-edge OS features (e.g., Dynamic Island) before they reach cross-platform bridges.

---

### 2. White-Label Architectures
SaaS companies serving enterprises often need to deploy "branded" versions of the same app.

*   **The Problem:** Apple’s **Guideline 4.3 (Spam)** forbids submitting multiple identical apps.
*   **The Strategy:**
    1.  **Container Apps:** One "Parent" app in the store; users log in and the UI dynamically rebrands (colors, logos, features) based on the tenant ID. **(Highly Recommended)**
    2.  **True White-Label:** If the client insists on their own App Store listing, use **Expo Config Plugins**. You maintain one codebase and use environment variables/build flavors to inject unique `bundleIdentifier`, `google-services.json`, and asset folders during CI/CD (GitHub Actions + Fastlane).

---

### 3. The App Store "Minefield"
App Store Review is the primary risk factor for SaaS mobile delivery.

*   **Guideline 4.2 (Minimum Functionality):** Your app cannot just be a "web wrapper." It must use native features (push, haptics, offline storage) or it will be rejected.
*   **Guideline 3.1.1 (In-App Purchases):** If you sell digital goods (SaaS seats, credits) consumed *in the app*, you **must** use Apple IAP and pay the 30% (or 15% for Small Business) tax.
    *   **Workaround:** "Reader Apps" (Netflix, Kindle) can allow login to access content bought elsewhere, but cannot link to a web checkout. B2B "Enterprise" apps sold via invoice are usually exempt.
*   **ASO (App Store Optimization):** Focus on the first 3 screenshots. They should show value (e.g., "Manage Leads on the Go"), not just UI.

---

### 4. Push Notifications & Engagement
Push is the #1 reason users install SaaS apps.

*   **Infrastructure:** Use **FCM (Firebase Cloud Messaging)** as the unified bridge for both APNs (iOS) and Android.
*   **UX Pattern:** Never ask for permissions on the first launch. Wait for a "Value Moment" (e.g., a user sets a reminder or expects an alert).
*   **Silent Push:** Use `content-available: 1` to wake the app in the background to sync data before the user even opens the notification.

---

### 5. Offline-First & Sync
SaaS apps are often used in "dead zones" (elevators, planes, job sites).

*   **Storage:** Use **MMKV** for high-speed key-value storage or **SQLite (via expo-sqlite)** for relational data.
*   **Architecture:**
    *   **Optimistic UI:** Update the local state immediately.
    *   **Queueing:** Store mutations in a local "Outbox."
    *   **Conflict Resolution:** Last-write-wins (LWW) is standard for most SaaS; use CRDTs for collaborative editors.

---

### 6. Authentication & Deep Linking
Mobile auth must be frictionless.

*   **Biometrics:** Implement `expo-local-authentication`. Use it to unlock an existing session, not to replace the initial login.
*   **Deep Linking:** 
    *   **iOS Universal Links / Android App Links:** Use these for magic links. They prevent the browser from opening and jump straight into the app.
    *   **Deferred Deep Linking:** Use **Branch.io** or **AppsFlyer** to preserve the link context even if the user has to install the app first.

---

### 7. Performance Optimization
*   **List Rendering:** Standard `FlatList` in React Native struggles with thousands of rows. Use **@shopify/flash-list** for near-native virtualization.
*   **Startup Time:** Minimize the size of your JS bundle. Use "dynamic imports" for heavy libraries.
*   **Image Caching:** Use `expo-image` (built on SDWebImage/Glide) to handle memory-efficient caching and blur-hash placeholders.

---

### 8. Analytics & Observability
Mobile metrics differ from web metrics.
*   **KPIs:**
    *   **D1/D7 Retention:** Do they come back after the first day?
    *   **Cold Start Time:** How long from tap to interactive?
    *   **Crash Free Sessions:** Aim for >99.9%.
*   **Tools:** **Sentry** for crash reporting; **PostHog** or **Amplitude** for event tracking.

---

### 9. When NOT to Build
Do not build a mobile app if:
1.  **Complexity is too high:** Your web app requires 27-inch monitor screen real estate (e.g., complex Gantt charts).
2.  **No Native Hook:** If you don't need Push, Camera, Offline, or Location, a well-optimized mobile-responsive website is faster to iterate on and costs $0 in "App Store Tax."

---

I'd add this as: **SaaS Mobile Strategy: The Engineering & Product Reference** in **software-engineering, product-strategy** — want me to?