Apple Developer Program (99 €/Jahr) — Tiefenrecherche für Silverscale

Quellenbasierte Machbarkeits- und Umsetzungsanalyse für Dennis (Familie Fisch). Stand: Juni 2026, OS-Generation iOS 26 / watchOS 26 / tvOS 26, Xcode aktuell. Kontext: Capacitor-Hülle um silverscale.dennisfisch.de, aktuell SideStore/Gratis-Apple-ID.

1. Executive Summary

Konfidenz-Urteil: Ja, dein Zielbild geht — mit zwei ehrlichen Einschränkungen.

Der bezahlte Apple Developer Program (ADP) Account schaltet alles frei, was du heute schmerzlich vermisst: echte APNs-Push (inkl. Live-Activity-Push), 1-Jahres-Provisioning statt 7-Tage-Refresh, TestFlight, Widgets/Live Activities, watchOS- und tvOS-Builds. Der 7-Tage-Refresh-Tanz verschwindet komplett — er ist eine reine Limitierung des Gratis-„Personal Team", nicht eine technische Notwendigkeit (Apple, Compare Memberships).

Die zwei Einschränkungen, die du kennen musst:

1. Builds laufen nie „für immer". Der bequemste Familienweg (TestFlight) hat ein 90-Tage-Build-Ablaufdatum — danach muss ein frischer Build hochgeladen werden, sonst kann die Familie nichts mehr starten (Apple Forums / PTKD). Der „echte" 1-Jahres-Weg ist Ad-hoc (Profil bis 1 Jahr gültig), aber der koppelt jedes Gerät per UDID fest und du musst die IPA selbst verteilen. Es gibt keinen privaten Weg, der gleichzeitig „1 Jahr Ruhe" UND „bequemes Auto-Update" bietet. Du wählst pro Plattform zwischen bequem-aber-90-Tage (TestFlight) und umständlich-aber-1-Jahr (Ad-hoc).

2. „Kacheln in der Home-App" ist nicht dasselbe wie ein Home-Screen-Widget. Home-Screen-Widgets (WidgetKit) sind trivial machbar. Echte Kacheln in Apples Home-App (HomeKit/Matter) gehen für selbstgebaute Software-„Geräte" zwar (z. B. via Homebridge/Matter-Bridge vom VPS), brauchen dafür aber den ADP gar nicht — sie laufen über HAP/Matter auf deinem Server, nicht über deine signierte iOS-App. Der ADP hilft hier nur, falls du eine eigene iOS-App mit dem HomeKit-Framework schreiben willst (eigenes Entitlement). Für „Silverscale-Werte als Kacheln im Apple-Home" ist die Bridge der Weg, nicht der Dev-Account.

Empfehlung: Account holen (Individual, kein D-U-N-S nötig, ~24 h Freischaltung). Capacitor-Hülle behalten, native Widget-/Live-Activity-Extensions ergänzen. Auf iOS/watchOS/tvOS jeweils TestFlight intern als Primärweg, Ad-hoc als „kein-90-Tage-Stress"-Fallback für die Stamm-iPhones.

2. Zusammenfassung in einfachen Worten

Heute signierst du deine App mit einer Gratis-Apple-ID. Apple behandelt das wie „Bastler probiert was aus": Die App stirbt nach 7 Tagen, Push gibt es nicht, Uhr und Apple TV sind tabu. Das ist kein Bug, das ist Absicht — die Gratis-Stufe ist absichtlich kastriert.

Für 99 € im Jahr wirst du ein „echter" Entwickler. Dann darfst du: Push-Nachrichten verschicken (auch die hübschen Live-Aktivitäten mit dem Insel-Ding oben am iPhone), Apps auf die Uhr und den Fernseher bringen, und — am wichtigsten für dich — die Apps laufen ein Jahr statt eine Woche.

Der Haken: „ein Jahr Ruhe" und „bequem per Knopfdruck auf alle Familiengeräte" bekommst du nicht gleichzeitig. Entweder du nimmst Apples eingebautes Familien-Tool TestFlight (super bequem, Updates kommen automatisch, ABER jeder Build verfällt nach 90 Tagen — du musst also alle ~3 Monate einmal neu hochladen), oder du machst es per Ad-hoc (ein Jahr Ruhe, ABER du musst jedes Gerät einzeln eintragen und die App-Datei selbst rüberschieben). Für eine Familie mit 2–4 Geräten ist TestFlight fast immer die richtige Wahl — einmal alle 3 Monate „Build hochladen" ist nichts gegen den heutigen Wochen-Rhythmus.

