There have been multiple threads and questions about IAP, and “it’s our top priority” seems to have turned into “maybe a closed beta in October” and who knows how long after that.
Fact: you cannot “just use Stripe” in the USA if you want users to pay for your iOS app. If you charge users for your app, you must offer IAP.
The only way out of supporting IAP is if you’re a “reader app” like Spotify/Kindle or selling non-digital products outside of the app (Amazon).
We will be paying Bubble for mobile apps long before IAP is supported by Bubble.
Other than “give up on Bubble” or “use a web wrapper” what are the options? Is it possible to build IAP functions in a plugin?
It could be possible I guess if you have access to also closed Beta mobile plugin editor… But I think you could wait for Bubble to release it too. In most case, when they say a specific month for Closed beta… you can expect this will be near this month. When they say something like At the end of 2025… you can expect some delay. However, you will probably be not part of closed beta so I would not expect to be available as beta to everyone before end of november.
my understanding is that libraries with native code are required for IAP. I remember another topic saying that it’s currently not possible to install libraries with the plugin editor. Even if you could install it you would require a custom build of the bubbleGo app to include the native code of the library in order to test.
I personally will pause my subscription until IAP are ready. There is no reason for me to have an app live that can’t be monetized. I’m afraid that ‘late summer’ will become late winter. So I will keep an eye on this forum and continue when IAP are ready.
Given what’s possible with plugins, it doesn’t look like that road leads anywhere. I’m going to proceed with “free” and sell premium support. I like Bubble way too much to look for the exit any time soon.
Hi,
first of all, thank you so much for raising the topic, i’m in the same situation.
A question for you, as you mentioned: what you mean exactly with “reading app”? and in case, how would the process and solution differ in that case?
I’m asking you because i might fall in this case. I can say the app i’m building is something like an app podcast, imagine spotify but only with podcast. The app would be free to download, but to listed to podcasts, you have to pay. Differently from Spotify, would be that users wont’ pay a monthly subscription, but a time-limited access (e.g. access to all content for 3 days, 1 week, 2 weeks, etc)
is that the case you were referring to? you know a solution for that?
You need in app payment. In general, if you want to make money with your mobile app, Bubble is not ready. Maybe end of year but to get in app payment right and easy is hard. Bubble will notice it and will delay full delivery. There is a reason there are companies like RevenueCat. But also in order to use RevenueCat, Bubble first need to add in app payment and then the api calls to RevenueCat.
the other solution might be that Bubble will deliver a bare minimum and then users need to do all the little details themselves. Doable for a technical person, not that easy for non coders.
So if you really need in app payment, look at for instance FlutterFlow (I think one of the only true NoCode mobile app builders), or build a Bubble web app add a mobile wrapper like build natively and have in app payment running in under a day. Another option is wait for 6-9 months to have a full fledged in app payment system in Bubble mobile. And start selling from that moment on.
ok, thank you for the explanation.
But what i don’t get is that i’m trying to create something that apparently works quite similarly to existing services like spotify, or babbel - where the payment is done in a webpage, and then you see content on the app according to the plan - if you have purchased it or not.
Why should work for them and not for me? Tell me in case i’m missing some points
If you can make a case that your app is just a means of viewing a main service that you offer online via various channels it might be just fine to use something like stripe. If you app IS the product and the app is selling digital goods that only live or can be obtained from the app it is a different story.
Uhm well, i didn’t plan to have a web version of it, but if it might make it work in terms of payment, i would def go that way. the backend is the same, so it won’t take somuch effort for me to kinda replicate what i have in the app on the web. Guess i’ll try.
but what do you mean exactly when you say “make a case”?
Apple is strict. They even can say “we have already enough of those kind of apps so we will not grant you access to our store”. Think about epic story with Fortnite. Apple believed they should pay 30% of sales in the app, epic said, we are a platform and our users can login to any kind of platform with their account so we sell digital goods via the web.
so there are black and white cases such as e-commerce selling clothes, they can use web payments. But mobile only game apps that sell digital goods in app must go through the Apple payment flow. And then there are grey areas where either party thinks they are right.
