Was tun, wenn TestFlight „Not Available for Testing“ zeigt? Fehlerleitfaden 2026

DevOps & CI/CD ·ca. 11 Min. Lesezeit

Was tun, wenn TestFlight „Not Available for Testing“ zeigt? Fehlerleitfaden 2026

Der neue TestFlight-Build ist in App Store Connect sichtbar, aber mit „Not Available for Testing“ gekennzeichnet.

Prüfen Sie zuerst die Statusdetails: Apple ordnet diesen konkreten Status einem Provisioning Profile ohne App-ID zu. Korrigieren Sie die Signaturkonfiguration, erstellen Sie einen neuen Build mit passendem Profil und laden Sie ihn erneut hoch. Eine erneute Einladung der Tester behebt diesen Signaturfehler nicht.

Dieser Leitfaden richtet sich an Sie, wenn ein gerade hochgeladener Test-Build nicht freigegeben ist, Sie die verwendete Signierung nachvollziehen oder nach einem neuen Upload sicherstellen möchten, dass die richtigen Tester Zugriff erhalten. Auch wenn Sie Signierung und Build-Konfiguration im Team betreuen, können Sie damit die Ursache von einem anderen App-Store-Connect-Status abgrenzen.

Statusdetails statt erneuter Einladungen

„Not Available for Testing“ ist nicht bloß eine andere Bezeichnung für einen noch verarbeitenden Build. Apple beschreibt diesen konkreten TestFlight-Status mit einer spezifischen Ursache: Das verwendete Provisioning Profile enthält keine App-ID. Die Statusangabe ist deshalb der Ausgangspunkt für die Diagnose, nicht die Vermutung, ein Tester habe eine Einladung übersehen. Maßgeblich ist Apples Definition der App-Store-Connect-Build-Status.

Was bedeutet „Not Available for Testing“ in TestFlight? In diesem Fall ist der Build laut Apple nicht zum Testen verfügbar, weil das Provisioning Profile die App-ID nicht enthält. Das ist eine Aussage über diesen Status und kein allgemeiner Grund für jede TestFlight-Störung. Andere Status, etwa „Processing“, eine fehlende Export-Compliance-Angabe oder ein abgelaufener Build, müssen Sie separat anhand ihrer jeweiligen Statusdefinition behandeln.

Gehen Sie in App Store Connect zum betroffenen Build und lesen Sie den angezeigten Status samt Detailhinweis. Notieren Sie, welcher Build gemeint ist, und vergleichen Sie dessen Zustand mit dem zuletzt hochgeladenen Artefakt. Ein erfolgreicher Upload bedeutet noch nicht automatisch, dass der Build bereits testbar ist; Apple trennt den Upload vom anschließenden Status des Builds. Die offiziellen Hinweise zum Hochladen von Builds beschreiben diesen Ablauf.

Unterscheiden Sie die Fälle, bevor Sie Änderungen am Projekt vornehmen:

Diese Abgrenzung verhindert unnötige Änderungen am Projekt. Wenn die Statusdetails tatsächlich die fehlende App-ID nennen, ist es sinnvoll, die Signierung zu untersuchen. Weist App Store Connect einen anderen Zustand aus, wählen Sie die dafür vorgesehene Maßnahme, statt Profile ohne konkreten Hinweis auszutauschen.

Profil, Bundle Identifier und Ziel-App gemeinsam abgleichen

Ein Provisioning Profile ist nicht schon deshalb passend, weil sein Dateiname oder Anzeigename dem Projekt ähnelt. Entscheidend ist, ob die App-ID im Profil zum Bundle Identifier der Ziel-App gehört und ob genau dieses Profil beim Archivieren verwendet wurde. Apples Anleitung zum Erstellen eines App-Store-Provisioning-Profils beschreibt die Zuordnung des Profils zur App.

Welches Provisioning Profile sollten Sie bei einem nicht testbaren Build prüfen? Prüfen Sie das Profil, das beim Erstellen des betroffenen Archivs tatsächlich zum Einsatz kam. Ein anderes Profil, das im Entwicklerkonto vorhanden ist oder denselben Anzeigenamen trägt, belegt nicht, dass das hochgeladene Archiv mit diesem Profil signiert wurde. Vergleichen Sie daher Ziel-App, Team, Bundle Identifier und die im Build verwendete Signierkonfiguration.

Arbeiten Sie die Zuordnung in dieser Reihenfolge durch:

  1. Ziel-App festlegen. Öffnen Sie das Projekt und wählen Sie das Target, aus dem der hochgeladene Build entstanden ist. Bei mehreren Targets oder App-Erweiterungen darf die Prüfung nicht bei einem ähnlich benannten Hauptprojekt enden.
  2. Bundle Identifier vergleichen. Lesen Sie den Bundle Identifier des betreffenden Targets ab und vergleichen Sie ihn mit der App-ID, die für die App in App Store Connect vorgesehen ist. Ein ähnlich geschriebener Anzeigename ersetzt diesen Abgleich nicht.
  3. Signierteam und Konfiguration prüfen. Kontrollieren Sie im Projekt die Auswahl des Teams und die Signiereinstellungen für die verwendete Build-Konfiguration. Die Einstellungen des Debug-Targets müssen nicht denen des archivierten Release-Targets entsprechen.
  4. Konkretes Profil identifizieren. Ermitteln Sie, welches Provisioning Profile beim Archivieren verwendet wurde. Prüfen Sie dessen Inhalt und App-ID, nicht nur den Namen in einer Auswahlliste. Apples Informationen zum Bearbeiten und Herunterladen von Profilen helfen Ihnen, das zugehörige Profil im Entwicklerkonto zu kontrollieren.
  5. Übereinstimmung dokumentieren. Halten Sie Bundle Identifier, Team, Profil und Build-Konfiguration nebeneinander fest. Stimmen sie nicht überein, korrigieren Sie zuerst die Ursache und erstellen Sie danach ein neues Archiv.

Wie beheben Sie ein Provisioning Profile ohne App-ID? Verwenden oder erstellen Sie ein App-Store-Provisioning-Profile, das zur tatsächlichen App-ID passt, und stellen Sie sicher, dass der Build-Prozess dieses Profil für das richtige Target nutzt. Danach müssen Sie ein neues Archiv erzeugen und hochladen. Ein bereits hochgeladener Build erhält durch eine nachträgliche Profiländerung im Projekt nicht automatisch eine neue Signatur.

Automatischer Abgleich statt Namensvermutung

Die App-ID umfasst die Zuordnung zur App; der Bundle Identifier ist daher ein zentraler Prüfpunkt, aber nicht der einzige. Bei Projekten mit Erweiterungen kann ein Archiv mehrere signierte Komponenten enthalten, für die jeweils die passende Ziel- und Signierkonfiguration entscheidend ist. Prüfen Sie deshalb nicht nur, ob das Haupt-Target plausibel aussieht, sondern auch, ob die im Archiv enthaltenen Targets der vorgesehenen App-Struktur entsprechen.

Wenn Xcode die Signierung automatisch verwaltet, ist das kein Grund, die Kontrolle auszulassen. Die Automatisierung kann Profile auswählen oder aktualisieren; für die Diagnose zählt dennoch, was beim konkreten Archiv tatsächlich verwendet wurde. Behandeln Sie automatische Signierung als Arbeitsweise, nicht als Beweis, dass die Konfiguration jedes Targets korrekt ist. Apples Dokumentation zur Verteilung von Apps für Beta-Tests und Releases erläutert die Verteilung aus Xcode.

Manuelles Archiv und Automatisierung getrennt nachvollziehen

Bei einem manuell erzeugten Archiv prüfen Sie in Xcode die Einstellungen des tatsächlich archivierten Schemas und Targets. Sehen Sie im Organizer nach, welches Archiv exportiert und anschließend hochgeladen wurde. Vergleichen Sie diese Angaben mit dem Build in App Store Connect, damit Sie nicht versehentlich das Profil eines anderen Archivs untersuchen.

