App-Test auf anderer Maschine crasht (M1 vs. Intel)

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • App-Test auf anderer Maschine crasht (M1 vs. Intel)

    Hallo Leute,

    Hilfe, ich bin nicht mehr in der Lage, eine langjährige App unter alten macOS-Versionen zu testen. Aber der Reihe nach:

    Besagte App unterstützt macOS >= 10.11, wird über den App-Store vertrieben, nutzt IAP, iCloud etc. und ist seit > 1 Jahr eine Universal App (Intel / ARM).

    Ich habe neben meinem M1-Entwicklungsrechner einen Intel Mac-Mini, auf dem per VMware Fusion diverse macOS-Versionen vorgehalten werden. Auf diesen teste ich schon seit Jahren problemlos. Jetzt allerdings werden mir die Builds mit einem "Code Signature Invalid"-Fehler beim Start abgebrochen. Das Dumme ist, ich kann mich um's Verrecken nicht erinnern, in der Vergangenheit irgendwas anders gemacht zu haben:
    • Unter Xcode "My Mac (Rosetta)" als Device auswählen, das natürlich erst neuerdings um ein Intel-Build zu erzeugen
    • Einmal starten (um ein App-Store Receipt zu erhalten)
    • In die Intel-VMs kopieren, starten ... und mit dem AppStore Test-User anmelden
    Zum letzten Schritt komme ich nicht mehr, weil die App mit o. g. Fehler crasht. Inzwischen habe ich alle möglichen anderen Wege mit einem Universal Archive probiert: Im Xcode-Organizer nur exportiert/kopiert, mit Developer ID signiert (notarized oder nicht), als Development Distribution ... und per App Store Connect via TestFlight. Nur der letzte Weg funktioniert, hilft mir aber für alte macOS-Versionen wenig.

    Mittlerweile zweifle ich an allem ... irgendwelche Ideen?

    Mattes
    Diese Seite bleibt aus technischen Gründen unbedruckt.
  • MCDan schrieb:

    Lässt sich die per TestFlight installierte App nicht auf die alten macOS Installationen kopieren?
    Das hatte ich auch probiert, ohne Erfolg: Ich glaube, da war die Fehlermeldung sinngemäß „Apple cannot check for malicous code“ … bin aber ob der vielen Versuche nicht mehr sicher.

    Danke für den Hinweis bzgl. Intermediate Certificates: Das werde ich mir morgen nochmal in Ruhe anschauen. Für heute bin ich „durch“, da kommt nix Sinnvolles mehr.

    Ich werde auch noch einmal mit expliziten Provisioning Profiles arbeiten, die ich IIRC seit Jahren nicht mehr brauchte … zumindest gingen einige Kommentare von Quinn in Apple‘s Developer Foren in die Richtung. Gerne folge ich auch weiteren Ideen!

    Alles sehr merkwürdig, Mattes ?(
    Diese Seite bleibt aus technischen Gründen unbedruckt.
  • OSXDev schrieb:

    @MyMattes: Hast Du Little Snitch oder eine andere App in Gebrauch, welche die Netzwerkverbindungen überwacht?
    Nein, aber fast alle Tests fanden in VMs mit gebridgetem Netzwerk statt ... wobei: Ich habe auch auf dem Host-System getestet.

    Dachtest Du an eine mögliche Fehlerquelle bei einem ReceiptRequest - das ist schon im Bundle - oder einer Zertifikatsvalidierung? Die erfolgt meines Wissens lokal. Oder meinst Du zur Analyse?

    Momentan vermute ich, dass (inzwischen?) ein extra Provisioning Profile notwendig ist, falls eine macOS-App restricted entitlements nutzt. Könnte sein, dass Apple dort restriktiver geworden ist, zumindest lässt mich Quinn's Kommentar in diesem Artikel sowas annehmen.

    Oder es fehlt wirklich ein aktuelles intermediate certificate auf den Test-Maschinen ... dagegen spricht aber der Fehler unter (Intel-) Monterey.

    Mattes
    Diese Seite bleibt aus technischen Gründen unbedruckt.
  • MyMattes schrieb:

    ...

    Dachtest Du an eine mögliche Fehlerquelle bei einem ReceiptRequest - das ist schon im Bundle - oder einer Zertifikatsvalidierung? Die erfolgt meines Wissens lokal. Oder meinst Du zur Analyse?

    Momentan vermute ich, dass (inzwischen?) ein extra Provisioning Profile notwendig ist, falls eine macOS-App restricted entitlements nutzt. Könnte sein, dass Apple dort restriktiver geworden ist, zumindest lässt mich Quinn's Kommentar in diesem Artikel sowas annehmen.

    Oder es fehlt wirklich ein aktuelles intermediate certificate auf den Test-Maschinen ... dagegen spricht aber der Fehler unter (Intel-) Monterey.

    Mattes
    Meine erste Vermutung war, dass eine Prüfung des Validierungsprozess unterbrochen sein könnte.

    Als nächstes würde ich prüfen, Beschreibung findest Du im Artikel, ob die notwendigen Zertifikate vorhanden sind. Sollte dies der Fall sein, läge es nahe, dass das Problem innerhalb von Rosetta 2 liegt. In diesem Fall würde ich Dir raten Dich direkt an Apple zu wenden.

    Für den Fall, dass nicht alle Zertifikate vorhanden sind, diese nachinstallierten. Eigentlich sollte es reichen wenn Du im VM Client ein neues Projekt anlegst. Wenn Du ganz sicher gehen möchtest, nutze die selben Sandbox Attribute. Sollte das Dummy-Projekt ohne Fehlermeldungen kompiliert werden, probiere aus ob dies auf Deinem M1 läuft. Sollte es dort nicht laufen, erzeugte dieses Dummy Projekt mit exakt den gleichen Sandbox Attributen native auf dem M1. Läuft es, dann vergleiche nochmals die verwendeten Zertifikate der beiden Dummy-Projekte. Diese sollten identisch sein. Wenn dem so ist, dann liegt es nahe, dass die Ursache innerhalb von Rosetta 2 liegt.

    Um vollständig auszuschließen, dass es ein Zertifikatsproblem ist, schalte das Signieren bzw. Validieren aus indem Du die beim Signieren die Einstellung AD HOC (lokale Installation) verwendest - falls notwendig bei Provision NONE eintragen. Eine solche App läuft dennoch auf anderen Rechnern, allerdings musst Du in der Sandbox dann händisch die Freigabe erteilen.
    Kurz ausprobieren und wenn nun die Test-App aus der VM auf dem M1 läuft, deutet es daraufhin, dass evtl. die Bridging Einstellungen evtl. hierfür verantwortlich sein könnten. Ich selbst nutze kein Fusion - aber auch dort sollte es möglich sein eine Einstellung zu treffen, so dass direkt auf den Netzwerkadapter zugegriffen werden kann - also das reale Adapter genutzt werden kann. Da dies jedoch bisher keine Probleme bereitete, gehe ich nicht davon aus, dass die Fehlerquelle innerhalb von Fusion zu suchen ist.

    Stichwort Monterey - hätte ich beinahe überlesen. Dieses setzen wir hier noch nicht produktiv ein. Selbstverständlich könnten die Restriktionen, welche mit jeder neuen OSX Version einhergehen - zumindest meine Erfahrungen über die letzten Jahre - dazu führen, dass hier weitere "alte Zöpfe" abgeschnitten wurden.

    P.S.: Rosetta 2 hat bisher keine solche Probleme erkennen lassen. Bis zu welchem Zeitpunkt lief Deine App ohne Probleme auf einem Intel bzw. M1?

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von OSXDev () aus folgendem Grund: Nachtrag: Hinweis Rosetta 2, Stichwort

  • Hier kommt die Auflösung ... zumindest für meine Konstellation.
    • App auf dem M1 in Xcode archivieren (damit eine Universal App erzeugt wird)
    • "Distribute App" - "Development" - "Automatically manage signing" (beim manuellen Signieren braucht man ein Provisioning Profile, das explizit die Test-Geräte listet - das möchte ich mir für die VMs ersparen)
    • Das beim Transfer auf den VM-Host erzeugte quarantine-Attribut entfernen, sonst meckert GateKeeper, die App könnte nicht überprüft werden: xattr -r -d com.apple.quarantine <app>. Alternativ eine Transfer-Methode nehmen, die kein Flag setzt (scp?)
    Ich glaube, dass ich gestern einfach zu geschafft war und daher die Fehlerfälle nicht sauber differenzierte: Meistens war es wie oben geschrieben ein Zertifikatsfehler, in mindestens einem Fall aber auch der Gatekeeper-Hinweis, die App könnte nicht auf Schadcode überprüft werden - und das war genau der richtige Weg, nämlich das Development-Deployment.

    Der entscheidene Hinweis fand sich hier im Apple Developer Forum im o. g. Thread.

    Früher musste ich diesen Schritt nicht vornehmen, da die Entwicklungs-Maschine auch VM-Host war ... und Gatekeeper somit kein Problem hatte. Dass ein einfaches Kopieren reichte, dürfte damals an der Solo-Architektur gelegen haben.

    Danke für Eure Hilfestellungen, sie haben mir geholfen, das Problem analytisch anzugehen!

    Mattes
    Diese Seite bleibt aus technischen Gründen unbedruckt.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von MyMattes ()