tobias
979ea92ce7
Ansage des Eigentuemers: alles, was Xcode oder das Apple Developer Portal braucht, wird kuenftig in einer eigenen Liste gefuehrt - Xcode-Laeufe werden gebuendelt und erst gestartet, wenn eine nennenswerte Menge zusammengekommen ist. APPLE_DEV_BACKLOG.md haelt den am Artefakt gemessenen Stand der ausgelieferten .ipa fest (2026.9.4.17, beide Profile bis 2027-08-29, alle vier Berechtigungsschluessel da, packageClassList ohne die beiden eigenen Plugins) und trennt: was auf einen Lauf wartet, was auf das Portal wartet, was nach dem Lauf zu pruefen ist, und was das Skript ohnehin selbst erledigt. Offen sind zwei Positionen, beide bereits im Repo korrigiert und nur auf einen Lauf wartend: die nicht registrierten Plugins (Zwischenablage und Kalender sind auf dem Telefon tot) und der Installationslink mit dem zweiten Fragezeichen. Im Portal ist derzeit nichts offen. Verankert als verbindliche Apple-Regel in AGENTS.md neben Wartungs- und Paritaetsregel, in der Leseordnung, und als Querverweis aus Abschnitt DH - dessen Untersuchungsbericht bleibt stehen, gepflegt wird der Zustand im Backlog.
143 lines
6.1 KiB
Markdown
143 lines
6.1 KiB
Markdown
# Apple Dev Backlog (DM360)
|
|
|
|
Alles, was einen **Xcode-Lauf** oder das **Apple Developer Portal** braucht,
|
|
wird hier gesammelt - und nur hier.
|
|
|
|
**Warum:** ein Xcode-Lauf lohnt sich nicht für eine einzelne native Änderung.
|
|
Er wird erst gestartet, wenn eine nennenswerte Menge zusammengekommen ist; die
|
|
Entscheidung darüber trifft der Eigentümer, nicht eine Sitzung.
|
|
|
|
## Arbeitsregel (verbindlich)
|
|
|
|
* Jede Aufgabe, die Xcode oder das Apple-Portal braucht, kommt **in diese
|
|
Datei**, in derselben Sitzung, in der sie auffällt - nicht in eine Notiz im
|
|
Bericht und nicht nur in `AGENTS.md`.
|
|
* **Nichts davon wird von sich aus gestartet.** Ein Xcode-Lauf ist eine
|
|
Handlung des Eigentümers am Mac; eine Sitzung bereitet ihn vor und meldet,
|
|
wenn sich genug angesammelt hat.
|
|
* Was **ohne** Xcode geht, gehört nicht hierher: Änderungen an der Oberfläche
|
|
der App reisen im OTA-Bündel (`@capgo/capacitor-updater`), Änderungen am Panel
|
|
und am Backend über die Selbstaktualisierung der Integration. Nur nativer
|
|
Code, Plugins, Berechtigungen, Signatur und Auslieferungsweg brauchen einen
|
|
Lauf.
|
|
* Erledigtes wird **nicht gelöscht**, sondern nach unten unter „Erledigt"
|
|
verschoben - mit der Fassung, in der es ausgeliefert wurde. Sonst wird
|
|
dieselbe Frage in einem halben Jahr wieder aufgemacht.
|
|
|
|
---
|
|
|
|
## Stand der ausgelieferten App
|
|
|
|
Gemessen am Artefakt `companion-app/auslieferung/App.ipa`, nicht aus dem
|
|
Gedächtnis (06.09.2026):
|
|
|
|
| | |
|
|
|---|---|
|
|
| Fassung | **2026.9.4.17** (Build 1), App und Erweiterung gleich |
|
|
| Bundle-ID | `app.datametric360`, Erweiterung `app.datametric360.teilen` |
|
|
| Profile | beide Ad Hoc, **2 Geräte**, gültig bis **2027-08-29** |
|
|
| Berechtigungen | Standort, Kalender (beide Schlüssel), Kamera - alle vorhanden |
|
|
| `packageClassList` | **6 Klassen - beide eigenen Plugins fehlen** |
|
|
|
|
Zum Vergleich: das Repository steht auf `2026.9.6.5`. Der Abstand ist **kein**
|
|
Rückstand - alles dazwischen war Oberfläche und Backend und reist über OTA. Was
|
|
wirklich auf einen Lauf wartet, steht unten.
|
|
|
|
---
|
|
|
|
## A. Wartet auf einen Xcode-Lauf
|
|
|
|
### A1. Zwei eigene Plugins sind auf dem Telefon tot
|
|
|
|
**Auswirkung: Zwischenablage und Kalendereintrag funktionieren nicht.** Das ist
|
|
die einzige Position mit sichtbarem Ausfall.
|
|
|
|
Capacitor 8 registriert ausschließlich, was in `packageClassList` der
|
|
`capacitor.config.json` im Bündel steht (`CapacitorBridge.swift`,
|
|
`registerPlugins()`). Diese Liste erzeugt `cap sync` aus den installierten
|
|
npm-Paketen - app-eigene Plugins sind keine. Beide Klassen liegen nachweislich
|
|
im Programm der ausgelieferten `.ipa` und werden trotzdem nie registriert.
|
|
|
|
*Korrektur liegt im Repo* (`a99ae43`): `ios-teilen-einrichten.mjs` trägt die
|
|
Klassen nach jedem `cap sync` nach und liest ihre Namen aus den Swift-Dateien
|
|
selbst, damit sie nicht an zwei Stellen gepflegt werden. `ios-signieren.sh`
|
|
**bricht ab**, wenn eine davon im fertigen Bündel fehlt.
|
|
|
|
Hintergrund vollständig: `AGENTS.md`, Abschnitt DH und CM.
|
|
|
|
### A2. Installationslink ohne zweites Fragezeichen
|
|
|
|
`ios-luftweg.sh` hängte den Cache-Brecher `?v=` auch an die Manifest-Adresse
|
|
**innerhalb** des `itms-services`-Links - damit steht dort ein zweites `?`, der
|
|
Abruf scheitert, und weil iOS die Rückfrage erst aus dem geladenen Manifest
|
|
baut, passiert sichtbar gar nichts.
|
|
|
|
*Korrektur liegt im Repo* (`6365136`). Die bereits ausgelieferte
|
|
`auslieferung/index.html` wurde von Hand nachgezogen; das Skript zieht beim
|
|
nächsten Lauf nach. Hintergrund: `AGENTS.md`, Abschnitt CK.
|
|
|
|
---
|
|
|
|
## B. Wartet auf das Apple Developer Portal
|
|
|
|
Derzeit **nichts offen.** App-Gruppe, beide App-IDs und die Gerätefreigabe sind
|
|
eingerichtet (Abschnitt AK), die Profile laufen bis 2027-08-29.
|
|
|
|
Vorzumerken, aber noch lange hin:
|
|
|
|
* **2027-07-17** - das Entwicklerzertifikat läuft ab.
|
|
* **2027-08-29** - beide Bereitstellungsprofile laufen ab.
|
|
* Ein **neues Gerät** braucht eine Registrierung im Portal *und* frisch
|
|
ausgestellte Profile. Ein bereits ausgestelltes Profil erfährt von einem neuen
|
|
Gerät nichts - deshalb räumt `ios-signieren.sh` die zwischengespeicherten
|
|
Profile vor dem Bauen weg (Abschnitt AI).
|
|
|
|
---
|
|
|
|
## C. Nach dem Lauf zu prüfen
|
|
|
|
Am **fertigen Bündel**, nicht am Projekt. Die Begründung steht in Abschnitt AK:
|
|
von fünf Fehlern der nativen Hülle haben vier einen erfolgreichen Archivlauf
|
|
erzeugt und sind erst am entpackten `.ipa` aufgefallen.
|
|
|
|
Das Skript prüft selbst und bricht ab, wenn etwas fehlt:
|
|
|
|
1. Die Erweiterung hat ein echtes Programm.
|
|
2. App und Erweiterung tragen dieselbe `CFBundleShortVersionString` **und** eine
|
|
brauchbare `CFBundleVersion` (ohne die lehnt iOS die Installation der ganzen
|
|
App ab - Abschnitt CD).
|
|
3. Die App-Gruppe steht in den Entitlements **beider** Ziele.
|
|
4. Beide eigenen Plugin-Klassen stehen in `packageClassList`.
|
|
|
|
**Von Hand bleibt genau eine Prüfung** - auf dem Gerät: einen Beleg über das
|
|
Teilen-Blatt schicken, ein PDF aus der Zwischenablage einfügen, einen
|
|
Kalendereintrag anlegen. Ob die Plugins *registriert* sind, sagt Punkt 4; ob sie
|
|
*tun*, was sie sollen, sagt nur das Telefon.
|
|
|
|
---
|
|
|
|
## Was der Lauf von selbst erledigt
|
|
|
|
Damit es niemand ein zweites Mal von Hand macht: `ios-signieren.sh` trägt bei
|
|
jedem Lauf Standort-, Kalender- und Kamera-Berechtigung ein, richtet die
|
|
Share-Erweiterung ein, spielt das App-Symbol ein und setzt die Versionsnummern
|
|
in beide Ziele. Das muss sein, weil `companion-app/ios/` gitignored ist und von
|
|
`npx cap add ios` jederzeit neu erzeugt wird - alles, was man in Xcode
|
|
anklickt, wäre danach weg (Abschnitt AI).
|
|
|
|
Unvermeidlich von Hand bleiben: die einmalige Portal-Einrichtung, das
|
|
Schlüsselbund-„Immer erlauben" beim ersten Signieren, und `git push` der
|
|
fertigen `.ipa`, weil das Telefon sie aus dem Repository lädt.
|
|
|
|
---
|
|
|
|
## Erledigt
|
|
|
|
| Fassung | Was |
|
|
|---|---|
|
|
| 2026.9.4.17 | Kamera-Berechtigung für den QR-Scanner |
|
|
| 2026.9.4.7 | `CFBundleVersion` in beiden Bündeln - die App war vorher nicht installierbar |
|
|
| 2026.9.4.5 | Versionsnummern von App und Erweiterung angeglichen |
|
|
| 2026.9.2.7 | Share-Erweiterung, Zwischenablage- und Kalender-Plugin gebaut und signiert |
|
|
| 2026.8.30.8 | Erste signierte `.ipa`, Luftweg über Gitea eingerichtet |
|