KAN-66 bereitet iOS und iPadOS für TestFlight im Apple-Team ZZX2KZGTHU mit der expliziten App-ID de.kanbangit.ios vor. Tauri, XcodeGen und das erzeugte Xcode-Projekt verwenden diese Werte konsistent; die macOS-App behält ihre bisherige Identität.
Der neue lokale Buildweg kompiliert mit der installierten Rust-Toolchain, prüft ein extern gespeichertes Provisioning Profile und das dazugehörige Zertifikat mit privatem Schlüssel und erzeugt Archiv und IPA mit manueller Signierung. Er erstellt keine Apple-Ressourcen und lädt nichts hoch. Exportierte Apps werden erneut auf Signatur, Team, App-ID, Profil, Version und Entitlements geprüft. Simulatorbuilds bleiben unsigniert; Geräteentwicklung verlangt ein eigenes Development-Profil. Die iOS-Icons enthalten keinen Alphakanal mehr. Der bestehende Navigationstest verwendet eine simulierte HTTP-Antwort, damit WebKit einen regulären Verlauf erzeugt, und prüft die tatsächliche Rücknavigation.
Prüfung: 33 neue Build-/Asset-Tests; insgesamt 212 JavaScript-Tests bestanden, ein externer Hetzner-Test planmäßig übersprungen. Je acht Swift-Tests im iPhone- und iPad-Simulator sowie 18 Rust-Tests bestanden (ein Rust-Test planmäßig ignoriert). Nativer JavaScript-Lint, Rust-Formatprüfung, Clippy mit allen Targets/Features und Diff-Prüfung erfolgreich. Ein unsigniertes Simulatorarchiv sowie ein mit Apple Distribution signiertes Releasearchiv und eine lokal geprüfte TestFlight-IPA für Version 0.2.1, Build 1 wurden erzeugt. Zertifikate, Profile, private Schlüssel und Buildartefakte sind nicht Teil des Commits.
Für einen weiteren lokalen Releasebuild: im Verzeichnis native die Variable IOS_PROVISIONING_PROFILE auf das heruntergeladene App-Store-Connect-Profil außerhalb des Repositorys setzen und node build-ios.mjs --mode testflight ausführen. Vor einem weiteren TestFlight-Upload bundle.iOS.bundleVersion in src-tauri/tauri.ios.conf.json erhöhen. Die Ausgabe liegt unter src-tauri/target/ios-testflight/<Version>-<Buildnummer>/.
Geräteabnahme bestätigt: Der Nutzer hat Version 0.2.1, Build 1 selbst zu Apple hochgeladen, über internes TestFlight installiert und App-Start, Login, Sitzung nach App-Neustart, Dateiauswahl und externe Links erfolgreich geprüft. Die noch laufende externe TestFlight-Prüfung ist für diese interne Geräteabnahme nicht erforderlich. Kein Upload und keine Änderungen im Apple-Portal durch den Agenten. Die Umsetzung ist bereit für Review; eine CI-Action für TestFlight-Uploads ist nicht Bestandteil dieses PRs.
Ursprüngliche Branchbasis und PR-Ziel: main, nach erfolgreichem git pull --ff-only origin main bei fa8a0cc5126896b336bddaa1775c2b5c35991505.
KAN-66 bereitet iOS und iPadOS für TestFlight im Apple-Team `ZZX2KZGTHU` mit der expliziten App-ID `de.kanbangit.ios` vor. Tauri, XcodeGen und das erzeugte Xcode-Projekt verwenden diese Werte konsistent; die macOS-App behält ihre bisherige Identität.
Der neue lokale Buildweg kompiliert mit der installierten Rust-Toolchain, prüft ein extern gespeichertes Provisioning Profile und das dazugehörige Zertifikat mit privatem Schlüssel und erzeugt Archiv und IPA mit manueller Signierung. Er erstellt keine Apple-Ressourcen und lädt nichts hoch. Exportierte Apps werden erneut auf Signatur, Team, App-ID, Profil, Version und Entitlements geprüft. Simulatorbuilds bleiben unsigniert; Geräteentwicklung verlangt ein eigenes Development-Profil. Die iOS-Icons enthalten keinen Alphakanal mehr. Der bestehende Navigationstest verwendet eine simulierte HTTP-Antwort, damit WebKit einen regulären Verlauf erzeugt, und prüft die tatsächliche Rücknavigation.
Prüfung: 33 neue Build-/Asset-Tests; insgesamt 212 JavaScript-Tests bestanden, ein externer Hetzner-Test planmäßig übersprungen. Je acht Swift-Tests im iPhone- und iPad-Simulator sowie 18 Rust-Tests bestanden (ein Rust-Test planmäßig ignoriert). Nativer JavaScript-Lint, Rust-Formatprüfung, Clippy mit allen Targets/Features und Diff-Prüfung erfolgreich. Ein unsigniertes Simulatorarchiv sowie ein mit Apple Distribution signiertes Releasearchiv und eine lokal geprüfte TestFlight-IPA für Version 0.2.1, Build 1 wurden erzeugt. Zertifikate, Profile, private Schlüssel und Buildartefakte sind nicht Teil des Commits.
Für einen weiteren lokalen Releasebuild: im Verzeichnis `native` die Variable `IOS_PROVISIONING_PROFILE` auf das heruntergeladene App-Store-Connect-Profil außerhalb des Repositorys setzen und `node build-ios.mjs --mode testflight` ausführen. Vor einem weiteren TestFlight-Upload `bundle.iOS.bundleVersion` in `src-tauri/tauri.ios.conf.json` erhöhen. Die Ausgabe liegt unter `src-tauri/target/ios-testflight/<Version>-<Buildnummer>/`.
**Geräteabnahme bestätigt:** Der Nutzer hat Version 0.2.1, Build 1 selbst zu Apple hochgeladen, über internes TestFlight installiert und App-Start, Login, Sitzung nach App-Neustart, Dateiauswahl und externe Links erfolgreich geprüft. Die noch laufende externe TestFlight-Prüfung ist für diese interne Geräteabnahme nicht erforderlich. Kein Upload und keine Änderungen im Apple-Portal durch den Agenten. Die Umsetzung ist bereit für Review; eine CI-Action für TestFlight-Uploads ist nicht Bestandteil dieses PRs.
Ursprüngliche Branchbasis und PR-Ziel: `main`, nach erfolgreichem `git pull --ff-only origin main` bei `fa8a0cc5126896b336bddaa1775c2b5c35991505`.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
KAN-66 bereitet iOS und iPadOS für TestFlight im Apple-Team
ZZX2KZGTHUmit der expliziten App-IDde.kanbangit.iosvor. Tauri, XcodeGen und das erzeugte Xcode-Projekt verwenden diese Werte konsistent; die macOS-App behält ihre bisherige Identität.Der neue lokale Buildweg kompiliert mit der installierten Rust-Toolchain, prüft ein extern gespeichertes Provisioning Profile und das dazugehörige Zertifikat mit privatem Schlüssel und erzeugt Archiv und IPA mit manueller Signierung. Er erstellt keine Apple-Ressourcen und lädt nichts hoch. Exportierte Apps werden erneut auf Signatur, Team, App-ID, Profil, Version und Entitlements geprüft. Simulatorbuilds bleiben unsigniert; Geräteentwicklung verlangt ein eigenes Development-Profil. Die iOS-Icons enthalten keinen Alphakanal mehr. Der bestehende Navigationstest verwendet eine simulierte HTTP-Antwort, damit WebKit einen regulären Verlauf erzeugt, und prüft die tatsächliche Rücknavigation.
Prüfung: 33 neue Build-/Asset-Tests; insgesamt 212 JavaScript-Tests bestanden, ein externer Hetzner-Test planmäßig übersprungen. Je acht Swift-Tests im iPhone- und iPad-Simulator sowie 18 Rust-Tests bestanden (ein Rust-Test planmäßig ignoriert). Nativer JavaScript-Lint, Rust-Formatprüfung, Clippy mit allen Targets/Features und Diff-Prüfung erfolgreich. Ein unsigniertes Simulatorarchiv sowie ein mit Apple Distribution signiertes Releasearchiv und eine lokal geprüfte TestFlight-IPA für Version 0.2.1, Build 1 wurden erzeugt. Zertifikate, Profile, private Schlüssel und Buildartefakte sind nicht Teil des Commits.
Für einen weiteren lokalen Releasebuild: im Verzeichnis
nativedie VariableIOS_PROVISIONING_PROFILEauf das heruntergeladene App-Store-Connect-Profil außerhalb des Repositorys setzen undnode build-ios.mjs --mode testflightausführen. Vor einem weiteren TestFlight-Uploadbundle.iOS.bundleVersioninsrc-tauri/tauri.ios.conf.jsonerhöhen. Die Ausgabe liegt untersrc-tauri/target/ios-testflight/<Version>-<Buildnummer>/.Geräteabnahme bestätigt: Der Nutzer hat Version 0.2.1, Build 1 selbst zu Apple hochgeladen, über internes TestFlight installiert und App-Start, Login, Sitzung nach App-Neustart, Dateiauswahl und externe Links erfolgreich geprüft. Die noch laufende externe TestFlight-Prüfung ist für diese interne Geräteabnahme nicht erforderlich. Kein Upload und keine Änderungen im Apple-Portal durch den Agenten. Die Umsetzung ist bereit für Review; eine CI-Action für TestFlight-Uploads ist nicht Bestandteil dieses PRs.
Ursprüngliche Branchbasis und PR-Ziel:
main, nach erfolgreichemgit pull --ff-only origin mainbeifa8a0cc5126896b336bddaa1775c2b5c35991505.