Crash when using PurchaseOption.appAccountToken

[davidgiga1993]

When using the following code the app crashes:

String userUuid = "05abfa67-fe21-49c3-bb2d-b90593baa938";
NSSet<Product.PurchaseOption> options = new NSMutableSet<>();
options.add(Product.PurchaseOption.appAccountToken(new NSUUID(userUuid)));

Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '+[missing_RvmProduct_PurchaseOption appAccountToken:]: unrecognized selector sent to class 0x1332748a0'

It is unclear to my why it stopped working, because this code has been in use for quite some time without issues.

Tested on iOS 18.5 (iPad with M1), when testing it on an iOS Simulator with iOS 18.3 it works.

[davidgiga1993]

Just tried another static method on PurchaseOption - also failing:

Product.PurchaseOption option2 = Product.PurchaseOption.customString("a", userUuid);
Log.i(LOGTAG, "Option2: " + option2);
options.add(option2);

Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '+[missing_RvmProduct_PurchaseOption customStringWithKey:value:]: unrecognized selector sent to class

All the other StoreKit stuff seems to work (getting produts, starting purchase, etc)

[dkimitsa]

it seems to be related to StoreKit2 bindings, can you please share gradle entries where do you use it from (e.g. version) ? Thx

[davidgiga1993]

My gradle file is huge, but the relevant part is:

implementation("io.github.dkimitsa.robovm:robopods-storekit-swift:18.2.0.2-SNAPSHOT")

from repo maven { url = "https://central.sonatype.com/repository/maven-snapshots/" }
using robovm 2.3.23

I'm currently upgrading xcode to see if it crashes with iOS 18.5 simulator as well.

[davidgiga1993]

Ah forgot to mention: Used build SDK 18.2, now upgraded to 18.5.
Still works fine in 18.5 Simulator and crashes on iOS 18.5 device. Also tried an iPhone with iOS 18.6, also crashing

[dkimitsa]

this means that RvmProduct_PurchaseOption is missing but this should not happen as it is part of binding (wrapper class) e.g. not system one. Will check tomorrow to see if library itself has corresponding arch slice.
strange it was working before )

[davidgiga1993]

Yeah I also did not update anything robovm related in quite some time, just regular app updates.
I also checked the symbols of the native lib in the jar and they seem to look correct, at least the PurchaseOption ones are included.

Thanks a lot for your help on this!

[davidgiga1993]

So I compiled the entire repo locally (including the natives) but the issue persists.

[davidgiga1993]

I fixed it - although unsure why. I moved the RvmProduct.PurchaseOption into its own top level swift class:

@available(iOS 15.0, macOS 12.0, tvOS 15.0, watchOS 8.0, visionOS 1.0, *)
@objc public class RvmPurchaseOption: NSObject  {
	let raw: Product.PurchaseOption
	init(raw: Product.PurchaseOption) {
		self.raw = raw
	}

	public override func isEqual(_ object: Any?) -> Bool {
		return if let other = object as? RvmPurchaseOption { self.raw == other.raw } else { false }
	}

	public override var hash: Int { raw.hashValue }

	/// Apply an app account token to a purchase.
	///
	/// The app account token will persist in the resulting `Transaction` from a purchase.
	/// - Parameter token: A UUID that associates the purchase with an account in your system.
	@objc public static func appAccountToken(_ token: UUID) -> RvmPurchaseOption {
		return Product.PurchaseOption.appAccountToken(token).toRvm()
	}
....

adjusted the java code accordingly:

@Library(Library.INTERNAL)
@NativeClass("StoreKitRvm.PurchaseOption")
public class PurchaseOption extends NSObject
{
	public static class PurchaseOptionPtr extends Ptr<PurchaseOption, PurchaseOptionPtr>
	{
	}

