toolctrl-labs/HiveGrid-Wireframes
9
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
e341c5938ac25ff069732732835837de3d39d5e1
HiveGrid-Wireframes/hivegrid-cloud/_bmad-output/brainstorming/context/hivegrid-apple-rules.md
T

12 KiB
Raw Blame History

Apple App Store Rules — Briefing fuer HiveGrid (B2B-SaaS-CRM, Stand Mai 2026)

Kontext: HiveGrid ist ein B2B-SaaS-CRM (Multi-Tenant) fuer Handwerksbetriebe. Web-App ist Hauptzugang. Nativer Wrapper (Capacitor/React Native) fuer App-Store-Praesenz erwogen. Subscriptions zahlt der Betrieb extern (Web/Rechnung), Endnutzer (Monteure/Buero) loggen sich nur ein.

1. In-App Purchases (IAP) — fuer HiveGrid NICHT Pflicht (bedingt)

  • Grundregel 3.1.1: Digitale Goods/Services in der App muessen via Apple-IAP (15-30% Provision) verkauft werden.
  • Relevante Ausnahme — Guideline 3.1.3(c) "Enterprise Services": Wenn die App ausschliesslich an Organisationen/Gruppen fuer deren Mitarbeiter verkauft wird (typisches B2B-SaaS-Modell), darf extern abgerechnet werden. HiveGrid faellt klar darunter.
  • Zusaetzlich 3.1.3(b) "Multiplatform Services": Login fuer eine bereits ausserhalb der App (Web) erworbene Subscription ist erlaubt — solange die App keinen Link, Button oder Hinweis enthaelt, der auf externe Bezahlung steert.
  • Was in der App NICHT erlaubt ist (ausserhalb EU/USA): Pricing-Pages, "Upgrade your plan"-Buttons, Links zur Web-Bezahlung, "Sign up at hivegrid.cloud"-Hinweise. Nur reiner Login-Screen ist sicher.
  • EU-DMA-Update (Juni 2025): In der EU duerfen Apps inzwischen aktiv auf externe Bezahloptionen verlinken (Core Technology Commission 5%, optionales Modell). Fuer HiveGrid nicht relevant, da gar keine Consumer-Bezahlung in der App stattfindet — die DMA-Lockerung betrifft primaer Apps die selbst IAP umgehen wollen.
  • Fazit: Nicht-Pflicht, sofern strikt nur Login + App-Funktionen, keinerlei Pricing-/Upsell-Inhalte. Reject-Risiko bei jedem "Subscribe"-Hinweis.

Quellen:

2. Sign in with Apple — fuer HiveGrid NICHT Pflicht (bedingt)

  • Grundregel 4.8: Wer Drittanbieter-Login (Google, Facebook, Microsoft) als primaeren Auth-Mechanismus anbietet, MUSS Sign in with Apple gleichwertig anbieten.
  • Klare Ausnahme: "Education, enterprise, or business apps that require the user to sign in with an existing education or enterprise account" — also genau HiveGrids Modell (Mitarbeiter logged sich mit Firma-Credentials ein).
  • Weitere Ausnahme: Apps die ausschliesslich eigene Account-Systeme nutzen (Email + Passwort) brauchen kein Sign in with Apple.
  • Knifflig: Wenn HiveGrid auch Google/Microsoft-OAuth fuer "regulaere" Endnutzer (nicht nur SSO via Tenant) anbietet, koennte ein Reviewer das als "primaeres Auth" werten. Dann doch Pflicht.
  • Magic-Link/Email-Only: Reicht aus, um die Anforderung zu umgehen — keine Apple-Login-Pflicht.
  • Fazit: Nicht-Pflicht, wenn HiveGrid den Login als "Enterprise/Tenant-Login" framed. Pflicht, wenn Google-OAuth als allgemeiner Consumer-Login angeboten wird.

Quellen:

