iOS / Android Dev Tools

Bereitstellungsprofil anzeigenDie XML-Felder lesen

Lokale Datei auswählen oder das synthetische Beispiel laden. Nach dem Dekodieren stehen Übersicht, Rechte, Feldbaum und XML bereit.

Bereitstellungsprofil anzeigen

Profildatei

Eine .mobileprovision- oder .provisionprofile-Datei hier ablegen. Maximal 5 MiB.

Keine Datei ausgewählt

Ergebnis

Die Datei bleibt in diesem Tab. Das Werkzeug lädt sie nicht hoch und speichert sie nicht.

Optionen

Bekannte Gerätezeichenketten ersetzen und Binärdaten leeren. Team, App und weitere Metadaten bleiben. Nach Änderungen erneut dekodieren.

Datei auswählen und dekodieren.

Das Dekodieren prüft weder Signatur, Zertifikate, Widerruf noch Installierbarkeit.

Der Export ist eine unsignierte XML-Kopie, kein installierbares Profil.

Bereitstellungsprofil anzeigen hilft bei einem falschen Team im Archiv oder einem Testgerät, das die App nicht installieren kann. Vergleichen Sie möglichst die tatsächlich eingebettete Datei mit der heruntergeladenen Kopie, statt sich auf gleiche Dateinamen zu verlassen.

Wer eine mobileprovision öffnen möchte, braucht Zugriff auf den Inhalt der CMS-Hülle. Dieses Werkzeug folgt deren Struktur bis zum XML. Moderne Systeme können dagegen DER-Encoded-Profile als Grundlage verwenden; die lesbare Darstellung dient der Fehlersuche.

Warum Bereitstellungsprofil anzeigen?

Zusammenfassung mit nachvollziehbaren Feldern

Bereitstellungsprofil anzeigen verbindet Team, App-Kennung und Ablaufdatum mit den ursprünglichen Feldpfaden. In der separaten Entitlements-Ansicht bleiben Arrays und boolesche Werte unterscheidbar. So lässt sich eine Vermutung über eine Berechtigung direkt am tatsächlichen Wert prüfen.

Eine Profilhülle öffnet sich zu einem Baum mit Zweigen für Identität, Datum und Berechtigungen.

Maskierung auch in der exportierten Kopie

Geräte-UDIDs werden standardmäßig ersetzt, ebenso ihre Wiederholungen in anderen Zeichenketten. Binäre data-Inhalte werden geleert, weil sie weitere Kopien dieser Kennungen enthalten können. Team und App bleiben erkennbar; die Maskierung anonymisiert das Dokument nicht.

Gerätezeilen auf einem Bildschirm und in einer Exportdatei tragen dieselben Masken, andere Metadaten bleiben sichtbar.

Die Datei aus dem tatsächlichen Build verwenden

01

Beispiel und echtes Profil unterscheiden

Entnehmen Sie embedded.mobileprovision dem eigenen App-Bundle. Das Beispiel ist ein synthetischer CMS-Container ohne Unterzeichner und dient nur zum Erkunden der Ansichten. Es ist kein von Apple ausgestelltes Profil.

02

Nach einem Optionswechsel erneut dekodieren

Ein Wechsel der Maskierung entfernt das alte Ergebnis und sperrt den Export. Starten Sie erneut per Schaltfläche oder Ctrl/Cmd + Enter. Der Wechsel zwischen Übersicht, Feldbaum und XML verändert den gelesenen Inhalt nicht.

03

Lange Zweige gezielt öffnen

Dictionary- und Array-Pfade lassen sich auf- und zuklappen. Der Baum zeigt jeweils 50 zusätzliche Zeilen, der Export enthält weiterhin die gesamte aktuelle Kopie. Löschen und Dateiersatz haben eine Vorschau und lassen sich einmal rückgängig machen.

Den Auslöser in den Originalfeldern suchen

Team und App-Kennung

Name, UUID, TeamName und TeamIdentifier erscheinen gemeinsam. Die Bundle ID wird durch Entfernen des ersten Präfixsegments aus application-identifier abgeleitet; der alternative macOS-Schlüssel wird berücksichtigt. Platzhalter bleiben erhalten, fehlende Angaben werden nicht erfunden.

Rechte mit ihren Datentypen

Entitlements erhält eine eigene Ansicht. Dictionaries, Arrays, boolesche Werte, Ganzzahlen, Datumswerte und Binärdaten behalten ihre Typen. Diese Rechte beschreiben den erlaubten Umfang des Profils, nicht die tatsächlich in der App-Signatur beanspruchten Rechte. Ein Abgleich beider Seiten findet nicht statt.

Zeitpunkt der Datumsprüfung

CreationDate und ExpirationDate bleiben UTC-Werte. Das Ablaufdatum wird mit der Browserzeit beim Dekodieren verglichen. Die Anzeige unterscheidet abgelaufen, noch nicht abgelaufen und unbekannt. Eine falsch eingestellte Rechneruhr beeinflusst das Ergebnis; ein zukünftiges Datum belegt keine gültige Signatur.

Strukturierter plist-Export

Die XML-Nutzdaten werden aus SignedData entnommen, statt XML-Fragmente irgendwo in der Datei zu suchen. Reihenfolge und Werttypen bleiben erhalten. Bei aktiver Maskierung werden bekannte Gerätekennungen ersetzt und sämtliche data-Elemente geleert.

Grenzen der Aussagekraft

Keine Vertrauens- oder Installationsprüfung
CMS-Signaturen, Zertifikatsketten, Widerruf und Apple-Vertrauen werden nicht geprüft. Auch die Installierbarkeit der App wird nicht entschieden. Ein Container ohne Unterzeichner wird ausdrücklich gekennzeichnet. Erfolgreiches Dekodieren bedeutet nur, dass die unterstützte Struktur gelesen wurde.
Inneres DER bleibt uninterpretiert
Moderne Systeme können sich auf DER-Encoded-Profile stützen. Das Werkzeug interpretiert dessen innere Bedeutung nicht und gleicht es nicht mit XML ab. Unbekannte Felder bleiben lesbar, ohne erfundene Bedeutung oder eine abgeleitete Klassifizierung des Verteilungsprofils.
Ein klar begrenztes Dateiformat
Akzeptiert wird eine binäre CMS-SignedData-Datei mit eingebettetem UTF-8-XML-plist. BER mit bestimmter und unbestimmter Länge sowie konstruierte Octet Strings werden unterstützt. Rohes XML, binäre plists, verschlüsselte oder abgetrennte CMS-Inhalte sowie IPA, P12 und URLs sind ausgeschlossen.
Maskieren ersetzt keine Inhaltsprüfung
Kennungen aus ProvisionedDevices werden in Zeichenketten und Schlüsseln ersetzt; sämtliche Binärdaten werden geleert. Namen, Teams, Bundle IDs und andere Metadaten bleiben. Prüfen Sie den Inhalt vor dem Weitergeben. Für vollständige Werte müssen Sie die Maskierung ausschalten und erneut dekodieren.
Begrenzter Aufwand, unsignierte Ausgabe
Die Eingabe ist auf 5 MiB begrenzt, jeder Parser auf 10000 Knoten und 64 Ebenen, die serialisierte Ausgabe auf 10 MiB. Doppelte Schlüssel und unpassende Werte werden abgewiesen. Der Export entfernt die CMS-Hülle und kann kein Profil verlängern, signieren oder installieren.

Bereitstellungsprofil anzeigen: Fragen

Wie öffne ich eine mobileprovision-Datei?

Wählen Sie die lokale Datei und starten Sie das Dekodieren. Zuerst wird der CMS-Aufbau geprüft, danach das eingebettete XML-plist gelesen. Dass ein Texteditor lesbare Fragmente anzeigt, beweist nicht, dass die umgebende Datei das unterstützte Format hat.

Wie sehe ich, welche Geräte-UDIDs ein Build enthält?

Öffnen Sie ProvisionedDevices im Feldbaum. Standardmäßig bleiben Anzahl und Platzhalter sichtbar. Schalten Sie die Maskierung aus und dekodieren Sie erneut, um echte Gerätekennungen zu sehen. Eine fehlende Liste bedeutet nicht automatisch eine Freigabe für alle Geräte.

Wie prüfe ich das Ablaufdatum eines Profils?

Vergleichen Sie ExpirationDate mit der angezeigten Prüfzeit. Das zeigt nur, ob die eingetragene Frist nach der aktuellen Rechneruhr verstrichen ist. Ob Apple Zertifikat, Signatur oder Profil noch akzeptiert, muss mit den Plattformwerkzeugen geprüft werden.

Welches Profil wurde für die IPA-Datei verwendet?

Entpacken Sie ein Entwicklungs- oder Ad-hoc-IPA selbst und suchen Sie embedded.mobileprovision im App-Bundle unter Payload. Diese Seite entpackt keine IPA-Dateien. Aus dem App Store gelieferte Apps enthalten möglicherweise kein eingebettetes Profil.

Kann ich das Ablaufdatum eines Profils ändern?

Eine Änderung am exportierten XML verlängert das von Apple signierte Profil nicht. Die Kopie besitzt keine CMS-Signatur. Erstellen oder aktualisieren Sie das Profil im Entwicklerkonto beziehungsweise in Xcode und bauen Sie die App anschließend mit der passenden Datei neu.

Fehlt ein Detail zur Profilansicht?

Den nächsten Unterschied nachvollziehen

Bereitstellungsprofil anzeigen macht Team, Geräte und Rechte des verwendeten Builds nachvollziehbar. Nutzen Sie XML als Diagnosebeleg und die Apple-Werkzeuge für Entscheidungen über Vertrauen und Signierung.