Und die „Kacheln in der Home-App": Das sind zwei verschiedene Dinge, die gleich heißen. Widgets auf dem Sperr-/Home-Bildschirm sind einfach. Echte Kacheln in Apples Zuhause-App (wie für smarte Lampen) gehen auch, aber dafür baust du auf deinem Server eine kleine Brücke (Homebridge/Matter) — der Dev-Account ist dafür gar nicht nötig.

3. Top 10 (mit Konfidenz)

1. Individual-Enrollment braucht KEINEN D-U-N-S. Nur Apple-ID mit 2FA, volljährig, eigene Kreditkarte, dein Klarname erscheint als „Seller". D-U-N-S ist nur für Organisationen. (hoch) (Apple, D-U-N-S Help)
2. Der 7-Tage-Refresh verschwindet komplett. Er ist die Gratis-Personal-Team-Grenze (Profile/App-IDs/Geräte verfallen nach 7 Tagen). Bezahlt: Profile bis 1 Jahr. (hoch) (Apple, Compare Memberships)
3. APNs-Push braucht zwingend den bezahlten Account. Push/„Advanced capabilities" sind paid-only; das aps-environment-Entitlement kommt nur über ein Distribution-/Dev-Profil mit aktivierter Push-Capability. (hoch) (Apple, aps-environment, Compare Memberships)
4. TestFlight ist der beste Familienweg — aber Builds verfallen nach 90 Tagen. Du musst spätestens alle 90 Tage einen frischen Build hochladen, Apple verlängert nicht. (hoch) (PTKD Journal, TheLastTech)
5. Interne TestFlight-Tester: KEIN Review, Build in Minuten. Bis zu 100 interne Tester (App-Store-Connect-User), je bis 30 Geräte. Externe Tester (bis 10.000) brauchen Beta-App-Review beim ersten Build je Version. Für Familie = intern reicht satt. (hoch) (Apple, TestFlight overview, Add internal testers)
6. Ad-hoc = 100 Geräte pro Produktfamilie pro Mitgliedsjahr, Profil bis 1 Jahr gültig. Der einzige private „1-Jahr-Ruhe"-Weg, aber UDID-gebunden + manuelle Verteilung, kein Auto-Update. (hoch) (Apple, Devices overview)
7. Live Activities / Dynamic Island per Push gehen — mit Budget-Falle. Per-Activity-Push-Token via ActivityKit; APNs-Budget drosselt häufige Updates. apns-priority: 5 für unkritische Updates und NSSupportsLiveActivitiesFrequentUpdates=YES mildern das. iOS 18+ kennt zusätzlich Broadcast-Push (Channels). (hoch für Mechanik, mittel für exakte Budget-Zahlen) (Apple, ActivityKit Push, WWDC24 Broadcast)
8. watchOS 26: Widgets (Smart Stack) + Komplikationen laufen auf SE 2 und Series 10; iPhone-Live-Activities spiegeln automatisch in den Smart Stack. Eine eigenständige watchOS-App ist extra Arbeit, aber Komplikationen + gespiegelte Live Activity sind „billig". (hoch für Spiegelung/Komplikationen, mittel für SE-2-Detailgrenzen) (Apple Support, Watch Smart Stack)
9. „Kacheln in der Apple-Home-App" ≠ Home-Screen-Widget. Eigene Software-„Geräte" in Apples Home gehen via Homebridge/Matter-Bridge vom VPS — ohne ADP. Den ADP brauchst du nur für eine eigene iOS-App mit HomeKit-Framework (Entitlement). (hoch) (Homebridge, Apple HomeKit FAQ)
10. Bei Nichtverlängerung: nach 24 h aus dem Store (irrelevant für dich, da nicht veröffentlicht), aber installierte Ad-hoc/Dev-Apps sterben mit dem Profil; Testgeräte werden nach 180 Tagen entfernt; 30-Tage-Vorwarnung. Renew reaktiviert ohne Resubmit. (hoch) (Apple, Program Renewal)

4. Ausführlicher Body

4.1 Machbarkeits-Matrix je Zielbild-Punkt

4.2 Step-by-Step-Guide (end-to-end)

Schritt 0 — Account-Typ wählen: Individual

