Beyond the button: Sign in with Apple, Server-Side Up

Good morning, Drew. How are you? No, we started that way last time. Cut. Okay. Good morning. Good morning. Good morning. Well, it's another ⁓ bright morning here. No coffee cup. Got the Starbucks going. You? No coffee cup. ⁓ it is morning, but I do not have any Starbucks going. But Okay. But welcome everyone to Drew and Dan in the morning. We're we're rolling right into it. Actually it's been a it's been l a little bit, but we've had work and ⁓ life happens in between podcast episodes. So welcome back to Drew and Dan in the morning, everyone. Well, let's see. When we last left you, what were we talking about? ⁓ I've got a little bit of follow-up actually. ⁓ if we could just kind of go over a couple last time we talked a couple things about the app review guidelines and if and asking for ratings, like can you ask for a rating? Can you ask for a review? ⁓ we know a lot of apps ⁓ do the thing where they ask you if you like the app first. And if you say, ⁓ my god, it's the best thing ever, then they say, Hey, probably leaving us a review or a rating. And then if you don't say it's the best thing ever, they go, ⁓ geez, tell us why, but they don't send you to the review prompt. And that's why I say, you know, four and a half is sort of the ⁓ the baseline ratings. The minimum. I I've actually that's that thing has stuck with me for a moment because ⁓ when I was in training for work last week, ⁓ there's a a an app that you can download to order food from the cafeteria, and that app had two and a half stars, which I thought was pretty funny because it can't possibly be used. by very many people. ⁓ but maybe that's why it's only two and a half stars. But it it's it's a thing. It it it it is important. ⁓ and honestly, I don't prompt too often for the app store review, but it is ⁓ important for surfacing your app on the app store. it it it's something that I'm I'm I need to probably focus on a little bit more in my Yeah. So ⁓ I just did a little bit of follow up a little research after that we talked last time to see what The app review guidelines say about it. And I found a couple things. ⁓ got a couple little snippets here. You know, if you attempt to cheat the system, for example, by trying to trick the review process, steal data, et cetera, et cetera, manipulate ratings. ⁓ your apps may be removed from the store and you will be expelled from the developer Apple developer program. So that's pretty clear. ⁓ then there's another one that says apps must not force to you force users to rate the app or review the app, or a bunch of other things, ⁓ in order to access functionality, content, or use the app. It says App Store reviews can be an integral part of the app experience. So you should treat customers with the respect when responding to their comments. Keep your responses targeted to the user's comments and do not include personal information, spam, or marketing in your response. And then it says, use the provided API to prompt users to review your app. This functionality allows customers to provide the app store rating and review without the inconvenience of leaving your app. And then it says, and we will disallow custom review prompts, which makes it pretty clear that it's not allowed. ⁓ And then there's another part under discovery fraud under 5.6.3 that says manipulating any element of the app store customer experience, such as charts, search, reviews, or referrals to your app. Referrals to your app, interesting. ⁓ Erodes customer trust and is not permitted. Indications that you might not be meeting that expectation might include ⁓ excessive customer reports about concerns with your app. such as negative customer reviews and excessive fund requests. So and then it goes on to say inability to maintain high quality may be a factor in deciding whether a developer is abiding by the developer code of conduct. So you know, if you're gonna have low quality reviews, i i that could get you kicked out is what I'm how I read that. I wonder how extreme that has to go because I feel like there's a lot of low quality apps on the App Store. You know, and but if they're not getting reviews, maybe they're just not surfaced or they're not getting enough downloads. ⁓ but what my question for you is is how what do you determine ⁓ is a good place in your app to request a review? Like do you use a timer? Do you use a certain number of interactions? ⁓ where do you where do you put that trigger? ⁓ well, I'll tell you where I where Apple says you should put it. They say and this is in not in the developer, not in the app. Review guidelines, but in the Apple Human Interface Guidelines says I grabbed a couple quotes out of here. ⁓ ask for a rating only after people have demonstrated engagement with your app or game. And then it says, consider allowing at least a week or two between week between requests. ⁓ and then it says prefer the system rebu provided prompt. ⁓ and that does appear to indicate to contradict the app store review guidelines just above where we just talked about that said disallow will that they may disallow they say may or will? What do they say? We will disallow custom review prompts. But the human interface guidelines say prefer the system provider prompt. Prefer. Interesting. So you know, they prefer you to design by using the system provider prompt, but they will disallow custom review prompts when they review your app. As well as how I read that. So you know, I so I think the thing that most of the a lot of the apps are doing, which is you know, asking you how you f like feel like the about the app and then if you say it's great, then you give then you send them to the review prompt is maybe not okay. Sure, right, right. That would be that would be ⁓ a a custom review prompt. Without looking at my code specifically, ⁓ if I remember where I put this into my app with the MIST, I think I had it something like if if the person has interacted with with a screen or two screens five different times. And I just have a little ⁓ user defaults counter that goes up and says, You did this thing five times, then they're probably using the app a reasonable amount. and and so then I I trigger the r the prompt at that point. So it's an interaction target that I'm that I'm reaching for. But what what do you look for? I and maybe you I don't know if you remember about the the review prompt, but I think Doesn't it say that it'll only show it to the user a maximum of like three times in a year or three or three times ever or something or app version, maybe? Yeah, new app version you can Right. And and so I was kind of relying on Apple's ⁓ the like the system to not show it too often. Right. Because I know that it'll prevent it. So ⁓ so I felt like, well, I'm not gonna ⁓ put some kind of a timer on there. I'm just gonna have a a an interaction gate that people cross. And then with every app update that that ⁓ that user defaults value is gonna get ⁓ I think I reset it. Right. And a lot of people talking about like right after they did whatever the main thing was or something that indicated it was positive like, you know, if you let's see well what are your apps? You've got your ⁓ The Midst, which is very popular ⁓ kind of life logging almost, right? ⁓ life logging, yeah. Anyway, but that one, I think after you ⁓ like after you checked in somewhere, maybe that would be a good time to say, let's ⁓ throw up that thing saying, Hey, how do you love the midst? Yeah, we know you love it, but like can you please hit the five right here? That'd be great. What do you guys all think? Anyone else who's watching this? I know there's probably at least a couple hundred of you by now. There must be episode two. I would be curious to know. It seems like it's something that's not really talked about a whole lot. It's where you trigger that. Or I I haven't gotten into a lot of conversations about where you trigger that. It it's kind of this ephemeral thing that ⁓ that Well and I think it's at odds with the you know, the marketing. like if you watch someone say, Hey, what makes people make your app work well and that's they'll sell they'll tell you throw that rating or review prompt up on the screen as soon as you can, on the very first launch, right away, because which is a terrible customer experience, but also it apparently drives better review numbers and those drive downloads. So then, you know, there's a there's definitely a a trade off there and you can certainly see apps Going to both extremes, I'll say. Yeah, it it's this endless struggle with w having a good experience and and but then getting promoted or elevated on the app store to get downloads. I I hate that when I open an app and it I've barely opened it and it asks me Yeah, like review why would I want to review it? I just opened it. Like Right. It feels like a dark pattern to me, so I I avoid that. A large pa a large, a large ma I don't know, majority, but a large number of apps ⁓ will give you that review prompt, not necessarily not not the first second you open it, but during their during their onboarding or toward the end of their onboarding. Certainly before you hit a paywall screen though. ⁓ so yeah anyway. Well I don't have a really a news item or a follow up other other than ⁓ I ⁓ what I have is a tool. And it kind of dovetails into what I'm gonna talk about today, which is signing with Apple, but When working with sign in with Apple, there's a front end side of it, there's the back end side of it, and working with the back end. One of the tools that I use on my on my Mac to to test my endpoints is a is an app called Git API. And ⁓ and a very f more popular one I feel like is Postman. ⁓ that's the one I started with, but I I've discovered Git API from ⁓ I think it I actually don't remember where I discovered it. ⁓ but somehow I ran across this and and What the app does is just a Mac app that you can use to create, you know, ⁓ create, read, update, delete endpoints to query ⁓ CRUD app, yeah, ⁓ operations. And ⁓ you can configure your ⁓ your headers and the JSON body in there to to send or you know, make requests to your your ⁓ server as you're testing it. And ⁓ it's just a very simple app. I actually And how is that how is that ⁓ sorry to interrupt you? ⁓ how is that different than me just using curl like from the command line? From the command line? Well, the reason it's different from the command line, Drew, is because I am not the command line wizard that you are. And I much more lean towards the graphical user interface apps for doing things like this. so git API, I also use fork, which is my git repo, ⁓ You know, my Git management tool, that's another tool that I use, because I'm just not as well versed in the command line. So if you're like me and you prefer to use ⁓ visual tools rather than command line tools for doing these types of inputs, then I definitely recommend Git API. And and the reason I I gravitated away from Postman is because it just felt like Postman was so bloated, it did so much. That honestly I didn't it feels like it's more bloated every time I've Is that right? Okay. Yeah. I I don't even have Yeah, and it's it definitely feels geared towards like larger corporate environments, like I don't know. Everything is kind of like like nothing well, it's weird 'cause like they ha yck you have to log into this web thing and then there's ⁓ like synchronized things that don't stay synchronized and they're I I don't know. I feel like it's ⁓ gotten worse over time. So yeah. I mean the main features are still there, but they haven't really changed that much either. So Yeah, it to me it felt like just way too big of a hammer. For what I'm trying to do. All I want to do is just test my endpoints. And and the app isn't perfect. You can see that there's some there's a little bit of bugs in it. You know, sometimes like things won't won't won't reorder the way you want if I'm trying to reorder things or or whatnot. Is it available? I was gonna ask you, where do you get it? Is it available on the app store? Do you download it from the website somewhere? I wasn't prepared for this. I think it is available. Let me see. Git Git API.com. ⁓ $39. Buy once used forever. Yeah, so it is it is ⁓ a one-time download, one time purchase ⁓ from gitapi.com. ⁓ yeah, I've been I've been very happy with it. Okay. Well that seems great. ⁓ and what do I use it for, Drew, you might ask? Yes, I would love to know. I use it for for working with the the the server side Swift code that I write ⁓ using Vapor. And ⁓ what I've been working on recently is a lot of sign in with Apple code because ⁓ for my new app I'm using sign in with Apple when the user wants to create an account. ⁓ when they get to that point in the app and then for my existing app, the midst, you have to create an account right from the beginning because it is a social network and so anything that you do associated with that is going to be associated with your username. And what I've been working on with with signing with Apple has been not only the front end, which a lot of blog posts that you find out there seem to only talk about the the front end side, the client side of sign in with Apple. And then you kind of fall off a cliff when it comes to what happens on the back end on the server side. If you want to save any of this information to your server, you're going to need ⁓ some identific identifying markers on your server. So to talk about sign in with Apple in a podcast format is a little tough, but I'm I'm gonna do the best I can. If you're implementing it using Swift UI, there is a sign in with Apple button. That is built right into Swift UI. It's just called the I think, well, I think it's called sign in with Apple button view. And then there's ⁓ some some options that you can you can say, do you want to say sign in with Apple, continue with Apple? I'm kind of doing this on the top off the top of my head, but ⁓ I think I have sign in with Apple is just what I've selected. And then ⁓ that button, when you click that button, it's gonna pop up that sheet that you're probably familiar with that just says sign in, that's gonna use your face ID, your touch ID. ⁓ to authorize that. Right. When that comes back, that that's going to make a query to Apple. That's going to come back with a ⁓ what's called an AS authorization Apple ID credential. And ⁓ well it returns a result and if the result is successful, because it could fail if if it's you know failed for whatever reason it fails. But if it if it comes back successful, you're going to have that credential. And that credential cr ⁓ contains a very unique identifier for every user. And that identifier Is interesting to me because it's not a UUID. It's a it's a user identifier which is stable across your devices. ⁓ you could down you could delete an app and then reinstall it and you're it's still going to recognize you as the same person. You may have seen this where you've used sign in with apple once and you come back to that app or that website again. And if you click the sign in with apple button again, it will say continue with your account. Right. It's ⁓ it wants you to log back in with your Not not sign up or whatever. So yeah, it does know that it's you again. So that's tied to your Apple ID, I assume. ⁓ that's great. That seems yeah. So why so the biggest question I have, I guess, I mean, signing with Apple sounds good. ⁓ I guess w do you think of it as like ⁓ do you pro do you prefer it? Do you like it? Well, I do like it. And and do I prefer it? Absolutely prefer it, mostly because then I Well, like do you prefer it over, let's say either having a different sign in system, having no sign in system. ⁓ and what are the situations where you might want to use it as opposed to not? Well, I ⁓ there's there's a lot of reasons not to use it. I it it's it creates friction, right? A lot of people probably you I don't I have to create an account, I don't wanna create an account, you know. So so that is a ⁓ can be like a paywall for some people. You know, I just wanna use the app, I don't wanna have to create an account. I just wanna use the app, I don't wanna have pay, of course. So But if there's reasons where you have certain interactions or certain experiences in your app that are tied to an individual user, you're going to need some way of tracking who that individual user is. A social network, for example. ⁓ The new app that I'm working on is has accounts because one person is going to be looking for a team to join, and so that person is going to need to be continually identified. Whether they ⁓ you know, maybe they haven't used the app in a while, maybe they've deleted the app or they come back to it a year later, you're gonna need to re identify that person as the same as the same person or ideally you would identify Ideally, yeah, right. And I know just I mean, I know I see signing with Apple and some of the apps, and if like if I have to create an account, I usually choose that ⁓ because it's convenient and you know, the first time I think you do you get to choose if you share your email or not, or does it always just share an email? ⁓ you choose if you share your actual email or you can spoof an email or a fake email. A fake email, yes. ⁓ and that's another reason to use sign in with Apple. And the the reason I don't use like my own system is because now on my own server, let's say I set up my own system to to track users, right? Like email address, birthday, name, ⁓ whatever other identifying you know markers you want to use. Now you're responsible for that security. If your server your server gets hacked now that's all out in the open and that's on you, whereas sign in with Apple passes that responsibility off to Apple. Now you you have certain, you know, ⁓ identifying things that you can save on your server, ⁓ but but signing with Apple really reduces the the amount of data that's transferred between ⁓ your your server and or saved on your server, I I I should say. So that's the reason that I that I prefer it. It's also You know, kind of one of these trusted things. So sign in with Google. ⁓ you know. Yeah, I mean I think as far as trusting it, I think feel like it's got that, certainly in the aco apple ecosystem. the one time where sometimes there are some times where I will avoid using it, which is ⁓ well, like my normal Apple ID I have is normally sort of my personal Apple ID, and I'm like, well, if this is like a businessy thing, I'm not gonna wanna use that same Apple IDP tied to it whatever. Or once in a while I won't choose it if it's something I think I'm gonna use long term but really, really infrequently. But ⁓ you've written a blog post is what I hear. Certainly swift.com. I I did. I wrote a bo blog post about this because to go back to that the thing that the most posts that I see about sign in with apple, they don't address the back end side of things. And and remember when when we use that sign in with apple button, you're gonna get a unique identifier for your person, but you also get a JSON web token. That has a bunch of other identific ⁓ identifiers in it. And you can send that JSON Web Token to your server. And then using Vapor, Vapor has a built-in helper that ⁓ is called JWT.aple.verify, and it uses the identity token that's that's within that JSON Web Token and your own app's bundle identifier. That is sent to Apple's server to verify that that ⁓ JWT is valid. And as long as that comes back valid, you'll you'll again get the app's ⁓ the the app user ⁓ their unique identifier, that same sign in with apple identifier that's tied to the iCloud account. So you can use that to to pair with their account on your server. And you've so that way you're doing it almost feels like a triple check. You're you're checking it on device when the sign in with Apple button is tapped. You're sending that JWT to your server, which is querying Apple's server. And and sending back ⁓ on authentication and ⁓ and and everything is verified. So okay, so do you ha I guess first question, I'm I have never used sign in with Apple as a developer. So ⁓ do you have to have like do you have to have that that back end piece? Like what if I don't what if I've got a junkie app or something like that? I was actually that was kind of a question I had for you. For example. Why would you use this but not use the back end? Because Unless you're storing that Apple identifier, I I like I don't I can't think of a way to use only the front end, only the client side of this sign in. ⁓ unless you were using it as like an authentication gate that just making sure your user can sign in. I I honestly couldn't think of a scenario where you wouldn't use this on the back end. Okay. Maybe you can think of something. I honest Yeah, I mean, I don't know. Most sort of real quote real apps have Back end anyway, so it doesn't probably matter. I just I don't know. I'm just thinking. Yeah, no, I I was trying to think of this scenario where where why is this because it does work. You could just implement the front end side on the client and stop there because you'll you'll still get back some information, but you would have to store that. I guess you could store that information in the user's keychain. but if they Yeah, but yeah, that doesn't seem great. Yeah, I I honestly don't know. I I mean I feel like that the if you know half of this is is the server side. I don't see blog posts about it a lot ⁓ for the server side. All right. Well so give us a high level overview of the server side. ⁓ what what's involved there. So you they sign in with Apple on their device, you get ⁓ JSON web token that you send to your server, your server verifies it with Apple. This is is this on the first request or is it every time you Well, every time you sign in you're gonna get a every time you trigger a sign in, you're gonna get ⁓ a new JSON web token because ⁓ if I remember correctly, that is only valid for about five minutes. There are things that you do only get on the first request. ⁓ the email address ⁓ for sure is something you only get on the first time. ⁓ really? ⁓ yeah, so if you don't save it ⁓ and and the first request being the first time that that user hits the sign in with Apple and gets an authentication ⁓ back. the second time they do it and and when when would the second time be? That might be if they deleted your app and reinstalled it. you know it it it will not send again because Apple knows that that that user has tapped that button in that app before. And and so it's not gonna send back an email ⁓ the the next time and that's for I don't you know security or or whatever reason that that Apple chose to do that. But On the server side, when you when you send that JSON web token, ⁓ it comes back as as an authenticated token. So as long as it doesn't throw, you're gonna get a number of items back ⁓ from that, such as do they use a private email, do they have a real user status? And Apple does their own checks on their end to to determine if it's an actual user. Okay. So okay, so first time you go through this process, it gets sent to your server, you've sent it to Apple, they send you back, you get this. sort of information about the user that you only get the one time. And then now how is that different from like if I come back to the app later again ⁓ and I do the sign in or like 'cause like if I know if I sign in with Apple, I don't like it doesn't tell me sign in with Apple every time I launch the app, right? It just does it sometimes. ⁓ why did why do I never have to show it again? Like why don't I have to sign in every time or Yeah, well what I do, I create ⁓ after that sign in has happened, I create a bearer token on my server and send that back. to the app. And that bearer token is going to contain the token that I ⁓ created on my server and the person ID that's tied to that user. And so then on the on the client side, I save that and the person ID is that's one of your database things or this is part of the sign in with Apple system? That's actually one of my database things. So I I tie that bearer token to the to the person account that I created on my server. Wait, wait, I'm sorry. I'm sorry, let's back up a step. ⁓ so I launched the app wow the second time. I've already signed with Apple the first time. Like what what does the app have to do there? Does it have to send something to to Apple or to your like what is it how how what's the process? What I do is I check to see if that if that person has a bearer token, a valid bearer token saved on their keychain. In their keychain, okay. Correct. Yep. And if there is one and it's still valid, then bam, you're just in. And it's valid by based on like the expiration time of the token or Right. Right. Okay. okay, so if that's still valid, you're just in, and you use that to then to send to your server to identify the user, or how does the user get identified from that? That bearer token? Yeah, I guess. like what do you use that token for? I just ⁓ for me I'm just verifying that it exists because if it doesn't exist or is invalid, then I trigger the sign in flow again. And and honestly that's how I handle it. ⁓ it w y yeah, what are your thoughts on that? I don't know. ⁓ I'm so a little naive about all this stuff, ⁓ I guess so I think I am too, and but ⁓ but this is But you've got it in a couple hours. I do I do, but it it still feels like okay, am I doing this correctly, right? Like am I doing something Incredibly stupid that I don't even realize. Yeah, because I I I'm not a security expert. ⁓ this is just the the the flow that I've gone through and you know in in researching signing with Apple, which was actually pretty tough to find information on the server side of how to handle this stuff. I don't even know that much about bearer tokens. It's just I'm creating a ⁓ how do I do it? I create a ⁓ like a random identifier on the server ⁓ and then and and I just send that back ⁓ to my to my client. So when your client then talks to your server on that second launch, how does your cli how does your server know who the client is then? Like how does they do they know that that's associated with me or how does my client know it's talking to that? ⁓ well because I had to think about that for a second. Every query that it sends to ⁓ to to check for new posts, ⁓ it's sending the the like the not the client ID but the the the this the like a user identifier the user identifier. Yeah, yeah. And I and I'm can't remember if I'm using the person identifier that which would be a UUID or the sign in with Apple identifier. ⁓ I I can't remember which of those. In fact I could look at get API real quick to find how I am ⁓ asking about those endpoints. Let me just see. So I'm using okay, I'm using the the the sign in with apple identifier. When I when I send a request to get new new posts, any new posts that are that have been made, I'm using the sign in with apple identifier that is on the client ⁓ to to verify that. So that's how it knows, or that's how I'm using it anyway. So every mess communication from your app to your server, to your backend, is using is sending the sign in with Apple identifier, which then gets validated again, I guess, by the server, or does it use that just as a lookup? Maybe that's proprietary and secret and I shouldn't ask. No, no. It's using a ⁓ and I've got to look at my code again. This is this is great. This is ⁓ this is this is li it's like a live demo, ⁓ because ⁓ I didn't expect these questions, but they're valid questions and and I think it's it's good. So I have a I have protected roots and those roots have to be validated. ⁓ I think it's to create statuses. Yes, I have a token authenticator and this is kind of some middleware stuff that it's called an async bearer authenticator and this is this is vapor side or JSON web token ⁓ o ⁓ side stuff that's making sure that you have a bearer token in there in order to create a post. What did you say it was called again? ⁓ async bearer authenticator. and ⁓ and so I'm filtering on the server side, do I have a qu ⁓ a bearer token that that matches a value that's on the server that matches also with the user. And and so if those things all tie up, then yes that's a user. Yes that's a bearer token. Those are valid and that user can now post or what's what's ever ⁓ in my protected roots. Very cool. So then once you've got all that set up, as your if if you want to add a new API endpoint for your back end or change some data structure, anything like that. You don't you're not having to think about this on every little Right, as long as it's in that protected route, because you can you y it's called ⁓ it's a group, ⁓ root grouped. And so anything that's under that group is just going to be authenticated. Now you're gonna have to provide your C WA or your sign up with Apple identifier in order to in order for that to pass that that gate, that root that authenticated group. ⁓ so that will be part of your new endpoint. But ⁓ Yeah at least call a thing that jumps through those hoops, make sure that it's yeah, but you'd have to do that. You have to do something anyway, right? You have to always make sure that your users who they who you think they are and And do you feel like ⁓ integrating like I know you were using Vapor on the back end. Is does vapor seem like it feel like it works well with sign in with Apple, or do you feel like they're kind of at odds or i irrelevant? No, really I mean the the the the method that is used to handle that sign in with apple process on the back end ⁓ is is actually pretty straightforward. There's a lot of little steps that that are going into it, but you know, it's really that one line that you're sending to Apple to verify that JSON web token. And after that it's kind of up to you how you handle the the identifier that comes back from Apple, that the that sign in with Apple ID, ⁓ the expiration time, you know, how you create your bearer token. That's kind of down to you. And the the one line that it's a helper method and it it's somewhat opaque to me, but you know, it's just jwt.apple.verify. And they have other helper methods for ⁓ sign in with Google, ⁓ but ⁓ you know how that's working a little bit behind the scenes, I don't know. So for that reason I do like Vapor's implementation that that it's like you want to use sign in with Apple, you want to verify with their servers, ⁓ just send that JSON web token and send your apps bundle identifier and And it's it's gonna it's gonna authenticate with them. It's easy it can be, but it maybe isn't super easy, huh? It wasn't immediately clear to me how to do this. In fact, when I first implemented Sign with Apple, it took me a lot longer than I expected because I just didn't feel like I had a whole lot of resources as to what to do with this information once you put it on the back end. You know, how you handle it on the server side. And ⁓ that's why I wrote the blog post. And have you ⁓ did you end up finding Good information somewhere or is it you just kind of stumbled your way through it or chat GPT or Yeah, I'm I'm sure there was a combination of of blog posts, vapor documentation. ⁓ there actually Apple has a a ⁓ fairly decent website about ⁓ signing with Apple with a REST API. And so there there is documentation out there, but kind of collaborating all of it and getting it into one flow, it was it took me a while. ⁓ well I've looked at your ⁓ Your blog post, I have not read all of it. ⁓ 'cause it was just a couple days ago and I haven't had much chance. But ⁓ you have a lot of detail there and a lot of code. A lot of you know, you had said somewhere here, ⁓ you better make sure you get this the first time because you're never gonna get it again. and boy, I can't imagine you that could make testing hard if you have to keep creating a new ID for something, a new Apple ID to Sign up as a new person and it it is hard. In fact, I think on my own device I have my email is nil email because I didn't get it the first time and you are not gonna get it again. ⁓ thankfully I know what my own email is, but ⁓ but yeah, it it can be ⁓ a gotcha if you if you didn't do something right and and you got a whole bunch of users right away and ⁓ y you will not get their emails if if you didn't s I was just thinking about the email because you had said ⁓ last episode that when we were at the ⁓ we had just come from the Swift ⁓ what is called Deep Dish Swift conference and one of the speakers there had talked about collect those email addresses, send the people a message. ⁓ I don't remember did we talk about that last time I think we did. I think we didn't kind of like doing like win back email campaigns. Yeah. I mean and they just did, you know, they just had a little he just demonstrated like you know a little form that's like, hey, keep up to date on what's going on, put in your email. Or but in this case if you're collecting it anyway, collecting those and sending a message say, Hey, we just released a new update. Or, you know, ⁓ that they do amount to something over time. And I made some notes about it, but but it one of the biggest notes that I made was the fact that you actually have to you have to do some ⁓ authorization or you have to ⁓ there there's some stuff you have to do on the app ⁓ app store connect side to say that you are going to be using these emails ⁓ to market to your customers. Yeah, there was there was you can't just send emails because ⁓ and what email are you sending them from? You you gotta do some registration and ⁓ right, right. There was something about that, right? ⁓ and and it it prevents, you know, the the evil aspect, you know, just just harvesting emails. Just harvesting, yeah. Yeah. Well that's great. I I really recommend you go read through Dan's ⁓ blog post. It is Quite detailed, especially if this is something you're interested in doing. ⁓ even if you're not, I think you can learn something probably. But ⁓ yeah. I think that's it. All right. We will ⁓ talk to you all soon. Thanks. Thanks, Drew. See ya. See ya.