The Core Problem

Your Situation, Honestly Assessed

The 4 Paths Available to You

Path 1 — The "Multiplatform Services" Reply (3.1.3(b)) — Won't Work Alone

Path 2 — US: Use External Payment Link (Best Option for US)

• You can add a button/link in the app like "Subscribe on our website" that links to your Stripe checkout page
• No special entitlement needed anymore
• No Apple commission on those purchases
• You keep Stripe, nothing changes in your backend

Path 3 — India: You Must Add IAP (or Remove India)

• Implement StoreKit/IAP alongside Stripe
• Users in India see IAP pricing; users in US see the external link
• You detect storefront using SKPaymentQueue.storefront and show the right flow
• Your Stripe subscriptions still work for web users; iOS India users go through IAP
• Yes, Apple takes 15–30% of India IAP revenue, but you get access to the market

• Skip India for now (or make it a free app in India with no paid features accessible)
• Get approved in US using the external link method
• Handle India separately once you've built IAP

• Only show features that don't require a subscription in India
• Paid features are simply hidden/locked with a message directing users to your website
• Risky — Apple may still reject if the app's value is gated behind a purchase they can't make through IAP

Path 4 — Reply to Apple Now (Short-term, for the US Argument)

Thank you for the detailed feedback.

We understand the requirements under Guideline 3.1.1. We'd like to clarify our model and proposed resolution:

Our app is a multi-platform digital service. Subscriptions are currently purchased on our website. We plan to add an external link button in the app (linking to our website's subscription page) for the United States storefront, in accordance with the updated Guideline 3.1.1(a) which now permits external payment links on the US storefront without a special entitlement.

For non-US storefronts (such as India), we are actively implementing In-App Purchase via StoreKit so that the same subscriptions are available to purchase within the app, per Guideline 3.1.3(b).

We request a short extension to implement these changes and resubmit. We are committed to full compliance.

Thank you for your patience.

Recommended Action Plan

1. For US (immediate fix): Add a "Subscribe" button that opens your website in Safari. This is now fully allowed. No IAP needed for the US storefront. This likely gets you US approval quickly.
2. For India (medium-term): Implement IAP using StoreKit. You don't have to replicate your entire Stripe subscription model — you can offer a single "Pro" or "Premium" subscription tier via IAP, and keep the more complex upgrade/downgrade/custom plans on the web. Many SaaS apps do exactly this — simple IAP on iOS, full plan management on the website.
3. Detect storefront in your app: Use Storefront.current (StoreKit 2) to show IAP UI to Indian users and external link to US users. This is standard practice.
4. Send the reply above in App Store Connect while you work on the changes — it shows good faith and buys you time.

Bottom Line

Can You Avoid IAP Entirely? Storefront-by-Storefront Reality

🇺🇸 United States — Yes, you can fully avoid IAP

🇮🇳 India — No, you cannot avoid IAP if your app gates features behind a subscription

Legitimate Paths That Avoid IAP (for India too)

Option 1 — Launch as a Fully Free App (No Paywalled Features in the App)

• The iOS app is 100% free to download and use
• All features are unlocked if the user has an active subscription (validated server-side via your backend)
• You never prompt, offer, or display a subscription purchase inside the app — not even a link
• Users who don't have a subscription see a message: "Visit orris.app to subscribe" — but it's purely informational, not a button that navigates anywhere
• Users buy on your website, come back, log in, and get access

Option 2 — Genuinely Free App with Web-Only Upsell

• Your iOS app offers a real free tier with meaningful functionality
• Paid plans/subscriptions are only ever mentioned or purchased on your website
• Inside the app: zero mention of pricing, plans, or "upgrade" — just a link to your website or support page (not a payment page) for users who want more
• This removes all ambiguity for Apple

Option 3 — US + India Geo-Split Strategy (No IAP, India handled differently)

• US: External link to Stripe checkout — fully compliant, Apple confirmed this
• India release delayed — you submit only to the US storefront initially, get approved, build audience and revenue, then decide if India's market size justifies adding IAP

What Will NOT Work

• Hiding the subscription mention but still gating all features: Apple reviewers test the app. If everything is locked and there's no way to use the app without a subscription bought elsewhere, they will reject it — that's what happened here.
• Claiming 3.1.3(b) Multiplatform without offering IAP: That guideline says users can access content bought elsewhere provided it's also available via IAP. You still need IAP for it to apply.
• Arguing the app is a "tool" not "content": Apple doesn't make this distinction. If your app delivers digital services for a fee, IAP applies regardless of whether it's a SaaS tool or a media app.

The Practical Recommendation (No IAP, Ever)

1. Build a meaningful free tier — even basic features work. This is your India-safe path.
2. Subscribed users get full access automatically (server-side entitlement check on login).
3. Non-subscribed users in the app see a screen that says something like "You're on the free plan. To unlock [X], visit our website." — no link, no button to a payment page, just text.
4. For US only, you can additionally add a "Subscribe" button that opens your Stripe page in Safari — that's fully allowed.
5. In your App Review Notes, explain clearly: "This app does not sell digital content within the app. Subscriptions are purchased exclusively on our website. The app serves as a companion interface for existing subscribers. A free tier is available to all users."

Option 1 — "Free App + Server-Side Entitlement" Deep Dive

The Core Logic

What the App Must Look Like

• They can log in or sign up for free
• They get access to a genuine free tier — real features, not just a blank screen with a lock icon
• If they hit a paid feature, they see something like:

"This feature is available on Pro. Visit orris.app to upgrade."

• That line of text is not a button, not a link, not a call to action — just informational text. No tapping, no navigation to a payment page.
• This is the critical line. The moment that text becomes a tappable link to your pricing page, Apple will flag it as an external purchase call-to-action (at least for non-US storefronts).

• They log in, your app calls your API, gets back plan: "pro" or similar
• Features are unlocked silently, seamlessly — no purchase flow ever shown

The "Genuine Free Tier" Requirement — This is Non-Negotiable

• Give real, limited access — e.g. limited number of messages, projects, workspaces, API calls, history, etc.
• The core experience is functional; paid plan just removes limits or adds advanced features
• Think: Notion's free plan (limited blocks), Slack's free plan (90-day message history), Figma's free plan (3 projects)

The App Review Notes (What to Write)

App Review Notes — Orris

Orris is a [describe what your app does] platform available on web and mobile. The app is free to download and includes a free tier that allows all users to [describe what free users can do — e.g., "create up to 3 projects, send up to 50 messages per month, etc."].

Subscriptions are managed exclusively on our website (orris.app) and are not sold within the app. When a subscribed user logs in, their subscription status is verified via our backend API and premium features are unlocked automatically — no purchase flow occurs inside the app.

Non-subscribed users are shown informational text directing them to our website if they wish to upgrade, but no payment links, buttons, or external purchase calls-to-action are present within the app.

This model is consistent with how multi-platform SaaS tools operate on the App Store.

Demo account for review: Email: review@orris.app Password: [password] (This is a pre-subscribed Pro account so you can review all features.)

Your Reply to Apple Right Now

Thank you for the detailed feedback regarding Guideline 3.1.1.

We'd like to clarify our app's business model:

Orris is a multi-platform digital service. Our app offers a genuine free tier available to all users upon signup. Subscriptions are purchased exclusively on our website — no in-app purchase, payment link, or external call-to-action for purchasing exists within the app on non-US storefronts.

When a user who has purchased a subscription on our website logs into the app, their subscription status is validated server-side and features are unlocked automatically. This is not an in-app purchase — it is simply a server-side entitlement check.

We are updating the app to ensure:

1. A meaningful free tier is clearly accessible to all users without requiring a subscription
2. No payment links or calls-to-action appear inside the app (except on the US storefront, per the updated Guideline 3.1.1(a))
3. App Review Notes clearly explain the model with a pre-subscribed demo account

We are resubmitting with these changes shortly and appreciate your patience.

What to Change in the App (Engineering Checklist)

US-Specific Enhancement (Bonus, No Extra Work on Backend)

// StoreKit 2
if let storefront = await Storefront.current, storefront.countryCode == "USA" {
    // Show "Subscribe" button linking to your Stripe page
} else {
    // Show plain text only: "Visit orris.app to manage your plan"
}

Risks and How to Mitigate Them

TL;DR — The 3 Things That Make This Work

1. Real free tier — the app must be genuinely usable without a subscription
2. Zero purchase UI inside the app — no links, no buttons, no pricing screens (except a US-only external link if you choose)
3. Clear App Review Notes + a pre-subscribed demo account so the reviewer can see everything

Free App + Server-Side Entitlement — Full Implementation Guide

How the System Works (Big Picture)

User logs in to app
       ↓
App calls your backend: GET /api/me/subscription
       ↓
Backend checks Stripe → returns { plan: "free" | "pro" | "enterprise", status: "active" | "inactive" }
       ↓
App stores this in state/context
       ↓
Every feature check reads from this state — no purchase, no IAP, no Apple involved

Part 1 — Backend Changes (Python / Django or FastAPI)

The Subscription Status Endpoint

# routes/subscription.py
from fastapi import APIRouter, Depends
from app.auth import get_current_user
from app.services.stripe_service import get_subscription_status

router = APIRouter()

@router.get("/api/me/subscription")
async def subscription_status(current_user=Depends(get_current_user)):
    status = await get_subscription_status(current_user)
    return status

# services/stripe_service.py
import stripe
from app.config import STRIPE_SECRET_KEY

stripe.api_key = STRIPE_SECRET_KEY

async def get_subscription_status(user):
    # If user has no stripe customer ID, they're on free
    if not user.stripe_customer_id:
        return {
            "plan": "free",
            "status": "active",
            "features": get_features_for_plan("free")
        }

    # Fetch active subscriptions from Stripe
    subscriptions = stripe.Subscription.list(
        customer=user.stripe_customer_id,
        status="active",
        limit=1
    )

    if not subscriptions.data:
        return {
            "plan": "free",
            "status": "active",
            "features": get_features_for_plan("free")
        }

    sub = subscriptions.data[0]
    plan_name = sub.metadata.get("plan", "pro")  # set this in Stripe metadata

    return {
        "plan": plan_name,
        "status": sub.status,           # "active", "trialing", "past_due"
        "current_period_end": sub.current_period_end,
        "features": get_features_for_plan(plan_name)
    }


def get_features_for_plan(plan: str) -> dict:
    plans = {
        "free": {
            "max_projects": 3,
            "max_team_members": 1,
            "can_export": False,
            "can_use_api": False,
            "advanced_analytics": False,
        },
        "pro": {
            "max_projects": -1,       # -1 = unlimited
            "max_team_members": 10,
            "can_export": True,
            "can_use_api": True,
            "advanced_analytics": True,
        },
        "enterprise": {
            "max_projects": -1,
            "max_team_members": -1,
            "can_export": True,
            "can_use_api": True,
            "advanced_analytics": True,
        }
    }
    return plans.get(plan, plans["free"])

• You call Stripe's API on the backend, not from the app — keeps your Stripe secret key safe
• Cache this response (Redis, or even a DB field) — don't hit Stripe on every API call, sync via Stripe webhooks instead (see below)
• Return a features object so the app doesn't need to know your plan logic — it just reads flags

Stripe Webhook to Keep Your DB in Sync

# routes/webhooks.py
from fastapi import APIRouter, Request, HTTPException
import stripe
from app.config import STRIPE_WEBHOOK_SECRET
from app.models import User

router = APIRouter()

@router.post("/webhooks/stripe")
async def stripe_webhook(request: Request):
    payload = await request.body()
    sig_header = request.headers.get("stripe-signature")

    try:
        event = stripe.Webhook.construct_event(
            payload, sig_header, STRIPE_WEBHOOK_SECRET
        )
    except stripe.error.SignatureVerificationError:
        raise HTTPException(status_code=400, detail="Invalid signature")

    if event["type"] in [
        "customer.subscription.created",
        "customer.subscription.updated",
        "customer.subscription.deleted",
        "invoice.payment_succeeded",
        "invoice.payment_failed",
    ]:
        subscription = event["data"]["object"]
        customer_id = subscription["customer"]

        user = await User.get(stripe_customer_id=customer_id)
        if user:
            user.subscription_status = subscription["status"]
            user.subscription_plan = subscription.get("metadata", {}).get("plan", "pro")
            user.subscription_ends_at = subscription.get("current_period_end")
            await user.save()

    return {"status": "ok"}

Part 2 — React Native Frontend Changes

The Subscription Context

// context/SubscriptionContext.js
import React, { createContext, useContext, useState, useEffect } from 'react';
import { AppState } from 'react-native';
import api from '../services/api';

const SubscriptionContext = createContext(null);

export function SubscriptionProvider({ children }) {
  const [subscription, setSubscription] = useState({
    plan: 'free',
    status: 'active',
    features: {
      max_projects: 3,
      max_team_members: 1,
      can_export: false,
      can_use_api: false,
      advanced_analytics: false,
    },
    loading: true,
  });

  const fetchSubscription = async () => {
    try {
      const data = await api.get('/api/me/subscription');
      setSubscription({ ...data, loading: false });
    } catch (e) {
      // On error, default to free — never crash the app
      setSubscription(prev => ({ ...prev, loading: false }));
    }
  };

  useEffect(() => {
    fetchSubscription();

    // Re-check when app comes back to foreground
    // (user may have just subscribed on the website)
    const subscription = AppState.addEventListener('change', (state) => {
      if (state === 'active') {
        fetchSubscription();
      }
    });

    return () => subscription.remove();
  }, []);

  return (
    <SubscriptionContext.Provider value={{ subscription, refetch: fetchSubscription }}>
      {children}
    </SubscriptionContext.Provider>
  );
}

export const useSubscription = () => useContext(SubscriptionContext);

The Feature Gate Component

// components/FeatureGate.jsx
import React from 'react';
import { View, Text, StyleSheet } from 'react-native';
import { useSubscription } from '../context/SubscriptionContext';

export function FeatureGate({ feature, children, fallback }) {
  const { subscription } = useSubscription();

  if (subscription.loading) return null;

  const hasAccess = subscription.features[feature] === true
    || subscription.features[feature] === -1
    || (typeof subscription.features[feature] === 'number'
        && subscription.features[feature] > 0);

  if (hasAccess) return children;

  // Show fallback or default upgrade notice
  return fallback || <DefaultUpgradeNotice />;
}

function DefaultUpgradeNotice() {
  return (
    <View style={styles.notice}>
      <Text style={styles.title}>Pro Feature</Text>
      <Text style={styles.body}>
        This feature is available on the Pro plan.{'\n'}
        Visit orris.app to upgrade.
      </Text>
      {/* ⚠️ NO BUTTON. NO LINK. Just text. This is intentional for App Store compliance. */}
    </View>
  );
}

const styles = StyleSheet.create({
  notice: {
    padding: 20,
    backgroundColor: '#f5f5f5',
    borderRadius: 12,
    alignItems: 'center',
  },
  title: {
    fontSize: 16,
    fontWeight: '600',
    marginBottom: 8,
  },
  body: {
    fontSize: 14,
    color: '#666',
    textAlign: 'center',
    lineHeight: 22,
  },
});

// In any screen
import { FeatureGate } from '../components/FeatureGate';

function AnalyticsScreen() {
  return (
    <FeatureGate feature="advanced_analytics">
      <AnalyticsDashboard />
    </FeatureGate>
  );
}

US-Only External Link (Bonus — Legal for US Storefront)

// hooks/useStorefront.js
import { useState, useEffect } from 'react';
import { Platform, NativeModules } from 'react-native';

export function useIsUSStorefront() {
  const [isUS, setIsUS] = useState(false);

  useEffect(() => {
    if (Platform.OS !== 'ios') return;

    // Get device locale/region as a proxy
    // For more precision, use a native module to read SKStorefront
    const locale = NativeModules.SettingsManager?.settings?.AppleLocale
      || NativeModules.SettingsManager?.settings?.AppleLanguages?.[0]
      || '';

    // Or simply check from your backend — pass the storefront in the subscription response
    setIsUS(locale.includes('US') || locale.includes('en_US'));
  }, []);

  return isUS;
}

function DefaultUpgradeNotice() {
  const isUS = useIsUSStorefront();

  return (
    <View style={styles.notice}>
      <Text style={styles.title}>Pro Feature</Text>
      <Text style={styles.body}>
        This feature is available on the Pro plan.
      </Text>
      {isUS ? (
        // US: allowed to show external link
        <TouchableOpacity onPress={() => Linking.openURL('https://orris.app/pricing')}>
          <Text style={styles.link}>Subscribe at orris.app →</Text>
        </TouchableOpacity>
      ) : (
        // Non-US (India etc.): plain text only, no link
        <Text style={styles.body}>Visit orris.app to upgrade.</Text>
      )}
    </View>
  );
}

Part 3 — What to Write to Apple

Reply to Send Right Now in App Store Connect

Thank you for your review and feedback on Guideline 3.1.1.

We'd like to clarify our app's model and the changes we are making:

Our business model: Orris operates across web and mobile. Subscriptions are managed exclusively on our website via our web checkout. The iOS app does not sell, advertise, or link to any external purchase mechanism — it simply checks the user's subscription status from our backend at login and unlocks features accordingly.

Changes we are implementing before resubmission:

1. Genuine free tier: All users get access to core features (up to 3 projects, basic functionality) without any subscription. The app is fully usable on the free tier.
2. No purchase UI: Any screens referencing subscription upgrades have been removed from the app. Non-subscribed users see informational text only ("Visit orris.app to manage your plan") — no buttons, links, or calls to action to external payment on non-US storefronts.
3. US storefront: Per the updated Guideline 3.1.1(a), US users will see an external link button to our website for subscription management, as now permitted.
4. App Review Notes: We have updated the App Review Information section with a pre-subscribed demo account and a full explanation of our model.

We are resubmitting shortly. Thank you for your patience.

App Review Notes to Add in App Store Connect

Orris is a multi-platform productivity/[your category] tool available on web and iOS.

Business model: The app is free to download. A free tier is available to all users with no subscription required (up to 3 projects, [list your free features]). Paid subscriptions are purchased exclusively on our website (orris.app) using Stripe. No in-app purchases, external payment links, or purchase calls-to-action exist within the app on non-US storefronts.

How premium features unlock: When a subscribed user logs in, the app calls our backend API which checks their Stripe subscription status and returns a feature entitlement object. The app unlocks features based on this response. No payment processing occurs on-device.

US storefront: An external link to our website is shown to US users per Guideline 3.1.1(a).

Demo credentials (pre-subscribed Pro account): Email: review@orris.app Password: ReviewOrris2026!

Please use these credentials to access and review all Pro features.

Checklist Before Resubmitting

• Free tier is real and usable — reviewer can do something meaningful without subscribing
• All pricing/upgrade/subscription screens removed from the app
• All "Upgrade" buttons replaced with plain informational text (non-US)
• US users can optionally see an external link (or leave this out for simplicity)
• Backend /api/me/subscription endpoint returns plan + feature flags
• Stripe webhooks sync subscription status to your DB
• AppState listener re-fetches entitlement when app resumes from background
• App Review Notes filled in with explanation + demo account
• Demo account is a working Pro account Apple can log into

The User Flow After This

1. Download app → sign up free → use free features
2. Hit a Pro feature → see "Visit orris.app to upgrade" (plain text)
3. Open browser, go to your site, subscribe via Stripe
4. Come back to app → app detects AppState change → re-fetches entitlement → features unlock automatically

What Apple is Actually Upset About

What You Need to Do — In Plain English

The Magic Part

So Yes — You're Basically Right

The WebView Trick Will Get You Permanently Banned

"Don't use a WebView to load content that mimics App Store features or payment flows."

"Apps should not be submitted that are intended to deceive the reviewer."

• Remove your app from the App Store entirely
• Terminate your developer account — meaning you can never publish on iOS again
• Ban your Apple ID permanently

The "Keep It Free for 1 Week" Part — Also Risky

What You Should Actually Do Instead

1. The "Limits & Usage" section (Daily Credits, Topup Credits)
2. The "Billing" button

• Either nothing (just remove the row entirely)
• Or a row that says "Account" or "Manage Plan" that opens your website in Safari (not a WebView) — this is fully allowed for US users, and for India you just remove it entirely or show plain text

The Simple Honest Path

Changes to Make in the App

1. The "Limits & Usage" section (Daily Credits, Topup Credits, the progress bars)
2. The "Billing" row in Settings

US vs Rest of World — How to Think About It (No Code)

Reply to Send to Apple Right Now

Thank you for your continued review of Orris and for the detailed feedback.

We have reviewed Guideline 3.1.1 carefully and want to clarify the changes we are making before resubmission:

What we are changing:

1. We are removing the "Limits & Usage" section from the app's Settings screen entirely.
2. We are removing the "Billing" button from the Settings screen. For users on the United States storefront, we will replace this with an external link to our website, which is permitted under the updated Guideline 3.1.1(a). For all other storefronts, no billing link or button will be present in the app.

Our model going forward:

Orris does not sell digital content or subscriptions within the app. Subscriptions are managed exclusively on our website. The app itself serves as a companion interface — when a user who has an active subscription logs in, their access is determined server-side. No purchase flow, payment link, or external call-to-action for purchasing exists within the app on non-US storefronts.

We are resubmitting with these changes shortly. Please find demo credentials below to access the app during review:

Demo account: Email: [your review account email] Password: [your review account password]

Thank you for your patience and we look forward to a successful review.

Regards, [Your name] Orris

What to Put in App Review Notes (Separate Field in App Store Connect)

Orris is a multi-platform AI tool available on web and iOS. The app does not contain any in-app purchases, billing screens, or payment links (except an external website link for US storefront users per Guideline 3.1.1a).

Subscriptions are purchased and managed entirely on our website. The app checks subscription status from our backend at login and provides access accordingly.

Demo account (active subscription): Email: [your review account email] Password: [your review account password]

Your Action Checklist

• Tell your developer to remove the Limits & Usage section
• Tell your developer to remove the Billing button
• Tell your developer to show a "Manage Billing" button (opens website in browser) for US users only — hide it for everyone else
• Create a dedicated email like review@orris.app with an active subscription for Apple to test with
• Send the reply above in App Store Connect
• Fill in the App Review Notes field
• Resubmit the new build