4 ms·

For small indie devs who's products run on multiple platforms, supporting each platforms native IAP system is a nightmare.

kkarakk 6y ago
if you're a small indie dev supporting multiple platform you're a unicorn. i don't think this is a common usecase. most devs tend to focus on apple initially and then make an android app if they blow up.
- pjmlp 6y ago
  Or given that Apple only has 20% world wide, and the local market happens to be almost exclusively Android, a couple of other smartphones and feature phones, focus on Android first, and iOS only if it ever goes global.
  - akmarinov 6y ago
    If you want to reach people - yes. If you want to make money - Apple’s 20% greatly outspend Android’s users, so you should start there, to verify your product.
    - pjmlp 6y ago
      It is hard to make money with iOS if no one in the country owns Apple devices (note "local market"), if you managed to do such feat please let us know.
      - akmarinov 6y ago
        No one is a bit drastic, don't you think?
        pjmlp 6y ago
        It is called real world, there are plenty of countries with zero Apple devices, and if they happen to be available, only a couple of government level people have them, completely irrelevant for the companies selling their goods to the local population, the market that they actually get their money from. So if you have a formula how the e.g. train service gets money from a selling tickets app for iOS in a country with zero iPhone presence, you have our attention. https://deviceatlas.com/sites/deviceatlas.com/files/images/map-world-os-q1-2019-lrg.png https://deviceatlas.com/sites/deviceatlas.com/files/images/m...
        hardlianotion 6y ago
        Not in the market I operate in.
- camhart 6y ago
  No doubt you start with one, but if you hit on any real vein of success you'll build for other platforms too if it makes sense to. There's no way this is "unicorn" rare. I've done it, and so have my competitors within a short time frame. All are bootstrapped.
manquer 6y ago
I don't think that is too much of a worry. Just like authentication, there will be abstraction libraries that take care of it soon enough, or somebody like stripe will build a SDK and do some consolidated billing management for you.
- camhart 6y ago
  As someone in these shoes, coming from experience, it is a pain. Where it could just be stripe/whatever single payment system you choose, it now has to be an abstraction at best. The abstractions aren't perfect--they limit you to only using the common features across all payment systems you have to support. It absolutely creates a poor user experience for customers. Want to prorate upgrades? Well google play doesn't offer that. Want to allow switching from monthly to annually? Does Apple offer that? Want to issue a partial refund? Want to credit an account? Etc. It goes further, a customer emails and asks "how do I cancel?". Instead of having easy instructions for them, it's now a switch block for all the different IAP solutions. If that customer forgets how they signed up, now they need to dig through all the IAP steps for cancelling. And it's not just Google Play and Apple. There's web, Windows store, amazon app store, android, ios, chrome payments (deprecated), something for linux, etc. While revenuecat seems decent for Google/Apple, it doesn't touch any of the others. I'm not saying it's not possible. All I'm saying is it's a whole lot of extra work just to allow the largest companies in the world to scalp 30% from an indie dev, and force a poor experience down users throats.
  - manquer 6y ago
    it is going to be rough around the edges. Platform pain is already there, react native is a solution to a similar problem. It is no means perfect, you cannot avoid knowing the underlying platform kinks and library limitations Abstractions are not excuse for the underlying payment grab both the vendors are forcing on the devs. Just saying such problems and abstractions are not new and indie devs will get some relief with an abstraction