Bei einer CI- oder skriptbasierten Veröffentlichung reicht die aktuelle Projektansicht ebenfalls nicht aus. Der Build kann mit abweichenden Umgebungsvariablen, einer anderen Konfiguration oder einem anderen Profil erzeugt worden sein. Gleichen Sie deshalb drei Belege miteinander ab: die Projekteinstellungen zum Zeitpunkt des Builds, das Build-Protokoll und die Signierinformationen des tatsächlich hochgeladenen Archivs. Wenn Sie den Fehler reproduzieren, ändern Sie nicht mehrere Signierwerte gleichzeitig; andernfalls wird unklar, welche Korrektur den Status verändert hat.

Was tun, wenn die Xcode-Einstellungen korrekt aussehen, der Status aber bestehen bleibt? Prüfen Sie als Nächstes die Herkunft des hochgeladenen Artefakts. Ein korrektes Profil im aktuellen Projekt erklärt nicht, womit ein früher erzeugtes Archiv signiert wurde. Erstellen Sie bei Bedarf ein neues Archiv aus der geprüften Konfiguration und laden Sie genau dieses Archiv hoch. Die oben verlinkte Xcode-Dokumentation beschreibt die unterstützten Verteilungswege.

Nach dem Upload den tatsächlichen Status abwarten

Nach dem Neuaufbau beginnt die Prüfung nicht mit der Testergruppe, sondern mit dem neuen Build in App Store Connect. Kontrollieren Sie, ob die Verarbeitung abgeschlossen ist und welcher Status anschließend angezeigt wird. Der Upload-Erfolg bestätigt zunächst, dass die Übermittlung angenommen wurde; er ist nicht gleichbedeutend mit einer Freigabe für TestFlight.

Gehen Sie bei den folgenden Zuständen unterschiedlich vor:

Dieser Ablauf verhindert eine häufige Verwechslung: „hochgeladen“, „verarbeitet“, „zum Testen verfügbar“ und „einer Gruppe zugeordnet“ sind unterschiedliche Stationen. Verwenden Sie die Statusdefinitionen von Apple als Referenz, statt aus einer einzelnen Erfolgsmeldung auf den gesamten Testablauf zu schließen.

Erst bei verfügbarer Version die Testgruppe prüfen

Sobald der Build als testbar angezeigt wird, kontrollieren Sie die Zuweisung zur vorgesehenen Testgruppe. Prüfen Sie, ob die richtige Build-Version der internen oder externen Gruppe zugeordnet ist und ob die Tester für diese Gruppe eingerichtet sind. Die Apple-Anleitung zum Hinzufügen von Testern zu Builds führt durch die Verwaltung der Tester und Build-Zuweisung.

Bei externen Tests ist die externe Prüfung als eigener Freigabeschritt zu betrachten. Wenn ein Build nicht verfügbar ist, behebt eine Änderung an der Testergruppe nicht die fehlende App-ID im Provisioning Profile. Umgekehrt bedeutet ein technisch testbarer Build nicht automatisch, dass jede Person bereits Zugriff hat: Gruppe, zugewiesener Build und Status einer eventuell erforderlichen Prüfung müssen zusammenpassen.

Apple nennt für TestFlight bis zu 100 interne Tester und bis zu 10.000 externe Tester; diese Kapazitätsgrenzen stehen in der TestFlight-Übersicht. Für die Diagnose eines einzelnen fehlenden Zugriffs sind diese Obergrenzen selten der erste Prüfpunkt. Prüfen Sie zunächst die konkrete Gruppenzuordnung und den Zugriff des betroffenen Testers. Erst wenn eine Gruppe ihre Grenze erreicht, wird die Kapazität selbst zum relevanten Ausschlusskriterium.

Wie bestätigen Sie nach dem erneuten Upload, dass Tester den Build verwenden können? Verifizieren Sie zuerst den endgültigen Status des neuen Builds, dann dessen Zuordnung zur richtigen Gruppe und schließlich den Zugriff der vorgesehenen Tester. Dokumentieren Sie diese Prüfungen getrennt: Ein positiver Status allein bestätigt noch keine Gruppenzuweisung, und eine Gruppenzuweisung macht einen nicht verfügbaren Build nicht testbar.

