Leo chats with Andy Boedo of RevenueCat about the current changes coming to StoreKit 2 as well as the how court decisions will change the way developers interact with the App Store and deal with In-App Purchases.
Show Notes
Guest
Related Episodes
- Episode 26 - App Store Optimization with Ariel Michaeli
- Episode 71 - App Dev Stack with Jordan Morgan
- Episode 97 - Day One App Ideas with Mikaela Caron
- Episode 103 - Learning From Your App Store Competitors with Ariel Mitcheli
- Episode 100 - 100th Episode Spectacular
Related Links
- What's New with StoreKit 2 by Maddie Beyl
- Developer’s Guide to Apple Family Sharing by Andy Boedo
- Converting a Paid iOS App to Subscriptions by Cody Kerns
Show Notes
- How Court Cases will affect the App Store
- Why In-App Purchases and Subscriptions are popular?
- Why go with Apple's payment system vs. outside payment system?
- How to decide what features to cut-off behind your app's paywall?
- What exactly is a receipt in StoreKit?
- What's new in StoreKit2?
- Future of the App Store
Social Media
Email
leo@brightdigit.com
GitHub - @brightdigit
Twitter
BrightDigit - @brightdigit
Leo - @leogdion
Reddit
Leo - /u/leogdion
leo@brightdigit.com
GitHub - @brightdigit
BrightDigit - @brightdigit
Leo - @leogdion
Leo - /u/leogdion
Credits
Music from https://filmmusic.io
"Blippy Trance" by Kevin MacLeod (https://incompetech.com)
License: CC BY (http://creativecommons.org/licenses/by/4.0/)
"Blippy Trance" by Kevin MacLeod (https://incompetech.com)
License: CC BY (http://creativecommons.org/licenses/by/4.0/)
- Tomáš Slíž
- Edward Sanchez
- Steven Lipton
Creators & Guests
What is Empower Apps?
An exploration of Apple business news and technology. We talk about how businesses can use new technology to empower their business and employees, from Leo Dion, founder of BrightDigit.
- 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.