audi-app/APPLE_DEV_BACKLOG.md

# 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.

---

## Wie ein Lauf abläuft

**Diese Datei ist die Übergabe.** Wer am Mac sitzt - mit oder ohne Claude am
Xcode - braucht keine weitere: hier steht der Stand, der eine Befehl, und was
danach zu prüfen ist. `AGENTS.md` ist nur für das *Warum* nötig.

### Vorher

**Nichts vorzubereiten** - auch kein `git pull`. Das Skript holt `origin/main`
selbst und bringt den Klon darauf, solange das nachweislich verlustfrei ist:
ein reiner Rückstand wird vorgespult, und Commits, die zwar nur lokal liegen,
gegenüber dem gemeinsamen Vorfahren aber **keine einzige Datei ändern**, werden
verworfen. Beides sagt es an; das Reflog hält Verworfenes noch 90 Tage.

> **Warum kein `git pull`:** am 07.09.2026 sind drei Commits am Ende von `main`
> entfernt und der Branch per Force-Push zurückgesetzt worden. Ein Klon von davor
> steht damit **vor** `origin/main` - dort wäre `git pull` genau das Falsche: der
> Merge hängt die entfernten Commits wieder in die Historie, und der nächste Push
> stellte sie auf dem Server wieder her (er ginge sogar ohne `--force` durch).
> Genau diese Lage räumt das Skript von sich aus auf.

Ab **hier** entscheidet es nichts mehr allein: liegen lokale Commits, die **auch
den Inhalt** ändern, bricht es ab und legt dir beide Wege vor (pushen oder
verwerfen) - ungepushte Arbeit wirft es nie weg.
Ein nicht sauberer Arbeitsbaum bricht den Lauf ebenfalls ab - er ist die
Voraussetzung dafür, dass Zurechtrücken oben gefahrlos ist. Und ebenso bricht er
ab, wenn das Zielgerät nicht im Team eingetragen ist („Your team has no
devices"); das ist dann eine Portal-Sache, kein Projektfehler.

### Der Lauf

```bash
bash companion-app/scripts/ios-signieren.sh
```

Ein Befehl, von jedem Verzeichnis im Repository aus. Er wechselt selbst nach
`companion-app/` und erledigt der Reihe nach: Git-Stand prüfen, Webbündel bauen,
native Hülle synchronisieren, Standort-/Kalender-/Kamera-Berechtigung eintragen,
Share-Erweiterung einrichten, App-Symbol einspielen, Versionsnummern setzen,
Archiv bauen und signieren, `.ipa` exportieren, **die fertige `.ipa` gegenlesen**
und die Auslieferung über die Luft vorbereiten.

**Die Fassung kommt aus `custom_components/audi_dashboard/manifest.json`** - es
gibt nichts von Hand hochzuzählen. Beim Schreiben dieser Zeilen wäre das
`2026.9.6.5`.

**Einmalig beim ersten Signieren:** der Schlüsselbund fragt, ob `codesign` den
Schlüssel benutzen darf. **„Immer erlauben"** wählen, nicht „Erlauben" - ein
Archiv signiert über 25 Programmteile und fragte sonst jedes Mal erneut. Bleibt
der Lauf minutenlang beim Signieren stehen, wartet er auf genau diesen Dialog.

### Danach

```bash
git add companion-app/auslieferung && git commit && git push
```

Das Telefon lädt die `.ipa` aus dem Repository - ohne diesen Push ändert sich
dort nichts. Danach in **Safari** auf dem Telefon öffnen (andere Browser reichen
`itms-services://` nicht an das System weiter):

```
itms-services://?action=download-manifest&url=https://gitea.nothaft.cloud/paul/audi-app/raw/branch/main/companion-app/auslieferung/manifest.plist
```

Die Adresse trägt **kein** `?v=` - ein zweites Fragezeichen zerlegt den
Parameter, und weil iOS die Rückfrage erst aus dem geladenen Manifest baut,
passiert dann sichtbar gar nichts (Abschnitt CK).

Zum Schluss die eine Prüfung, die kein Skript abnehmen kann - siehe Abschnitt C
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 |