Mac Catalyst und OpenSSL

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

  • Mac Catalyst und OpenSSL

    Hallo zusammen,

    hat jemand von Euch schon erfolgreich OpenSSL (statisch gebunden) in einer Mac-Catalyst-App verwendet?

    Hintergrund: Ich habe gestern In-App-Purchase in eine neue App eingebunden, die neben iOS auch per Mac Catalyst unter macOS läuft. Hierzu habe ich - wie auch in anderen Projekten - Receigen verwendet, welches für die Kryptografie ein statisch gelinktes OpenSSL nutzt. So weit, so gut und klappt auch unter iOS problemlos. Beim Versuch, das macOS-Target zu linken, kommt aber leider der folgende Fehler:

    Quellcode

    1. ld: in /Users/.../OpenSSL/lib/libcrypto.a(tasn_typ.o), building for Mac Catalyst, but linking in object file built for iOS Simulator, for architecture x86_64
    Ich habe (bisher nur etwas) recherchiert und wahrscheinlich läuft es darauf hinaus, OpenSSL mit einem zusätzlichen Target x86_64-apple-ios13.0-macabi zu kompilieren. Da ist für mich noch Neuland - bisher hatte ich bequemerweise fertig kompilierte Bibliotheken verwendet. Eine tolle Alternative wäre OpenSSL als XCFramework, aber auch da bin ich komplett unbeleckt.

    Bevor ich mich einlese, wie ich OpenSSL mit dem genannten Target neu kompiliere: Hat eine(r) von Euch Erfahrung mit OpenSSL unter Mac Catalyst? Ist mein Ansatz richtig oder befinde ich mich komplett auf dem Holzweg? Wenn letzteres, kennt Ihr eine Lösung?

    Mattes
    Diese Seite bleibt aus technischen Gründen unbedruckt.
  • Die Sache war dann doch etwas komplizierter, da die OpenSSL-Bibliotheken ja plattformabhängig eingebunden werden müssen. Leider scheitert dies an der Namensgleichheit von librypto.a und libssl.a für die verschiedenen Plattformen. Ich habe nun ein XCFramework verwendet, welches OpenSSL für iOS, watchOS, tvOS und Mac Catalyst beinhaltet ... fairerweise sei gesagt, dass ich mich hier den fertigen Binaries auf diesem GitHub-Repo bedient habe.

    Das Projekt läuft nun ... zumindest technisch, denn die Receipt-Validierung unter Mac Catalyst schlägt noch mangels Receipt fehl: Ich vermute / befürchte hier weitere Plattformspezifika. Leider habe ich bisher im Web nichts zu IAP unter Mac Catalyst finden können.

    Hier (OpenSSL) und hier (IAP) habe ich auch im Apple-Developer-Forum Hilfe gesucht, vielleicht kommt ja noch etwas. Und den Autor von Receigen habe ich auch angeschrieben...

    Grüße, Mattes
    Diese Seite bleibt aus technischen Gründen unbedruckt.
  • Wir haben uns (ohne Catalyst, nur iOS und macOS) damit beholfen, die fertigen Binaries in unterschiedliche Unterordner zu stopfen und via Buildconfiguration plattformspezifisch zu linken.
    Allerdings nutzen wir auch weder IAP noch Receigen und OpenSSL in der unglaublich aktuellen Version 1.0.2…
    Also nix mit "fertiges Framework nehmen" sondern hübsch halbmanuelle cross-compilation. :/
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P
  • @Marco Feltmann: Hey, lange nicht gesehen / gelesen :D Danke für die Bestätigung, dass ich Dinge nicht unnötig verkompliziert habe!

    Die IAP-Sache habe ich erst einmal auf Eis gelegt, da die Mac Catalyst Version bisher eh nur für eine "interne Verwendung" geeignet ist: Zu viele Baustellen, als die in absehbarer Zeit auszuliefern.

    Munter bleiben, Mattes
    Diese Seite bleibt aus technischen Gründen unbedruckt.
  • Ich brauchte libcrypto und libssl für SFTP. Beide libs sind auf dem Mac vorhanden, können aber nicht gelinkt werden.
    Das wird vom Apple duch setzen der isysroot auf das SDK verhindert.
    In den Commandline Tools für Xcode ist unter /Library/Developer/CommandLineTools/usr/bin/tapi ein Programm zum erstellen von .tbd Files vorhanden.
    Damit können die Openssl Libs gelinkt werden.
    Der Pfad zu den .tbd Files muss auch in die Library Serarch Paths eingetragen werden.

    Chris
    Man macht einfach solange irgendwelche Dinge, bis man tot ist.
    Und dann bekommen die anderen Kuchen.
  • Chris schrieb:

    Ich brauchte libcrypto und libssl für SFTP. Beide libs sind auf dem Mac vorhanden, können aber nicht gelinkt werden.
    Ich nutze neben dem -isysroot Flag auch noch ein -isystem Flag, dass auf die Erweiterungen für unsere Apps zeigt.
    (Hier irgendwas mit Boost, Xalan-C, Xerces-C, OpenCV, OpenSSL…)

    Shell-Script

    1. INCLUDE -isystem /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1 -isysroot /Applications/Xcode-beta.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.0.sdk -isystem /Applications/Xcode-beta.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS14.0.sdk/usr/include -isystem Ext_BOOST -isystem /Volumes/Daten/Sysroots/SDKs/iOS14/usr/local/include/boost-1_64_0 -isystem /Volumes/Daten/Sysroots/SDKs/iOS14/usr/local/include
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P

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

  • Ich such' mir gerade ziemlich einen Wolf, daher einmal die Frage in die Runde:

    Kennt jemand von Euch ein GitHub-Projekt (o.ä.) für ein XCFramework von OpenSSL, das iOS inkl. Mac Catalyst und Simulator, sowie macOS inkl. ARM unterstützt? Also quasi die eierlegende Wollmilchsau...

    Ich habe bisher nur Teilmengen gefunden und scheitere beim Zusammenfügen oder gar Neubau an meiner Unkenntnis :(

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

    Ich habe bisher nur Teilmengen gefunden und scheitere beim Zusammenfügen oder gar Neubau an meiner Unkenntnis :(
    Antwort auf meine eigene Frage ... falls Ihr genauso sucht:

    Im oben verlinkten Git-Repository gibt es einen Pull-Request zu einem anderen Projekt, indem jemand in einer eigenen Branch ARM-Support hinzugefügt hat. Eben mit OpenSSL 1.1.1h gebaut und in ein XCFramework gepackt. Nun habe ich eine zentrale Stelle mit OpenSSL für diverse Plattformen und Architekturen ... letztere wurden übrigens mit klassischen fat binaries innerhalb des XCFramework realisiert:
    • macOS (x86_64, arm64)
    • iOS Mac Catalyst (x86_64, arm64)
    • iOS (armv7, arm64)
    • iOS Simulator (x86_64, arm64)
    • ... zzgl. tvOS, watchOS (für mich bisher nicht interessant)
    Bisher nur mit iOS inkl. Simulator und Mac Catalyst getestet ... es macht scheinbar, was es soll und der "Härtetest" mit einem ARM-Mac muss noch etwas warten :D

    Mattes
    Diese Seite bleibt aus technischen Gründen unbedruckt.
  • Ich bin gespannt, ob alles mit mit der Catalyst/OpenSSL/Receigen Implementierung geklappt hat. Die einfachste OpenSSL/Catalyst Lösung scheint jetzt das folgende Github-Repository zu sein: github.com/krzyzanowskim/OpenSSL.
    Die universelle OpenSSL version unterstützt seit dem Jahresbeginn 2021 auch Catalyst.

    Mein app ist bis jetzt 100% Swift und ich müsste erst einmal mit den Objective C headers klarkommen. Das ist für mich Neuland und habe gerade schmunzeln festgestellt, das die letzten Beiträge, die sehr hilfreich auf dem englischen Apple Forum wahren auch von Ihnen stammen. ;) Danke für die bisherigen Erkenntnisse - Ich hoffe das inzwischen alles wie Butter läuft!
  • .@. schrieb:

    Ich bin gespannt, ob alles mit mit der Catalyst/OpenSSL/Receigen Implementierung geklappt hat.
    Wie oben bemerkt, habe ich den IAP für Mac Catalyst erst einmal auf Eis gelegt: Die UX einer (etwas komplexeren) App ist unter Mac Catalyst eher dürftig. Ich werde mich bei Gelegenheit noch mehr mit eigenen Menüs, Tastatur-Shortcuts etc. auseinandersetzen, aber bisher bleibt die App unter macOS der internen Verwendung vorbehalten ... da brauche ich kein IAP.

    Das o. g. XCFramework erfüllt seinen Dienst unter macOS (x64, arm) und iOS inkl. Simulator. Unter Mac Catalyst kompilieren und linken Receigen / OpenSSL auch problemlos. Allerdings scheint der Receipt-Request nicht zu ziehen. Entweder muss Receigen hier macOS-like konfiguriert werden oder vielleicht muss man auch selber einen per exit(173) triggern: Ich habe da noch nicht weiter geforscht.

    Wäre nett, wenn Du - bei neuen Erkenntnissen - hier etwas schreibst: Mir kommen meine diesbezüglichen Threads fast wie Monologe vor :)

    Mattes
    Diese Seite bleibt aus technischen Gründen unbedruckt.
  • Danke für die zusätzlichen Informationen. Ich habe gerade festgestellt, das die einzelnen OpenSSL header/libs von 'Universal Open SSL' in Xcode platform spezifisch lokalisiert werden können:

    HEADER_SEARCH_PATHS = $(PROJECT_DIR)/OpenSSL/$(PLATFORM_NAME)/include
    LIBRARY_SEARCH_PATHS = $(PROJECT_DIR)/OpenSSL/$(PLATFORM_NAME)/lib

    Das geht zumindest für iOS and Catalyst. In einer zukünftigen Version soll es auch für macOS (X) gehen.

    Ansonsten geht es schneckenweise voran. Wie wird die receipt.h file für beide iOS/Catalyst integriert? In einer einzelnen 'file' mit '#if targetEnvironment(macCatalyst)' - oder kann man sie auf diese Weise nicht kombinieren? Verschiedene Code Prefix sind schon definiert.
  • *Meine folgenden Aussagen bitte überspringen und gleich nach unten scrollen :D :

    Für Receigen muss der macOS(X) code bei Catalyst verwendet werden. Es müssten also beide iOS and macOS(X) in demselben Xcode project vorhanden sein. Exit(173) ist schon in dem macOS(X) rebeigen code vorhanden, aber der Befehl muss auch vor Programmstart durchgeführt werden. Es muss dabei unter anderem die @UIApplicationMain von dem AppDelegate gelöscht werden um den _CheckReceiptAndRun durchzuführen.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von .@. () aus folgendem Grund: * Man lernt immer etwas neues!

  • Es scheint an dem @UIApplicationMain 'app delegate' zu scheitern. Es scheint nicht möglich zu sein ein 'app delegate' mit der 'main.swift' file für Catalyst einzurichten:

    'NSApplication' is unavailable in Mac Catalyst

    Ohne eine main.swift file die @UIApplicationMain ersetzt kann bin ich vorerst am Ende. Vielleicht auch der Grund warum Catalyst Apps nicht in der Receigen Dokumentation erwähnt werden. Die Dokumentation wurde in 2020 mit StoreKit Testing erweitert - sie ist also auf dem letzen Stand der Dinge.
  • Übrigens wird NSApplicationMain in dem Receigen code auch als 'out of scope' gemeldet. In dem code sind auch Referenzen von AppKit. AppKit ist nur begrenzt zugänglich für Catalyst Apps.

    OpenSSL - installiert und läuft ^^

    Receigen - incompatible mit Catalyst ||

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

  • .@. schrieb:

    Receigen - incompatible mit Catalyst
    Kann ich so nicht bestätigen: Ich war neugierig, habe besagtes Projekt "ausgegraben" und die auskommentierte Receipt-Prüfung für Mac Catalyst aktiviert: Es funktioniert unter macOS 11 "Big Sur" / Xcode 12.3 (12C33) nun ohne besonderes Zutun (unter Catalina war es nicht so):
    • Receigen wird mit dem iOS-Header eingebunden
    • Wenn kein Receipt gefunden wird, frage ich den User, ob ein ReceiptRefresh erfolgen soll, der wird dann über CheckInAppPurchasesAndReceipt von Receigen ausgelöst
    • Ein bestehendes Receipt wird mit dem gleichen Aufruf sauber ausgewertet (inkl. IAP)
    • Für Käufe erfolgen die erwarteten Abfragen vom StoreKit, anschliessend ist die Receipt-Validierung wie oben ebenfalls erfolgreich
    Für mich sieht das alles - in der Sandbox - in Ordnung aus: Keine Sonderbehandlung, sondern stumpf vorgehen, als wäre man unter iOS.

    Man merkt auch hier, dass Apple mit Big Sur einiges an der Catalyst-Implementierung verbessert hat: Es sind einige Ungereimtheiten verschwunden, bei mir beispielsweise beim Settings-Bundle und Umordnen in Collection Views. Trotzdem ist bei meiner App das Look & Feel nicht, was ich von einer macOS-App erwarte (und ausliefern möchte). Aber das ist ein anderes Thema.

    Mattes
    Diese Seite bleibt aus technischen Gründen unbedruckt.
  • Bei mir hat es nach meinem letzen Kommentar auch noch einmal in den Fingern gekribbelt. Probleme gibt es nur bei der Exit(173) Implementierung von Receigen, die Zugriff auf das NSApplicationMain benötigt.

    Die Exit(173) Implementierung liegt bei iOS Apps nicht als Option vor - es ist ausschließlich eine macOS(X) Funktion. Interessanter Weise ist ReceiptRefresh laut Receigen Dokumentation ausschließlich eine iOS Option.

    Wenn alles Problemlos läuft frage ich mich, ob die Catalyst Apps jetzt als iOS Apps validiert werden und nicht als macOS Apps. Auf iOS wird doch sonst immer die Vendor ID und auf macOS die Mac Addresse als GUID benutzt. Eine weiter offene Frage ist, ob der Exit(173) code bei Programmstart von Catalyst Apps überhaupt benötigt wird.
  • .@. schrieb:


    Eine weiter offene Frage ist, ob der Exit(173) code bei Programmstart von Catalyst Apps überhaupt benötigt wird.
    Wie ich oben schrieb: Ich implementiere Receigen iOS-like ... kein exit(173), Ersatz in main() oder ähnliches, sondern 100% identischer Code (inkl. Receigen-Header) für beide Plattformen. Unter Mac Catalyst ist es bzgl. der Receipt-Behandlung eine reine iOS-App.

    So läuft's bei mir, Mattes
    Diese Seite bleibt aus technischen Gründen unbedruckt.
  • MyMattes schrieb:


    • Ein bestehendes Receipt wird mit dem gleichen Aufruf sauber ausgewertet (inkl. IAP)
    • Für Käufe erfolgen die erwarteten Abfragen vom StoreKit, anschliessend ist die Receipt-Validierung wie oben ebenfalls erfolgreich
    Für mich sieht das alles - in der Sandbox - in Ordnung aus: Keine Sonderbehandlung, sondern stumpf vorgehen, als wäre man unter iOS.
    Tja, ich würde gerne nochmal die Zeit zurückdrehen: Entweder hat sich mit Xcode 13.1 (13A1030d) unter macOS 12.0.1 (21A559) etwas maßgeblich geändert oder ich hatte Anfang der Jahres in meiner Euphorie Tomaten auf den Augen - wahrscheinlich letzteres:

    Heute habe ich den entsprechenden Code noch einmal angepackt: Nachdem ich diverse UI-Unstimmigkeiten unter Mac Catalyst behoben habe, wollte ich nun eine Veröffentlichung als "Universal Purchase" in's Auge fassen:

    Die Receipt-Validierung scheitert an der macOS- / iOS-Unstimmigkeit bzgl. BundleVersion vs. CFBundleShortVersionString und auch bei Überspringen dieses Check ist der Hash ungültig. Somit wird das bestehende Receipt nicht akzeptiert und kein IAP freigeschaltet. Beim Kaufversuch wird der schon bestehende IAP erkannt, die erneute Receipt-Prüfung scheitert natürlich erneut.

    Also "back to square one": Hat irgendjemand eine Mac Catalyst App mit IAP-Validierung über Receigen?

    Frustriert, Mattes
    Diese Seite bleibt aus technischen Gründen unbedruckt.
  • Ich habe jetzt keine Erfahrungen mit Catalyst-Projekten, aber wenn du mit einer zusätzlichen Build Phase einen separaten Receigen-Header nur für macOS generierst, sollte es eigentlich machbar sein. Receigen kann man über den Parameter --os ja mitteilen, für welches OS der Receipt-Check generiert werden soll. Mit --p kann man auch einen Code Prefix angeben, falls das notwendig sein sollte. Zur Laufzeit kann man dann an geeigneter Stelle den jeweiligen OS-spezifischen Receipt-Check anstossen:

    C-Quellcode

    1. BOOL isMacCatalystApp = [[NSProcessInfo processInfo] isMacCatalystApp];
    2. if (isMacCatalystApp) {
    3. // Receigen-Receipt-Check für macOS aufrufen
    4. }