Mac- und iOS-Apps bauen und ausliefern, ohne Xcode zu öffnen

 (scottwillsey.com)
2 Punkte von GN⁺ 4 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Nach der anfänglichen Einrichtung von Apple-Account und Zertifikaten lassen sich Build, Signierung und Auslieferung von Mac- und iOS-Apps allein mit den CLI-Tools innerhalb von Xcode.app automatisieren
  • Mit XcodeGen wird aus project.yml das .xcodeproj neu erzeugt; xcodebuild, notarytool, stapler und devicectl übernehmen alles von der Projekterstellung bis zur Notarisierung auf dem Mac und Installation auf dem iPhone
  • Die Mac-Auslieferung führt mit einem einzigen scripts/release.sh nacheinander Archivierung, Developer-ID-Signierung, Notarisierung, Stapling des Tickets, Gatekeeper-Prüfung und Installation nach /Applications aus und bricht bei Fehlern sofort ab
  • Für schnelles Kompilieren und Testen kann CODE_SIGNING_ALLOWED=NO verwendet werden, doch dieser temporär signierte Build besteht Gatekeeper nicht, und iCloud KVS sowie App-Group-Berechtigungen werden nicht an die echte Team-ID gebunden
  • Private Signaturschlüssel und Notarisierungs-Passwörter werden im Login-Schlüsselbund gespeichert; wenn Befehle und Auslieferungsregeln in CLAUDE.md oder AGENTS.md dokumentiert sind, können Agenten wie Claude Code den gesamten Workflow wiederholt ausführen

Was ohne Xcode-GUI möglich ist

  • Xcode selbst muss installiert sein, muss aber nicht gestartet werden; xcodebuild, notarytool, stapler und devicectl sind allesamt Shell-Tools innerhalb von Xcode.app und laufen eigenständig
  • Für die Ersteinrichtung wie Apple-ID-Login, Erstellung eines Developer-ID-Zertifikats und Speichern des Notarisierungs-Passworts ist eine GUI oder ein interaktives Terminal nötig
  • Nach Abschluss der Ersteinrichtung lassen sich Projekterstellung, Build, Archivierung, Export einer signierten App, Notarisierung, Prüfung, Installation und sogar die Auslieferung auf ein echtes iPhone ohne Maus erledigen
  • Wenn man bei Konfiguration oder Skripterstellung stecken bleibt, kann man Claude Code oder einem anderen LLM-Coding-Tool die Anforderungen und projektspezifischen Werte geben, damit es den Workflow erstellt

Vollständige Xcode-Toolchain auswählen

  • Zuerst sollte geprüft werden, ob das Ergebnis von xcode-select -p /Applications/Xcode.app/Contents/Developer ist
  • Falls die eigenständigen Command Line Tools ausgewählt sind, wird mit folgendem Befehl die vollständige Xcode-Toolchain festgelegt
sudo xcode-select -s /Applications/Xcode.app/Contents/Developer
  • Die über xcode-select --install installierten /Library/Developer/CommandLineTools enthalten zwar clang und git, aber nicht die vollständigen App-Entwicklungstools wie iOS SDK, notarytool oder devicectl
  • Wenn Xcode bereits installiert ist, ist kein separates Command-Line-Tools-Paket nötig
  • Auch Lizenzannahme und Installation zusätzlicher Komponenten lassen sich über die CLI erledigen
sudo xcodebuild -license accept
sudo xcodebuild -runFirstLaunch

Projekte mit XcodeGen reproduzieren

  • XcodeGen verwaltet Xcode-Projekteinstellungen als YAML und erzeugt bei jedem Build das .xcodeproj neu
  • Es kann von GitHub heruntergeladen oder über Homebrew installiert werden
brew install xcodegen
  • Ein .xcodeproj ist unter macOS ein Ordner, der wie eine Datei aussieht; weil Xcode interne Dateien und Referenzen laufend ändert, kann es im Git-Repository zu Konflikten oder unnötigen Änderungen kommen
  • Wenn man nur project.yml in Git committet und das erzeugte .xcodeproj ignoriert, bleibt die Projektkonfiguration reproduzierbar
xcodegen generate