Entscheidungshilfe: Welcher Schritt passt zu Ihrem Status?

Arbeiten Sie diese abhakbare Prüfliste von oben nach unten durch. Sobald eine Zeile zutrifft, erledigen Sie den zugehörigen Schritt und prüfen anschließend erneut den Status des neuen oder bestehenden Builds.

Der Vorteil dieser Vorgehensweise ist eine klare Ursache-Wirkungs-Kette: Sie können unterscheiden, ob die Korrektur an der Signierung, an einem separaten App-Store-Connect-Schritt oder an der Testerzuweisung lag. Der Nachteil ist, dass Sie ein neues Archiv und einen erneuten Upload einplanen müssen, wenn tatsächlich das Profil des bestehenden Builds falsch war. Eine Einladung zu wiederholen ist zwar schneller, aber bei einer fehlenden App-ID keine wirksame Reparatur.

Remote-Neuaufbau nur mit nachvollziehbarer Signatur

Wenn Sie auf einem entfernten Mac neu archivieren, legen Sie vor dem Upload fest, welche Nachweise den Erfolg belegen: Commit oder Quellstand, verwendetes Target und Build-Konfiguration, Herkunft des Provisioning Profiles, Kennung des neu hochgeladenen Builds und dessen endgültiger Status. Führen Sie diese Angaben in einem kurzen Release-Protokoll zusammen. So können Sie bei einem Rückfall erkennen, ob der falsche Quellstand, ein abweichendes Profil oder ein anderer Build hochgeladen wurde.

Ein Remote-Mac ist hier ein Ausführungsort, kein Ersatz für die Signierprüfung. Prüfen Sie den Zugriffsschutz für Zertifikate und Profile, begrenzen Sie Berechtigungen auf die Personen und Prozesse, die sie für den Release benötigen, und speichern Sie keine Signiergeheimnisse in allgemein zugänglichen Protokollen. Für die Auswahl eines geeigneten Betriebsmodells können Sie Mac-Angebote vergleichen; wenn Sie einen entfernten Mac für einen konkreten Build benötigen, sehen Sie sich die Mac-Umgebung in Virginia an.

Der Fernaufbau ist vor allem dann eine Option, wenn Ihr Team keinen geeigneten Mac für einen gelegentlichen oder verteilten Release-Prozess bereitstellen möchte. Er ist nicht automatisch die beste Wahl für dauerhaft hohe Build-Last, zwingend benötigte lokale Geräteanschlüsse oder Abläufe, die eine physische Testumgebung voraussetzen. In diesen Fällen kann ein eigener Mac oder ein lokaler Build-Rechner besser zu Ihren Anforderungen passen.

Wenn Ihr aktueller Ablauf auf einem einzelnen Entwickler-Mac beruht, bleiben als Nachteile typischerweise die Bindung an dessen Verfügbarkeit, die wiederholte lokale Einrichtung und die erschwerte Übergabe der Signierkonfiguration. Ein gemieteter Mac kann für zeitlich begrenzte Neuaufbauten oder eine gemeinsam genutzte Release-Umgebung sinnvoller sein, sofern Datenschutz, Zugangskontrolle und der benötigte Testaufbau dazu passen. Prüfen Sie vor einer Umstellung, ob Ihr Projekt und Ihre Signiermaterialien sicher auf die gewählte Umgebung übertragen werden können.

Für den nächsten Schritt gilt: Ist das Profil als Ursache bestätigt und fehlt Ihnen eine passende Mac-Umgebung für den korrigierten Build, prüfen Sie, ob eine gemietete Mac-Umgebung zu Ihrem Release-Prozess passt. Wenn Sie hingegen dauerhaft hohe Build-Last oder lokale Geräte benötigen, behalten Sie einen eigenen Mac als möglicherweise passendere Lösung im Vergleich.

Richten Sie Ihre iOS-Entwicklung auf einem dedizierten Mac von VpsHold ein

Mieten Sie einen eigenen physischen Mac mini statt einer virtuellen Maschine und führen Sie Builds sowie Signierprüfungen in einer macOS-Umgebung aus.

Modell und Mietdauer wählen Alle Preise ansehen