Für dich ist Individual richtig (sole proprietor / Einzelperson). Dein Klarname „Dennis Fisch" erscheint als Seller — irrelevant, da du nichts veröffentlichst. Organisation brauchtest du nur, wenn ein Firmenname als Seller stehen soll oder du Team-Admin-Rechte an Dritte vergeben willst — beides nicht dein Fall, und Organisation verlangt D-U-N-S + aufwändigere Verifikation (Apple, Compare Memberships).

Schritt 1 — Enrollment

• Voraussetzungen: Apple-ID mit 2FA aktiv, volljährig, eigene Kreditkarte, Klarname. Kein D-U-N-S (Apple, Program Enrollment, D-U-N-S Help).
• Weg: Apple-Developer-App (empfohlen, Identitätsprüfung läuft dort glatt) oder Web.
• Dauer: i. d. R. innerhalb 24 h freigeschaltet; wenn nach 24 h keine Bestätigung → Apple kontaktieren (Apple, Program Enrollment).
• Kosten: 99 €/Jahr (auto-renew, wenn über die App gekauft).

Schritt 2 — Xcode, Zertifikate, Automatic Signing

• Aktuelles Xcode, Apple-ID in Xcode › Settings › Accounts hinterlegen.
• Automatic Signing anhaken: Xcode erzeugt Dev-/Distribution-Zertifikat, App-ID, Profile selbst. Für eine Familien-App ist manuelles Profil-Gefummel unnötig.
• App-ID-Capabilities aktivieren, die du brauchst: Push Notifications, App Groups (für Widget/Live-Activity-Datentransfer), ggf. HomeKit (nur falls eigene HomeKit-App).

Schritt 3 — Familiengeräte registrieren

• Geräte (iPhones, Watches, Apple TV) per UDID unter Certificates, Identifiers & Profiles › Devices eintragen — nur für Ad-hoc/Dev nötig, für TestFlight nicht.
• Limit: 100 pro Produktfamilie pro Mitgliedsjahr (iPhone, Watch, TV zählen getrennt). Reset bei Renewal (Apple, Devices overview).

Schritt 4 — Verteilweg je Plattform (mit Begründung)

Adversariale Klarstellung interne vs. externe Tester: Interne Tester (= App-Store-Connect-User deines Teams, bis 100, je bis 30 Geräte) bekommen Builds ohne Review in Minuten. Familienmitglieder als interne Tester einzurichten geht (du legst sie als ASC-User mit Rolle Developer/Marketing an). Externe Tester (bis 10.000) brauchen Beta-App-Review beim ersten Build jeder Version (~1 Tag), Folgebuilds meist ohne. Für eine 2–4-Personen-Familie nimmst du intern und sparst dir jedes Review (Add internal testers, Invite external testers).

Schritt 5 — APNs-Key + erste echte Push

1. Certificates, Identifiers & Profiles › Keys › + → APNs Auth Key (.p8) erstellen (ein Key deckt Sandbox und Production ab; Token-basiert, statt der alten ablaufenden Zertifikate).
2. Key-ID + Team-ID + .p8 sicher ablegen (z. B. in deine .env auf dem VPS, analog zu VAPID heute).
3. Push-Capability in der App-ID + im Xcode-Target aktivieren → aps-environment-Entitlement landet im Profil (aps-environment).
4. Im App-Code Geräte-Token via registerForRemoteNotifications holen, an deinen FastAPI-Server schicken (ersetzt die VAPID-Subscription-Logik in backend/push.py).
5. Server: JWT aus dem .p8 signieren, POST an api.push.apple.com (Production) bzw. api.sandbox.push.apple.com (Sandbox/Debug). Sandbox vs. Production hängt am Build-Typ, nicht am Key — beide brauchen den bezahlten Account (Registering with APNs).

Schritt 6 — Minimale Live Activity mit Push-Update

1. In Xcode Widget Extension hinzufügen, „Include Live Activity" anhaken; geteilte ActivityAttributes in beide Targets (Capacitor-Live-Activity-Praxis).
2. SwiftUI für Lock-Screen-/Dynamic-Island-Layout bauen.
3. Activity starten → per-Activity-Push-Token via Activity.pushTokenUpdates einsammeln, an den Server schicken.
4. Server pusht Updates an dieses Token (apns-push-type: liveactivity).
5. Budget-Falle: Default-Priorität 10 zählt aufs ActivityKit-Budget; für unkritische Updates apns-priority: 5 nutzen, bei häufigen Updates NSSupportsLiveActivitiesFrequentUpdates=YES in der Info.plist setzen, sonst Drosselung (ActivityKit Push). Für „eine Familie, ein Tagesziel-Tracker" ist das Budget faktisch nie ein Problem — relevant würde es erst bei Sekunden-Takt.