Apple-Entwicklerkonto und Zertifikate einrichten

  • In Xcode muss unter Settings → Accounts eine Apple-ID hinzugefügt werden
  • Für App-Auslieferung und Notarisierung ist ein kostenpflichtiger Apple-Developer-Account erforderlich
  • Unter Settings → Accounts → Apple ID → Manage Certificates… → + → Developer ID Application wird ein Zertifikat für die Auslieferung erstellt
  • Apple Development und Developer ID Application haben unterschiedliche Zwecke
    • Apple Development wird genutzt, um auf eigenen Geräten auszuführen oder zur lokalen Fehlersuche auf ein iPhone zu übertragen
    • Developer ID Application ist nötig, um eine notarisierte .app auszuliefern, die auch auf den Macs anderer Personen Gatekeeper passiert
  • Beim Erstellen eines Developer-ID-Application-Zertifikats werden das Zertifikat und der zugehörige private Schlüssel im Login-Schlüsselbund installiert
  • Für die tatsächliche Signierung wird der private Schlüssel verwendet; er kann nicht erneut heruntergeladen werden, sollte also nicht gelöscht werden, und der Schlüsselbund sollte gesichert werden

Notarisierungs-Zugangsdaten im Schlüsselbund speichern

  • Die Notarisierung einer Mac-App ist der Prozess, bei dem eine signierte App zu Apple hochgeladen und auf Schadcode geprüft wird
  • notarytool authentifiziert sich über ein im Schlüsselbund gespeichertes Profil; beim erstmaligen Anlegen des Profils muss ein app-spezifisches Passwort interaktiv eingegeben werden
xcrun notarytool store-credentials App-Name \
  --apple-id "you@example.com" \
  --team-id YOUR-TEAM-ID
  • Das Notarisierungsprofil sollte nicht von einer anderen App übernommen, sondern passend zum App-Namen erstellt werden, um stille Fehlschläge in anderen Umgebungen zu vermeiden
  • Ein app-spezifisches Passwort unterscheidet sich vom Apple-ID-Passwort und wird auf der Apple-ID-Website unter Sign-In & Security → App-Specific Passwords erzeugt
  • Wenn das Apple-ID-Passwort geändert wird, kann ein app-spezifisches Passwort ohne gesonderte Warnung ablaufen
    • Tritt bei der Notarisierung 401 invalid credentials auf, sollte vor Verdacht auf die gesamte Einrichtung zuerst geprüft werden, ob das app-spezifische Passwort abgelaufen ist
  • Ob das Profil gespeichert ist, prüft folgender Befehl
xcrun notarytool history --keychain-profile App-Name
  • Wenn das app-spezifische Passwort in einem 1Password-Tresor gespeichert wird, auf den Claude Code zugreifen kann, kann man auch das Erstellen von Notarisierungsprofilen für neue Apps einem Agenten überlassen
  • Die Passworteingabe lässt sich mit --password automatisieren, aber das Passwort kann in der Shell-Historie landen; daher sollte es einmal manuell eingegeben und anschließend im Schlüsselbund oder in 1Password gespeichert werden

Lokale Signierkonfiguration und Geheimnisse trennen

  • Die für die tatsächliche Signierung nötige Team-ID und das Bundle-Präfix werden in Local.xcconfig gespeichert
cp Local.xcconfig.example Local.xcconfig

BUNDLE_PREFIX     = your.real.prefix
DEVELOPMENT_TEAM  = YOUR-TEAM-ID
  • Local.xcconfig wird zu .gitignore hinzugefügt, damit projektspezifische lokale Einstellungen nicht ins Repository gelangen
  • Der private Signaturschlüssel verbleibt im Login-Schlüsselbund, das app-spezifische Passwort für die Notarisierung im notarytool-Schlüsselbundprofil; dadurch werden keine Geheimnisse in Git aufgezeichnet

Mac-Auslieferung mit release.sh automatisieren

  • Das scripts/release.sh im Repository führt die gesamte Auslieferungspipeline der Mac-App mit einem einzigen Befehl aus