3. Face ID / Touch ID Integration

  • Apple stellt keine Pflicht zu Biometrie-Login. Es ist optional, aber dringend empfohlen fuer eine "app-like experience" (s. Punkt 5 / Guideline 4.2).
  • Capacitor: Plugins wie @aparajita/capacitor-biometric-auth oder capacitor-face-id wrappen Apples LocalAuthentication-Framework. Integration: ~1-2 Tage. Kein Problem mit Apple Review.
  • React Native: react-native-keychain + expo-local-authentication (bei Expo) — vergleichbar simpel.
  • Echt nativ (Swift): Direkt LocalAuthentication.framework, ~paar Stunden Aufwand.
  • Apple-Anforderungen: NSFaceIDUsageDescription im Info.plist (Pflicht-String warum Face ID genutzt wird), Fallback-Mechanismus (PIN/Passwort) muss existieren.
  • Fazit: Nicht-Pflicht. Mit Capacitor problemlos machbar (~1-2 Tage). Hilft enorm gegen Guideline 4.2 Reject (s.u.).

Quellen:

4. Sonstige Huerden fuer B2B-SaaS-CRM

4.1 Account-Loeschung in der App — PFLICHT seit 30.06.2022 (Guideline 5.1.1(v))

  • Jede App mit Account-Erstellung muss In-App-Loeschung anbieten — auch wenn Account ausserhalb erstellt wurde.
  • Deaktivieren reicht nicht, alle Personendaten muessen geloescht werden.
  • Ausnahme fuer "highly regulated industries" (5.1.1(ix)) — Handwerk faellt nicht darunter.
  • Praktisch: Settings-Screen mit "Konto loeschen"-Button, der Backend-Endpoint anstoesst. Fuer Multi-Tenant: kann sein dass nur "Mitarbeiter aus Tenant entfernen" gemeint ist, aber Apple ist da streng — User-eigene Daten muessen weg.
  • Apple: Account deletion

4.2 Privacy Manifest — PFLICHT seit 01.05.2024

  • PrivacyInfo.xcprivacy muss alle gesammelten Daten + Drittanbieter-SDK-APIs deklarieren.
  • Apple lehnt 12% der Submissions in Q1 2025 wegen fehlerhafter Manifests ab.
  • Capacitor/Expo-Communities haben i.d.R. fertige Manifests — trotzdem pruefen.
  • App Tracking Transparency (ATT) Prompt nur wenn echtes Tracking stattfindet — fuer ein internes B2B-Tool i.d.R. nicht noetig.
  • Apple Privacy Manifest Docs

4.3 TestFlight & Sandbox

  • Internal Testing: 100 Tester, sofort verfuegbar, keine Apple-Pruefung.
  • External Testing: 10.000 Tester, erfordert App-Review (leichter als Production, ~1-2 Tage).
  • Sandbox-Accounts fuer IAP-Tests in App Store Connect anlegen — fuer HiveGrid nicht relevant da kein IAP.

4.4 Typische Reject-Gruende fuer B2B-Apps

  1. Guideline 2.1 (App Completeness): ~40% aller Rejects. Reviewer kann nicht einloggen → bricht ab. Demo-Account in Review Notes ist kritisch.
  2. Guideline 4.2 (Minimum Functionality): "Webview-Wrapper" (s. Punkt 5).
  3. Guideline 3.1.1 (IAP): Schon ein "Upgrade auf Pro"-Button im UI loest Reject aus.
  4. Guideline 5.1.1 (Privacy): Fehlende Account-Loeschung, kein Privacy-Manifest, fehlende Privacy-Policy-URL.
  5. Guideline 2.3 (Metadata): Screenshots zeigen Features die in der App nicht funktionieren.

Quellen:

5. Capacitor vs React Native vs Expo vs nativ — und Guideline 4.2

  • Apple ist agnostisch ggue. Framework, aber sehr empfindlich gegenueber "Webview-Wrappern" ohne nativen Mehrwert (Guideline 4.2 "Minimum Functionality").
  • Was sicher rejected wird: Pure WebView, die nur die mobile Website laedt, ohne native Features.
  • Was 2026 minimal verlangt wird (Best Practice, nicht alle gleichzeitig):
    • Native Navigation (kein Hamburger-Menue im Webview)
    • Push Notifications (echt genutzt — nicht nur "registriert")
    • Mind. ein Device-Feature: Kamera (Foto vom Auftrag), Biometrie (Login), Geolocation (Einsatzort), Offline-Mode (mind. teilweise)
    • App-Icons, Splash-Screens, vernuenftige Tab-Bar
  • Capacitor: Webview-basiert aber mit nativen Plugins. Gut geeignet, wenn Web-App schon existiert (HiveGrid-Fall). Reject-Risiko nur, wenn Native Features fehlen — Framework selbst ist kein Problem.
  • React Native: Native UI-Components, leichter durch 4.2 zu kommen, aber doppelter Code-Aufwand vs. Capacitor.
  • Expo: React-Native + Managed Workflow + EAS Build. 2026 die beliebteste Variante fuer kleinere Teams. Privacy Manifest weitgehend automatisiert.
  • Echt nativ (Swift/SwiftUI): Maximale Akzeptanz, ~3-5x Aufwand vs. Capacitor.
  • Empfehlung 2026: Capacitor ist OK fuer HiveGrid, wenn mindestens 2-3 native Features (Push, Biometrie, Kamera fuer Auftrags-Fotos) implementiert werden.

