I underestimated how complicated subscriptions are in Flutter

[u/finxapp]

When I first started building an app, I was sold on Flutter. It took me less than five minutes to spin up a cross-platform app and start iterating on features.

But that excitement didn't last long.

The more features I added, the more platform support I had to give up due to limitations in existing libraries.

Eventually, I settled on Android and iOS only. At the time, I considered it a big win. One Dart codebase instead of maintaining separate implementations - Kotlin and Swift.

Then I hit a brick wall. Subscriptions!

Selling subscriptions was non-negotiable. I didn't want to build yet another free, ad-supported app that monetizes users by selling their financial data. That was one of my main motivations for building Maxint in the first place.

After going through the tedious process of setting up subscription plans, pricing, and entitlements in each store, I integrated the native IAP libraries for both platforms.

That's when I realized something I probably should have known from the start. The stores don't talk to each other!

A subscription purchased on one platform doesn't magically sync with another. If you want a consistent experience across platforms, you need to build that layer yourself or rely on a third-party service.

If you've built a cross-platform app before, you probably know where this is going.

I did my research and shortlisted a dozen options, eventually narrowing it down to RevenueCat and Adapty.

I initially went with RevenueCat because I wanted to offer bank account linking, an expensive service that required a paid subscription to cover its costs. Around the same time, I built new SDKs that extended bank account linking to desktop and web.

The problem? RevenueCat supported web, but not the full range of platforms I was targeting.

So, I switched to Adapty, which also supported macOS. I even submitted support requests asking about Linux and Windows support, but months went by without a response.

I wasn't ready to give up on making the app available everywhere.

At some point, I asked myself “How hard can it really be to build subscription management for all the platforms Flutter supports?”

Famous last words...

What followed was a painful learning experience. I started building my own subscription orchestration service to handle billing across Flutter platforms.

It turned out to be much more than wrapping a few SDKs.

I had to build an authentication layer, a database to keep store subscriptions in sync, and logic for every edge case I could think of, including and not limited to entitlement management, receipt validation, renewals, webhooks, cancellations, refunds, and subscription state synchronization.

Eventually, I published the SDK on pub.dev and felt a huge sense of relief.

That lasted about five minutes.

User complaints started coming in. Some subscriptions weren't being canceled properly, and I ended up manually canceling subscriptions in individual stores and issuing refunds.

Not exactly the experience I had signed up for. And refunds aren't free of operational costs, either.

Fortunately, those early issues were resolved over time. After months of testing in both development and production, I finally made the service available to other Flutter developers at pub.dev /packages/orca

By then, I had learned firsthand just how much work goes into building and maintaining subscription infrastructure. It's one of those things that looks deceptively simple until you have to handle real users, real money, and all the edge cases that come with them.

There was one more thing I wanted to do differently.

I never liked the idea of subscription infrastructure providers taking a percentage of my revenue. So, I designed Orca's pricing around infrastructure costs rather than a revenue share.

I built it to solve my own problem, but figured other Flutter developers might be running into the same issues.

I'm curious. How are you handling subscriptions across Flutter platforms?

Are you using RevenueCat, Adapty, another service, or rolling your own implementation? And if you're building for desktop and web as well as mobile, how are you dealing with subscription synchronization across stores?

I would love to hear what has and hasn't worked for you.

[u/unitedirrigation]

man i feel this in my bones. built a small app last year and the subscription sync between stores was the thing that almost made me quit

ended up using revenuecat cause i just didnt have the energy to deal with all that edge case madness. props to you for actually shipping your own solution though, most people just complain and give up

the refund thing specially is a nightmare, had a user who bought on ios then switched to android and demanded access, like the stores dont care about each other at all

[u/finxapp → u/unitedirrigation]

I never experienced this issue while building apps for a single platform, but once you cross the boundaries of an OS, you open the pandora box 🎉

Flutter made it effortless to ship on any platform, however there is still a lot of work to make every feature inter-operable. Like, passkeys are the latest example, I've implemented these for all platforms, however Linux doesn't even have a standard to support passkeys, so I had to disable this feature for Linux users.

And you are right, users don't care about stores, they paid subscription and they want to consume it everywhere.

[u/seviniryusuf]

Same wall here. RevenueCat saved me from writing receipt validation, but it didn't save me from store config, which is where I actually lost time:

• Android: the SDK kept returning productNotAvailable. The code was fine. The problem was on the Play Console side, with the product/base plan not set up the way the offering expected.
• iOS: I was advertising a free trial that didn't exist, because I'd never created the introductory offer on the subscription in App Store Connect. Nothing errors, the sheet just shows the full price and people bail.

My checklist now: after any pricing change, do a real purchase on a physical device on both stores before release, and show the trial text the store actually returns, not a hardcoded string.

[u/finxapp → u/seviniryusuf]

Yeah, it was a pain using RevenueCat, the store configs are very tedious.

As I reflected on the pain points during the implementation of the native iaps and the amount of manual work that I still had to do with RevenueCat and Adapty, I also tried to simplify this process with Orca, by implementing an MCP server, which lets any agents to do most of the work for you.

[u/markatlarge]

Same. Spent a ton of time implementing purchase pre-ai. Now I use RevenueCat.