./scripts/release.sh

  • Das Skript arbeitet in folgender Reihenfolge

    1. Vorab prüfen, ob xcodegen und das Notarisierungsprofil vorhanden sind
    2. Projekt mit xcodegen generate neu erzeugen
    3. Release-Archiv mit xcodebuild archive erstellen
    4. Mit ExportOptions.plist und xcodebuild -exportArchive eine Developer-ID-signierte App exportieren
    5. App als ZIP packen und mit notarytool submit --wait bei Apple einreichen
    6. Notarisierungsticket mit stapler staple anhängen
    7. Mit spctl prüfen, ob Gatekeeper die App zulässt
    8. Vorhandenen Prozess beenden und App nach /Applications kopieren
    9. Installierte App mit lsregister registrieren
    10. Ticket und Gatekeeper-Status des installierten Bundles erneut prüfen

  • Auch wenn das Modell den allgemeinen Auslieferungsablauf kennt, muss der Nutzer projektspezifische Informationen wie Scheme-Name, Team-ID, Name des Notarisierungsprofils und Installationsort bereitstellen

  • Scheitert das erste Skript, ist ein iterativer Anpassungsprozess anhand der Ausführungsergebnisse nötig; sobald der Workflow stabil ist, kann man ohne weitere Änderungen nur noch den Auslieferungsbefehl ausführen

  • Fehler und unvollständige Auslieferungen vermeiden

    • set -euo pipefail bricht das Skript sofort ab, wenn auch nur ein Befehl fehlschlägt, damit kein unvollständiger Zustand als Erfolg behandelt wird
    • cd "$(dirname "$0")/.." wechselt in das Repository-Root, egal aus welchem Verzeichnis das Skript aufgerufen wird
    • Der Vorabprüfungsblock prüft xcodegen und das Notarisierungsprofil vor der zeitaufwendigen Archivierung
    • Nicht nur die exportierte App, sondern auch die nach /Applications kopierte App wird erneut geprüft, um Beschädigungen des Bundles beim Kopieren zu erkennen
    • Wenn ein anderes Notarisierungsprofil nötig ist, kann es per Umgebungsvariable überschrieben werden
    TZED_NOTARY_PROFILE=<name> ./scripts/release.sh

Auslieferungsregeln an Agenten weitergeben

  • Wenn release.sh die Auslieferung mit einem einzigen Befehl erledigt, sorgt CLAUDE.md oder AGENTS.md dafür, dass der Agent diesen Befehl in jeder Sitzung ohne zusätzliche Anweisung verwendet
  • In der Dokumentation werden Projekterneuerung, Unit-Tests, schneller macOS-Build und der echte Auslieferungsbefehl festgehalten
xcodegen generate
swift test

xcodebuild -project YOUR-APP-NAME.xcodeproj \
  -scheme YOUR-APP-NAME-macOS \
  -destination 'platform=macOS' \
  CODE_SIGNING_ALLOWED=NO build

./scripts/release.sh
  • Auch der Unterschied zwischen den beiden Build-Pfaden sollte dokumentiert werden
    • Ein Build mit CODE_SIGNING_ALLOWED=NO eignet sich für CI und schnelle lokale Prüfungen
    • Für die tatsächliche Auslieferung einer Menüleisten-App, das Bestehen der Quarantäne-Attribute und iCloud-Synchronisierung ist release.sh mit Developer-ID-Signierung und Notarisierung nötig
  • Wenn man Claude Code anweist, die Methode einer App in einem anderen Repository als Referenz zu nutzen, kann es dieselbe Einrichtung auch für spätere Apps replizieren

Schnelle Builds ohne Signierung und Tests

  • Unit-Tests auf Basis des Swift Package Manager werden ohne Xcode-Build ausgeführt
swift test
  • Eine schnelle Kompilierungsprüfung der macOS-App erfolgt mit deaktivierter Signierung
xcodebuild -project TZed.xcodeproj \
  -scheme TZed-macOS \
  -destination 'platform=macOS' \
  CODE_SIGNING_ALLOWED=NO build
  • Simulator-Builds der iOS-App und von Widget-Erweiterungen können auf dieselbe Weise ausgeführt werden
xcodebuild -project TZed.xcodeproj \
  -scheme TZed-iOS \
  -destination 'generic/platform=iOS Simulator' \
  CODE_SIGNING_ALLOWED=NO build
  • Ein mit CODE_SIGNING_ALLOWED=NO erstellter temporär signierter Build kann zum Kompilieren und für die Ausführung im Simulator verwendet werden
  • Dieser Build wird von Gatekeeper abgelehnt und besitzt kein Team-Präfix, sodass Berechtigungen wie iCloud KVS und App Group nicht gebunden werden; für die Auslieferung ist er daher nicht geeignet

Headless-Auslieferung auf ein echtes iPhone

  • Für die Auslieferung auf iOS-Geräte gibt es keine Notarisierungsphase wie bei Mac-Apps; verwendet werden xcodebuild und devicectl
  • Eine App für ein echtes Gerät wird mit Apple-Development-Zertifikat und Development-Provisioning-Profil gebaut und signiert
