If you get it through review I would love to check it out!

I am just about to deploy this workaround as well and hopefully thats it! I am quite annoyed that this is affecting my customers and something Apple should be looking to fix I have also filed a report via Feedback Assistant

At what point do you stop worrying tho 🤣 there could be many more apps out there who are having this problem and haven't realised 🤔

You would still use the groupID for the subscriptionStatusTask. The productIDs in the initializer for SubscriptionView is just another way to initialize the SubscriptionView with the specific products you want to manage.

Yep I am getting the same thing now as well 🤔

I understand that Apple’s documentation is primarily meant to demonstrate API usage, but that doesn’t mean it should contain flawed logic that could mislead developers. The example isn’t just showcasing syntax—it’s demonstrating how to determine whether a user’s app version predates a business model change. If the provided logic doesn’t actually work correctly, then the documentation is, by definition, incorrect.

A lexicographical comparison of version numbers can lead to incorrect results in real-world scenarios, potentially causing unintended behavior in production. Anyone referencing this example without catching the mistake would be implementing a broken check. If API documentation includes examples, they should be correct and reliable, not just placeholders. Developers trust these examples, and Apple should ensure they demonstrate best practices—or at the very least, functional logic

If you’ve had issues outstanding for years, that’s unfortunate, but it doesn’t mean valid concerns should be ignored. I mentioned 23 days for context, not as a complaint. The real issue is that a potential problem in Apple’s examples remains unaddressed. Lexicographical comparisons may pass basic tests but fail in real cases—like "10" being seen as less than "2".