Hello, everyone. I’m David Bernard, developer advocate revenue cat. And today for this very special WWE. TLDR say that 10 times fast. We’re going to be chatting with Josh Holts, senior software engineer here at revenue. Hey, Josh, Thanks for. Hey, How’s it going? Good, good. Thanks for doing this with me today. Yeah, Thanks for having me. So, as most of you all know, we both work for revenue cat and a lot of the stuff we’re going to talk about today, you don’t even have to worry about because revenue can’t handle that for you, I do think it’s important, though, even as a revenue cat customer to actually understand some of what’s going on behind the scenes, some of the complexity that we take care of. But then there are some new features that we’re actually there’s quite a few new things that we’re talking about today that just are kind of outside revenue cat’s purview. That will be interesting to you. And then we will talk about the things that we do, talk about some of that which won’t apply to revenue cat customers, but then we’ll talk about why it doesn’t apply. And how revenue cat handles it. And so most of you already know. But for those of you who don’t, you know, revenue cat is a subscription app platform. So we have native SDK for app store, Play Store for Android stripe as well as Flutter SDK and other React Native. And so we manage the in-app transactions and then also have pretty sophisticated server side backend so that you don’t have to every year. Apple kind of does a little work for us with some of their slides. This year was no exception. In some of their server API slides. There’s just a complex web of transaction here to update to server notification here. And so we handle all that and then normalize that across all the different platforms. And that’s another thing a lot of people think, oh, you just, you know, make stalking easy. Well, no, but yes, a lot of the value. We also provide is that if you’re working cross-platform, it’s not just the complexity of managing Apple servers, server notifications. Android also has served us ever notifications and then they have different concepts for how Grace periods work, how free trials work. And so we normalize that across your whole stack so that when you’re sending a grace period event to brace to do a win back, you can send trigger the same event and braze from Android stripe, iOS. You know, you don’t have to configure different lifecycles for different platforms because we’re able to normalize that across all the different platforms that you’re going to have your app on. So I could go on for another 10 minutes on revenue, but most of you already use revenue card. So let’s talk about DC. So the first thing I did want to say, just I’m a total Apple fanboy, embarrassingly so. I did get to go to WWE. See this year I’m actually in this picture, you can kind of see a red shirt in the first row after the tables there and it was just an incredible event. Apple does an amazing job and this event really was incredibly special. Being at Apple park, getting to meet with even more Apple engineers. I get talk with people on the Memstore team. They’re just milling around in the inside of Apple park, talking to developers. And they had a whole section of different people from App Store discovery and people from app review were there live to just go talk to. It would have been amazing if Apple could have had 20,000 people there. But whatever, you know, 1,000 or 1,500 were able to go. It it was a very special event and a good reminder with the Developer Center and everything else. Apple is doing that they do genuinely, genuinely care about developers. You know, I have my frustrations, our revenue cap, we have our frustrations. I kind of go on and on and Twitter about those frustrations personally. But at the end of the day, Apple does care about developers and and that the new Developer Center that we got to tour the whole event was just kind of a love letter to developers because we are the heart and soul of their platform. So I’ve kind of gushed a little, little more than intended. Let’s get into the meat of this. So it. We’re going to go through all of the different announcements that are relevant notice to revenue and then a few, as I said, that are as relevant. But store it too right off the bat. Very relevant to all of our customers because of what we’re going to be able to do. So Josh, what is price local and why does it matter to revenue estimates? Yes so we adapted store it to almost as fast as we could try DC last year and it’s super nice. Makes things easier on our end. Now we have to manage post market one and store it to stuff and in store it too. When it was first announced last year it was actually missing this field. So price local for an IP would be like English, French, and that’s what we use to format the actual amount. And Apple does provide a localized price, but sometimes you might want to format the price on your own. So if you’re doing like a yearly subscription and you want to show how much it is, you’d like over divided by 12, you want to displayed in the exact same format as the price that Apple has. So with price local, we actually had that field in store it one, but it was missing in store kit too. So our price formatter was actually using auto locale and store it to which would get it correct maybe most of the time. But it wasn’t correct 100% of the time. So price local will actually also or all these fields actually will get back support on to iOS 15, which is when store kit two was announced. As long as you’re compiling with Xcode 14. So this is something that our users won’t have to adopt themselves because we’ll handle this. But they should see a more consistent. Once this is released next month. 14 Gotcha. And that’s one thing I think a lot of people don’t realize the complexity. You are on the team. I mean, we had quite a few engineers working for the better part of a year to simultaneously convert the entire SDK to Swift and then also manage both circuit two and circuit one seamlessly so that our developers don’t have to think about whether somebody is on. In special case, if somebody is on, I was 15 or I was 16 or 13. And so so you can support even further back. I know, you know, kids apps and there’s so many apps that in a lot of these mass market apps like, you know, Netflix, they want to support as far back as they possibly can because they have a huge customer base. And that yeah, I have an iPad that my kids use that’s like stuck on iOS nine. And it’s so frustrating how many apps I can’t get now and which makes sense. Like we’ve got to move forward. And I just see the tossing into one. Yeah, but it’s great that we’re able to, to support that, that Yeah. Yeah as far back as we can with circuit one and make that seamless for our customers. Yeah and then it is really cool how now with circuit two, Apple has kind of worked ahead to be able to backport some of this stuff. So it’s great that price local is it was 16 only because so many of these that was a surprise to me. Yeah Yeah. Some of these new features end up being I was 16, I was like, Oh geez, you know, it’ll be years before I can depend on it being there. But it seems like Apple’s really doing some great work and being thoughtful about these kind of things, and it’s great to see it in store kit too. So the next thing up is Nick actually had a good question in chat. Good so the price local is not the currency itself. That is actually that’s actually already available to us. But the symbol and locale are two different. So an example would be like if a decimal is formatted with a comma or not. So that’s what the price the price local will determine. So like euro is in euros in like English users has a period where euro is in, let’s say like UK or French I believe is comma. So those are two separate and having. Yeah so it’s like $22, comma, 99. Sense yeah, that makes sense. Yeah, I’m not a currency expert, so I think that’s how it works. We have tests that do this stuff, but I’m like 99% sure. Yeah now, tell me about the server environment. In circuit two. Yeah so server environment is now will come up on a product transaction and it’s also available through another slide that we’ll hit Next. But if you’re looking for the transactions locally on the device, it’ll say if the transaction was purchased on sandbox through Xcode or production watch this one won’t this server environment for this talk of two models won’t affect our customers since we do everything on the API side, this is more of a bit more for the store it to direct developers to see if they do need to query transactions or whatever. Right yeah, that’s one thing you and I were talking about this earlier while we were prepping. It’s pretty cool there since we’re doing a client side and sending that up to our server that you can see that it’s an executed transaction versus a sandbox transaction versus a production correct environment. And having all three of those is great compared to the circuit two API is only going to give you the production environment and sandbox environment. And so it’s a nice little, little bonus and could make some things easier to troubleshoot for our customers. Definitely what about the recent subscription start date? Yeah so this one was a little bit of a surprise for me. I’m not I didn’t know that I wanted this or how it would affect things. But this is a field that will show if the reason subscription is within the last 60 days, which David explained to me early this morning why this is relevant. I don’t know if you want to explain this since your March. Sure Yeah. So before the App Store small developer program came out and up to $1,000,000 a year in proceeds, developers would get a 15% cut Apple in I think 2015, 2016 frame introduced a lower rate on subscription renewals. So for most people in the subscription business, probably, you know, remember this because it’s actually a huge incentive. So you’re so if you’re making over $1,000,000. And you’re not in the App Store small business program, your initial transaction will be at 30% And if it’s a monthly, then every transaction for the first year. So the first would be 11 renewals. So 12 total transactions will all be at 30%, but that 13th transaction will be at 15% And it’s an incentive to retain customers to build great apps. Right people are going to stay subscribed if they value the app. And so Apple was not just incentivizing this subscription business model, but incentivizing to build great apps using the subscription business model. But there’s like a few caveats as always with Apple. So if there is more than AI don’t remember all the technicalities, I actually haven’t looked this up in a while. But if there’s more than a 60 day gap in any 12 month period, it resets the clock. So and Josh and I were talking earlier, kids apps is a great example. You might subscribe to a kids app for a few months. The kid gets bored of it. You can subscribe for a few months and then you come back on and you subscribe for a few months and it’s fresh again. My wife does this with like physical toys. She’ll put them in the garage for a while. And then a little box back and it’s like, yeah, so a little parenting tip there, but but that actually kind of messes with the kid’s app developers because they don’t end up with that continuous renewal or where they would get the 15% So what’s important about this is that in Apple didn’t say this explicitly. I think sometimes it’s like they don’t like to talk about money or I don’t want to highlight the 15%, 30% They just don’t want to say anything about percentages anymore. You know, it’s in developer state of the unions. So they didn’t say this explicitly, but I think this was intentionally done to make it easier to track when a customer tips over to that 15% take rate. So that you can calculate your proceeds. So this is something we already do at revenue, but it will it’ll make it easier for us to do it. And then if you’re not running revenue and you want to catch. The proceeds. You can use this recent subscription start date to kind of start the ticker to see when you’re going to kick over to that 15% Yeah, that explanation makes a lot more sense. Like I thought was like a weird time frame. I’m like, why? Yeah, why 60 days out? Because it makes sense to me. Like, it’s cool. Is it just like a random day? But this actually makes sense. Yeah and they were talking about wind backs and they talked about various things in the SWBC presentation. But bottom line, I think this is what it was really about. Yeah, that makes sense. All right. App transaction API. So oh, and we lost Josh. Yeah well, while we’re waiting for him to come back, I will, I we’ll hit this one because it’s actually kind of interesting. During the keynote, the ducks dropped and people found this app transaction API and they were excitedly thinking, oh, this, this will enable this is Apple saying we’re going to enable sideloading because it does allow you to validate that the transaction was completed on that the app was downloaded from the App Store. But that’s actually just one part of this API. One of the big things, and this is what they talked about in the d.c. session on it, was that it makes it easy to facilitate business model changes so you can verify the original purchase date of A or original purchase version and original purchase day of a customer. So that if you were switching from single like one time in-app purchase or a paid up front app and you wanted to move to subscriptions and this is the example they gave in the session was that you can give all of the existing users access to everything that they’ve had in the past. This is another one of those things where revenue we already let you easily look this up in the subscriber attributes. So it’s not really going to change much for our customers, but it will make it easier for other folks to look at when that original purchase date was. So that so that you can grandfather your users in who you want to, you know, charge a different subscription price or otherwise kind of favor them when you switch business models. And just since Josh hasn’t come back yet, I will say there’s a lot of. Hey, Josh, welcome back. You there, josh? I can’t hear you. Get your back. Still can’t hear you. While Josh is working on his Mike. You can once you start talking interrupting me but Brennan asking the questions. Can that business model switch happen for an app that has a different bundle id? I’m releasing a brand new app with a subscription model. But I’d like to get my existing users of the old version of my app that has a different bundle idea discount on the subscription. And the answer to that is, unfortunately, no. So the transactions are bundle specific and you can’t see receipts from as far as I know. And Josh, correct me if I’m wrong, but you can’t see receipts from other apps in the developer account. The way that this has been done in the past is to force users to URL in the old app that, you know, attaches a string and is a deep link into the new app that gives them that kind of grandfathering. You could also because there is a shared space, a shared sandbox across apps in the same developer account. So you could put a flag in that shared storage and flag users who had the old app. But that means you would have to open the old app in order to do that. So no, Apple’s still not facilitating the move from one bundle ID to another. And there’s other business reasons of why you wouldn’t want to switch bundle ideas. You lose all your SEO mojo in the app store, you lose reviews. And there’s a lot of other issues with doing that. So sorry, Brian. And if you want to ask some more questions about that, happy to chat online about something I’ve done myself. And talk to a lot of developers about switching to the subscription business model. So, so yeah, we can talk more about that. OK I think I’m back now. Josh is back. OK so the live storm thing kicked me out. It thought my credentials were being used on a different computer somewhere. Oh, Wow. And I kept like, yeah, I was using Chrome’s like, shared, shared space or whatever. It was kind of thing where I was thinking train computers and maybe it did something weird. So, yeah, I don’t know. You’re but I’m here. All right, guys. Anything I mean, I talked to the app transaction API. OK pretty well. The only question that you and I were talking about earlier is, is sideloading. And then so you did a little deep diving into why apple, you know, put in the dogs that it could verify whether or not an app was downloaded on the App Store. It sounded very sideloading. Yeah I don’t know if it’s either for sideloading or against sideloading, because it could be. It can be for both. Right? like you could check to see, like, is this version cracked, hacked and/or whatever? And then be like, hey, I’m going to just disable all the things. Or if Apple does approve sideloading, then you can be like, all right, I’m going to use purchases outside of the App Store instead, like Stripe and like that. So like it could go both ways. And I don’t want to assume which way it was intended for, but I’m just going to leave it as it could be used for both good and bad. Yeah and then one thing you’re explaining to me as well is that this seems currently very targeted at Mac OS. And so it’s not Mac OS specific, so that Apple didn’t have to limit it to Mac OS. But currently it does have application for Mac OS apps, correct? Correct Yeah. Yeah, because you can officially install those outside of the App Store. But this does work across IOS, Intuvo’s catalyst, watchOS stone, this one iPadOS. So iPad os, I think that counts as iOS in the docs. But yeah, Yeah. It’s for all. Mac is the one where it probably sense which iOS version I actually have the docs open right now let me find that tab 16 plus so. Oh no, I lied. Hold on. Mac OS 13 plus. Watchos nine. Plus iOS iOS 6 plus the. And only next go 14 and up is. So you have to be relatively new in order to use this one. Gotcha so with that little hiccup in us already droning on and on, we’re going to need to really start to be running these all day. And so far from here on, if you do have a question, drop it in the Questions tab and then upload the ones you want answered. We will leave time for questions at the end and that’ll probably be a better way to manage the questions rather than Josh and I tried to read those live while we’re, while we’re speed running the rest of the slides. So Yeah drop things in the questions I put the ones you want answered so if you API so this is pretty cool. Make it super easy now in Swift UI to trigger an offer redemption sheet and a request review sheet. How does that impact revenue cat customers? So for the users that use our SDK, we actually had an offer code redemption sheet method that made this a one line call. So it wasn’t too hard to do in Swiftkey y. It still actually might be less lines of code technically to use our way of doing it, but having your app be very SwiftUI is definitely nice. So they do offer a way to do this and I think we might add similar SwiftUI things on our side. Just so if people do want to still use our. Implementations of these, they still can. We don’t need to do the Request Review. Right and, you know, we don’t do requests. Correct Yeah. And this request for review is still pretty simple to do. It was actually pretty easy to also do without SWIFT UI. It just didn’t feel very swiftly. But with request review, you still kind of want to do a lot of logic around it, like do it after a positive approach after they use the app for a certain amount of time. So you want to write code around that to trigger this at a specific time. But now calling it, there is a very Swiftkey wide method for it. Yeah Yeah. That’s pretty cool. Circuit messages. This is another one. So I’m excited about this one. Yeah as I mentioned early on, I have my frustrations with apple, but then you see stuff like this and it’s like, wow, this is really. Apple took a very thoughtful approach to this and I was hypothesizing with Josh before the call that it seems like apple, you know, built up the circuit, team to build circuit two. And once they got over that hurdle of building out circuit two, now they have some really talented engineers who are thinking and playing the long game on building out store kit and all the things around it in a very thoughtful way. And you’re watching the video on store kit messages and then reading through the docs, they implemented this in a really thoughtful, future looking way. So with all that build up, what Josh, what investor kit messages and why should people care? Yeah so this is a way for Apple to display information in your app, something that Apple needs to show. So right now, they really only talk about the increase in subscription price, which I believe does come through an email right now. But I know my email is a disaster and I would probably miss it and I wouldn’t consent to it. And I would lose my subscription because I didn’t agree to it. So it would just it would just be bad for my experience. So I start getting messages. Apple can actually throw up a sheet in your app itself saying, hey, price increase. Do you want to accept? Which I would probably see a lot more often than the email version, and by default, it’ll just show it whenever that message comes in and your app is up on your phone, but you can actually defer it and then show it whenever it is best in your app. So if your user doing some critical thing, looking at a map or something like that, you don’t want this to show up. But then you could show that after they’re done with that critical thing. Yeah and then they did a lot of really smart things. So there’s only one message. What did they call it? Message type or whatever type, I think. Yeah, Yeah. There is only currently one message type, but you can see that it was architected to handle future message reasons. And then the way they did this message listener was super smart as well. So So, like Josh was saying, it’s like you open the app, somebody opens your app, you don’t want to hit him with a sheet right away, like the apps app review prompt. You want to hit him at the right time. And so when Apple dumps this into the queue, you get to choose when to show it. But Apple tracks whether or not it’s been showed so that you’re not going to show duplicate messages. So they did a lot of smart stuff there. And then, Josh, you were kind of theorizing on some other potential uses for this in the future. Yeah, like, I don’t know, like if your credit card expires or something like that. Mine has and I don’t remember seeing any message from Apple. Maybe it comes in an email, maybe it doesn’t. But if my credit card expires, my subscription wouldn’t renew and then we kind of get into the same thing again. So like that one, that one, I don’t know how that would work because that one might show across multiple apps then if I have a bunch of subscriptions, but it would probably show in the app that would expire the soonest. Yeah, but this is what this is about. Yeah this is what’s super cool about Apple doing it though, is that and this is something again, I think a lot of people don’t give Apple credit for is that Apple manages dining at an incredible scale. People maintain their credit card in Apple way more than they’re going to go to stripe and update their credit card for your one subscription. And what’s cool about this is that it incentivizes the developers are incentivized to get the credit card updated, but then it’s kind of a crowdsourced thing. Right and because Apple’s handling it, I bet they’re going to be able to do it intelligently. Where has that been shown in any app, including the app store? And then if it has, maybe you wait another 30 days to show it again. So they can kind of maybe throttle the messages. And they may be able to track cross app weather. So if it shows up in your queue and you don’t display it, they may see that it gets displayed in a different app and then market as already seen in your app. So, so this would be a super cool use. I hope this is what Apple is thinking. And if not, I’m going to I’m going to file a feedback request saying that they should do this because this is exactly the sort of reason why App Store payments can be great for developers, is that it just makes it so easy to have multiple apps, multiple subscriptions, all getting that person to update their credit card rather than relying on whatever email or something that you’re sending. And if they’re able to do it in app, all the better. So I’m excited to see that if they do this and then excited to see how else they use this because clearly they put a lot of thought into building this API. Yeah and I did this check and this is only for iOS 16. OK and mako. Nope, it is only iOS. Actually, it does say catalyst. OK so my computer there will come to Mac as catalyst, apparently, but not Mack. As native Mack. Right now, I think according to the docs. But see if you’re on I was 15. You don’t get to use this, but new ones you will. Cool appstore Connect API. I know you’re super excited about different thing about this. Yes so we could talk another 30 minutes, but give us the TLDR and I’m really curious. So those of you watching might not realize Josh is the lead maintainer of fastlane, which already does interact with the official appstore API and maybe even some unofficial builds. The unofficial ones, Yes. Yeah but so I’d love to. So I’d love to hear first about app Store Connect API and then maybe some thoughts on, you know, things that revenue Kat may handle for developers in the future and then things that you’re excited to implement in fastlane that are maybe kind of adjacent to revenue card or don’t make sense for us to build. Yes, I’m super excited about this one. This is one of the major APIs that we were missing. But I mean, it’s I completely understood it because there is a lot there. And it and it is a very important one that does a lot of potentially dangerous things. So yeah, this, this one now you can create, edit, delete, IEPs. So consumables, not consumables subscriptions create your subscription groups, anything that you can do on app store, connect that deals with subscription and things you can now do with this so you can query all like your how much your subscriptions are, update them if you want, submit them for review which which Apple does have to approve of some of your product updates, but it doesn’t necessarily need to happen with a new app update itself and you can create offers and promo codes. So if you want to. I think right now with promo codes, when I was doing it for my personal apps, I had to do it in the website, do it like a very manual process was kind of slow. You copy and paste, then send them over to whatever thing. Now you could easily create like a, a shortcut that does this for you. And I’m super excited about that one. Yeah, that’s super cool. And so, so what aspects of this do you think will be working on it? Revenue cat and then and then what do you do? What do you think fastlane will be working on? And then are there stuff that developers might need to do themselves or will they just be able to rely on on? Fastlane and yeah, so for fastlane we’re going to implement pretty much all of the new APIs that exist because right now all of our API stuff is very legacy and it is not great to use. It still works, but like if something breaks it, it’s going to be impossible to fix now. So as soon as this comes out, I’m going to spend two or three days nonstop to try and get that out. But it should shouldn’t be too hard to do, hopefully, but like if you have a lot of consumables or non consumables that you create, let’s say if you’re like a video provider and like you want to manually create like consumables to buy stuff or not consumables right now have to do that in the dash board kind of thing where you could automate this relatively quickly. And you know, it’s going to go through. So if you have to create hundreds of months, thousands a month, you can do that. Automate that on your end. So for me personally creating apps, that’s probably not something that I’m going to use it for because I don’t have a business of that size. But more for like big apps, this is probably something that they’ll use a lot in terms of revenue cat stuff. So right now, the products are entered by the identifier manually. This would be a way that we could query them and make sure they match up, pull them in automatically if we needed, validate that everything in our configuration works. So that when you go to use our SDK, you know, everything is going to connect there. I know when I first started doing some stuff on my side, I entered things wrong and misspelled thing having extra space and then things didn’t connect up and there’s errors and I have to go look in the app and I’m like, OK, like what’s going on in this work? And it’s cause I spelled something wrong. Now we can, like, validate that your, your stuff is actually good before you use the SDK. Yeah it’s. Since we’re able to query, is this something where we could actually query daily to look for price changes and actually track price changes more carefully on our end? Yeah Yeah. That that’s going to be a huge, a huge thing for us. Just because you can change subscription prices in a product more often, because it’s easier to do and consent. We we could pull for those daily or when a new price comes in and actually like update our charts then to go with that information. Yeah so one thing about this is that developers will have to give us an API key for us to use this. So it’s not something that users will just get for free. They got to give us that key for us to be authorized to query this information, but way better than having to store credentials? I think so, Yes. 100% 100 percent, Yeah. I don’t want to store any Apple ID passwords or anything. Yeah, totally. All right. We got to do that fairly quick. Surprising good job. Circuit testing. So this is something I actually have not had the time to dive deep into, so I’m going to have a lot of questions. So one of the big things is that store kit configuration files can now be automatically generated. What what does that matter. And will that streamline things? 100%, Yes. So just as I entered IDs wrong in our side, when you create a starting configuration file, you kind of want those ideas to match up. And I messed this up a whole bunch of times, and you pretty much have to create your server configuration file to match what you have on the App Store. So you have your, your subscriptions, your consumables, your non consumables and getting that is kind of a process and you’re like, you had this information already, why can’t you just do it yourself? So I created a, a, a plugin for this that I stripped it out. A few months ago to do it for myself because my apps have six products or so and I have four apps and I didn’t want to do that for all of them, but now I can trash that code. Since Xcode 14 has, it’s built in very quickly. So you can create a single store configuration file, which will pull all of your products from your App Store Connect account, and that’ll actually stay sent. So if you want to test exactly what you have on production, you totally can. If you want to do more tests locally, you can actually pull this out of the same state and still edit it locally, add different subscription types, different lengths if you want just to test more things. But you can’t, you can’t sync that back up then. But you can create another thing version, right? So this will save developers here like bunch of time just. There’s, there’s so many less steps because there’s almost no steps. Yeah that’s amazing. And then what about the new transaction, inspector? Yeah so I haven’t played with this one yet. I have Xcode 14, but I’ve been able to do it on my personal apps yet. But this will actually make testing all the star kid stuff so much easier because previously, years and years ago, your testing was pretty much on your physical device sandbox mode. You couldn’t really do a lot of easy tests for renewals, price increases, expirations, and it’s like seeing all the information about that those transactions with trick with new transaction inspector this uses the x or these stalking configuration files and all the transactions that go through there. And you can see all, all the subscriptions you belong to consumables. Non consumables. Like what? What groups they belong to when they expire. But you can also simulate price increase. If a user rejected the price increase, you can pretty much mock any behavior that a user would happen and do it locally and quickly. So for us and developing our SDK, this is going to be awesome for us to test and make sure like our code is actually behaving properly with all this stuff and then for our users they can do the same thing for their like specific use cases that they’re implementing. Yeah that’s pretty much getting rid of pretty much getting rid of having to rely on sandbox. You still want to use sandbox because it is a more real life environment. Even though sandbox can be all that bug you’re than production using all 3 is still great. But this will get a lot of the different things that can happen done a lot quicker. That’s awesome. Yeah, I kind of a wrote essentially the definitive guide to testing subscriptions and I wrote it based on my knowledge from like 2016, 2017 when I was migrating my apps to subscriptions. And, and I mean probably most people in the audience also realize what a huge pain it’s been historically. And even still is to test. So, yeah, we need to update that post and, and build out some good documentation around what developers should be testing because this is going to make it so much easier and have a lot more confidence that things are going to work in production. The next one here is swift duck c, so I never realized that documentation was something that everybody has their own style, everybody has their own approach to documentation. And you’re explaining to me that bouncing back and forth between Apple’s documentation and random other developer documentation, some other SDK documentation is actually a huge pain. And that’s part of why Apple created Swiftkey. So yeah, why is revenue cat now using it and how does it simplify things? Yeah so we were using, I think, jazzy before doxy, which was kind of like the open source third party created one that, that kind of did similar things. But Apple created doxy I think it was, it was last year, maybe two years ago and we just started using it with our started to updates but it takes the doc that we have in our SDK and creates like a web version of that. And this, this, this web version matches Apple’s styles. Exactly so when you’re an Apple platform developer and you use our docs, they are designed and look and function and search everything the exact same way. So it is exactly what you would expect from a Apple platform SDK. And then it’s so super cool too that you’re, you’re documenting in the code. So when you’re changing a bit of code, it’s an instant reminder to change the documentation there. And then the documentation just gets auto updated whenever that pull request gets merged, which that’s super cool. Yeah Yeah. So with, with, with this one, it did only work. Doxy did only work with swift. So if you had any older SDK is doxy wouldn’t work. So we just recently migrated over to Swift so we could use doxy. We, we couldn’t use doxy before but now older SDK is still can and it actually is a bit more usable now navigation bar is there where before there wasn’t this nice way to navigate and you can search for things and it is a super nice update and we get it for free, which is awesome. Very good. Thank you. I think I think our docs were updated the day after this was announced to this. So nice. Yeah so so for our customers and hopefully customers of other stocks out there, you’ll see some real improvements to the documentation which, you know, I hadn’t, you know, I don’t I don’t code myself. And so I’ve never paid attention to these things. Revenue cat gets a lot of kudos for how well documented our stuff is. And I didn’t, I just didn’t realize not being a coder myself what a hassle it is when other aspects aren’t as well documented. So so while it’s great to see Apple building this out and now continuing to improve it, but then also just really cool that we’re using it and, you know, document stuff pretty well. So kudos to the rest of the revenue CAT team. How does that work? A a great I, I sure hear about it. It’s so good. Yeah yeah, I network. Oh, this annoys me. I screwed me on this one. I know. I know nothing about K ad network, how you use it, why you would use it, what it does. So this one’s all on you. Yeah so, you know, I could. I could talk for 30 minutes on this, and we probably will. Do you only have an hour? Yeah a webinar or a podcast to. To dive deeper. Apple introduced hierarchical ideas and conversion values. And so essentially what Apple’s trying to do, and I’m still a little frustrated with that network, even with 4.0, which was a huge update, but it’s a very kind of academic exercise to not leak any possible personal data versus kind of a trade off. Because at scale, if a little bit of personal data does happen to leak at scale, Facebook’s not going to build something to get a little tiny bit of extra personal data on one user here and one user there, like if it’s not working at scale, second to work. And so Apple in the original ad network it really felt like an academic exercise too to allow zero possibility of leaking personal information, but then was built in a very kind of Apple way of not really understanding what the industry needed. And so this what 4.0 does is tries to give a little more flexibility, again, without sacrificing any privacy. And so the hierarchical IDs mean that you can get up to a 4 digit conversion value. And if there’s enough if there are enough users who are in a specific cohort so that it will so that four digits won’t be enough to leak an ID. So so, you know, you could think if, if, if there’s only 10,000 people in if there’s 10,000 people in a cohort, you can send a four digit ID and not tag each individual user. And so they introduced this concept of crowd anon anonymous. Totally but that was it. Oh, but if there aren’t very many people in the cohort, you get a two digit conversion value. If there are more people, if you have medium and anonymity, got it that time you get a three digit conversion value and then if it’s a very large cohort, you get the four digit. And so that is going to help larger apps who do operate at scale be able to get more conversion data without leaking any private information. So it is really cool that they did this. And again, I mean, I could talk for a long time on the specifics and I probably kind of botched the summary, but hopefully that kind of makes sense. Like the more people who are in a specific cohort, the more granularity you’re going to be able to get on what exact ad they saw, you know, what network it came from and things along those lines. So the next thing is multiple conversion values. So originally Apple had this super convoluted timer system where once somebody launches the app, a timer starts and you have a certain amount of time. I think it was up to like 30 days to send this conversion, these conversion post backs. But once you sent the conversion post back, that started a second timer and that second timer was variable between 24 and 48 hours. Again, a very kind of academic exercise of like, you know, we can’t leak any personal data, so we’re not even going to let them send the post back in real time. We’re going to create this dual timer system. So you only got one shot. And so if you were trying to measure something down the funnel. And you waited a week, you know, the number of people in the cohort was going to reduce and you were going to get way less signal on those ad conversions. And so with these multiple conversions values, you now is it you have 0 to three days to send one conversion value and then that one goes. And it doesn’t sacrifice anything to go ahead and send that one. And there’s no convoluted timers and things like that. And then there’s the next range, I think is three days to seven days. So you can send a second conversion value and then a third conversion value to kind of measure that deeper in the funnel events. And then the second and third conversion value aren’t going to be as they’re going to be more coarse, not as granular, again, to prevent tracking. So that’s probably more detail than any of you really care. No, I’ll get to the TLDR web to get at network. This is actually pretty cool and I’m interested to see if this enables better advertising on the web. So if you’re advertising an app on the web, you pretty much are wanting to send people to the App Store to download your app. But the App Store is a complete Black box. So even with the idfa, if you were on the web, you know, website cannot get the user’s EDFA. So, so even pre 80 web advertising for apps was not a huge thing because it broke. As soon as you send somebody to the app store, you know, there was fingerprinting and other stuff that people still try and do and have done in the past, but it’s just not super reliable. So now when you send somebody to the app store, you can actually send I network data as well and track them all the way through into actually launching the app and get those conversion values based on the web. Advertisement so this could be a big deal in that app. Advertising on the web has had just never really taken off. And so being able to advertise more on the web and actually measure the results of this, I think could really open more opportunities. And then there are a few caveats Apple said later this year. So it’s probably not coming out in the fall with iOS 16. So, OK, so you know, maybe November, December, may 22, 2023. It also may be I 16 only. So then you’re going to be waiting for the everybody to update in order to be able to send these hierarchical IDs and multiple conversion values. So, you know, the impact of this will probably not be felt. And then then, you know, Facebook and others have to build the tech to actually make use of all of this. So really, we’re talking Q1, maybe even Q2 2023 before any of this really matters. But the TLDR is that. It is a huge step forward. So I ads get get, you know, dragged on a lot that I think Facebook especially created a bad taste in a lot of people’s mouths and a lot of the bad stuff that happened with the EDFA kind of reflected on the ad industry for, for good reason. I mean, there’s a lot of crappy stuff going on with the idea that Apple was right to enact something with to prevent all of this privacy violation. But at a fundamental level, you know, ads and measuring the performance of those ads are not immoral. You know, when you’re building a product, you need to get attention. And being able to buy that attention via ads is a very normal part of the business process. And then being able to measure the results of those ads is an important part of that process. And then on the display ads side, doing some level of targeting where the ad isn’t completely irrelevant. You know, this is something I’ve actually come to appreciate about Instagram is the ads are pretty cool. Like they actually are relevant to me. They’re good ads. And so I think the ad industry generally kind of gets thrown under the bus because they did do a lot of crappy stuff. But ad network to me is the first bright light off in the distance saying, OK, maybe we can actually have good ads, good ad measurement. And respect privacy. And so it’s super exciting to me that Apple is going to start marching down this road of building out a privacy focused ad measurement platform with an ad network. So I’ve rented way more than I should have, but hopefully that folks are more to the side. I do want to hear more about this in some other kind of format, though. Yeah, absolutely. The last thing and let’s get real quick. Yeah we can stay late to answer questions. So so I guess we got five minutes for this answer and then I can do this one in five minutes. All right. So app store, server API. Yeah so this one won’t have a direct effect on our end users because we already do a lot of what these new changes do already. This will be for people that aren’t using us and the bizarre stuff that will adapt to but the extra server API, which is how, how we query subscription statuses, transaction history, all of those things is getting some new fields. One is the environment that it was purchased in, which is either going to be sandboxed or production. This is unlike the one that is in historical model, which also has Xcode. Xcode is not something that the app stor server deals with directly because Golden State is locally. So this is only getting sandbox and production and then it’s also getting that. I’m going to watch this again the recently the recent subscription start date that now one year. So it is also getting that those are general fields the app stor server V2 transaction history end point, which already exists is getting more fields for filtering and sorting so you can sort transactions in descending order, meaning you get your newest transactions first and you can also filter by like user product, subscription type. There is a few more in there, but this is nice because it can make for a more performant server. You don’t have to get all of the transactions at once and filter in sort locally, which is more work on Apple’s API because you have to get all the things at once more work on your site because if you do a lot of this stuff locally here, you’re just getting directly what you need. So it’s not true. There is a field for the last revision. And so you can just basically say, give me everything since the last revision. So then you’re not having to repass all the transactions every single time. Yeah Yeah. So there’s always something like that. Is that field new this year? The OK, remember, I, I, I had no interest in IEPs over a year ago, so that’s brand new for me this year. I don’t exactly know the history of transaction history, but I think the docs do show what is newly added and there is a revision on the docs for this. Yeah I just don’t know much about my head. Yeah but TLDR for revenue cat customers is like we’ve already been doing all this for you for multiple weeks. It’s pretty much the beginning of revenue. I mean, early on we relied almost completely on polling. Now if you do put your server to server API key in to the revenue cat dashboard, which I highly recommend, we do pretty much get real time subscription lifecycle events and this is something that really is super important if you’re running a subscription app. I had this experience recently, talked about it in another webinar and on the podcast, but I previously subscribe to the 0 app and you it it’s a for like time restricted feeding, intermittent fasting. And so I used it for a while and just hadn’t been using it lately. I go to the App Store to unsubscribe and had to open the app in probably weeks, maybe months. And I’m in the App Store app and I hit unsubscribe. And before I could even switch to my email, I get an email from 0 saying, hey, we’ve confirmed that you unsubscribe. It was a really great user experience to get that confirmation of like, hey, you know, they know I’ve unsubscribed and and that’s a great time for most developers. They weren’t doing the win back, but, you know, if they would have sent a coupon code and been like, hey, you know, yeah, $30 in the next year, I may have taken them up on that because I probably will use the app again at some point. And so having it happen in that near real time from us being able to push those events through revenue cat to, you know, a CRM platform is incredibly important. So if you haven’t already entered those credentials into our dashboard, do it and set up your cancellation event, win back campaigns. But then we also still to this day fall back on polling the App Store where it’s like we have the receipts or side and hey, Apple has something changed and then, you know, hours later, hey, Apple has something changed. And so eventually we’ll probably be able to stop polling and rely on this completely. But we have continued to find, you know, holes and other issues with retries and other things that Apple wasn’t doing well and missing service every notification. So it looks like. This is going to maybe be the final piece and we can slowly wean ourselves off of the polling. And so if you’re a revenue care customer, you don’t have to worry about it because we’ve been doing all this to let this slide. Yeah and if you’re not a revenue cat customer, it’s a lot of work. But, you know, you can build against these server to server notifications now and do some of what we do, but they’re easier. But yeah, it’s a lot of work. Still a lot of work. Yeah all right. We did it one hour. So I know some of you may need to jet, but Josh and I do have some time, so we’ll answer a few questions. If you if you have any additional questions, go ahead and drop them in the questions now and then upload the ones you are most excited to hear the answer to. So the first question from Jim is the process of adding new IP and revenue can be simplified. Right now I have to enter several bits of info in several places. Product offerings would be nice to have a quick setup path where most of the variables would be provided. Do you see something like this coming up on your roadmap soon? Josh this is definitely something we’re excited about because the possibilities are here without us having to have your ID now. So I don’t really have any like concrete information yet. And this is still relatively new and we kind of had plans already, but like this is something that is a pain point for users. When something does go wrong, we see it, we hear about it, we want to fix, we want things to just magically work even more. So this is definitely something that we do want to see. Yeah, I think it’s safe to say it was immediately put on the roadmap, but in priority order has yet to be determined. Neither Josh nor I are product managers at revenue cap. We actually have a whole team now of product managers and so it’s going to be on them to prioritize. But I can say from being part of the chatter in the revenue cut Slack over the past couple of weeks, that we are incredibly excited about this. It’s something we’ve actually been talking about for years, about something I personally want as well because I do it for apps on revenue card. Yeah, I’m making a fifth and like I don’t want to enter this stuff myself. So like if I can just. If it can do it for me, like. Yes, please. So I want it from a revenue card developer standpoint and also as a user standpoint as well. Yeah so to be determined on when we will ship it. But it is definitely happening and we’re excited. So all right. Next up from abu, do they fix the problem when upgrade, downgrade, cascade subscription, you’ll get multiple active subscriptions in the sandbox. Have you had time to dig into that yet, josh? No, the sandbox is always a little bit dicey. Uh, which is why like having the, the new transaction stuff in Xcode for store config files is super nice because that one is a bit easier to test all of these things. I have never personally seen that problem in the sandbox, so I can’t super answer it. But I feel like the ideal situation is to test most of these scenarios using the storage configuration file. Now Yep makes sense. All right, James asks. I have several apps that is revenue cat and would love to offer a bundle and get all apps for a single lifetime price. Is this possible with revenue cat? Nah, that’s a good one. Have you have you looked into this, josh? Apps that users seem to love to offer a bundle to get all apps. For a single. OK so that is using the same or allowing subscriptions to work across multiple, multiple apps. And we actually do offer that. I think that was I think we released that feature last year. I think it’s also a native App Store feature as well. But revenue cap does make it a little bit easier as long as all of your apps are in the same revenue. Cat count. same revenue cat account. Yeah project. I look at the docks for this. There, there. There are dogs. This might be a given. This is coming to me. Yeah, this might be a good one, James. To search the community as well. Community dot revenue cat. I’m pretty sure I’ve seen a thread in the community about doing this. And if there isn’t a thread there should come later. So Yeah. So so I’m the thread says and Josh, Josh or somebody else will jump in and explain in more detail. And as Joshua say, I believe it’s in our docs. So yeah, it’s as long as we’re using, I think it’s all the apps in the same project. They can see the entitlements that you grant and they’re shared across all the apps. There’s nobody like put this bundle like on the App Store. It has to be done and marketed through one of your apps. So if you in app one say you subscribe to this and unlock access to ABC and then that. You can configure it to work that way. Gotcha all right. Next question. If we are starting with a new app now, is there any upcoming revenue SDK feature to look out for? Are we expecting any major client side features that could change the way we use the sdk? The answer to this is there is probably no major client side changes since we just released iOS v four, which was the objective-c swift rewrite, which allowed us to use store one and store it too. So this question was asked a year ago. It would have been, yes, there’s a lot of changes to look forward to because it was a major SDK change. It was a breaking change. Even though we did have a lot of Xcode fixes that helped direct the migration. But right now, there aren’t any super major changes that to look out for, except for some of the ones that we talked about on that store. It slide that users will get it for free. So using a new an app now creating a new app now with our iOS V4 SDK, there shouldn’t be anything that is going to change. There may be some more features that do get added, but it’s nothing that’s going to break stuff. Cool it’s great to know. Yeah, I know. It’s been a ton of work getting that swift and I’m actually excited because now it’s kind of like Apple with circuit two is like now that Apple’s over the hump with circuit two, it’s exciting to see what this circuit, team does because now they’ve got, you know, a whole team of very talented engineers that kind of got over this big hurdle and can now start doing really thoughtful stuff like this, circuit messages. So I’m personally excited for revenue cut that we’ve gotten over this, you know, massive hurdle and are incredibly talented team. You know Josh and the other Josh with Josh on the engineering team working on the same projects, which is fine and Andy and Matty and we have some incredible engineers. So I’m excited to see now that we got over this huge hurdle, what’s going to be in store. But since we are over the hurdle, as Josh said, there shouldn’t be any major breaking changes, just new features added and making things easier. So next question. When the user launches my old app, after my new app is released, can I generate a unique offer code for that user to get a discount on the new subscription version of my app? Again, separate bundle ideas. Not sure if offer codes can be unique to a specific user’s Apple ID. Go ahead. I I’d say you could I think you could end up adding a different well, I don’t know about an offer code, but you could like back support them access to other ones, use it like adding a different entitlement to that old product. And then maybe like dynamically showing another slight cheaper subscription or something in app. To subscribe to all of the. I don’t that was going to be my solution. I don’t know if there’s an actual proper solution. I should let you answer first. I don’t actually know you. Well, to answer the question specifically, the offer codes, as far as I know, are tied to the specific bundle idea. Like when you set them up in App Store connect, you’re within the app, you’re not in a global system. And I was actually just recently trying to set up promo codes and offer codes or offer codes and there’s no like, you know, attached multiple apps or anything like that. I mean, you know, for apple, this unfortunately, Apple has not made these kind of business transactions a priority to support I mean, these business transitions. I think I said transaction in like when I was moving my app from paid upfront to subscription, you know, we had to do a lot of work to figure out how we were going to grandfather, what discounts we’re going to offer and all of that. And it’s just something that I think Apple sees as enough of an edge case that they haven’t built a lot out. I think the new transaction API is a signal like, hey, we realize people have been doing this and we’re going to make it a little bit easier. But again, it’s actually something we already made super easy and revenue card with our subscriber attributes. So so that, you know Brennan this actually would be a great topic. I do weekly office hours where I talk through these kind of things. Sahith me up David at revenue and you can schedule an office hours call to chat through this there’s I it sounds like you maybe have your mind made up that they need to transition from an old SKU to a new SKU. There are quite a few cases where I would not recommend doing that. You may have some specific reasons, but but a lot of this is not applicable to the rest of the folks on the call. So let’s chat directly and then I should, I should probably write a blog post on this and that could just point you to the blog post. We do have one by blog post on transitioning that gets into some of the technical details on entitlements and checking subscriber attributes for what version they previously owned. But it doesn’t go into these kind of details about transitioning your whole business model and moving from one SKU to the other. So yeah, let’s chat in an office hours in the future. Brendan Emmanuel asks. I sometimes see a subscription convert months after a three day trial starts. Could that be triggered by a user updating their expired credit card details and opening the app again for the first time since it had expired? Or what could possibly do that? So I’ll take this one. Josh Yeah. So actually, you may have seen a manual and actually been on the we did a different webinar in February, I believe, and it’s on YouTube now called App Store accounting. And in researching for that webinar, I was actually looking at my transaction data and it found a similar thing where there was a transaction that was initiated. And this was not a subscription app. This was even AI think it was one of my paid up front apps only have one left, but the transaction was initiated. But did not actually complete for something like 33, 35 days. And so this apparently is not subscription specific. And I think what’s going on is that Apple tries very hard to get your money for you. And for them. Another thing about the rev share between Apple and developers, that Apple is highly incentivized to help us collect that money. So I think what ends up happening is some combination of insufficient funds, outdated credit card. There’s probably multiple reasons that the initial transaction didn’t complete. And then Apple works hard to make sure that transaction does eventually complete. And in the docs, it says the grace period is only 7 to 10 days. But like you, I’ve seen transactions that were live for up to 35 days. I have theories that, you know, if somebody is using App Store gift card and don’t have a credit card attached to their App Store account, it may be that Apple knows that and they wait for it to get filled back up again to then go ahead and charge the transaction again. If they’re using a debit card and they’re or a credit card and the credit cards maxed out, you know, if they get an insufficient funds and Apple probably like smartly tries again, you know, after a payday or after a certain amount of time and then continues to retry it. So so that’s likely what’s going on in that case. And I don’t think they actually have to reopen the app for that to happen. I believe Apple continues to do that in the background, both as part of the grace period for subscriptions. You know, there is this specific grace period that you can enable in app Store Connect. But apparently, again, you know, this happened on one of my apps is not a subscription. So I think all transactions, Apple continually tries to close out that transaction instead of just canceling it. All right. Well, Laredo asks. Dave was talking about instant email from a subscription cancellation. Is there a doc that describes how to link a CRM to revenue cannot Apple subscription events. So the most straightforward way to do that is to use one of our integration partners. So Brays intercom, iterable, one signal. I shouldn’t be naming names because now I’ve forgotten one. And hopefully whoever integration partner is listening doesn’t realize I forgot them. But that’s the most straightforward way to do it, because those integrations do stream those events, live to those CRM platforms. If it’s a Syrian platform that’s not supported or if you’re rolling your own, you can use our webhooks to send those to stream those events to whatever you’re using to kick off those emails. So there are docs around all the integrations and how to get them to link the docs and to awesome the chat right now. And then there’s the webhook docs. If you do need to roll your own, you would look at the webhook hook docs for how to stream those events to whatever CRM you want to use or customize even to reply directly to this, this question. And I think just drop it in the chat. Drop in the chat then there. All right. All right. We’ll make the entire list there. We’ll make this the last question. It is. We have gone quite long. And my. Well so long that my camera overheated. Oh, nice. All right. I think that was, like, auto shut off or something. I’m back. So Nick asks, does revenue have an implementation of the circuit two function that restores apps proactively if the user is downloading on a new device? Oh so we do have the, the method that our developers can call to restore the purchases. I don’t. Hell I’m trying to think here. This is I want to say it’s a loaded question, but if well, I’ll answer it because I think I actually know the answer to this one. Right so. So if they’re opening on a new device, there is an App Store receipt that’s going to be on device that we’re going to collect on app open. And then if that receipt is already on our server, once that’s uploaded, the local cache is going to be updated to say they have the entitlement. And so I don’t I don’t know exactly in code since I don’t code how it’s implemented in my apps. But this is something I’ve actually tested and talked to some of the developers I work with specifically about is that if you open our app and you’re a subscriber, it’s just unlocked and like, so I know there’s a way to do it. I don’t know what a code level the way to do it. But one thing to keep in mind too is, is that revenue does cache locally the subscriber attributes and the entitlements and all the data. So you don’t have to wait on a server call to ping our server before you unlock it. First thing you want to do is, is, you know, create a blocking UI and then they happen to be on the subway or something and then the app won’t load. And so so I know there’s a way to do this. And again, check, check the docs, check the community and my calendar repeated again I’ll link the restoring purchases docs it doesn’t do it. They actually I’m pretty certain it doesn’t do it automatically because sometimes if you’re restoring the purchases it does, it might want you to log in. So it will prompt that. And we don’t want to force that. If you identify your user with our log in method, then we will pull out all of the transactions and subscriptions and whatnot that we have on our server side. And pull those down automatically so that the user won’t have to manually restore. But that requires our developer to click or to do the log in method. But Apple does recommend still that you have a restore purchase button in your app for users to manually click and that restored purchases could prompt the authorization again. So we don’t do it automatically because of that prompt. But if you are able to identify your user with our login method, as soon as your app opens or having your user do this and sort of off, then we’ll pull those down automatically. Yeah and that’s, that’s probably what we do. So we don’t, we don’t have log in my apps and so on app launch. I think we use the login method to send the receipt up to revenue cache and then all of that, all of that essentially for us happens automatically because you don’t. And that’s it’s actually kind of tricky because you don’t actually have to restore purchases to restore purchases because the initial receipt that’s on the device will have that unique ID that once you’ve uploaded to revenue cat so and like Josh said triggering the actual restore purchases dialogue can force the user to log in, which is a terrible experience but but again because we’re storing everything server side if they’ve ever used the app before and you had the revenue cat SDK installed, which is, you know, probably 99% of the people who are coming back to an app, it essentially feels like it’s automatic because you use that log in event. And then if you do have a user log in, then as part of the user log in, you would then identify that user and then it would just automatically have all their purchases. If you have any further questions, just create a community post and we’ll well discuss more solutions in their. All right. Well, that was fun. Thank you. Everyone went longer than intended, but it always does. And we probably could have talked another two hours if we were going to use Intel, but I hope this was helpful for everybody. And we’ll be sharing the video of this for those who didn’t make it. And for those of you who did make it, you will still get an email letting when it hits our YouTube channel and when it’s left. So Thank you, everyone. And let us know, too, if you have any feedback on, you know, questions. We should have asked for format or anything like that. I personally run the webinar events here at revenue cat and I am happy to continue evolving to what feels useful. So if you have a suggestion for changing format for topics that you want covered in a webinar, just let me know. David at revenue cnet.com. Thanks, everyone. Yeah, thanks, Josh. Thanks for having me.