xcodebuild -project TZed.xcodeproj \
  -scheme TZed-iOS \
  -destination 'generic/platform=iOS' \
  -allowProvisioningUpdates \
  -derivedDataPath build/ios \
  archive -archivePath build/TZed-iOS.xcarchive
  • Die erzeugte .app wird durch Angabe der UDID des verbundenen Geräts installiert
xcrun devicectl device install app \
  --device <DEVICE-UDID> build/ios/…/TZed.app
  • devicectl list devices zeigt verbundene und gekoppelte Geräte sowie ihre UDIDs an
  • Mit -allowProvisioningUpdates werden die nötigen Development-Provisioning-Profile abgerufen

Wie Code-Signierung ohne GUI funktioniert

  • Beim Erstellen eines Developer-ID-Application-Zertifikats stellt Apple das Zertifikat aus, und der Mac erzeugt den zugehörigen privaten Schlüssel; beide werden im Login-Schlüsselbund gespeichert

  • Das von xcodebuild aufgerufene codesign signiert die Binärdatei mit dem privaten Schlüssel und bettet das Zertifikat, das bis zum Apple-Root-Zertifikat führt, in die App ein, damit der Signierer verifiziert werden kann

  • Mit signingStyle: automatic wählt xcodebuild ein zur Team-ID passendes Zertifikat aus und ruft die nötigen Provisioning-Profile von Apple ab

  • Deshalb müssen Provisioning-Profile nicht ins Repository committet werden

  • Berechtigungen, Notarisierung und Stapling

    • Die .entitlements-Datei jedes Targets enthält Berechtigungen wie Sandbox, Netzwerk-Client, iCloud KVS und App Group
    • Berechtigungen werden beim Signieren mit der echten Team-ID gebunden; in temporär signierten Builds funktionieren iCloud und App Group daher nicht korrekt
    • Signierung und Notarisierung sind unterschiedliche Schritte
    • Die Signierung belegt, wer die App erstellt hat
    • Bei der Notarisierung prüft Apple die signierte App auf Schadcode und stellt anschließend ein Ticket aus
    • Stapling hängt dieses Ticket an die App an, damit Gatekeeper ihr auch offline vertraut
    • Bei LSUIElement-Apps, also Menüleisten-Apps mit versteckter UI, ist Notarisierung nötig, um Erkennungen durch XProtect zu vermeiden

  • Manuelle Prüfkommandos

    codesign -dv --verbose=4 /Applications/TZed.app
spctl -a -vvv -t exec /Applications/TZed.app
stapler validate /Applications/TZed.app
    • codesign prüft Signierer und Zertifikate
    • spctl prüft, ob Gatekeeper die Ausführung zulassen würde
    • stapler validate prüft, ob ein Notarisierungsticket angehängt ist

Standardtools, die der Agent ausführt

  • Ein separater MCP-Server für Builds oder ein spezielles Plugin ist nicht nötig; Claude Code führt Standard-CLIs in einer nichtinteraktiven Shell aus
  • Verwendete Tools sind xcodebuild, xcrun notarytool, xcrun stapler, spctl, codesign, devicectl, xcodegen und swift
  • CLAUDE.md übermittelt dem Agenten die Benennungsregeln für Notarisierungsprofile, den Unterschied zwischen schnellem Build und echter Auslieferung sowie die Regel, für Releases release.sh zu verwenden
  • Nur das erstmalige notarytool store-credentials bleibt ein interaktiver Schritt; alles danach kann automatisiert werden

Xcode-GUI-Arbeiten durch CLI ersetzen

  • Die von Xcode verwaltete Erstellung von .xcodeproj wird durch project.yml und xcodegen generate ersetzt
  • ⌘B oder der Run-Button entspricht xcodebuild … build
  • Product → Archive wird mit xcodebuild … archive erledigt
  • Die App-Auslieferung aus dem Organizer lässt sich durch xcodebuild -exportArchive ersetzen
  • Der Upload aus dem Organizer erfolgt mit xcrun notarytool submit --wait
  • Für das automatische Anhängen des Tickets wird xcrun stapler staple verwendet
  • Die Installation per Drag-and-drop nach /Applications wird mit cp -R und lsregister erledigt
  • Die Run-Aktion auf einem echten iPhone wird durch xcodebuild archive und devicectl device install ersetzt
  • Sobald Xcode und XcodeGen installiert, die anfänglichen Zugangsdaten eingerichtet sowie release.sh und CLAUDE.md geschrieben sind, lässt sich die Auslieferung neuer Builds danach mit einem Satz oder einem Befehl ausführen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 4 시간 전
