Replying to my own post in case it helps it others.

This is a known issue that I wasn’t aware of - Apple put the Build Number in the originalApplicationVersion field NOT the Version Number (so if you follow common convention and bump  the version number for major releases re-starting the build number to use incrementally for minor changes within each version you don’t get what you expect.

According to this Stackshare post (now 7 years old) the originalPurchaseDate IS reliable so unless you know all the build numbers of your previous non-subscription apps, and don't reset the build number every time you bump the major version number, you need to use the originalPurchaseDate only.

Hey @JamesO!

Yep- this property is a little confusing. The originalApplicationVersion is actually the build number, not the App Store version number that is displayed to customers.

I’d also recommend checking out our blog post on making the switch from paid → subscriptions that goes over this topic: https://www.revenuecat.com/blog/converting-a-paid-ios-app-to-subscriptions

Thanks Cody.

This effectively makes that property useless for migrating a mature app, paid versions over the years have had pretty much every build number from 0 upwards. Guess I’ll have to rely on the date!

Hey @cody any chance you can point me to a React Native version of your original post above? We are migrating a legacy paid app to be subscription-based and need to grandfather in existing users. Thanks!