rn-store-skills 4.0.0 → 5.0.0

package/README.md

@@ -4,13 +4,15 @@ React Native store compliance + App Store Connect automation skills for AI codin
 
 17 skills covering everything from rejection prevention to release automation.
 
+> Apple rejected ~1.93 million of ~7.77 million app submissions in 2024 — roughly **25% of all submissions**. Most rejections come from a small set of repeated mistakes. This skill pack helps AI agents catch every one of them before review.
+
 ## Skills
 
 ### Store Compliance
 
 | Skill | Description |
 |-------|-------------|
-| `rn-store-compliance` | React Native compliance checker — Apple & Google guidelines, 20+ rejection rules, 10 app-type checklists, RN-specific patterns |
+| `rn-store-compliance` | React Native compliance checker — Apple & Google guidelines, 30+ rejection rules, 10 app-type checklists, RN-specific patterns, copyright/IP, legal compliance, OTA update rules |
 
 ### App Store Connect CLI (`asc`)
 
@@ -97,7 +99,7 @@ skills/
 │   ├── SKILL.md
 │   └── references/
 │       ├── guidelines/                   ← Apple & Google guidelines
-│       ├── rules/                        ← 7 detection rule sets
+│       ├── rules/                        ← 11 detection rule sets
 │       ├── app-types/                    ← 7 app category checklists
 │       ├── features/                     ← 3 feature checklists
 │       ├── all-apps.md                   ← Universal checklist
@@ -133,7 +135,8 @@ skills/
 ### Store Compliance (rn-store-compliance)
 - Apple App Store Review Guidelines (1.x–5.x) — full index
 - Google Play Store Policies — full index