Schritt 7 — Home-Screen-Widget (WidgetKit)

• Dieselbe Widget-Extension liefert auch statische/Timeline-Widgets.
• Datentransfer Capacitor <-> Widget über App Group (gemeinsamer Container) oder ein fertiges Plugin wie @capgo/capacitor-widget-kit (Capgo Widget-Kit, Kisimedia Widgets).

Schritt 8 — watchOS-App-Gerüst (Companion)

• iOS-Target um ein watchOS-App-Target ergänzen. Drei Ausbaustufen, aufsteigend nach Aufwand: 1. Nur Live-Activity-Spiegelung (fast gratis): iPhone-Live-Activities erscheinen automatisch im Smart Stack der Watch (Watch Smart Stack). 2. Komplikationen (WidgetKit-basiert in watchOS 26) für „Tagesbudget aufs Zifferblatt" — laufen auf SE 2 und Series 10. 3. Eigenständige Watch-App (eigene UI/Logik) — die teuerste Stufe.
• Für die Kinder-SE-2 ist Stufe 1–2 der pragmatische Start.

Schritt 9 — tvOS-Hinweise

• Eigenes tvOS-Target (iPhone-/iPad-Apps laufen NICHT auf Apple TV). Verteilung am bequemsten via TestFlight tvOS; alternativ Xcode-Install über LAN (Apple TV mit Xcode pairen, kein USB) (UMA, sideload Apple TV). tvOS ist klar „nice-to-have, später" — die Capacitor-WebView-Strategie greift auf tvOS schlechter (kein voll gleichwertiger WKWebView-Pfad), hier eher native View für eine einfache Anzeige.

Schritt 10 — Wartungsrhythmus

• Jährlich: Mitgliedschaft verlängern (sonst sterben Profile/Builds). Ad-hoc-Geräteliste-Reset prüfen.
• Alle <=90 Tage: Frischen TestFlight-Build hochladen (Auto-Update an die Familie). In deine Cron-/Deploy-Routine aufnehmen — analog zum heutigen Frontend-Build-Deploy.
• Bei jedem nativen Feature-Change: Build + Upload (Frontend-only-Änderungen erreichen die App weiter über den Capacitor-Remote-Modus ohne IPA-Rebuild — das bleibt euer Vorteil; nur native Extensions/Entitlements brauchen Rebuild).
• APNs-Key: Token-basiert, läuft nicht ab — kein Quartals-Stress wie bei alten Push-Zertifikaten.

4.3 Capacitor-Bezug: bestehende Hülle behalten

Pragmatischer Pfad: Hülle behalten + native Extensions ergänzen. Eure Stärke ist der Capacitor-Remote-Modus (Frontend-Deploys ohne IPA-Rebuild, ADR-40). Den wirfst du nicht weg.

• APNs: Capacitor-Push-Plugin (oder eigenes) holt das Geräte-Token; Server-Logik analog zum heutigen VAPID-Pfad.
• Widgets + Live Activities: Diese müssen nativ sein (SwiftUI-Targets), das geht in keiner WebView. Du baust sie als Xcode-Extension-Targets neben die Capacitor-App und teilst Daten über App Groups / fertige Plugins (Capgo, ludufre/capacitor-live-activities).
• Natives Neuschreiben lohnt nur, wenn du dauerhaft tief-native Watch-/TV-Erlebnisse willst. Für dein Zielbild ist „Hülle + Extensions" eindeutig der bessere Schnitt: minimaler Swift-Anteil genau dort, wo WebView nicht hinkommt.

4.4 Limits & Fallen (gesammelt, adversarial geprüft)

