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