-- 20+ rejection rules with detection patterns, fixes, and real rejection messages
+- 30+ rejection rules with detection patterns, fixes, and real rejection messages
+- 11 rule categories (metadata, subscriptions, privacy, design, entitlements, performance, permissions, copyright/IP, legal, OTA updates, app completeness)
 - 7 app-type checklists (social, kids, health, games, AI, crypto, VPN)
 - 3 feature checklists (subscriptions, UGC, macOS)
 - React Native / Expo specific patterns and detection

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "rn-store-skills",
-  "version": "4.0.0",
-  "description": "React Native store compliance + App Store Connect automation skills for AI coding agents. 17 skills covering rejection prevention, build management, metadata, TestFlight, signing, pricing, and more.",
+  "version": "5.0.0",
+  "description": "React Native store compliance + App Store Connect automation skills for AI coding agents. 17 skills covering rejection prevention, copyright/IP, legal compliance, OTA updates, subscriptions, build management, metadata, TestFlight, signing, pricing, and more.",
   "keywords": [
     "agent-skill",
     "react-native",

package/skills/rn-store-compliance/SKILL.md

@@ -14,7 +14,7 @@ description: >
 license: MIT
 metadata:
   author: JohnAdib
-  version: "2.0.0"
+  version: "5.0.0"
   tags:
     - react-native
     - expo
@@ -91,6 +91,10 @@ When you need detection patterns, fix steps, and example rejection messages:
 | Entitlement/capability issues | `references/rules/entitlements.md` |
 | Crashes / performance | `references/rules/performance.md` |
 | Permission problems | `references/rules/permissions.md` |
+| Copyright / IP / media | `references/rules/copyright-media.md` |
+| Legal compliance (GDPR, COPPA, DMA) | `references/rules/legal.md` |
+| OTA / CodePush update violations | `references/rules/ota-updates.md` |
+| App completeness / demo accounts | `references/rules/app-completeness.md` |
 
 ### Step 5: Submission & Rejection
 
@@ -126,3 +130,8 @@ When you need detection patterns, fix steps, and example rejection messages:
 | VPN app | `app-types/vpn.md` |
 | macOS app | `features/macos.md` + `rules/entitlements.md` |
 | Upgrading React Native | `react-native.md` + `rules/performance.md` |
+| Copyright / media licensing | `rules/copyright-media.md` |
+| Legal / GDPR / COPPA / DMA | `rules/legal.md` + `rules/privacy.md` |
+| OTA updates (CodePush/Expo Updates) | `rules/ota-updates.md` + `react-native.md` |
+| App completeness / demo account | `rules/app-completeness.md` |
+| Account deletion requirement | `rules/design.md` + `rules/legal.md` |

package/skills/rn-store-compliance/references/all-apps.md

@@ -54,6 +54,28 @@ Master checklist loaded for every app regardless of type or category.
 - [ ] POST_NOTIFICATIONS runtime permission handled (Android 13+)
 - [ ] 16 KB page size compatibility for native libraries
 
+## Copyright & Intellectual Property
+
+- [ ] All images properly licensed (owned, stock licensed, or CC0/permissive)
+- [ ] No copyrighted music or audio without license
+- [ ] No copyrighted video content without distribution rights
+- [ ] Fonts properly licensed for mobile app embedding
+- [ ] Open source licenses complied with (no GPL in App Store without compliance)
+- [ ] AI-generated content does not depict real people without consent
+- [ ] No screenshots or recordings of competitor apps
+- [ ] DMCA / copyright takedown process if app hosts user content
+
+## Legal Compliance
+
+- [ ] GDPR consent before data collection (EU users)
+- [ ] Account deletion available in-app (if account creation exists)
+- [ ] Export compliance: `ITSAppUsesNonExemptEncryption` set in Info.plist
+- [ ] COPPA compliance if targeting children under 13
+- [ ] Age rating questionnaire completed honestly
+- [ ] Terms of Service accessible in-app and on store listing
+- [ ] Loot box / gacha odds disclosed before purchase (if applicable)
+- [ ] Regional legal requirements checked (China AI terms, Russia data localization)
+
 ## Design & UX
 
 - [ ] Not a copycat of another app
@@ -79,6 +101,22 @@ Master checklist loaded for every app regardless of type or category.
 - [ ] Certificate/signing valid and not expired
 - [ ] Version number incremented above current live version
 
+## App Completeness
+
+- [ ] Demo account provided in review notes (if login required)
+- [ ] All premium features accessible during review (demo account unlocked or sandbox IAP instructions)
+- [ ] No placeholder content (Lorem ipsum, stock photos as real content, "coming soon")
+- [ ] No debug/staging labels or environment indicators in production
+- [ ] Backend services live and stable during review period (24/7)
+- [ ] All buttons and navigation destinations functional
+- [ ] No hardcoded localhost/staging URLs in production build
+
+## OTA Updates
+
+- [ ] OTA (CodePush/Expo Updates) used only for bug fixes, not new features
+- [ ] No hidden feature activation via remote config or date triggers
+- [ ] Feature flags only toggle features already present in reviewed binary
+
 ## Related Rules
 
 - See `rules/metadata.md` for metadata rejection patterns
@@ -88,3 +126,7 @@ Master checklist loaded for every app regardless of type or category.
 - See `rules/permissions.md` for permission patterns
 - See `rules/subscriptions.md` if app has subscriptions/IAP
 - See `rules/entitlements.md` for entitlement/capability issues
+- See `rules/copyright-media.md` for copyright/IP/media issues
+- See `rules/legal.md` for legal compliance (GDPR, COPPA, DMA, export)
+- See `rules/ota-updates.md` for OTA/CodePush update violations
+- See `rules/app-completeness.md` for demo accounts, placeholder content, backend readiness

package/skills/rn-store-compliance/references/features/subscriptions.md

@@ -52,3 +52,165 @@ Feature checklist — any app type can have subscriptions or in-app purchases.
 - Not testing sandbox purchases on real devices before submission.
 - Subscription screen missing required links (privacy policy, terms).
 - Play Billing Library version too old — Google rejects outdated versions.
+
+---
+
+## Auto-Renewal Disclosure (Required Legal Text)
+
+### Apple
+Subscription screens must include this disclosure (or equivalent) near the subscribe button:
+- "Payment will be charged to your Apple ID account at confirmation of purchase."
+- "Subscription automatically renews unless it is canceled at least 24 hours before the end of the current period."
+- "Your account will be charged for renewal within 24 hours prior to the end of the current period."
+- "You can manage and cancel your subscriptions by going to your account settings on the App Store after purchase."
+
+### Google Play
+- "Your subscription will automatically renew and your payment method will be charged at the start of each billing period."
+- "You can cancel anytime in Google Play Store > Subscriptions."
+
+Both stores: the disclosure must be visible without scrolling — not buried in fine print.
+
+---
+
+## Subscription Management Link
+
+### Apple
+Include a tappable link to Apple's subscription management page:
+```tsx
+import { Linking, Platform } from 'react-native';
+
+const openSubscriptionManagement = () => {
+  if (Platform.OS === 'ios') {
+    Linking.openURL('https://apps.apple.com/account/subscriptions');
+    // Or deep link: itms-apps://apps.apple.com/account/subscriptions
+  }
+};
+```
+Place this in Settings screen and/or subscription management UI.
+
+### Google Play
+```tsx
+const openPlaySubscriptions = () => {
+  if (Platform.OS === 'android') {
+    Linking.openURL('https://play.google.com/store/account/subscriptions');
+  }
+};
+```
+
+---
+
+## Cancellation UX
+
+- [ ] Cancellation instructions clearly visible in Settings / Account / Subscription screen
+- [ ] No dark patterns — do not hide the cancel option, require multi-step confirmations, or use confusing language
+- [ ] Do not show misleading "Are you sure?" flows that make it hard to cancel
+- [ ] After cancellation, clearly show when access expires
+- [ ] Apple: you cannot cancel subscriptions programmatically — you must link to Apple's subscription management
+- [ ] Google: you can cancel via Play Billing API server-side, but the standard approach is linking to Play Store subscription settings
+
+---
+
+## Grace Period and Billing Retry
+
+### Apple
+- Apple has automatic billing retry for 60 days after a failed payment
+- Grace period (optional, enable in App Store Connect): keeps subscription active for 6 or 16 days during billing retry
+- Enable grace period in App Store Connect → Subscriptions → Billing Grace Period
+- Your app should check `Transaction.expirationDate` and `Transaction.revocationDate` in StoreKit 2
+
+### Google Play
+- Grace period: configurable (3, 7, 14, or 30 days) in Play Console
+- Account hold: after grace period expires, subscription enters hold for up to 30 days
+- Your app should handle `SUBSCRIPTION_ON_HOLD` state — show "update payment method" message
+
+### React Native Implementation
+```tsx
+// StoreKit 2 via react-native-iap v12+
+import { getAvailablePurchases, purchaseUpdatedListener } from 'react-native-iap';
+
+// Listen for transaction updates (renewals, expirations, revocations)
+purchaseUpdatedListener(async (purchase) => {
+  // Validate receipt server-side
+  // Check subscription status including grace period
+});
+```
+
+### RevenueCat
+RevenueCat handles grace period and billing retry automatically:
+- `CustomerInfo.entitlements` reflects active entitlement during grace period
+- Webhooks: `BILLING_ISSUE_DETECTED`, `SUBSCRIPTION_PAUSED`, `EXPIRATION`
+- Check `subscriberInfo.entitlements.active` — it accounts for grace period
+
+---
+
+## Family Sharing
+
+### Apple
+- [ ] Enable Family Sharing for subscriptions in App Store Connect (optional)
+- [ ] If enabled, check entitlements for family members using StoreKit 2 `Transaction.ownershipType`
+- [ ] `Transaction.ownershipType == .familyShared` indicates access via family sharing
+- [ ] Family organizer manages the subscription — individual family members cannot cancel
+
+### Google Play
+- [ ] Family Library not available for subscriptions on Google Play
+- [ ] Only one-time purchases can be shared via Family Library
+
+---
+
+## Offer Codes and Promo Codes
+
+### Apple
+- [ ] Offer codes: create in App Store Connect → Subscriptions → Offer Codes
+- [ ] One-time use or multi-use codes
+- [ ] Redeem via `presentCodeRedemptionSheet()` in StoreKit 2
+- [ ] React Native: `react-native-iap` supports `presentCodeRedemptionSheetIOS()`
+
+### Google Play
+- [ ] Promo codes: create in Play Console → Monetize → Products → Promo codes
+- [ ] Limited to 500 codes per quarter per app
+- [ ] Redeem via Play Store or deep link
+
+---
+
+## Price Increase Consent
+
+### Apple (StoreKit 2)
+- If you raise the price of an existing subscription, Apple requires user consent
+- Price increases < 50% AND < $5 (or equivalent): Apple auto-consents if user is on auto-renew
+- Price increases above thresholds: Apple shows consent dialog, subscription cancelled if user doesn't accept within 60 days
+- Listen for price consent messages:
+```tsx
+// StoreKit 2 Message listener
+import { Message } from 'StoreKit';
+// In react-native-iap, handle price consent via purchase update listener
+```
+
+### Google Play
+- Google notifies users of price increases automatically
+- Users have 30 days to accept; subscription cancelled if declined
+- Implement `onPriceChangeConfirmationResult` callback
+
+---
+
+## Subscription Upgrade / Downgrade
+
+### Apple
+- [ ] Upgrade: immediate, prorated refund for remaining time on current plan
+- [ ] Downgrade: takes effect at next renewal date
+- [ ] Crossgrade (same tier, different duration): treated as upgrade or downgrade depending on value
+- [ ] Implement `Product.SubscriptionInfo.UpgradePolicy` handling in StoreKit 2
+
+### Google Play
+- [ ] Proration modes: `IMMEDIATE_WITH_TIME_PRORATION`, `IMMEDIATE_AND_CHARGE_PRORATED_PRICE`, `DEFERRED`, etc.
+- [ ] Set proration mode when calling `launchBillingFlow` for upgrade/downgrade
+- [ ] `react-native-iap`: pass `prorationModeAndroid` parameter
+
+---
+
+## Introductory Offer Eligibility
+
+- [ ] Check eligibility BEFORE displaying offer pricing — don't show introductory price to ineligible users
+- [ ] Apple: `Product.subscription.isEligibleForIntroOffer` (StoreKit 2)
+- [ ] Google: `SubscriptionOfferDetails.pricingPhases` — check if free trial phase exists for this user
+- [ ] RevenueCat: `offerings.current.availablePackages[0].product.introPrice` — RevenueCat handles eligibility
+- [ ] Displaying intro offer to ineligible users is misleading and can trigger rejection under 3.1.2

package/skills/rn-store-compliance/references/react-native.md

@@ -190,6 +190,78 @@ Validate all parameters. Test from: cold start, background, other apps, Safari/C
 ### 10. Large App Size
 See `rules/performance.md` for size reduction strategies.
 
+### 11. OTA Update Violations (CodePush / Expo Updates)
+Using CodePush or Expo Updates to push new features (not just bug fixes) violates Apple 3.3.2.
+See `rules/ota-updates.md` for what's allowed and what's not.
+
+### 12. IPv6-Only Network Failure
+Apple tests on IPv6-only networks. Hardcoded IPv4 addresses or IPv4-only APIs fail.
+See IPv6 section below.
+
+---
+
+## IPv6-Only Network Compliance
+
+**Apple**: 2.5.6 — IPv6 | **Severity**: REJECTION
+
+Apple reviews apps on IPv6-only networks (NAT64/DNS64). If your app uses hardcoded IPv4 addresses, raw IP sockets, or APIs that don't support IPv6, it will fail during review.
+
+**Common React Native issues:**
+- Hardcoded IPv4 addresses in API URLs (`http://192.168.1.1`, `http://10.0.0.1`)
+- WebSocket connections to IPv4-only servers
+- Third-party SDKs that use raw sockets (some analytics, game SDKs)
+- Custom native modules using `AF_INET` without `AF_INET6` support
+
+**Detection:**
+```bash
+# Check for hardcoded IPv4 addresses
+grep -rnE "\b\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}\b" \
+  --include="*.tsx" --include="*.ts" --include="*.jsx" --include="*.js" \
+  src/ app/ 2>/dev/null | grep -v "node_modules" | grep -v "0\.0\.0\.0" | grep -v "255\.255"
+
+# Check native code for IPv4-only socket usage
+grep -rnE "(AF_INET[^6]|inet_addr|SOCK_STREAM.*AF_INET)" \
+  --include="*.swift" --include="*.m" --include="*.mm" --include="*.h" \
+  ios/ 2>/dev/null
+```
+
+**Fix:**
+1. Use hostnames (domain names) instead of IP addresses — DNS resolution handles IPv6 automatically.
+2. Use high-level networking APIs (`NSURLSession`, `fetch`, `axios`) — they support IPv6 natively.
+3. Test on an IPv6-only network: Mac → System Preferences → Sharing → Internet Sharing → "Create NAT64 Network."
+4. If using custom native modules with sockets, use `getaddrinfo()` which returns both IPv4 and IPv6 addresses.
+
+---
+
+## OTA Updates (CodePush / Expo Updates)
+
+React Native's JS-based architecture enables over-the-air updates without store review. This is powerful but strictly regulated.
+
+**Key rule**: OTA is allowed ONLY for bug fixes and minor improvements. New features, behavior changes, or anything that changes the app's purpose MUST go through store review.
+
+See `rules/ota-updates.md` for complete rules, detection patterns, and what's allowed vs prohibited.
+
+**Quick reference:**
+- Bug fix → OTA ✅
+- Text/translation fix → OTA ✅
+- New screen or feature → Store submission required ❌
+- New IAP product → Store submission required ❌
+- Permission change → Store submission required ❌
+
+---
+
+## New Architecture (Fabric / TurboModules)
+
+React Native's New Architecture (enabled by default in RN 0.76+) changes the native bridge. Compliance implications:
+
+- **Bridgeless mode**: Native modules must be rewritten as TurboModules. Verify all third-party libraries support New Architecture before upgrading.
+- **Fabric renderer**: Custom native views need Fabric components. Check library compatibility.
+- **Build size**: New Architecture may slightly increase binary size. Monitor against store limits.
+- **Crash patterns**: New bridge behavior may introduce new crash vectors in release builds. Test thoroughly.
+- **Hermes**: Required with New Architecture. Ensure Hermes-specific compliance (see `rules/performance.md`).
+
+Check compatibility: `npx react-native-new-architecture-check` or review the React Native New Architecture compatibility table.
+
 ---
 
 ## AI / Generative AI Features

package/skills/rn-store-compliance/references/rules/app-completeness.md

@@ -0,0 +1,222 @@
+# App Completeness Rules
+
+## Missing Demo Account for Review
+**Apple**: 2.1 — App Completeness | **Google**: Store listing requirements | **Severity**: REJECTION
+
+If your app requires login, you MUST provide a demo account in the App Review notes. The account must be pre-populated with realistic data, have all premium features unlocked (if behind paywall), and not require 2FA or external verification.
+
+### Detect
+```bash
+# Check if app has login/authentication
+grep -rnE "(login|signIn|sign.?in|auth|authenticate|LogIn|SignIn)" \
+  --include="*.tsx" --include="*.ts" --include="*.jsx" --include="*.js" \
+  src/ app/ screens/ 2>/dev/null
+
+# Check for 2FA / MFA that might block reviewers
+grep -rnE "(two.?factor|2fa|mfa|otp|verification.?code|sms.?code|authenticator)" \
+  --include="*.tsx" --include="*.ts" --include="*.jsx" --include="*.js" \
+  src/ app/ 2>/dev/null
+
+# Check for social-only login (no email/password option)
+grep -rnE "(GoogleSignin|FacebookLogin|AppleAuth)" \
+  --include="*.tsx" --include="*.ts" --include="*.jsx" --include="*.js" \
+  src/ app/ 2>/dev/null
+
+# Check for paywall / premium features
+grep -rnE "(premium|pro|subscribe|paywall|upgrade|locked|gated)" \
+  --include="*.tsx" --include="*.ts" --include="*.jsx" --include="*.js" \
+  src/ app/ 2>/dev/null
+```
+
+### Fix
+1. Create a dedicated demo account before submission:
+   - Username: `demo@yourapp.com` (or similar)
+   - Password: a simple, non-expiring password
+   - Pre-populate with realistic content (not empty states)
+   - Unlock all premium/subscription features on this account
+2. Add credentials in App Store Connect → App Review Information → Notes for Reviewer:
+   ```
+   Demo Account:
+   Email: demo@yourapp.com
+   Password: DemoPass123!
+
+   This account has Premium features unlocked for testing.
+   To test the subscription flow, navigate to Settings > Subscription.
+   ```
+3. If 2FA is required: either disable it for the demo account, or provide the 2FA seed/backup codes in the review notes.
+4. If login is social-only (Google/Apple/Facebook), also implement email/password login for the demo account, OR provide detailed instructions for how to create an account.
+5. Test the demo account before every submission — credentials expire, sessions get invalidated, passwords get rotated.
+6. If using Firebase Auth: create the demo user in Firebase Console, not through the app registration flow (to avoid triggering verification emails).
+
+### Example Rejection
+> Guideline 2.1 — Performance — App Completeness: We were unable to review your app as it requires login credentials. Please provide a demo account in the App Review notes.
+
+---
+
+## Features Hidden Behind Paywall During Review
+**Apple**: 2.1 — App Completeness | **Google**: App review policy | **Severity**: REJECTION
+
+Apple reviewers must be able to access ALL app features. If features are behind a subscription or IAP, the demo account must have them unlocked, or you must provide sandbox IAP testing instructions.
+
+### Detect
+```bash
+# Check for subscription gates
+grep -rnE "(isSubscribed|isPremium|isPro|hasPurchased|entitlement|subscription.?status)" \
+  --include="*.tsx" --include="*.ts" --include="*.jsx" --include="*.js" \
+  src/ app/ 2>/dev/null
+
+# Check for feature gates
+grep -rnE "(feature.?locked|premium.?only|upgrade.?required|purchase.?required)" \
+  --include="*.tsx" --include="*.ts" --include="*.jsx" --include="*.js" \
+  src/ app/ 2>/dev/null
+
+# Check for IAP / subscription products
+grep -rnE "(productId|purchaseProduct|requestSubscription|getSubscriptions)" \
+  --include="*.tsx" --include="*.ts" --include="*.jsx" --include="*.js" \
+  src/ app/ 2>/dev/null
+```
+
+### Fix
+1. **Option A (recommended)**: Grant the demo account full premium access server-side. Add a flag on your backend that bypasses the subscription check for the demo account.
+2. **Option B**: Provide sandbox IAP testing instructions in review notes:
+   ```
+   To test premium features:
+   1. Sign out of your personal Apple ID in Settings > Media & Purchases
+   2. Use Sandbox account: sandbox@test.com / TestPass123!
+   3. Navigate to Settings > Subscription > Subscribe
+   4. Complete the sandbox purchase (no real charge)
+   ```
+3. **Option C**: Temporarily unlock all features for the review build (using a build flag), then remove the flag for the production release. ⚠️ Risky — if Apple notices different behavior between builds, it can trigger a deeper review.
+4. Document ALL premium features and how to access them in the review notes.
+5. If your app has multiple subscription tiers, unlock the highest tier on the demo account.
+
+### Example Rejection
+> Guideline 2.1 — Performance: We were unable to access premium features in your app. Please provide a demo account with premium features unlocked or provide instructions for testing in-app purchases.
+
+---
+
+## Placeholder and Incomplete Content
+**Apple**: 2.1 — App Completeness | **Google**: Minimum functionality policy | **Severity**: REJECTION
+
+Any visible placeholder content — Lorem ipsum text, stock photo placeholders, empty states that should have data, "coming soon" labels, or debug information — triggers rejection. The app must feel complete and production-ready.
+
+### Detect
+```bash
+# Check for Lorem ipsum and placeholder text
+grep -rniE "(lorem ipsum|dolor sit amet|placeholder|dummy|sample|test data|coming soon|under construction|TODO|FIXME|HACK)" \
+  --include="*.tsx" --include="*.ts" --include="*.jsx" --include="*.js" --include="*.json" \
+  src/ app/ 2>/dev/null
+
+# Check for debug/test labels
+grep -rniE "(debug|test|staging|dev|development|beta|alpha|prototype)" \
+  --include="*.tsx" --include="*.ts" --include="*.jsx" --include="*.js" \
+  src/ app/ 2>/dev/null | grep -viE "(import|require|package|node_modules|\.test\.|\.spec\.|__test__|__mock__)"
+
+# Check for placeholder images
+find assets/ src/ -iname "*placeholder*" -o -iname "*dummy*" -o -iname "*sample*" 2>/dev/null
+
+# Check for incomplete navigation (screens that go nowhere)
+grep -rnE "(navigation\.navigate.*TODO|console\.log.*not.?implemented|alert.*coming)" \
+  --include="*.tsx" --include="*.ts" --include="*.jsx" --include="*.js" \
+  src/ app/ 2>/dev/null
+
+# Check for hardcoded test URLs
+grep -rnE "(localhost|127\.0\.0\.1|10\.0\.2\.2|staging\.|dev\.|test\.)" \
+  --include="*.tsx" --include="*.ts" --include="*.jsx" --include="*.js" \
+  src/ app/ 2>/dev/null | grep -v "node_modules" | grep -v "__tests__"
+```
+
+### Fix
+1. Replace all Lorem ipsum with real content — even if it's simple, it must be real.
+2. Remove all "Coming Soon", "Under Construction", and "TODO" labels from the UI.
+3. Remove debug/test/staging labels and environment indicators from the production build.
+4. Ensure all navigation destinations exist and are functional — no buttons that lead nowhere.
+5. Populate empty states with realistic data or show proper empty state UI ("No items yet. Tap + to add one.").
+6. Remove all `console.log`, `console.warn` statements from production (use a Babel plugin):
+   ```json
+   // babel.config.js
+   plugins: [
+     ["transform-remove-console", { exclude: ["error"] }]
+   ]
+   ```
+7. Replace hardcoded localhost/staging URLs with production endpoints.
+8. Test on a fresh install — cached data may hide empty states during your testing.
+
+### Example Rejection
+> Guideline 2.1 — Performance — App Completeness: Your app includes placeholder content ("Lorem ipsum") on the About screen and a "Coming Soon" label on the Reports tab. Please ensure all content is final.
+
+---
+
+## Backend Services Unavailable During Review
+**Apple**: 2.1 — App Completeness | **Google**: App functionality policy | **Severity**: REJECTION
+
+Apple reviews apps 24/7, including weekends and holidays. If your backend is down during review, the app appears broken and gets rejected. Staging servers with limited uptime, expired API keys, and rate-limited free tiers are common causes.
+
+### Detect
+```bash
+# Check API base URL configuration
+grep -rnE "(baseURL|BASE_URL|API_URL|apiUrl|endpoint)" \
+  --include="*.tsx" --include="*.ts" --include="*.jsx" --include="*.js" --include="*.env*" \
+  src/ app/ 2>/dev/null
+
+# Check for environment-specific configs
+grep -rnE "(staging|development|production).*url" \
+  --include="*.tsx" --include="*.ts" --include="*.jsx" --include="*.js" --include="*.env*" \
+  src/ app/ 2>/dev/null
+
+# Check for free-tier services that might hit limits
+grep -E "(firebase|supabase|heroku|render|railway|planetscale|neon|vercel)" \
+  package.json 2>/dev/null
+```
+
+### Fix
+1. Point the submission build to production servers (not staging/dev).
+2. Ensure backend services have 99.9%+ uptime during the review period (typically 1-7 days after submission).
+3. If using free-tier hosting (Heroku, Render, Railway): free tiers often sleep after inactivity — upgrade to a paid tier or implement keep-alive pings during the review period.
+4. Check that API keys, tokens, and certificates used in the release build are not expired.
+5. Implement graceful error handling — if the backend is temporarily down, show a retry option, not a crash or blank screen.
+6. If your backend requires VPN or IP whitelisting, add Apple's review team IP ranges or disable IP restrictions during review.
+7. Test the exact build you're submitting against production APIs before uploading.
+8. Include backend status information in review notes if applicable:
+   ```
+   Note: This app requires an internet connection. Our backend services are available 24/7
+   at api.yourapp.com. If you experience connectivity issues, please try again or contact
+   us at dev@yourapp.com.
+   ```
+
+### Example Rejection
+> Guideline 2.1 — Performance: Your app was unable to load content during our review. The app displayed an error "Unable to connect to server" on the home screen. Please ensure your backend services are operational and resubmit.
+
+---
+
+## Inadequate App Review Notes
+**Apple**: 2.1 | **Google**: N/A (less structured) | **Severity**: REJECTION (indirect)
+
+Poor or missing review notes lead to reviewers being unable to test your app, which results in rejection. Good review notes prevent misunderstandings and speed up the review process.
+
+### Fix
+1. Always include in App Review notes:
+   - Demo account credentials (if login required)
+   - How to access non-obvious features
+   - How to test IAP/subscription flows (sandbox accounts)
+   - Any required hardware (Bluetooth device, specific location, etc.)
+   - If features require specific conditions (e.g., "To test the alarm feature, set an alarm 2 minutes in the future")
+2. If your app uses location: specify a location the reviewer should use, or note that the app works with any location.
+3. If your app requires external hardware (BLE device, smart home device): provide a video demo in the review notes or App Store Connect attachments.
+4. Keep notes concise but complete — reviewers process hundreds of apps. Make it easy.
+5. Example good review notes:
+   ```
+   Demo Account: demo@app.com / Pass123!
+   (Premium features are unlocked on this account)
+
+   Key flows to test:
+   1. Home > Search > tap any result > "Add to Cart" > Checkout
+   2. Profile > Settings > Notifications (toggle on/off)
+   3. Camera tab > Scan any barcode (or use camera to photograph any text)
+
+   The app requires internet connection. Backend is live 24/7.
+   Location features work with any location.
+   ```
+
+### Example Rejection
+> Guideline 2.1 — Performance: We were unable to complete the review of your app because the demo account credentials provided in the review notes did not work. Please provide valid credentials and resubmit.