• TestFlight-90-Tage-Ablauf — die zentrale Falle. Apple verlängert nicht; abgelaufener Build = „Expired", Familie kann nichts starten, bis du neu hochlädst (PTKD, TheLastTech). Praxis: einmal pro Quartal hochladen. Verglichen mit dem 7-Tage-SideStore-Tanz ist das eine massive Erleichterung, aber nicht „nie wieder anfassen".
• Ad-hoc gibt 1 Jahr, aber kein Auto-Update. UDID-Pflege + IPA selbst verteilen (AirDrop/MDM/Link). Profil <=1 Jahr, dann neu signieren (Devices overview).
• Externe TestFlight-Tester ziehen Review nach sich — für Familie unnötig, intern bleiben.
• Live-Activity-Push-Budget drosselt Hochfrequenz; mit Priorität 5 + Frequent-Updates-Flag handhabbar, exakte Stundenzahlen dokumentiert Apple bewusst unscharf (Unsicherheit, siehe 4.6).
• watchOS-Eigenständigkeit kostet Arbeit — Spiegelung/Komplikationen sind billig, eine echte Standalone-Watch-App nicht.
• „Home-App-Kacheln" ist ein Begriffs-Stolperstein — siehe eigene Sektion unten.
• Nichtverlängerung: Veröffentlichungs-Apps fliegen nach 24 h aus dem Store (für dich egal). Wichtiger: Dev-/Ad-hoc-installierte Apps hängen an gültigen Profilen — läuft das Profil/die Mitgliedschaft aus, sterben sie. Testgeräte-Liste wird 180 Tage nach Ablauf geleert; 30-Tage-Vorwarnung mit Opt-out (Program Renewal). Renew = kein Resubmit nötig.

4.5 Die „Kacheln in der Home-App"-Frage (beide Lesarten)

Lesart (a) — Home-Screen-Widgets (WidgetKit): Trivial mit ADP. SwiftUI-Widget-Extension, Daten via App Group aus der Capacitor-App. Erledigt in Schritt 7.

Lesart (b) — echte Kacheln in Apples Home-App (HomeKit/Matter): Apples Home-App zeigt nur Geräte, die das HomeKit Accessory Protocol (HAP) oder Matter sprechen. Deine Silverscale-Werte (z. B. „Tagesbudget", „Vorrat niedrig") als Home-Kachel gehen — aber nicht über deine signierte iOS-App, sondern indem dein VPS ein virtuelles HAP/Matter-Gerät bereitstellt:

• Homebridge auf dem VPS emuliert HAP; ab v2 können Plugins Accessories auch über Matter (matter.js) ausspielen → erscheinen als Kacheln in Apple Home, Google Home, Alexa (Homebridge, homebridge-matter Wiki).
• Du würdest Silverscale-Zustände auf vorhandene Gerätetypen mappen (Sensor/Schalter/Kontakt). „Beliebige Datenkachel" gibt HomeKit nicht her — du modellierst deine Werte als Sensor o. ä.
• Wofür braucht man hier den Dev-Account? Für diesen Bridge-Weg gar nicht — das läuft komplett auf deinem Server. Den ADP brauchst du erst, wenn du eine eigene iOS-App mit dem HomeKit-Framework schreiben willst (Steuer-App mit HomeKit-Entitlement). Für non-commercial HAP-Eigenbau genügt ein registrierter (auch gratis) Developer-Account zum Lesen der HAP-Spec; MFi ist nur für verkaufte Produkte nötig (Apple HomeKit FAQ, HAP non-commercial Forum).

Fazit: Wenn du „Silverscale-Werte als Home-Kacheln" meinst → Matter-Bridge vom VPS, ADP dafür nicht erforderlich. Wenn du „Home-Screen-Widget" meinst → WidgetKit, ADP ja.

4.6 Offene Fragen / nicht zweifelsfrei verifiziert

• Exakte Live-Activity-Budget-Zahlen. Dass es ein Budget gibt und wie man es entschärft, ist klar belegt; die konkrete Updates-pro-Stunde-Grenze gibt Apple bewusst nicht hart an (variiert, Sekundärquellen nennen Richtwerte). Mittlere Konfidenz auf Zahlen, hohe auf Mechanik.
• watchOS-Live-Activity-Spiegelung im Detail auf SE 2. Smart-Stack-Spiegelung ist für watchOS 26 dokumentiert und SE 2 ist watchOS-26-fähig; ob jede Dynamic-Island-Feinheit identisch auf der älteren SE-2-Hardware erscheint, konnte ich nicht gerätegenau gegen eine Apple-Matrix verifizieren. Mittel.
• tvOS + Capacitor-WebView-Reichweite. Dass tvOS einen eigenen Target braucht, ist sicher; wie gut eure bestehende WebView-Codebasis auf tvOS wiederverwendbar ist (kein voller WKWebView-Komfort wie auf iOS), ist projektabhängig und nicht generisch belegbar. Niedrig–mittel.
• „Build läuft nach Mitgliedschafts-Ablauf weiter?" Für Enterprise sind 90 Tage Weiterlauf dokumentiert; für den normalen ADP ist die Formulierung weniger explizit — sicher ist nur, dass Profil-/Zertifikatsablauf die Apps stoppt. Mittel.

