One photograph. Two ways to keep its colours.

Meet Afterimage — a colour-study app built in Flutter.

A — Light Table: calm and photo-first. B — Pocket Collection: bold and playful.

Same features. Two different personalities.

Which would you choose — A or B?

Download the source code for both versions for free from my Contra products.

https://contra.com/products/pdCjLweR-afterimage-free-flutter-ab-design-kit

which one did you design first?

Cancelling a purchase and failing a purchase reach your Flutter code the same way, as a PlatformException. That is how a paywall ends up showing a red error to someone who simply changed their mind on the store sheet. PurchasesErrorHelper.getErrorCode is what distinguishes them, and two outcomes are not enough. A single call to Purchases.purchase can end five ways: cancelled, pending, completed, failed and unresolved. Pending is the one that catches people out. A parent still has to approve the purchase, or a slow payment method has to settle, and RevenueCat grants no entitlement until the store confirms it. Which means the paywall screen should not be what decides access. A pending purchase can complete after the paywall closes or after the app has been killed, and RevenueCat does not push that change to the device. Keep a CustomerInfo listener in an object that lives as long as the app, and have every paid feature read the entitlement from it rather than from whatever the purchase call returned. https://www.duskolicanin.com/blog/flutter-subscription-pending-cancelled-purchase

This is such a real pain point! So many paywalls break exactly here - treating a user cancellation as a crash. Thanks for pointing out PurchasesErrorHelper.getErrorCode to distinguish it. Handling cancelled vs pending correctly is crucial for UX, no one wants a red error for changing their mind. Saving this!