InAppBilling

[dhindrik]

@jamesmontemagno had a project/plugin for InAppBilling, https://github.com/jamesmontemagno/InAppBillingPlugin, which he has now archived. I think that is a really important part for the .NET MAUI Community. The best would be official support for a project like that. But I guess we never will get that. But when I discussed it with my friend and colleague @EngstromJimmy, he said something good, "that should be part of Community Toolkit". And I agree with that! What do you think?

[rokmeglic71]

While waiting, you can check following resources:

1. Somebody wrote some code for listeners - Android only
2. Maui In-AppBilling advice under Q&A
3. Stackoverflow - How to set up google play console subscriptions in Maui app
4. Reddit - I need to manage native in app subscriptions
5. Sample Payment App with Prism.MAUI

[jfversluis]

Allow me to answer this in a bit more detail than you probably anticipated, but I just want to bring a little clarity into why we won't just say yes to doing this, but I also don't want you to be disappointed if we say no and you don't understand why 😄

While I always welcome a great idea for the Toolkit (and you know me, I like to say "yes" a lot...) I do think we also need to realize that this project is still ran by community members. There is a group of core maintainers that stuck around over the years, but other also have come and gone. Which is a good thing, a healthy thing and I'm grateful for each and everyone of those people, but the core maintainers group is and has always been a handful of people. And since its "just" community work, next to our daily jobs and lives, we will sometimes have more time and sometimes have less time to spend on a project like this.

So, while great ideas are always coming in for features big and small (and I definitely think this is a bigger one), its hard, if not impossible, for us to take in everything. A one-time contribution is relatively easy to make, but what comes after that makes it hard. That code needs to be maintained. What happens a lot of the time is that someone will come in, contribute something amazing and then move on to the next thing. Which is totally fair: thank you for the great work and all the best! But that now presents us (the core maintainers) with a problem: we have a feature that none of us really know much about, that is slowly rotting, using older APIs, people want more features etc. but we took it, so now its on us to maintain at the very least. While there is already a big codebase that we try to maintain. The more features we pick up, without the people sticking around to maintain it, the bigger the problem will get until we all get overworked and now the whole project will be at risk.

That brings me to: if we were to take something like this into the Toolkit, I think we would want to have some sense of commitment from someone that it will not only be contributed, but that person is also willing to own that piece and keep moving it forward. There is no formal contract or anything, but it would be good that this person would at least realize all of the above and would be willing and able to dedicate some time to help us out with this (or any other feature for that matter).

The community is all of us bringing value to the broader ecosystem, and this is a great way to pay it forward from all the work we might have saved you by just pulling in the Toolkit!

Also see: https://github.com/CommunityToolkit/Maui?tab=readme-ov-file#submitting-a-new-feature

Hope that helps! And... This is in no way an answer on if we would want to do this yes or now 🤪 but my initial reaction is: no, unless someone comes along to indeed own this piece of the Toolkit.

[nodoid]

If someone (say me) wanted to own this part, what would I need to do to own this?

[dhindrik]

I am also open to be an owner of this. But I need to to investigate a bit more how to do it in the best way.

I have done some investigation already and StoreKit2 is a big concern. There are no official MAUI support for that for the moment. There are third-party bindings. But I don't know if we want to use them in a project like this. Or maybe the bindings should be part of this project as will in that case. At least I need to read a bit more about Swift bindings before commiting to adding it to this project.

dotnet/macios#16893

[dhindrik]

Seems like we will have experimental support for swift bindings in .NET 10. dotnet/runtime#95633

[pictos]

It shouldn't be a blocker, it's possible to use the actual tech to binding swift API into maui.

My question is, what are the requirements to test this feature in each platforms? Can you please summarize it?

[dhindrik]

I think @jfversluis is a better person to answer the question.

[dhindrik]

Montemagnos recommendation is to not put it in the toolkit, https://x.com/JamesMontemagno/status/1940443476795232470

[jamesmontemagno]

I would highly recommend against putting this into the toolkit.

1. IAB is EXTREMELY complex
2. Needs constant updates with a bunch of dependencies
3. iOS needs new Swift only APIs which will make this difficult
4. Android is ever changing
5. There is no really good way to streamline the differences between the platforms
6. You are dealing with people money and that has a high level of stress and complexity

I would maybe say it is okay to fork it or start from scratch (probably better) and use all of the new Swift APIs and latest Android libraries, however maybe as a "reference" for how to use the binding libraries and something that is not supported officially. I would love for it to exist somewhere even if people pull the repo into their codebase as a submodule, but it is really complicated.

I have loved working on IAB but dealing and handling people money is another level and has always been high stress for me.

[rokmeglic71]

@jamesmontemagno that means that if somebody will fork your package and update, OK, otherwise RevenutCat is the only way to go in MAUI world for now?

I saw your last commit, this means is just a temporal fix until next APIs updates?

[dhindrik]

You can also include the code directly into your project. James' project is just an abstraction, so you can access the underlying APIs from shared code. Because it is a library, it is probably written with a general mindset. If you implement it yourself, you can write it more specifically to your needs.

[sonofsmog]

It’s complex, but it’s not that complex — definitely within reach of a solo dev using Claude/ChatGPT/Gemini. For example, I swapped out the old Windows.ApplicationModel.Store namespace to the newer Windows.Services.Store and added subscriptions across all three stores. Works well in production ($$).

The biggest burden isn’t the code, it’s navigating the labyrinth of requirements for each platform’s In-App Purchase, and then keeping docs up to date. Honestly, I’d just let AI help with the doc refresh.

Because of that, I’m not sure it’s a good fit for the Community Toolkit. It feels more like a standalone library (where I’d happily contribute or even publish my fork). The Toolkit might get bogged down in the store-specific policy churn.

[rokmeglic71]

@sonofsmog I think sharging your fork is always good as I can see there is a need for this. Maybe add some of your consulting option on top of that ($$).