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