Hallo zusammen,
ich habe gerade einen spassigen Nachmittag mit der Receipt-Validierung unter iOS mittels Receigen verbracht. Vielleicht erspart dieser Post ja manch anderen dieses zweifelhafte Vergnügen ... Um es vorweg zu nehmen: "Wer lesen kann, ist klar im Vorteil..."
Kurze Vorgeschichte: Ich nutze in einer macOS-App Receigen, um mir das Verarbeiten von Receipts und In-App-Käufen leichter zu machen und bin davon sehr angetan. Nun sollte auch eine iOS-App mit IAP ausgestattet werden. Also habe ich eine Klasse zu Händeln der verschiedenen Store-Aktivitäten geschrieben und eine Receigen-Datei generiert, die (1.) das Receipt validieren und (2.) durch die In-App-Käufe iterieren sollte. So weit, so gut.
Leider scheiterte die Receipt-Überprüfung immer bei der Bundle-Version, die Fehlermeldung leider wenig sprechend: "Receipt version mismatch (expecting '(null)' but actual value is '(null)')". Super, dann mal los:
Wer hat sich dieses Mischmasch zwischen beiden Plattformen eigentlich ausgedacht? Halt, ich weiß, wer ... und die wollen mir etwas von universalen Apps für beide Plattformen erzählen
Meine Lösung ist einfach, aber unschön: Ich verabschiede mich von dem o. g. Automatismus und setzte nun wieder - wie in Anfangszeiten - CFBundleShortVersionString (2.15.0) und CFBundleVersion (2.15.0.0) manuell für das Target. Da iTC auf aufsteigende Werte besteht, wird der letzte Wert bei neuen Submits - z. B. für TestFlight - erhöht, während der andere die "offizielle" Version darstellt, die ich auch im Settings-Bundle anzeige.
Habe ich etwas verpasst und einer von Euch hat eine bessere Idee? Dann bitte her damit!
Mattes
ich habe gerade einen spassigen Nachmittag mit der Receipt-Validierung unter iOS mittels Receigen verbracht. Vielleicht erspart dieser Post ja manch anderen dieses zweifelhafte Vergnügen ... Um es vorweg zu nehmen: "Wer lesen kann, ist klar im Vorteil..."
Kurze Vorgeschichte: Ich nutze in einer macOS-App Receigen, um mir das Verarbeiten von Receipts und In-App-Käufen leichter zu machen und bin davon sehr angetan. Nun sollte auch eine iOS-App mit IAP ausgestattet werden. Also habe ich eine Klasse zu Händeln der verschiedenen Store-Aktivitäten geschrieben und eine Receigen-Datei generiert, die (1.) das Receipt validieren und (2.) durch die In-App-Käufe iterieren sollte. So weit, so gut.
Leider scheiterte die Receipt-Überprüfung immer bei der Bundle-Version, die Fehlermeldung leider wenig sprechend: "Receipt version mismatch (expecting '(null)' but actual value is '(null)')". Super, dann mal los:
- Eintrag im iTunes Connect geprüft, der war wie erwartet: "2.15.0"
- Info.plist geprüft: Hier wird aus git-Tags heraus der CFBundleShortVersionString gesetzt und eine hochzählende Buildnummer in CFBundleVersion geschrieben. Das sieht dann z. B. so aus 2.15.0 (1234) und ermöglicht mir, im iTC neue Builds einer Version hochzuladen, ohne mich um ein manuelles Setzen zu kümmern. Bewert und geliebt.
- Ich vermutete also einen Fehler in dem Sandbox-Receipt von Apple.
- Um wenigstens etwas weiter Testen zu können, wollte ich Receigen mit der Präprozessor-Definition RECEIGEN_LOOSE_VERSION_CHECK überreden, den Check auszulassen, leider ohne Erfolg ... wahrscheinlich eigene Dummheit.
Wer hat sich dieses Mischmasch zwischen beiden Plattformen eigentlich ausgedacht? Halt, ich weiß, wer ... und die wollen mir etwas von universalen Apps für beide Plattformen erzählen
Meine Lösung ist einfach, aber unschön: Ich verabschiede mich von dem o. g. Automatismus und setzte nun wieder - wie in Anfangszeiten - CFBundleShortVersionString (2.15.0) und CFBundleVersion (2.15.0.0) manuell für das Target. Da iTC auf aufsteigende Werte besteht, wird der letzte Wert bei neuen Submits - z. B. für TestFlight - erhöht, während der andere die "offizielle" Version darstellt, die ich auch im Settings-Bundle anzeige.
Habe ich etwas verpasst und einer von Euch hat eine bessere Idee? Dann bitte her damit!
Mattes
Diese Seite bleibt aus technischen Gründen unbedruckt.