Meinungen auf Hacker News

  • Es gibt vieles, was sich in einer Sandbox nicht lösen lässt, deshalb lasse ich AI Agents direkt auf dem Mac laufen. Aber der Vorfall, bei dem xAI ein Home-Verzeichnis samt SSH-Keys hochgeladen hat, lässt mich diese Entscheidung ernsthaft überdenken
    Dass die Maschine selbst kaputtgeht, bereitet mir keine großen Sorgen. Das meiste ist gesichert oder in Git committet und lässt sich innerhalb weniger Stunden wiederherstellen. Aber ich will auf keinen Fall, dass mein .ssh-Verzeichnis an einen AI Agent übertragen wird; das sollte man nicht per Prompt zu verhindern versuchen, sondern auf Systemebene blockieren. Ich erwäge, einen separaten Benutzer anzulegen und das Home-Verzeichnis mit 700-Rechten zu versehen. Sicherheit fühlt sich damit an wie ein Rückschritt in die 1990er, aber im Gegenzug kann man Dinge beispiellos schnell erledigen. Auch ich nutze diesen riskanten Ansatz, ich will also niemanden verurteilen

    • Man muss es nicht unbedingt auf dem Host-Mac ausführen. Neuere Macs unterstützen Virtualisierung mit kaum Performance-Verlust, sodass sich macOS- oder Linux-VMs derselben Architektur problemlos für die Entwicklung nutzen lassen
      Als paketierte Lösungen kann man die Open-Source-Projekte Tart https://tart.run/ oder VirtualBuddy https://github.com/insidegui/VirtualBuddy verwenden, oder sich selbst per Vibe Coding ein Tool bauen, das die OS-API https://developer.apple.com/documentation/virtualization kapselt. Kürzlich ist auch Apple Container https://github.com/apple/container erschienen
    • Ich baue gerade ein Wrapper-Tool, das Claude als separaten Benutzer namens agent ausführt. Vor einem Jahr bin ich wegen OAuth und Keychain gescheitert, aber kürzlich hat es dank Claudes Hinweis, dass man CLAUDE_CODE_OAUTH_TOKEN verwenden kann, geklappt
      Es braucht ein Hilfstool zum Setzen der Rechte per ACL, funktioniert derzeit aber unter macOS. Das Risiko liegt ungefähr zwischen der Standard-Sandbox von Claude und vollständiger Container- bzw. Maschinenisolation. Als Claudes eigene Sandbox besser wurde, habe ich am Nutzen dieses Defense-in-Depth-Projekts gezweifelt, aber angesichts möglicher Leaks des Home-Verzeichnisses gibt es genug Gründe, weiterzumachen. Open Source ist es noch nicht, aber ich bin bereit, mit Interessierten darüber zu sprechen
    • Ich lasse die AI in einem headless Docker-Container laufen und gebe ihr nur Zugriff auf Git, sodass sie ausschließlich Code beitragen kann. Wenn Secrets nötig sind, stelle ich einen Docker-Container aus einem Repository bereit; wenn Infrastruktur gebraucht wird, soll sie ein Jira-Ticket erstellen. So sieht der Workflow aus
    • Mich würde interessieren, wie man das Registrieren eines Bundle Identifier erledigt, ohne Xcode zu öffnen

  • Zum Spaß baue und teste ich iOS-Apps ausschließlich mit Linux, und es ist überraschend einfach; https://github.com/xtool-org/xtool funktioniert sehr gut
    Auch ohne Upload zu TestFlight oder in den App Store kann man eine App unter Linux per USB direkt auf ein iPhone installieren. Wenn man unsicher ist, kann man einen Coding Agent bitten, eine Hello-World-iOS-App zu erstellen und hochzuladen; damit kommt man leicht in Gang

    • Ich arbeite genauso, abgesehen davon, dass ich Linux unter WSL auf Windows ausführe. Ich übertrage die IPA mit Sideloadly aufs Telefon, und das funktioniert gut
    • Muss das iPhone weiter angeschlossen bleiben, nachdem die App per USB übertragen wurde?
    • Kennen Coding Agents xtool bereits?

  • Mein Open-Source-Projekt Axiom hilft Coding-Execution-Tools dabei, Entwicklungsaufgaben für Apple-Betriebssysteme effektiv zu erledigen
    Es umfasst verschiedene Techniken und Agents sowie die LLM-Tools xclog, xcprof, xcsym und xcui. Sie stellen die benötigten Funktionen token-effizient bereit und sind auch für Techniken oder Agents außerhalb von Axiom nützlich. Axiom: https://charleswiltgen.github.io/Axiom/, CLI-Tools: https://charleswiltgen.github.io/Axiom/tools/

    • Funktioniert das auch zuverlässig mit einer Kotlin-Multiplatform-Codebase? Es gibt zwar nativen Swift-Code, aber mich interessiert, wie Performance und Verhalten aussehen, wenn ein Teil der Logik geteilt wird
    • Ich sehe die nächste Frontier für iOS-App-Tools in selbst hostbaren Linux-Build-Servern; mich würde deine Meinung dazu interessieren
    • Funktioniert es auch mit Flutter?

  • Der Satz „Ich ließ Claude Code ein Skript erstellen, das ohne Xcode zu öffnen archiviert, mit Developer ID signiert, notarisiert, stapelt, nach /Applications installiert und bei jedem fehlgeschlagenen Schritt klar abbricht“ fühlt sich seltsam an. Denn der Text, den wir gerade lesen, wirkt selbst so, als würde Claude zu uns sprechen
    Auch dass in fast jedem Schritt des Artikels Anweisungen wiederkehren wie „Zeig diesen Artikel Claude Code oder einem beliebigen LLM-Coding-Tool und lass es das erledigen“, „Wenn du es nicht weißt, frag ein LLM und lass dir beim Einrichten helfen“, „Der Zweck von LLMs ist, unerwünschte Handarbeit zu vermeiden“ oder „Lass dir einen Workflow erstellen“, also immer wieder der Hinweis, erneut ein LLM zu fragen, wirkt merkwürdig

    • Dieser Artikel wurde nicht von Claude geschrieben, sondern von mir selbst
    • Es wirkt wie eine Schleife: Man zeigt Claude eine von Claude erstellte Website und lässt Claude die Build-Umgebung einrichten
    • Wegen der Fehler im Artikel dachte ich, er sei nicht von AI geschrieben, aber inzwischen könnte es sein, dass AI absichtlich Fehler macht

  • Aus der Perspektive von jemandem, der seit über einem Jahr Mac- und iOS-Apps mit Agenten entwickelt, halte ich diesen Artikel für schlechten Rat. Insbesondere muss das hervorragende Xcode MCP bei laufendem Xcode genutzt werden
    Mit den MCP-Tools kann man auf viele Funktionen deutlich schneller und knapper zugreifen als mit xcodebuild, und auch das Erzeugen und Rendern von #Preview, das bei geschlossenem Xcode nicht möglich ist, funktioniert damit. Das MCP und der integrierte Agent von Xcode 27 steuern über DeviceHub auch Simulatoren sehr gut. DeviceHub ersetzt Simulator.app und scheint für Agenten verständlich und bedienbar zu sein, ohne dass man die Accessibility-API mit Tools wie axe zweckentfremden muss
    Xcode MCP ist nicht perfekt. Das Problem, dass bei jedem Start des Agenten ein Berechtigungsdialog erscheint, habe ich umgangen, indem Keyboard Maestro ihn automatisch bestätigt. Trotzdem hat Xcode 27 die Benutzbarkeit von Xcode-Vibe-Coding deutlich verbessert. Inzwischen starte ich Codex direkt in der Agent-UI von Xcode, ohne MCP separat zu handhaben; diese Laufzeitumgebung leitet das Modell besser dazu an, die verfügbaren Tools zu nutzen. Am Ende bekommt man das Wichtigste: schnelleres Feedback und robustere Validierung

    • Es gibt Xcode-mcp-proxy, das Xcode MCP proxyt, Dialoge anklickt und auch Verbindungen wiederherstellt. Mich würde interessieren, ob für macOS-App-Tests Peekaboo verwendet wird oder allgemeine Screenshot-Automatisierung
    • Auch Xcode MCP von Sentry ist einen Versuch wert. Es ist deutlich umfassender und erfordert nicht einmal, dass Xcode läuft

  • Wenn man iOS- und Android-IDEs möglichst wenig anfassen möchte, sind React Native und Expo ebenfalls eine gute Wahl
    Xcode und Android Studio nutzt man nur zum Installieren der Gerätesimulatoren; den Rest bis hin zur Store-Auslieferung übernimmt die Expo-Toolchain. Selbst unter Windows, wo sich Xcode nicht installieren lässt, kann man mit den verwalteten Apps von Expo iOS-Apps direkt auf dem iPhone ausführen. Als gut gepflegter Einstiegspunkt auf Basis von RN und Expo ist Ignite hervorragend: https://github.com/infinitered/ignite

  • Streng genommen verwendet man weiterhin Xcode. Xcode ist eine extrem fehlerbehaftete GUI um mehrere weitgehend stabile UNIX-Utilities und Apps auf Systemebene herum
    Apps per CLI zu veröffentlichen ist eine alte Praxis und war mindestens seit 2012 möglich, als ich meine erste Xcode-App veröffentlicht habe

    • Das ist mir bewusst. Der entscheidende Punkt ist aber, dass nicht ich Xcode nutze, sondern Claude
    • Nachdem ich Xcode einmal geöffnet hatte, hat mich die Einstiegshürde davon abgehalten, überhaupt darüber nachzudenken, ein Programm für macOS zu bauen

  • Zumindest für Teile des Debuggings kommt niemand darum herum, Xcode zu verwenden
    Builds können Agenten bereits größtenteils über die Kommandozeile erledigen, und mit situationsbezogenen expliziten Anweisungen können sie schneller bauen. Wenn man die Dateisystem-Synchronisierungsgruppen von Xcode verwendet, ist XcodeGen möglicherweise unnötige Zusatzarbeit
    Für iOS würde ich vor allem empfehlen, dem Agenten App-Store-Connect-Funktionen hinzuzufügen: https://github.com/rorkai/App-Store-Connect-CLI. Dann muss Xcode nicht ständig geöffnet bleiben, und man muss nicht einmal in der Nähe des MacBooks sein. Man kann auf dem iPhone Änderungen mit Codex vornehmen, asc mit Build und TestFlight-Upload beauftragen, die neue Version herunterladen und ausführen und so iterieren

    • Ich habe mit einem Agenten fast eine komplette iOS-App fertiggestellt, und auch App-Store-Release und Social-Media-Promotion hat der Agent erledigt. Xcode habe ich nur genutzt, um Builds vorab auf dem Gerät zu prüfen und die Richtung für den nächsten Prompt festzulegen

  • Mich beschäftigt weiterhin, dass Entwickler mit knappem Budget, die sich keinen Mac leisten können, faktisch von der iOS-Entwicklung ausgeschlossen sind. Jedes Mal, wenn Apple-Produkte teurer werden, gibt es mehr Menschen, die nicht an der Entwicklung teilnehmen können

    • Es ist bedauerlich, wenn Menschen keinen Zugang zu Technologie haben, aber heutzutage bietet Apple auch günstige Geräte im Vergleich zu Konkurrenzprodukten mit ähnlichen oder sogar niedrigeren Spezifikationen an. Ein Apple Silicon MacBook Air mit angemessenem Arbeitsspeicher ist ein Beispiel dafür

  • Wenn man eine App per Vibe-Coding entwickelt, wäre Expo langfristig die bessere Wahl gewesen. Da es auf React basiert, gibt es in den LLM-Trainingsdaten viel mehr React-Code als Swift-Code, und auch die Qualität des erzeugten Codes ist höher
    Man kann alles über die Kommandozeile erledigen, und da es eine Webview ist, ist auch das Debugging einfach. Nach der Kompilierung als native iOS-App fühlt sie sich ähnlich an wie andere native Apps. Mit der Kombination aus Expo und Fastlane lässt sich iOS-Einreichung und -Bereitstellung vollständig automatisieren, sodass man mit einem einzigen Befehl eine neue Version in den App Store hochladen kann

    • Gibt es beim Erstellen einer neuen App nicht auch Schritte, die sich nicht automatisieren lassen, etwa das Registrieren der App selbst?
    • Meinst du mit Expo https://expo.dev/? Wenn man die Seite derzeit aufruft, erscheint der Hinweis: „Der Code ist kaputt, und es ist ein Fehler aufgetreten, der geprüft werden muss“