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".

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

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.

Yep I am getting the same thing now as well 🤔

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.

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 🤔

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

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