	static
	{
		ObjCRuntime.bind(PurchaseOption.class);
	}
...

and now it also works on all my iOS devices.

Do you have any idea why this would be?
I don't think I'm calling a static method on any other Product sub-class, maybe it's just related to that somehow. Maybe the @NativeClass names are different than before in the lib?

[dkimitsa]

hey,
as I can see StoreKitRvm.framework is compiled as dynamic library but bindings are made for static @Library(Library.INTERNAL).

quick check could be:

• replace all @Library(Library.INTERNAL) with @Library("StoreKitRvm")
  or
• recompile binaries as static library:

diff --git a/storekit/src/main/native/StoreKitRvm.xcodeproj/project.pbxproj b/storekit/src/main/native/StoreKitRvm.xcodeproj/project.pbxproj
index 75ce674..61bf163 100644
--- a/storekit/src/main/native/StoreKitRvm.xcodeproj/project.pbxproj
+++ b/storekit/src/main/native/StoreKitRvm.xcodeproj/project.pbxproj
@@ -172,6 +172,7 @@
                                        "@executable_path/Frameworks",
                                        "@loader_path/Frameworks",
                                );
+                               MACH_O_TYPE = staticlib;
                                MARKETING_VERSION = 1.0;
                                MODULE_VERIFIER_SUPPORTED_LANGUAGES = "objective-c objective-c++";
                                MODULE_VERIFIER_SUPPORTED_LANGUAGE_STANDARDS = "gnu17 gnu++20";
@@ -207,6 +208,7 @@
                                        "@executable_path/Frameworks",
                                        "@loader_path/Frameworks",
                                );
+                               MACH_O_TYPE = staticlib;
                                MARKETING_VERSION = 1.0;
                                MODULE_VERIFIER_SUPPORTED_LANGUAGES = "objective-c objective-c++";
                                MODULE_VERIFIER_SUPPORTED_LANGUAGE_STANDARDS = "gnu17 gnu++20";

[davidgiga1993]

Changing it to staticlib still causes the crash. Will now try dynamic and different library annotation

[davidgiga1993]

Using @Library("StoreKitRvm") causes java.lang.UnsatisfiedLinkError: Library 'StoreKitRvm' not found (I did not use MACH_O_TYPE = staticlib; for this test).

I've created a rough mr that fixed the issue for me: dkimitsa/robovm-cocoatouch-swift#2

[dkimitsa]

hi, played and was not able to reproduce on simulator.
just a quick question, is it reproducible with simple/empty project ?
e.g. with something like this:

    public static void main(String[] args) {
        try (NSAutoreleasePool pool = new NSAutoreleasePool()) {
            System.out.println(Product.PurchaseOption.customString("a", "b"));
            UIApplication.main(args, null, Main.class);
        }
    }

also what version of RoboVM do you use ?
ps, will try to get iOS device tomorrow to reproduce.

[davidgiga1993]

I was never able to reproduce it in a simulator, only on a real device. Using robovm 2.3.23
I haven't tried it with an empty project yet but it should still crash.

[dkimitsa]

ok, I have played a bit and seems like the issue is due way you lib is compiled and probably its swift/clang bug. Who knows.
root case: it crashes when as there is no symbol _OBJC_CLASS_$_RvmProduct_PurchaseOption in StoreKitRvm compiled for iphone/arm64. While it is present in simulator/arm64.

I've been investigated a bit and was able to trace it to smallest reproducible sample:

import Foundation
import StoreKit

@available(iOS 15.0, *)
@objc(RvmProduct_PurchaseOption) public class RvmProduct_PurchaseOption: NSObject  {
     let raw: Product.PurchaseOption
     init(raw: Product.PurchaseOption) {
        self.raw = raw 
     }
}

and when you compile against ios12:

swiftc test.swift -sdk `xcrun --sdk iphoneos --show-sdk-path` -target arm64-apple-ios12 -o arm64-iphone.o

there is indeed no such symbol:

nm ./arm64-iphone.o | grep OBJC_CLASS

(empty)

but if you compile it agains ios13 -- everything is working:

swiftc test.swift -sdk `xcrun --sdk iphoneos --show-sdk-path` -target arm64-apple-ios13 -o arm64-iphone.o 
nm ./arm64-iphone.o | grep _OBJC_CLASS_  
                  U _OBJC_CLASS_$_NSObject
 0000000100010310 S _OBJC_CLASS_$_RvmProduct_PurchaseOption

I don't know why it was working on 18.3 and stopped working 18.4+ but its most likely due swift 6.1. embedded into it, also it delivers changes to obj-c interop: SE-0436 Objective-C implementations in Swift which might affect how runtime builds obj-c classes .

anyway: trying to fix it might be long story and I prefer to compile libraries with proper minimal version as trying to use old one might introduce unexpected legacy issue that nobody is willing to fix.