Die Mac-App bekommt eine eigene Kennung

`DERIVE_MACCATALYST_PRODUCT_BUNDLE_IDENTIFIER: NO` gab der
Catalyst-Fassung dieselbe Bündelkennung wie der iPhone-App:
`com.scarriffleservices.flixy`. Auf einem Apple-Silicon-Mac, auf dem die
iPad-Fassung installiert ist, gibt es diese Kennung damit zweimal — und
das System entscheidet sich für eine davon, nicht unbedingt für die eben
gebaute. Der Start sah aus, als geschähe nichts.

`lsregister` zeigte sechs Einträge unter derselben Kennung. Apples
Voreinstellung ist `YES`, und zwar genau deshalb. Daraus wird
`maccatalyst.com.scarriffleservices.flixy`.

Dazu richtig signiert statt ad hoc: Flixy legt den Server-Token im
Schlüsselbund ab, und dem verweigert er sich bei einem Sandbox-Programm
ohne Team.

Und die Schemata stehen jetzt im Projekt. Xcode legte sie im
Benutzerordner an, wo `xcodegen generate` sie mitnahm — danach fand
`xcodebuild` keines mehr und konnte die Pakete nicht auflösen.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

project.yml

@@ -29,6 +29,15 @@ targets:
   Flixy:
     type: application
     platform: iOS
+    # Ausdrücklich aufgeschrieben, statt Xcode raten zu lassen.
+    #
+    # Xcode legt für jedes Ziel von selbst ein Schema an — aber im
+    # Benutzerordner, und `xcodegen generate` räumt den mit weg. Danach
+    # findet `xcodebuild` kein Schema mehr und kann die Pakete nicht
+    # auflösen. Hier steht es im Projekt und überlebt jedes Neuerzeugen.
+    scheme:
+      testTargets:
+        - FlixyUITests
     sources:
       # Das Icon ist ein Bündel, also technisch ein Ordner. Ohne diesen
       # Ausschluss läuft XcodeGen hinein und trägt icon.json und play.svg
@@ -172,6 +181,7 @@ targets:
   FlixyMac:
     type: application
     platform: iOS
+    scheme: {}
     sources:
       # Siehe Flixy: umgekehrt genauso, sonst trägt das Mac-Bündel die
       # Info.plist des iPhones in seinen Ressourcen.
@@ -202,16 +212,31 @@ targets:
         # „An das iPad angeglichen" statt „für den Mac optimiert" — genau
         # darum geht es.
         MACCATALYST_OPTIMIZE_FOR_MAC: NO
-        DERIVE_MACCATALYST_PRODUCT_BUNDLE_IDENTIFIER: NO
+        # **Eine eigene Kennung, nicht dieselbe wie die iPhone-App.**
+        #
+        # Hier stand `DERIVE_MACCATALYST_PRODUCT_BUNDLE_IDENTIFIER: NO`, und
+        # damit trugen beide Programme `com.scarriffleservices.flixy`. Auf
+        # einem Rechner, auf dem die iPad-Fassung installiert ist — und auf
+        # einem Apple-Silicon-Mac ist sie das leicht — gibt es die Kennung
+        # dann zweimal. Das System entscheidet sich für **eines** davon, und
+        # nicht unbedingt für das eben gebaute: der Start sieht aus, als
+        # geschähe nichts.
+        #
+        # Voreingestellt ist bei Apple `YES`, und zwar genau deshalb. Daraus
+        # wird `maccatalyst.com.scarriffleservices.flixy`.
+        DERIVE_MACCATALYST_PRODUCT_BUNDLE_IDENTIFIER: YES
         PRODUCT_BUNDLE_IDENTIFIER: com.scarriffleservices.flixy
         PRODUCT_NAME: Flixy
         ASSETCATALOG_COMPILER_APPICON_NAME: AppIcon
         TARGETED_DEVICE_FAMILY: "2"
-        # Selbst signiert: ein Build zum Ansehen soll nicht jedes Mal nach dem
-        # Schlüsselbund-Passwort fragen.
-        CODE_SIGN_STYLE: Manual
-        CODE_SIGN_IDENTITY: "-"
-        DEVELOPMENT_TEAM: ""
+        # Richtig signiert, wie die iPhone-App auch.
+        #
+        # Vorher war es eine Ad-hoc-Signatur ohne Team, damit ein Bau zum
+        # Ansehen nicht nach dem Schlüsselbund fragt. Nur legt Flixy den
+        # Server-Token im Schlüsselbund ab, und einem Sandbox-Programm ohne
+        # `application-identifier` verweigert der das — die Anmeldung hielte
+        # keinen Neustart aus.
+        CODE_SIGN_STYLE: Automatic
         ENABLE_HARDENED_RUNTIME: NO
         CODE_SIGN_ENTITLEMENTS: Flixy/Flixy-macCatalyst.entitlements
     info: