- Welcome to another episode at Empower Apps. I'm your host, Leo Dion. Today I'm joined by a Andy Boedo from RevenueCat. Hey Andy. Thank you so much for coming on. - Thank you for having me. I'm excited to be here. - Yeah, we had Ariel on from Appfigures and we talked about a lot of the new stuff as far as the App Store is concerned when it comes to posting, but a big part of the App Store is actually making some money.
So it's really good to have you on and talk about all the word new stuff coming out with StoreKit, things like that. First of all, in the last episode we talked about all the proposed settlements that have been going on and changes to the App Store for legal reasons. How has that affected the App Store for developers and what kinda updates are you looking at having to make in with RevenueCat when it comes to that stuff? - So the recent changes have been interesting.
They have not been dramatic in any way so far. So I think like the more exciting part is just the trend where it seems like Apple is very slowly starting to give developers a few more options. And it's kind of like, it's mostly by force, right? Because they all started with like lawsuits or investigation in different governments, but it's still allowing for a bit more flexibility. Like for example, reader apps can now link you to their website which makes sense. - Yeah, that's a big deal.
- Before that you just had like this very nonsensical experience, if you like started like the Netflix app and Netflix couldn't link you to their website, they could just say, "Hey, go visit netflix.com." So it introduces a bit more sanity and that kind of thing. And then the proposed settlement, it's not what people wanted, I think.
- Yeah. - And it only helps like clarifications and very minor tweaks, and like it rolls back like a new rule that was hard to enforce to begin with, but there's a clear trend, right? And the other day there was this thing with South Korea where the government is sort of forcing Apple to allow for essentially other App Store. So like they're forcing Apple to not force developers into using exclusively App Store in app purchases.
That one might be the more interesting one because if other governments use that as a base, like if the UE goes with that in there and like bases off of that and enforces App Stores to come along, then that's gonna be a bigger change. And it'll allow for developer flexibility, and I'm still somewhat concerned about the consumer experience. - Yeah. Yeah. Same here. I don't wanna get too off topic.
I'm a little bit worried that Apple has put them self in a position to where they have to wait for like a government to tell them what to do. - Yeah. - As opposed to them doing it by themselves, because what it ends up doing is, like you said, it can ruin the consumer experience if it's by edict. I feel like as opposed to just Apple being like, "Hey", I'm not a big fan of like alternate App Stores, I don't think that's gonna fix the problems that we're having. - Absolutely.
- It's never gonna be an awkward implement. It's always gonna be an awkward implementation if it becomes through legal edict. And I feel like, if Apple had nipped this in the butt earlier, we wouldn't be in the position we're in and it's kind of unfortunate. - And there's still time.
It would be great if Apple just went ahead and did like self regulation, they just revised the rules like very dramatically, but it seems like they're just for now doing the absolute, like bare minimum that they can to comply. - Right. - And if it comes by, like if it comes by big regulation, then that's gonna probably not be great. Like if you look at the story with, for example, in Windows and in the world of games, we have like multiple stores, but each game developer has their own store.
And it just leads to a very awkward experience. - Right. - They have like so many stores installed and they're not great at user experience either. So I'm hoping that that won't happen, but it might. - Yeah. Right, right. So I guess I wanna ask the topic, and this is something I've kind of faced. Is making money outside of the App Store when it comes to your app. So for instance, I have an app where it's a Apple watch app and there's a web component to it.
And so I've actually for better user experience, I've decided that I'm better off just going through Stripe instead of trying to make it In-App purchase cause I don't think it great experience to do In-App purchase on the watch when there's like a web dashboard where most of those features are in. Are there any other like instances where you think, yeah, it's not really worth doing an In-App purchase and just going outside of the App Store when you can, I guess.
- I think it really depends on how advanced your app is, what the product match grid fit situation is because like anytime you go, StoreKit is, it takes work to implement, but it kind of takes more work to do something else on your side. Because if you go with Stripe, for example, you have to think about the taxes, you have to provide a way to manage descriptions, you have to like provide support.
There's a lot that apple is, for better or for worse, they're doing and they're quite refined at doing. So it kind of really depend, I would say if you're well past a 100K in annual revenue, you have some things established, and you have probably like a team at this point. Like at that point, then you can probably start allocating some resources into having something outside of the App Store.
But for the vast majority of developers, if particularly in the developers, if you have a small team, it's a better idea to focus as much of your resources into providing the best app you can. And I think if you have a clear case where In-App purchases are not just providing a great UX, like what you mentioned on the watch. - Great. - Then perhaps that's a great use case for actually going outside.
But if not, then you try and focus as much of your resources into making a valuable app and into making sure that the thing that you're proposing as a purchase provides as much value as you can. And then like once that happens and you're sure that your users understand the value, there's a clear fit there, and things are a bit more established, then at that point you can start thinking about, okay, how can we expand revenue?
But the other thing to keep in mind is that Apple has done a remarkable job at making it easy to purchase and make and convincing users to make purchases. And so the value that you get out of that is that people are more inclined to make a purchase through the Apple system than going through like even Stripe, which is very very nice.
But it's still like they just make it so seamless that you won't get that much more like new traffic and new purchases coming in, as opposed to like the amount of work that you have to put in to actually go through another one. You know what I mean? - Right, right. And I think too, like it makes clear sense when it's, like you said, the seamless experience on the iPhone. Where it's like, that's where you're making a purchase.
But, yeah, if you have outside experiences and you can be willing to support, like doing all the handholding of trying to implement it in Stripe or whatever other service you want to do. Yeah. It might make sense to go outside of that, assuming like, burn the bridges of app review. Yeah. You're pretty much good to go. So In-App purchases with subscriptions still like the preferred way of making money in the App Store right now.
Cause I know Apple certainly tried to push that model as far as like iOS apps are concerned. - So I guess the answer like with all things is, it depends. In-App purchases with subscriptions don't fit every app out there, but they fit a remarkable amount. So the reason is like if you're making In-App purchase with a subscription and you get like recurring revenue, it's very nice for you because you get this stability of having like, stable revenue and hopefully growing revenue.
But on the other hand, like there's the expectation from the user that you're going to continue to increase the value of the product. So if you have something that you wanna like have one product that like one tool, that's one thing and you don't wanna ever touch it again, or you don't wanna like continue to work on it, then perhaps a subscription won't be the best match because it will also not match what the user is doing.
They're constantly paying for something as a service, then you should ask a service, try and like improve upon it. So if you're doing like a metronome for guitar and you have no plans of ever modifying it after the initial implementation that maybe a subscription isn't the best fit, but there are clear cases where like if you're working for example on a weather app, and you're using an external API and you have to (indistinct). - Yeah, there you go. All right.
- Then that's a clear no-brainer like you have fixed costs. And so you should try and like use subscriptions or something that will meet those costs as well. But they have a lot of advantages versus like, making a one time purchase in the App Store. So you have to like pay before you download then for the user, that's high very a friction, they don't really know what they're getting before they actually- - Right. - Make a purchase.
And if you go with ads, then they always diminish the user experience. There's just no way around it. Like you're always sacrificing a bit of the app experience in order to put the ads in. So versus, like, I would say for most apps, it'll probably be better to go with In-Apps with subscriptions as long as, well, you also planning on providing more value once you put the app out there.
- Yeah. Like for instance I have a NAC app that I want to convert over to subscription because I wanna continue building on it and I went with the simplest and easiest approach was just charge a price. But like part of that problem is there's no way to do trials or anything like that without going with some sort of In-App purchase model instead.
- Yeah. - So what are some other mistakes that you can think of that developers make when they put their app in the App Store as far as how they do their In-App purchases or how they monetize their app? - I think I've seen a few developers fall into some traps.
Like for example, assuming that, for example, like you have an app that's just turning out, but assuming that analytics and A/B testing will get you all the information you need, if you're small, that's very very unlikely to happen because you just won't have statistical significance for anything. - Right. - You just have anecdotal data. But it's in, folks try to like plug in A/B tests and you have like 1000 users. That's not gonna give you much.
And particularly like even when I used to work at Elevate, like even for a lot of our A/B tests, like we wouldn't get strong enough signals unless something was happening at the very, very start of the experience. And this was with a pretty established app with which had like 40, 50 million users. So it is just hard to get like any value out of analytics when you're just starting out. But a lot of folks dedicate a lot of time into it.
So that's one, I'd say another big one is kind of have the same spirit, overly focusing on going for too many platforms on day one. So for example, I've seen like folks who start out with something like, for example, they use fluter and because if you use fluter you also get the ability to deploy on Android as well and you could go for iPad, you can even go for Mac OS right now. So they decide to just go for all of them on day one.
And that kind of like, that means that you have to maintain a broader scope of things. Right? - Right. - You have to make sure that the experience works for everyone, and there's like such a wide set of devices that you have to test, and like that just takes away from the time that you spent like actually building the features.
So that I would say like, is the other trap is not focusing on just, I think in my experience it's better to just focus on one place, making sure that the experience is good there, that the value is good there and not another trap would be, like, making sure that the thing you wanna sell, the part where you want to do the cutoff for your app, that is valuable. Because you might, and it's more art than science. But what you have to decide which part of your app you're gonna make purchasable.
Sometimes you can go too far and make something like, make the entire app be behind a paywall, and then people don't actually understand what the value of the app is. You can go to the other extreme and just like put only stuff that very very few people actually care about behind a paywall, and then you won't like, most users will never pay for it.
So that's the kind of thing that you need to focus on understanding, especially if you're early on and you're trying out In-App purchases, just try and understand exactly what the value of your app is, focus on that and making it as valuable as possible and talk to users, definitely always talk to users, try to understand why they want the app and what they want out of it.
And then you can like start understanding where the paywall should be, what should be for free, or what shouldn't be, if you want to go with that model, and where you make the cutoffs. And particularly like, I guess all in all it just translates into focus and understand your product and the value of price to users. And then you can slowly expand. - So how do you contact your users if you're going through the App Store? - Well, okay.
So the settlement says that you can officially email them as long as they have an email account. Or if you're going through sign in with Apple, then you can go through those paths.
And then I guess like one of the possibly, I'd say underrated way of doing things is like, if you have an app, and that app is focusing on like a very specific need, try and find like forums online, try to find the people whose need you're solving, post it there, get those users to talk about those potential and maybe actual users to talk about it, to tell you about the app, to tell you about other apps in the market. But that's one way. - That's super powerful.
Yeah. The other thing I was gonna say- - It's very a little cost. Right? - Right. The other thing I was gonna say is like, one of the first things you should do is start a mailing list. - Yeah. - Before you even have an app in the App Store. Like especially if you want to start like a wait list or something like that. That's a great way to gauge interest in that app before it's even out.
Obviously give them a little bit of a taste about what this app does, what it might look like, but like yeah, that's something I've worked on is like starting a mailing list pretty easily and getting that started. - Absolutely.
- And then the other thing is, I wanted to ask is, regarding a paywall, I guess like you said, kind of like talk to the users and see what values, what features they like the most and they value the most and then kind of using that as a gauge of what to put behind the paywall. Right? - Yeah, absolutely. And you have to like revise your paywall a lot in order to like, it can be very easy to have the paywall not actually convey the value. - All right.
- It's very hard to tell users like, oh, here's the things that you get. And then so sometimes like, for example, at Elevate we had this problem and it was very clear or for a while that folks didn't really know what the pro subscription would grant. And so we started like trying things out. We ended up like adding pro badges to a lot of places in the app so that you could actually see, hey, here's what you would get if you were pro.
Cause otherwise like you might have something there that if, unless somebody actually like taps it, they won't actually see that it's part of a paywall. And it's not rather part of a subscription. So- - Right. - I guess like, making sure that the paywall is conveying everything that it should, but also making sure that the app is something like, without sacrificing user experience, it's telling you, "Hey, here are the things that you're missing out on." - Right, right.
So I wanna step back a little bit and get into some of the jargon that Apple users and commonly a lot of stores use as far as like the API is concerned when it comes to the App Store. I don't know if you wanna start with the word, that jargon, that you feel is more important or if I should start. Which of us should go first? - I can go. - Yeah, go for it. - So the first very basic thing is like, what's an In-App purchase, like what qualifies, and that'll be always for digital goods.
So you can't make an In-App purchase for a gym subscription, for example, because the gym is a physical thing. You can make for an in-home video based gym. But if you have like a physical gym that you go for, that's not an In-App purchase. That goes to a different system, goes through way smaller fees. So if you're not trying to sell digital goods, then that's not In-App purchase. And for all digital goods you should be doing app purchase.
- Yeah. - And then, so the way that that reflects is well, you have the product conceptually. You create this product in Apple land that would be an App Store connect. Could be a Google player for Android. You create this product, and that product has a unique identifier, and that product identifier is very important to your app.
So the idea is that you create your product in App Store connect and then you use that product identifier within your app to fetch an instance self escape product in the case of Apple, which will have all the information that you need. And that information is very specific to the user. So an SK product will have, for example, the price in the local currency for the user, it could have a localized description as well.
So you have like a user who speaks Spanish, or they're using a Spanish speaking store, you can have a description that's in Spanish for them. So that's kind of like the product in App Store connect, product identifier, and the SK product for just like what you use in the app. And that's the thing that you purchase, in SK products.
- Okay. - And when you make a purchase, that gets reflected on the receipt, and the receipt is a very like, that's probably one of the more interesting or valuable and complicated things in StoreKit land where the receipt is a file in the local file system in the device that is both the full transaction history for the user, so you make a purchase, it'll be reflected on the receipt. You make a purchase for a different thing, it'll be reflected on the same receipt.
And you can decode it as asn.one encoded thing. It's horrible to decode, but you can decode it. - I've actually done it and it's sort of clear cause one of the things they talk about is like, I think there pretty much against doing like local validation on it right now. - Yes. - So you had to do it. You have to like set up your own little server and of set up a server and swift to do it. And then yeah, you can like JSON decode it, and then from there you could look at that purchase history.
Right? - Absolutely. And so that's kind of the content of the receipt, but thing of about the receipt is that the thing that you get on device, first of all, if it's on device, you can't really trust it and that's the main reason that they tell you not to actually parse it yourself. - Exactly. - You can parse it. You can't trust that whatever's in the device is valid. Right? - Right. - And the receipt itself is also the token that you use to get the most updated version of that same history.
The thing is like the device might not know that you purchased something, like if you have an iPhone, an iPad, the iPad might not be aware that you just made a purchase on the iPhone, for example. - Right. - Right? So in order to get that information, you grab that same receipt and you send it over to Apple's, verify receipt service, and they will return, they will decode it and they will actually return a JSON with the full transaction history.
- Okay. And so that's the one that's guaranteed to be up to date. So that's kind of like the receipt in itself, It's at the same time, a version of the transaction history, which may or may not be trustable, and may or may not be up to date. - Right. - And also the token that you use to send it to Apple in order to get the full, trusted transaction history.
- And that like purchase, like when I was talking about that Mac app, like I look at your, you had a really good tutorial on RevenueCat about like converting over from app purchase to In-App purchase. And I'll post the link of that, the show notes. Cause I have like that Mac app where I want to take it from just a regular App Store purchase and put it to an App Store subscription.
And like that transaction history, we'll even have like, if you did purchase the app through the App Store, like a full on like regular app purchase, it'll have all that. So you can like easily, you can make up all sorts of rules about what, like you said, that's where you make up the rules about the paywall. Is like you look at the receipt and then okay, I need to disable this feature, this feature, this feature, or enable this feature, this feature, this feature and so on. Is that correct?
- Yeah. And so the one thing that StoreKit doesn't do very well is that mapping of, they mapping directly the products to the conceptual thing that you unlock. And that can lead to problems because like, if you, for example, if you wanna have different price points, or if you wanna have like different combinations of the thing that you unlock, like the part of your app that you unlock and the products that actually unlock it, like it's kind of tricky.
You have to like have somewhere like this mapping. And if you have like, if you're doing it on device, you have to have like either a reference to all the product identifiers, or a way to ask the backend for the product identifiers and a way to enable and disable parts of the app based on that. - Yeah. And I guess that's where you guys come in, right. Is kind of help help manage that.
- That is indeed one of the things that we do is just map that to something that's closer to the app experience where you have the concept of entitlements, which would map to like the thing that you unlock. - Right. - And it ties to the product identifiers, but it's not a one-to-one match so that you can mix and match and do whatever you need and have the app be independent of that. - Was there anything else as far as jargon was concerned before I jump into StoreKit two.
- I think that mostly covers the main concepts, I think. - Okay. So let's get into it then. What were the big updates this June when it comes to the StoreKit? - So StoreKit two does kind of like a big rewrite. And so the same, like, because it's same reasons that it's doing a big rewrite, it doesn't add that much on top because like that's already a lot of work. But they like, first of all, provide a whole new set of APIs. They're all swift based.
So there's no objective C compatibility with StoreKit two. - Another API that is not available on objective C. I hopefully developers have gotten the hint. But yeah. - Well, we certainly got the hint and we migrated at the entire RevenueCat as DK to swift in the past couple months. So yeah, I mean, it's a clear trend and they're even like, they actually went full on and used 5.5 for everything. - So you got all the async await stuff in there. Yeah, that makes sense. - Exactly.
And does make for a much, much nicer API. So some of the things that they cleaned out, for example, like if you're old school StoreKit one, which require you to go through a very awkward flow where for example for, in order to- - You probably used to have to set up a delegate, like for instance, which is pretty old. Yeah. - Exactly. So you wanna get the product, you have to ask for the products and then have a delegate for the answers.
You want to get the transactions, you have to observe the queue and we wait for the queue to tell you if something's going on. - Yeah. - So now we have more same things where you can just, you know, async await, like wait for products to come back and then you can take your flow. - Yeah. - I wait for the purchase to go through. You have an async stream for updates in the purchases. And the transactions for the user. So it is much nicer when it comes to the API.
It's really like, it does involve less work when it comes to the API. They also added some more server notifications. So you used to have like a very small subset of notifications that did not cover a lot of cases. - Okay. - So they kind of split it up into- - We're talking like web hooks. Right? - Exactly. - Okay. - Exactly. So you have more cases that trigger a notification, and within that notifications will have sub states.
So if you combine the actual notification with the sub state, you cover like most flows, which did not used to be a thing. And so for context on why that's a big deal in the first place, before in StoreKit one, in order to actually provide a subscription, you need to constantly pull Apple servers to check that subscriptions have renewed. If you have, you're close to the date where the subscription will expire, you had to start pulling Apple, hey, has this user made another purchase?
Have they renewed? Have they renewed? And so you had web hooks but they didn't cover a lot of cases. So you wouldn't have no way around the pulling. And now with these web hooks, they actually cover enough cases that you might still be need to do a little pulling, but much less. So that's a big change. Another big change is the change in the receipt.
So, you know how I said that you had like this full transaction history on device and I send that one receipt, they entirely overhaul that, and while you still have that, is still available in StoreKit one, and you can still fetch the receipt and you make a purchase in StoreKit two. Will still be reflected on to that receipt. But I have a new format, which is the JSON word tokens. So the idea is it's much more modern. It's still very secure, but it's more sane.
You can actually get the stuff from- - (indistinct) to store that information. - Exactly. And each purchase will be reflected in a transaction there. And from there on like instead of like going to the old verify receipt with the token that you used to do in StoreKit one.
You now have two APIs, one is for the full transaction history, which is now paginated, which is much better if you have, particularly if you have a lot of purchases for a single user, if somebody has been a subscriber for a long time, that used to be like super slow and it's to be like, huge receipt. It was awful. - Okay. So now they have imaginative history if needed, but you also have a separate API for just getting the latest information for a given user. - Oh, good good.
Okay. That's what I was gonna ask. Is like, can you like filter the receipt accordingly, but it sounds like you can just get the latest. Okay. - Yeah. They also have, well, TV day on how well that works because I've had some issues in Sandbox, but they have like the ability now from like on device, you should be able to verify transactions with no code. Just ask and StoreKit to verify it for you. So when you make a purchase, StoreKit will tell you whether it's verified.
Like in theory you should be able to trust the device now which you did not have that ability in StoreKit one. - Okay. - Again, TBD on how well that works, because as of a recording in Sandbox it doesn't work. - Are you thinking it's gonna work in a couple months? - I mean, I expect it to, but I expect them to eventually figure out the bugs. It would ideally happen before getting stuff to production, but history says that it might not.
But sooner or later they'll have this thing that you can actually trust on device and it should be kept somewhat up to date. So that's a huge new thing from StoreKit two which makes it saner. You still need a server in a number of situations. So if you wanna do, for example, something multi-platform, then you have no way around.
If you wanna have, like for example, Stripe payments, as well as the IOS side, then you don't have a choice because like you need somewhere to actually be able to verify this Stripe, and instruct transactions in the same way like if you have something in Android or if you have an account system, there are still a lot of reasons why you would need servers, but if you have a very simple setup now, StoreKit two might actually get you a lot more value than StoreKit one did.
Assuming that of course you can actually target, IOS 15 plus in the corresponding, OS releases because it needs with 5.5. For now it just like it won't be deployed on any earlier ROI versions. - Well yeah, I wouldn't imagine StoreKit two. Even if they do add back growth's compatibility to async await, I can't imagine StoreKit two it's gonna be available on 14 and lower. So yeah. - Yeah. I do. I don't think that'll be the case.
So if you wanna support IOS 14 as of today, same as thing to keep using StoreKit one and maybe integrate StoreKit two where it makes sense. - Okay. - Cause there are a couple of new things I recall, like for example, with StoreKit two you can also bring up this managed subscriptions model. - Okay. - From your app. So this could be like in StoreKit one days, you can go into your device and go into settings, App Store, subscriptions, and then you can manage your subscription.
- Now it's all In-App. - Exactly. - That's awesome. - So it's just within the app, which is really cool. And then they have this refund API. - Yep, yep. - Which sounds better than it is. It's an API to begin a refund request. - Yes. So you can't actually grant a refund, but you can have your user start the request from the app, and it ties in with another API, which is the consumption API, which essentially you use in order to help the App Store team figure out whether a refund is applicable.
So the idea is that you use the consumption API to tell Apple, hey, here's how the user has used this purchase if they have used it at all. So you provide a lot of metadata of like time used for the app and the cost of the purchase. And like a lot of things here and there. And then you call the begin refund request API, and with the two, the Apple App Store team should be able to make a more informed decision of whether a refund applies for the user.
So you can't refund the user yourself, you can make it slightly easier for them to do it. - So, is Apple the only one that can make that decision, or is it like, I thought it was Apple makes the decision and then you have that option to then give the user a refund or not. Which way is it? - It's up to Apple. It's up to Apple. - Completely up to Apple. - Yep. - Okay okay. - At least that's to my knowledge. - Okay. All right. Well, that's fun.
- It's kind of problematic because like for the last majority of developers out there, they just want to be able to refund because like- - Yeah. I agree, I agree. Yeah. I don't think you both developers are in a position of being penny pinchers when it comes to that kind of stuff. It's like if the user wants a refund, it's not worth burning bridges on that one. Yeah, totally agree.
- Absolutely. - So I wanted to ask, what do you think are some major differences as far as the approach that dev should make whether they're indie or large company when it comes to approaching the App Store? - I think it goes back to what I was saying earlier. Like if you're a smaller team, you need to make sure that you're using your resources as effectively as possible.
And to that spirit, it's probably, just try and focus on understanding your products and the value, and seeing like what merits being purchased and what people are actually willing to pay money for. - Yeah. - And if you're a larger team, of course that's still very important, but you can also like, if you have a larger app and then more users, you can actually start trying some things.
You can have like more advanced analytics that will actually provide you with a signal or whether like the price is fair. If you have a lot of traffic, if you have a lot of users, you might see some interesting stuff. Like for example, if you're trying out prices, you might find that you were stuck in a local maximum, but if you try like pricing it up even further, sometimes the amount of people purchasing jumps up a lot.
So if you have a larger team, you can try that kind of stuff out, and try expanding to more platforms. Like for example you can start seeing like, does it make sense to add iPad? And given that we have iPad, does it make sense to go with a full Mac app. And stuff like that. And if you're smaller, you maybe don't have the bandwidth for that, but you actually have, like you have a bit more agility when it comes to other stuff.
Like for example, smaller teams tend to be better at adopting like new APIs or this new thing here and there that actually like might get you a solid feature, which might get you some attention here and there. Or you might like try some... You can experiment a bit more with what the app is when you're smaller. And when you're bigger, you can experiment a bit more on like the finer touches on the app. And sometimes that also has like a very huge impact on monetization. - Yeah, yeah.
That makes a lot of sense. So before we close out, I wanted to ask, where do you see the future of the App Store as far as developers? Like what would you imagine WDC 2022? Or like, what features are they gonna be adding? With legal changes or not, like where do you think things are headed?
- So it looks like, I don't think like maybe not for WDC 2022, but there's definitely a trend for either apple to ease up a bit more on their rules, or somebody will just come in and force them to create a new... To allow for more App Stores. I don't know if like, if that happens, I don't know how impactful it it'll be because like one thing to keep in mind is that, this has been a thing in Android for a long time.
Like Android does have the Amazon store, and it wasn't like it gets fairly little traffic. - Yeah. - Maybe now with Windows 11 it'll get a bit more about- - Oh, cause you could put that Android app on Windows. - Yeah. - So we'll see how that goes, but, Android has had like a easier rules on everything for a while, and it hasn't had that big of an effect on the actual monetization. So we'll see, I guess.
- As far as like the API is concerned, where do you think they're headed as far as like StoreKit three would be concerned? - Well, I think like with, you can see some things with StoreKit two, where like they have just, and this is not something that you say often, but it seems like Apple is listening. So it does seem like there's some stuff like for example, they added introductory trial eligibility API which used to be a horrible thing to calculate yourself.
And it still is if you use IOS 14 or less. You have to like compute it yourself and you always have a best guess. And now they added something for it. So I'm hoping that they'll add some more stuff. Like for example, give you the price of the purchase, which is insane that we don't have access to, and give you like some more automation, like for example right now in App Store, the App Store connect API is not very flexible, it doesn't allow you to do many things.
For example you saw how Twitter has now the super follows. - Right. - And they set it up in a that each and every one of them is a single different product in In-App Store connect. And they created so many that I find it a little hard to believe that they did it manually. Maybe some poor intern got that job, but I have to believe there's an API out there, hopefully, and that they'll actually make it available to everyone.
And if that happens, then it'll make a lot of things like a lot easier when it comes to like just maintaining your In-App purchases, being able to validate, being able to test. They put a lot of focus last year on, and this year a little bit too on improving the experience for Sandbox, where like with StoreKit tests and StoreKit config files, you can actually try, you can make purchases in unit tests and test up that way. So I'm hoping that that's the kind of thing that they'll expand upon.
And I'm really not looking for that many new features, mostly just polish, allowing for the price of the transaction to be there, which- - It would be nice. - Still boggles my mind that you can't access allowing for App Store connect to have more valuable API when it comes to In-App purchases. So you can, well, at least get the price from there if not from the app, but you know, you can actually create them and maintain your products hopefully.
And that's the kind of thing that I would like to see them expand upon and add more stuff that doesn't work currently on Sandbox although it often feels like an afterthought. Like I mentioned before, for example, even in StoreKit two full rewrite, as of today, if you make a purchase with StoreKit two, it will always be unverified if you check it with StoreKit two. But if you check the receipt in StoreKit one, it will be there and it will be valid, which is crazy.
- Yeah. - So hopefully they'll work a little more on that developer experience, which has been, I'd say like developer sentiment today is kind of, is not great. And part of it is just that the experience has been really tough for developers. So I'm really hoping that they'll focus a bit more on that and not on adding that many features at least for one year. We'll see how it goes.
So if I'm asking for things, huge one that I ask, please Apple, give us a good way of managing like bulk purchases for businesses. - Is that really a pain in the neck? - It's terrible. - Okay. And I think like with family sharing, there's some of the ground work is already there. So you can now make purchases and have your family participate. But there's no way to do that for a business unless you set them up as a family. - Right, right.
It's a lot of the pain with the App Store is the fact that they started off with it being nothing but like part of the iTunes Store, and then they kind of like built stuff on top of it. I get that feeling sometimes. You know what I mean? - Yeah. It's absolutely, a lot of it is just inheritance from those days I think where developers are still referred to as MZ artists, and some of the places and like, and the whole web object stays and whatever.
So like the original implementation of StoreKit was just piling on to the thing where you purchased a single song, and then while you would purchase a single thing and then like subscriptions, like they just kept piling on without really rethinking the structure. And that's kind of what they did with StoreKit two. It seems like the first time that they stopped and said, okay, can we like rebuilt this in a slightly more sane way. - Right.
- So hopefully that like sets up a base for some of what they'll do in the future. Like, for example, this is something that they're doing for the first time is with the StoreKit two product has a field in it that is the backing value, which is essentially the JSON they get from their backend. - Okay. - They make it available.
And so the thinking there is that, if they add new features that involve a new JSON field, then they'll be able to expose it to you through the backing value in older OS versions. - Oh, wow. Okay. - So that's the first time I've seen them do like very forward thinking. Hopefully that's the kind of thing that we see next year. - Yeah, exactly. Exactly. Was there anything else you wanted to mention before we close out? - I think that's about it for what I had. - Thank you so much for coming on.
I don't wanna interrupt the construction in the background. - Yeah. I'm sorry about that. My neighbor in the building next door just decided that this was the best day to do heavy construction work. - It's not a raging fan who wants to know more about StoreKit, it is construction in the background. Thank you so much, Andy for coming on. Where can people find you online? - Well, you can find me on Twitter at Andres Boedo, that's A-N-D-R-E-S-B-O-E-D-O. And I think that's about it.
I'm not that much of a public person, but happy to answer any questions that people may have of StoreKit, RevenueCat and anything in between. - Yeah. And I'll provide links to that and RevenueCat, and some of the articles on there that have been super helpful to me and have come out of the RevenueCat team. Thank you again. - Thank you. - People can find me on Twitter at Leo G. Dion. My company is Bright Digit.
Please take some time to subscribe and like if you're watching this on YouTube, and if you're subscribe through podcast player of some sort, please post review. I'd love to hear any feedback you have, reach out to me on Twitter. Thank you again. And I look forward to talking to you in the next episode. Bye.