whakim 6y ago
Having built a cross-platform app recently as a very small team, I want to put in a plug for RevenueCat (https://www.revenuecat.com/ https://www.revenuecat.com/). They abstract away the differences between the Apple/Google APIs so you don't have to worry about dealing with both. You only interface with Revcat. They don't support every last Play Store/App Store API, but I haven't yet found that be an issue. Worth noting that our app uses subscriptions, though, so I don't really know how they do with regular old purchases (I would assume that's supported since it seems to be a simpler case).
- camhart 6y ago
  Thanks for this. I might just do that.
- lukeramsden 6y ago
  Another vouch for RevenueCat, has worked a charm for my project. Saved me a lot of time from not having to learn all the intricacies of both payment system backends.

kkarakk 6y ago

if you're a small indie dev supporting multiple platform you're a unicorn. i don't think this is a common usecase. most devs tend to focus on apple initially and then make an android app if they blow up.

pjmlp 6y ago
Or given that Apple only has 20% world wide, and the local market happens to be almost exclusively Android, a couple of other smartphones and feature phones, focus on Android first, and iOS only if it ever goes global.
- akmarinov 6y ago
  If you want to reach people - yes. If you want to make money - Apple’s 20% greatly outspend Android’s users, so you should start there, to verify your product.
  - pjmlp 6y ago
    It is hard to make money with iOS if no one in the country owns Apple devices (note "local market"), if you managed to do such feat please let us know.
    - akmarinov 6y ago
      No one is a bit drastic, don't you think?
      - pjmlp 6y ago
        It is called real world, there are plenty of countries with zero Apple devices, and if they happen to be available, only a couple of government level people have them, completely irrelevant for the companies selling their goods to the local population, the market that they actually get their money from. So if you have a formula how the e.g. train service gets money from a selling tickets app for iOS in a country with zero iPhone presence, you have our attention. https://deviceatlas.com/sites/deviceatlas.com/files/images/map-world-os-q1-2019-lrg.png https://deviceatlas.com/sites/deviceatlas.com/files/images/m...
      - hardlianotion 6y ago
        Not in the market I operate in.
camhart 6y ago
No doubt you start with one, but if you hit on any real vein of success you'll build for other platforms too if it makes sense to. There's no way this is "unicorn" rare. I've done it, and so have my competitors within a short time frame. All are bootstrapped.

manquer 6y ago

I don't think that is too much of a worry. Just like authentication, there will be abstraction libraries that take care of it soon enough, or somebody like stripe will build a SDK and do some consolidated billing management for you.

camhart 6y ago
As someone in these shoes, coming from experience, it is a pain. Where it could just be stripe/whatever single payment system you choose, it now has to be an abstraction at best. The abstractions aren't perfect--they limit you to only using the common features across all payment systems you have to support. It absolutely creates a poor user experience for customers. Want to prorate upgrades? Well google play doesn't offer that. Want to allow switching from monthly to annually? Does Apple offer that? Want to issue a partial refund? Want to credit an account? Etc. It goes further, a customer emails and asks "how do I cancel?". Instead of having easy instructions for them, it's now a switch block for all the different IAP solutions. If that customer forgets how they signed up, now they need to dig through all the IAP steps for cancelling. And it's not just Google Play and Apple. There's web, Windows store, amazon app store, android, ios, chrome payments (deprecated), something for linux, etc. While revenuecat seems decent for Google/Apple, it doesn't touch any of the others. I'm not saying it's not possible. All I'm saying is it's a whole lot of extra work just to allow the largest companies in the world to scalp 30% from an indie dev, and force a poor experience down users throats.
- manquer 6y ago
  it is going to be rough around the edges. Platform pain is already there, react native is a solution to a similar problem. It is no means perfect, you cannot avoid knowing the underlying platform kinks and library limitations Abstractions are not excuse for the underlying payment grab both the vendors are forcing on the devs. Just saying such problems and abstractions are not new and indie devs will get some relief with an abstraction

whakim 6y ago

Having built a cross-platform app recently as a very small team, I want to put in a plug for RevenueCat (https://www.revenuecat.com/ https://www.revenuecat.com/). They abstract away the differences between the Apple/Google APIs so you don't have to worry about dealing with both. You only interface with Revcat. They don't support every last Play Store/App Store API, but I haven't yet found that be an issue. Worth noting that our app uses subscriptions, though, so I don't really know how they do with regular old purchases (I would assume that's supported since it seems to be a simpler case).

camhart 6y ago
Thanks for this. I might just do that.
lukeramsden 6y ago
Another vouch for RevenueCat, has worked a charm for my project. Saved me a lot of time from not having to learn all the intricacies of both payment system backends.