Quellen:

6. Google Play Store — deutlich einfacher

  • Keine Sign-in-with-Google-Pflicht analog zu Apples SIWA.
  • Account-Loeschung ebenfalls Pflicht seit Mai 2024 — aber Google akzeptiert auch externe Loesch-URL (Apple verlangt In-App).
  • In-App-Billing: Theoretisch aehnliche Regel, aber in der Praxis weniger streng durchgesetzt fuer B2B. Seit Epic-vs-Google (Okt 2025, USA) duerfen externe Bezahllinks in den USA frei verwendet werden. EU: External Offers Program seit 2025.
  • Webview-Apps: Google ist toleranter — "Minimum Functionality"-Aequivalent (Spam Policy) wird selten gegen B2B-Wrapper gezueckt.
  • Data Safety Form (analog Privacy Manifest) — etwas einfacher als Apples Manifest.
  • Fazit: Google Play ist klar einfacher. Tipp: Erst Google Play launchen (lower risk), dann Apple.

Quellen:

Empfehlungen fuer HiveGrid

  1. IAP komplett vermeiden: App nur mit Login-Screen starten. Keine Pricing-, Upgrade-, "Plan waehlen"-Inhalte in der App. Subscription-Mgmt strikt im Web-Dashboard. Im App-Store-Listing als "B2B Enterprise Tool" positionieren — Reviewer-Hinweis in den App Review Notes: "Enterprise SaaS, sold directly to organizations, all payments handled outside the app per Guideline 3.1.3(c)".

  2. Sign in with Apple sparen: Login-Screen sollte als "Firma-Login" auftreten (z.B. "Mit Firma-Account anmelden"). Wenn Google/Microsoft-OAuth, dann als "Enterprise SSO" framen, nicht als allgemeiner Consumer-Login. Magic-Link/Email-Only ist die sicherste Variante zum Umgehen.

  3. Capacitor + native Features: Mind. 3 native Funktionen: Push Notifications (Auftrag-Updates fuer Monteure), Biometrie-Login (Face ID), Kamera (Fotos vom Einsatz). Damit ist 4.2 sicher gepasst.

  4. Account-Loeschung jetzt einplanen: Endpoint im Backend, Settings-Screen "Konto loeschen" — auch fuer Multi-Tenant. Loescht User-Personendaten, behaelt anonymisiert was rechtlich noetig ist (Audit-Trail).

  5. Privacy Manifest sauber: PrivacyInfo.xcprivacy mit allen Capacitor-Plugin-Reasons. Privacy-Policy-URL im App Store Connect setzen.

  6. Reviewer-Demo-Account vorbereiten: Dedizierter Tenant "apple-review" mit Mitarbeiter-Login, Beispieldaten, immer in App Review Notes mitliefern. Reduziert 2.1-Reject-Risiko massiv.

  7. Launch-Strategie: Erst Google Play (niedrigere Huerde, schneller Feedback) → dann Apple. Bei Apple unbedingt mit TestFlight (External Testing) ein paar Wochen vor Production-Submit testen — gleiches Review-Team, niedrigerer Stress.

Unklarheit (ehrlich): Ob ein Reviewer Google-OAuth als "Enterprise SSO" (kein SIWA noetig) oder als "Consumer Social Login" (SIWA Pflicht) wertet, ist Einzelfall. Im Zweifel SIWA mit-implementieren — Aufwand ~1 Tag.

Reference in new issue View Git Blame Copy Permalink