4.7 Kosten & Wartung — Kurzbilanz

• 99 €/Jahr, auto-renew. Keine Zusatzkosten für Push, TestFlight, Watch, TV.
• Wartungsaufwand realistisch: 1x jährlich verlängern + 1x pro Quartal TestFlight-Build hochladen. Das ist der gesamte „Pflicht-Rhythmus" — ein Bruchteil des heutigen 7-Tage-Schmerzes.

5. Quellenverzeichnis

Apple (primär): - Choosing a Membership / Compare Memberships - Program Enrollment (Help) - D-U-N-S Number (Help) - Program Renewal (Help) - Devices overview (Help) - TestFlight overview - Add internal testers - Invite external testers - aps-environment Entitlement - Registering your app with APNs - ActivityKit: Live Activities mit Push - WWDC24: Broadcast updates to Live Activities - Apple Support: Smart Stack auf der Watch (watchOS 26) - Apple Support: Komplikationen hinzufügen - Apple HomeKit FAQ (Developer) - Apple: Developing for the Home - Apple Help: TestFlight für iOS/tvOS/watchOS

Sekundär (Praxis): - PTKD: TestFlight-Build „Expired" - TheLastTech: TestFlight Build Expiry - UMA: Sideload/Sign Apple TV 4K - Kisimedia: Live Activities in Capacitor - Kisimedia: Widgets in Capacitor - Capgo: capacitor-widget-kit - ludufre/capacitor-live-activities - Homebridge (GitHub) - homebridge-matter Wiki: Matter aktivieren - Apple HAP non-commercial (Forums)

Wo Quellen unscharf oder widersprüchlich sind (Live-Activity-Budget-Zahlen, SE-2-Detailgrenzen, Build-Weiterlauf nach Ablauf), ist dies in Abschnitt 4.6 explizit als Unsicherheit markiert statt geglättet.

Addendum: Gegenprüfung am Vertragstext (07.06.2026)

Gegengeprüft an der öffentlichen Fassung des Apple Developer Program License Agreement vom 30.03.2026 (114 Seiten; Dennis' Account-Link ist login-gebunden, Inhalt ist dieselbe DPLA). Ergebnis: Der Bericht hält — mit einer wichtigen Verschärfung zugunsten von Ad Hoc:

1. Ad Hoc ist für Familien-DAUERBETRIEB vertraglich sauber — sogar sauberer als TestFlight. §7.3 erlaubt Verteilung an „individuals … who are otherwise affiliated with You for use on a limited number of Registered Devices" — Zweck ist „use", NICHT „testing". Und die Definition von „Registered Devices" schließt Geräte ein, die „owned by individuals who are affiliated with You" sind. Familie = affiliated group, ihre iPhones/Watches dürfen registriert werden. Pro Gruppe nur ein Block an Geräte-Lizenzen (Anzahl steht im Portal, nicht im Vertrag — die bekannten 100 je Geräteklasse/Jahr sind Portal-Policy).
2. TestFlight ist vertraglich Beta-only. §7.4: intern „solely for … testing, evaluating and/or developing", extern „solely for their testing and evaluation of such pre-release versions" + Apple-Freigabe (§6.5 Beta-Review). Dauerhafte Familien-Produktivnutzung über TestFlight ist also formal zweckfremd (praktisch verbreitet und unbehelligt — aber der Bericht hatte TestFlight als Komfort-Empfehlung; vertraglich ist Ad Hoc der vorgesehene Weg für „Familie nutzt die App dauerhaft").
3. Individual-Account-Nuance: Interne TestFlight-Tester sind Mitglieder der Organisation (App Store Connect User). Ein Individual-Account hat genau ein Mitglied — Familie wäre dort „External Beta Tester" inkl. einmaligem Beta-App-Review des ersten Builds. Auch das spricht für Ad Hoc als Primärweg.
4. Die 90-Tage-Build-Frist von TestFlight steht NICHT im Vertrag (reine TestFlight-Policy) — Befund des Berichts bleibt korrekt, Quelle ist die Doku.

Angepasste Empfehlung: Primärweg Familie = Ad Hoc (1-Jahres-Profil, vertraglich „use", kein Review, kein 90-Tage-Zyklus; Update = neue IPA aufs Gerät). TestFlight optional als Komfort-Kanal für schnelle Iterationszyklen mit Dennis selbst.