Der Unterschied ist einfach: Interne TestFlight-Builds werden nicht geprüft und stehen deinem Team innerhalb von Minuten zur Verfügung, während externe Builds die Beta-App-Prüfung durchlaufen müssen und meist einige Stunden bis 48 Stunden brauchen. Internes Testing ist also für Geschwindigkeit und die Prüfung im eigenen Team gedacht, externes Testing für Feedback echter Nutzer außerhalb des Teams. Wenn du schnell etwas verifizieren musst, ist intern fast immer die richtige Wahl; wenn du echtes Nutzerfeedback brauchst, extern.
Kurze Antwort
Interne Tester, bis zu 100 Personen mit einer Rolle in App Store Connect, erhalten Builds ohne Beta-App-Prüfung, meist innerhalb von Minuten nach der Verarbeitung. Externe Tester, bis zu 10.000 Personen, benötigen die Beta-App-Prüfung, die Apple laut seiner TestFlight-Seite automatisch startet, sobald du einen Build zu einer Gruppe hinzufügst. Die erste Version eines Builds braucht eine vollständige Prüfung, meist einige Stunden bis 48 Stunden. Wähle intern für Geschwindigkeit, extern für echtes Nutzerfeedback vor dem Launch.
Interner vs. externer Test: der Kernunterschied
Der entscheidende Unterschied ist die Beta-App-Prüfung: Interne Tests brauchen sie nicht, externe schon. Interne Tester sind Personen aus deinem eigenen Team mit einer Rolle in App Store Connect, und sie bekommen einen Build direkt nach der technischen Verarbeitung, ohne auf eine Prüfung durch Apple zu warten. Externe Tester sind Personen außerhalb deines Teams, und bevor sie einen Build installieren können, muss dieser die Beta-App-Prüfung bestehen.
Aus diesem einen Unterschied ergeben sich alle anderen. Die folgende Tabelle stellt beide Testarten direkt gegenüber.
| Aspekt | Interner Test | Externer Test |
|---|---|---|
| Beta-App-Prüfung | Nicht erforderlich | Erforderlich |
| Wer teilnimmt | Bis 100 Personen mit App-Store-Connect-Rolle | Bis 10.000 Personen außerhalb des Teams |
| Verfügbar nach | Minuten nach der Verarbeitung | Stunden bis 48 Stunden (erster Build) |
| Zweck | Schnelle interne Prüfung | Feedback echter Nutzer |
| Erste Version | Keine Prüfung | Vollständige Prüfung |
Wichtig ist, dass beide Wege denselben Build nutzen können. Du kannst einen Build gleichzeitig einer internen Gruppe geben, um sofort zu testen, und ihn zur externen Prüfung einreichen, um parallel Feedback von außen vorzubereiten. So kombinierst du die Geschwindigkeit des internen Tests mit der Reichweite des externen, ohne auf eines von beidem verzichten zu müssen.
Wann solltest du internes Testing wählen?
Wähle internes Testing immer dann, wenn Geschwindigkeit zählt und die Tester in deinem Team sind. Weil interne Builds keine Prüfung durchlaufen, stehen sie in Minuten bereit, was sie ideal für die tägliche Entwicklung macht: einen Fix verifizieren, eine neue Funktion im Team ausprobieren oder einen dringenden Fehler nachstellen. Für all das musst du nicht auf Apple warten.
Internes Testing eignet sich auch als Notausgang, wenn du auf eine externe Prüfung wartest. Wenn ein externer Build in der Warteschlange hängt und du trotzdem sofort testen musst, gibt dir eine interne Gruppe denselben Build in Minuten. Viele Teams warten tagelang auf die externe Freigabe, obwohl ein interner Test ihre eigene Prüfung sofort entsperrt hätte. Gerade in einem Sprint ist dieser Zeitgewinn oft wichtiger als die Frage, ob am Ende auch externe Tester dabei sind.
Wann solltest du externes Testing wählen?
Wähle externes Testing, wenn du Feedback von echten Nutzern außerhalb deines Teams brauchst. Vor einem öffentlichen Launch willst du wissen, wie sich die App auf fremden Geräten, in fremden Netzen und mit echten Nutzungsmustern verhält, und dafür reichen interne Tester nicht aus. Mit bis zu 10.000 externen Testern kannst du eine Beta breit ausrollen und aussagekräftiges Feedback sammeln.
Der Preis dafür ist die Beta-App-Prüfung, die Zeit kostet und die du einplanen musst. Externes Testing ist also der richtige Weg für eine echte Beta-Phase, aber nicht für die schnelle Zwischenprüfung während der Entwicklung. Wer beides verwechselt, wartet unnötig auf eine Prüfung, die für den eigentlichen Zweck gar nicht nötig war.
Wie lange dauert jeweils die Freigabe?
Intern dauert die Freigabe Minuten, extern meist einige Stunden bis 48 Stunden. Bei internen Testern gibt es nach der technischen Verarbeitung keine weitere Wartezeit, weil keine Prüfung stattfindet. Bei externen Testern kommt die Beta-App-Prüfung hinzu, und die erste Version eines Builds braucht immer eine vollständige Prüfung, während spätere Builds derselben Version oft schneller sind.
Apple garantiert keine feste Dauer, deshalb ist jede genaue Zahl ein Erfahrungswert, keine Zusage. In Phasen mit hohem Aufkommen, wie sie Anfang 2026 viele Entwickler in einem Thread der Apple-Entwicklerforen beschrieben, kann die externe Prüfung länger dauern. Genau deshalb ist es praktisch, für dringende Tests den internen Weg zu kennen. Wer beide Wege beherrscht, macht sich von der externen Warteschlange unabhängig, wann immer es nur um die eigene Prüfung geht.
Die Beta-App-Prüfung für externe Tester
Für externe Tester gelten einige feste Regeln, die erklären, warum ein Build wartet. Die erste Version eines Builds braucht eine vollständige Beta-App-Prüfung, bevor externe Tester sie installieren können. Außerdem prüft Apple nur einen Build pro Version gleichzeitig, sodass ein zweiter Upload derselben Version hinter dem ersten wartet, und es sind maximal sechs Builds für die TestFlight-Prüfung innerhalb von 24 Stunden erlaubt.
Auch die Angaben zum Build beeinflussen die Dauer. Ein leeres Feld "Zu testende Inhalte", fehlende Angaben zur Exportkonformität oder Berechtigungen ohne Begründung können die Prüfung verlängern oder zu einer Ablehnung führen. Diese Felder sauber auszufüllen, ist der einfachste Weg, einen externen Build zügig zu den Testern zu bringen.
Häufige Verwechslungen und Fehler
Die häufigste Verwechslung ist die Annahme, auch interne Builds würden geprüft. Das stimmt nicht: Interne Tester erhalten den Build ohne Prüfung, und wer das weiß, spart sich unnötiges Warten. Ein zweiter Fehler ist, aus Ungeduld einen neuen externen Build hochzuladen, was die Prüfung von vorn startet und dich in der Warteschlange nach hinten wirft.
Ein dritter Fehler betrifft die Verteilung. Ein Build kann bereits freigegeben sein, aber die Tester sehen ihn trotzdem nicht, weil er nicht verteilt wurde oder die automatische Benachrichtigung nicht aktiviert war. Prüfe deshalb im Zweifel, ob der Build wirklich noch in der Prüfung ist oder ob nur ein Verteilungsschritt auf deiner Seite fehlt. Diese drei Verwechslungen erklären einen großen Teil der Fragen, die sich mit einem Blick in die Einstellungen von selbst beantworten.
Ein Entscheidungsleitfaden, Schritt für Schritt
Ordne deine Situation der passenden Testart zu, statt pauschal extern zu wählen. Die folgende Tabelle gibt eine klare Empfehlung.
| Deine Situation | Empfehlung | Grund |
|---|---|---|
| Schnell etwas verifizieren | Intern | Keine Prüfung, sofort verfügbar |
| Feedback echter Nutzer | Extern | Größere, externe Testgruppe |
| Erster Build, Zeitdruck | Intern testen, extern parallel einreichen | Intern entsperrt sofort |
| Kurz vor dem öffentlichen Launch | Extern | Realistische Bedingungen und Reichweite |
| Nur das eigene Team | Intern | Einfacher und schneller |
Als Faustregel gilt: Nutze intern für alles, was schnell gehen muss und im Team bleibt, und extern für echtes Nutzerfeedback vor dem Launch. Wenn du unsicher bist, beginne intern, um sofort testen zu können, und reiche parallel den externen Build ein, damit die Prüfung schon läuft, während du weiterarbeitest.
Interne und externe Tester einrichten
Der Ablauf unterscheidet sich je nach Testart, ist aber in beiden Fällen überschaubar. Für interne Tester fügst du Personen mit einer Rolle in deiner App-Store-Connect-Organisation zur internen Gruppe hinzu; sobald ein Build verarbeitet ist, können sie ihn ohne Prüfung installieren. Für externe Tester erstellst du eine externe Gruppe, fügst den Build hinzu und reichst ihn zur Beta-App-Prüfung ein. Erst nach der Freigabe erhalten die externen Tester Zugriff über einen öffentlichen Link oder eine E-Mail-Einladung.
Ein Detail wird oft übersehen: Ob deine Tester automatisch benachrichtigt werden, entscheidest du beim Hinzufügen des Builds. Ist die automatische Benachrichtigung nicht aktiviert, musst du den Build nach der Freigabe manuell verteilen, sonst sehen die Tester nichts, obwohl der Build bereit ist. Prüfe diese Einstellung, bevor du von einem Problem ausgehst, denn häufig fehlt nur dieser eine Schritt auf deiner Seite.
Achte außerdem auf die Angaben, die externe Tester zu sehen bekommen. Das Feld "Zu testende Inhalte" beschreibt, was getestet werden soll, und eine klare Beschreibung hilft nicht nur den Testern, sondern auch der Prüfung, den Build schneller einzuordnen. Für interne Tester ist dieser Aufwand geringer, weil kein Prüfer beteiligt ist, aber eine kurze Notiz erleichtert auch dem eigenen Team die Arbeit.
Vor dem Upload: den Build prüfen
Der sicherste Weg, keinen externen Prüfzyklus zu verlieren, ist, keinen Build einzureichen, der ohnehin abgelehnt wird. Jede Ablehnung wirft dich in der Warteschlange zurück, und ein vermeidbares Problem wie ein eingebetteter geheimer Schlüssel, eine Berechtigung ohne Begründung oder eine unsichere Netzwerkkonfiguration kann dich einen ganzen Zyklus kosten, gerade wenn ein Team auf die Beta wartet.
Ein Scanner wie PTKD.com analysiert deine fertige .ipa vor dem Upload und liefert einen nach OWASP MASVS geordneten Bericht, damit du genau das behebst, was eine Ablehnung auslösen würde. Dabei sollte man ehrlich über die Grenze sein: Ein Scanner beschleunigt die Beta-App-Prüfung nicht und ersetzt bei risikoreichen oder regulierten Apps keine manuelle Sicherheitsprüfung. Er verhindert aber die vermeidbaren Ablehnungen, die dich zwingen, die externe Wartezeit noch einmal zu durchlaufen.
Das Wichtigste in Kürze
- Interne Builds werden nicht geprüft und stehen dem Team in Minuten zur Verfügung; externe Builds brauchen die Beta-App-Prüfung.
- Intern eignet sich für Geschwindigkeit und Team-Tests, extern für Feedback echter Nutzer vor dem Launch.
- Die erste Version eines externen Builds braucht eine vollständige Prüfung, meist einige Stunden bis 48 Stunden.
- Ein neuer Upload derselben Version setzt die Prüfung zurück; für dringende Tests nutze eine interne Gruppe.
- Prüfe den Build vor dem Upload mit PTKD.com, damit eine vermeidbare Ablehnung keinen externen Prüfzyklus kostet.
