- 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?
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.