Great! Thanks for the swift replies 🙏.
I will clarify that the app in question is iOS/iPadOS, so it feels clear that I should be looking at the build number. Our numbering follows a v.v.v structure for version, whereas the build numbers iterate up from 1 for each version number (as listed in the General pane in Xcode). So I'll make sure the build number and subsequent value to condition against are high enough to not cause issues, e.g. 100.
For testing, will Testflight also return the default 1.0 for originalAppVersion, even with external testers?
Just curiously, has Apple ever stated why macOS gets a different treatment in this case?
Thanks for the in-depth response, @endecotp 👏. Our apps are entirely offline and we don't collect analytics (per Apple's instructions for Made for Kids apps). We could, of course, but we don't gain much insight. This particular app is already 12 years old (almost to the date), and we've only done 10 updates to it in total (only one update in the last 11 years 😀). So any fancier receipt validation is a bit beyond our scope (and unnecessary).
Since we've only done one update during this entire decade, I can be absolutely sure that all users are currently on the newest version of the app, 1.4.0 (18). So the business model change isn't that risky in this case. However, we will be converting the rest of our apps to freemium during 2025, so I need to be certain how things work and what strategy to use universally.
Just FYI, I also did research originalPurchaseDate, but I saw on some thread that it was not advised. Perhaps it's strictly only meant for subscription IAPs.
Topic:
App & System Services
SubTopic:
StoreKit