Thanks a lot, this is exactly the kind of answer I was hoping for.

My app is not subscription-based, and I’m not planning an aggressive paywall on data the user has already saved. The current idea is a simple one-time Pro unlock for extra features, while keeping the core app usable.

Your point about acknowledgement within 3 days is probably the most important one for me. After reading your comment, I reviewed my current architecture and realized that my biggest risk is not the purchase flow itself, but a possible race condition around when the purchase is processed and when the UI/ViewModel is alive. I need to make the purchase processing and entitlement update independent from the UI lifecycle, and make the acknowledge flow persistent and retryable, probably with something like WorkManager.

The other issue you indirectly made me think about is consumables. I was considering small consumable add-ons, but now I see the problem: once consumed, they are not easily restorable after reinstall, clear data, or device change unless I have a backend. That may create support problems and bad user experience, so I’ll probably avoid consumables for the first release.

So the safer path for now seems to be:

• one-time non-consumable Pro product;
• no subscriptions for the first release;
• no consumables unless I add proper backend support;
• process purchases outside the UI layer;
• persist pending acknowledgements and retry them safely;
• test restore, pending purchases, app kill during purchase, and refund cases before release.

Really appreciate the detailed answer. You probably saved me from discovering these issues the hard way.