I’ve only done this from a web app - not mobile, but since the webhook works with a backend workflow to update the database, it should be fine, I think.
To manage their subscription, customers can take advantage of the customer portal, this should still be valid(ish) for getting that setup:
You have to check their terms carefully. Simply put, if you sell things that are directly related to the app such as digital items, you have to add the in payment option from apple. If you do not, your app will be rejected.
My advise, take a few hours to really investigate this topic so you are certain what you must do and can do.
Years ago we used a wrapping service from build natively as they have a solid Bubble.io plugin. Took a few hours but then we had our mobile app. Without the need of a second platform or second type of process that we had to learn. And they have so many plugins that you can do alot. For instance payment via RevenueCat.
Hi Nick, in-app payment is THE priority indeed, but do you have intel about Google Admob and Unity Ads plugins? They are essential for mobile apps today… Thanks, Arnaud
This is a very important point to keep in mind - these new changes, allowance to link out to your own external payment, is only allowed for apps offered in the United States! Apps offered in other countries CANNOT use external links for payments.
So for the rest of us outside the U.S., it looks like we still have to play by Apple’s IAP rules.
That brings me to my main question:
Has anyone successfully used RevenueCat for in-app purchases?
If so, any resources or guides to share?
I seriously doubt Bubble will ship native IAP anytime soon lol.
Hi everyone, just chiming in to stay that we are working on a proof of concept for supporting subscriptions through in app purchases (as a first step) and will have an update on a release date in august. This will be a native integration with StoreKit and Google Play Billing, no 3rd party services required. RevenueCat has expressed interest in creating an official plugin for those who would rather user them. Thanks all!
Ok I am slightly confused about the messages I am reading here. My app was approved just fine on Google Play, and I have in-app subscription purchase. So if you want premium features, you would need to purchase the subscription. I have built this with the API connector Stripe Checkout session (according to the great tutorial) and everything works great.
I had no problems launching this in Google Play store. App store, that’s a different story. So now I have an app which is avaible on Google, but not on App store.
Someone here said they had done a workaround having people sign up on the webpage and then just go back to the app. But does Apple actually allow this?
Greatful for any help, just a hobby coder here (check out my family assistant app on perelo.eu )
As a side note, it looks like they are also warning users about using payments that bypass the app store in the EU: Reddit - The heart of the internet
(All of this looks, of course, annoyingly complicated to sort through and set up. I’m just waiting for in-app payments – which I feel like are going to be available in the next month or so – because my app is a hobby app, and all this makes my head hurt).
Hey, great update! The mobile plan is more expensive than web, so IAP is super important to make it affordable. Please keep at it and roll it out soon!
I agree, if the mobile editor plan is more expensive than the web editor then in app purchases is not a feature. It should be launched before the new plans in my opinion.