Talking TestFlight
41:09 Share

What's up everybody, welcome to another episode of the Compulsive Podcast. By now you may be using that new shiny operating system and having to get your apps ready. So we have an episode for you. But first of all, Jeff, how are you doing, buddy?

Doing good. Stressing out about app review, but hey, what else is new? We'll get into that. Yeah. Okay, so let's talk about that. So folks, if you've been keeping up and you should be keeping up, right? Jeff has been working on an app with a time challenge in many ways.

And this week, Apple has not been helping you meet that deadline, have they? No, not at all. So tell us the story. We've all been there, so tell us the story. We'll feel your pain. Apple has some requirements that are...

In my mind, they're not clear. This is one that I'm willing to accept reasonable discussion on, that maybe people are saying that this is clear. But if you have an app with subscriptions, you have to provide in your...

app description on App Store Connect, information about your app's privacy policy, and terms of use. Now, if you go look at the app review guidelines, they really only say privacy policy. They don't say anything about terms of use. But I'm willing to, you know, I've heard this before. It's not clear. Whatever. Anyway, the first version of the app I put out, I only included privacy policy in my

uh app description that's an important point right there because i'm probably going to get canned now i only do a privacy policy and i've never got deemed if so i want to throw that it is only if your app has a consumable subscription that okay you are required to provide the terms of use now again like i said

I read the app review guidelines multiple times trying to look for it. I have the, I don't know if you remember what was this? Oh man, this was several years ago at this point, Apple put together the app review guidelines as like this comic book. Do you remember this?

Oh, I don't remember this. Oh, man. I'll have to find it and see if I can post it. Okay, cool. It is no longer available through Apple, but I definitely downloaded it at one point and have it. But it's this really cool, almost like Marvel Comics-style thing online.

the app review guidelines as of that year. It's like some great art, honestly, really. But yeah, no. So I've read the app review guidelines multiple times. I read them again, double, triple checking that I had everything exactly how they wanted it. Nothing says you are required to provide a terms of use in that app review guidelines, as far as I could tell. I don't know. I digress. All right. However, I did not include these terms of use in my original app description. So

So Apple rejects me. Fair rejection there, in my opinion. Whatever. They rejected me. They said, you have to add your terms of use to your app and to...

your app description. And so I went in, I changed on Revenue Cat, the sponsors of the hackathon, great paywall thing. I just had to go and drop a little link on their paywall page. It's right there. It's in the app. I didn't even have to do anything with my code base. It's there. It's in the app. Then I go and I add the link to my app description. Added at the very bottom, Bark is provided under a standard end user license agreement for more information link. That's what I added.

resubmitted the app, sent it to Apple, rejected again. You need to include this link in your app description. I did. It's right here. And so, yeah, that was what I sent them. I sent them a screenshot and I said, it's in the app description. It's right there. Here it is. It's circled in a red circle. It's right here.

And I've seen this. So I want to back you up here and say it's not even like something that can be misinterpreted. It's very clearly there. It's very clearly in black and white right there. And yeah, so let it run over the weekend and then into today, Monday, and waited for Apple to respond.

They did not respond. They haven't said anything. And so I've pulled the app and resubmitted it. And it has been about 12 hours since then. And I still have no further communication from them. So I'm not sure what I need to do. Like if they want me to change something, I'm happy to change something. But instead, I'm just kind of just being given the silent treatment and it sucks.

So the first thing that comes to mind is, yeah, okay, probably not the greatest day to submit something for review, given that so many people are going to be doing it. But that said, I remember a scenario.

And I'm going to purposefully be sketchy on the details because it's jobby job. But I remember a scenario submitting an app update for an app that had been in the store for a good few years. And they came back and the update had nothing to do with what they mentioned. And they came back and said, you know, basically, we have a problem with some purgatory.

So I looked at it and, you know, and I'm like, okay, well, it looks okay to me. And I went back and looked through the history and,

this piece of verbiage had been like this since day one on this app. So years, right? So, you know, knowing how it is and it's like, you know, okay, you got to be nice. Right. So I replied saying, Hey, um, this piece of verbiage has never changed in the app and it has been fine for X amount of time, X amount of versions and some details. And then, um,

The following day, yeah, sure enough, it just magically got approved. Yep. Not even like a, and I'm not saying that, you know, hey, you should say you're wrong or anything, but not even an acknowledgement of, okay, or anything. It just magically got approved. And this has always been a bit of an area of concern for me, and I know many others, is this not so much the, okay, you know, you didn't approve it,

You gave me some kind of rough explanation that I got to go through documentation for and figure out for myself. But it's very much a one-way communication. And I would argue not the most helpful communication. Right. It is very much a one-way conversation. And, you know, I have issues with that. Yeah. Right. And they have, like, made your...

anecdote kind of semi-official now where they say, if you have an app already in the store and you are doing a bug fix update and we reject you for some reason, you can then officially say, Hey, you know, I need this bug fix out. I'm doing this thing and you know, I will fix it in the next one. You can do this official promise. The part that I'm running into an issue with that is really kind of ruining my life is the,

That does not apply when you are submitting an app for the first time ever. And so this is a case where it's just like, well, we can't say you're going to do this later because this is the first version of the app, period. And so I'm not really getting to get away with this sort of, oh, yeah, I'll totally fix this problem later. They're just like, no, we want it correct the first time. But, you know, yeah. No, it is. It's like...

okay. And what should we do about that? And then they point you to, you know, some long documents. If they would tell me, Hey, we need you to do X. I would totally go do that. Instead. They are just ignoring me. And it's yeah. If you say, Hey, we need you to put this exact wording in here with this exact format of link and,

Fine, I'll do it. I'm happy to do this thing to make you happy to allow me to ship this app. What they are doing instead is they said, you didn't add this link. I go, yes, I did. Here it is. And then I've heard nothing for almost three days now.

Which is never a good sign, right? Because we all know folks. If it's not happened to us, we know someone where you fall into the infinity bucket of, I think I've just fallen down a deep, dark hole, and they're never going to find me again, right? Yep.

And, you know, the problem there is, like you said, you know, even if you pull it and sort of start over. Which I did. Yeah, there's no guarantee, of course. And not that anyone guarantees your app would ever make it in the store. But at the same time, there's also no other way. And therefore, essentially have sleepless nights wondering, is it ever going to happen?

right you know even even if this was not a case where you needed to happen within a certain time frame and i know you allowed plenty of time i think you even put a put a thing on threads about it right yeah before we know which i do a similar thing um and it's like that's plenty of time even to get a problem and deal with it normally so i mean it's almost a redundant question i guess but

You just sit and wait and hope for the best, right? And I mean, I even went through and called Apple and said like, hey, you know, like, I don't remember who it was that recommended this to me. They're like, you know, Apple has this phone line and...

So many people of our age, I guess, are unwilling to pick up the phone and actually call somebody that it's actually kind of understaffed and you can get a hold of a real person pretty quickly. So I did that and they're like, oh, well, we can't help with individual review. What does that statement even mean, right? It's kind of like, well, then why are you here? I've had it recommended before.

to me for other problems, but yeah, it definitely seems like that's more of a, you know, App Store Connect is not working type deal rather than I need help. You know, and I'll say this so you don't have to, you won't get in trouble. Apple, Apple, because we know Apple obviously pays attention to us, right? Apple, stop listening to this podcast for the next couple of minutes. All right, please. Unless you're one of those people that has enough, what's the phrase I'm looking for here?

celebrity status yeah you know or you know a company that has that kind of status or something and then once you start complaining about it on social media next thing you know it gets resolved right which is not 99% of us right

Yeah. Okay. I thought you can start listening again now. Yeah. Yeah. Okay. So anything else you want to add there or should we leave it there? Tune in next episode to see what happens. Yeah.

Find out whether or not I actually made it in time for the hackathon. Hey, folks, if you like what you're hearing in this podcast and you want to help this podcast to continue going forward and having great guests and great conversations, I invite you to become a Patreon supporter. You can go to patreon.com forward slash compile swift, where you will get ad free versions of the podcast along with other content.

Let's talk about the bit that happens before your horror story. And by that, this is something that I think most people know about as Apple developers. But also, there's probably a fair few who don't even think about it. And that's Test Flight.

And so we're going to go into detail here about how we use TestFlight, what it is, why you should use it, maybe why you shouldn't use it, and how you can get through all of that to then get rejected when you put the app review in. So I'll go ahead here. I'll give a quick sort of overview for those of you who don't know what TestFlight is.

If you are familiar with Android platforms, for example, you know of the Google Play Store. There is a Google Play Store console, and it is kind of Google's equivalent of TestFlight. It is a place to go in, and what it allows you to do is push from Xcode your binary up to TestFlight. You'll have seen this probably when you do the archiving process.

And it's a testing, it's a pre-staging area or staging area, I guess, for testing. And it can be tested just by you, by internal groups or external groups. But it's kind of a simulation, I guess I call it, of production before hitting production. Would you say that's a fair description? That's kind of how I describe it to people.

Yeah, it's basically a way to release your app to a subset of users, as you described, kind of two different sets of users. You can either have internal users, which are specifically users who have access to your App Store Connect page, which we'll get into why that may or may not be the best idea, and external users, which is users who do not have access to your App Store Connect page.

And there are a couple different ways that you can add people to those different groups. But yeah, this is a way to give access to your app to people before actually putting it on the App Store. Yeah. So there's, as Jeff says, there's very clearly two groups here.

Well, actually, I guess there's technically three. One of them is it's just you. We'll sort of divide them up here. But it all starts with you do your archive and Xcode. You push it up and you say, hey, I want to send this one to TestFlight. So it goes up into the TestFlight portal. It

It takes sometimes a few minutes, maybe a bit longer, depending on how the day is going. And then eventually it appears on this list where you have your app configured in the portal and different versions, whatever, 0.1, 0.2, different build numbers, which is super important. We'll talk about that because that can catch you out very easily right there.

So do you want to cover the internal group? And I'll go through and explain how I use the external group and how it may be beneficial to other people. Yep. So internal users are users, as I said earlier, who have access to your App Store Connect account. So you add them by going to App Store Connect, going to Users and Access, and literally giving them an account there.

and then adding them to your test flight groups. You can have multiple different groups in test flight, both internal groups and external groups. But this is just literally what is the set of users that are going to be given access to a given build. So the benefit to having people visible as internal users is they –

get immediate access to a build. You do not have to go through any review. You are able to just basically say, I put up this build, this user gets access to it, and they are immediately given access to it. The downside, or at least the

thing to be wary of when using internal groups is you have to give them a role in App Store Connect. And even the most limited roles in App Store Connect have quite a bit of power. So I think the most limited role that you can give to somebody in App Store Connect is customer support. And as customer support, they still have the

ability to purchase and submit technical support incidents, TSIs, those things that you get two of per year to ask for code level support on things. They can do that on your behalf using your account and charge it to you. They can also reply and edit responses to customer reviews in the app store. So if somebody has reviewed your app,

they are able to go in and be like, no, shut up, and have that as your official company response to their review. So make sure that you are giving these internal customer support levels to people that you do actually trust and are making sure that you're not giving too much power away just because you want somebody to be able to test your app.

Once you, you know, it's set up there, one thing that we should point out that applies to both is, assuming it's still the same, you get an email. Me as the tester, right? I would get an email saying, hey, you know, firstly, you would be invited to test the app. Probably most developers have seen that or certainly know of other apps that, you know,

They could have joined to be a tester on it. So it says, hey, you've been invited to test program, blah, blah, blah. So you accept that. And from then on in, you would have, am I right in saying, you know, you do have to have

TestFlight on your device, right? Because it's the only way. Yeah. So then it will get listed in TestFlight on your iPhone, for example. A new version is released. And we'll talk about that here in a second after we've gone through the different groups. They get notified. And actually, depending on the settings, it'll also update the installed app. For example...

Your app, right? I've been on the beta and it's set so that, hey, it just automatically updates when you push out a new one, right? Yep. So anything else you want to cover on the internal group and then I'll talk about the external. No. Okay. So on the external one, this is perhaps the one, would you say it was fair to say a lot of people will have seen because it opens up the possibility for...

in air quotes, anybody to join. Yeah. So what you do is you go to the portal, right? You'll see under testers, there will be the internal testing Jeff just spoke about, and there'll be an external testing and you can create groups. You can give them any name you like, right? So it might be, you know,

QA, developers, exec, you know, never give executives a group. Let's just cross that one off the list. Product managers, don't give them access. But that kind of thing, right? So you create a group and then inside that group,

One of the things you can do is you can assign testers. So, you know, you would go in, you would say, okay, you know, can I add somebody? Naturally, you put in a few details, like, for example, an email address. First name, last name, email address. Yes. Only email address is required.

Yes. Yeah. Although it's always good to have a name for when it comes to grooming these lists because sometimes they can get way out of hand, these lists. So, yeah. And then same thing, right? The person is going to get an email to be invited to the program, so on and so on, as we just described. But this is a way to do this without people being on the internal group, right? Because you...

At least in my opinion, you should keep that internal group as closed as possible and you don't want too many people on there. You want basically what's necessary is what I would describe it as. So for example, your developers, your QA folks, they might be on there, right? But the difference here is as well with an external group, you have this option to create a public link.

Now, you can reverse this because you can go in and disable. I'm looking at one of mine here for endless hurdles. You can go in and disable it. But if you turn it on, it's going to make a link, right? It'll be something like, you know, testflight.apple.com slash join slash some fancy string. And then you can copy that link and that will make it available to essentially anybody who uses that link can go get the app. But

Is it fair to say, in a way, this could be not as helpful as you might think, right? Because you don't want to have a whole bunch of testers who just want to get the app and use it because it's out there and it's new and it's cool and they want to play with it and they never give you any feedback. That is not the desired outcome. It depends on your...

goals with the app. But yeah. Yeah, because the reason I say it like that is because for a while people saw this as a way to get around, I don't have to put it in the store, I can manage it, and it's like, that's not the way this was meant to be used.

And looking here – sorry, go on. I was just going to say – and there are limitations to that in order to prevent it from being used that way. You can have a maximum of – I believe it's 10,000 external testers. And so if you think that your app is never going to have more than 10,000 users, hey, yeah, sure, just put it on TestFlight. Just go for it. And just do it that way. But the other downside is –

I don't believe it's possible to actually charge any money through in-app purchase if you have your app on TestFlight because any app that's been distributed through TestFlight, all in-app purchases are completely free. Yeah, it's my understanding that, yeah, it's like folks, it's like having your own, it's like a QA stack, right? You know, it's kind of like not real world, right? So, well, I hope people's QA stack is isolated from the real world. Let's put it that way.

that's a whole other bucket of trouble. For example, yes, there's this limit. I'm noticing here on the group management, as I'm looking at it here on the public link, it does actually say next to it, test account, so like four of 10. You can edit that limit. I may have set mine to 10 if I remember rightly. You can limit the number of users who are able to use the public link. Yes.

You can set a maximum amount. You see this often pretty with like big high profile test flights. So, for example, the one that I'm thinking of is Ivory, the tap bots app for Mastodon. I think that what they did was they published their test flight links and they did it like 50 people at a time. And then they would go bump that and they'd be like, hey, there's 50 slots open. First come, first served.

And yeah, they would roll it out more a period at a time. So if you want to have a large set of users, but you don't want to be overwhelmed by a massive amount right up front, that's another way to do it is to say, hey, you know, I'm going to set a low limit. I'm going to increase that limit over time just as I'm ready to make sure that I have the ability to support this many users. Yeah, actually, I think that's how I got into the ivory app was I was...

signed up to be on the beta, got in, and then I'm still using it now because now it's released and pay for it because love it. But yes, and another good reason to do this is real world example here, folks. You don't want to be in a situation where you have a mountain of users on there

And then you release a build, has a terrible screw up in it. Like they can't log in or something. Because guess what? You're going to get a lot of messages. Hey, I mean, at least you're releasing it to TestFlight and not to your real world. That's very true. I hope you stop there. Yeah. And so that's why in my mind, sometimes too, like you suggested, it's a good suggestion. Those, you know, grow, slowly expand the list is very much...

in my mind, a people version of alpha, beta, so on and so on, right? You hope that over time, those reports get less and less, right? And then you grow the group. So that's how this works. And your builds will appear on the list in TestFlight. And you can assign, you know, especially with the external groups and so on, you can assign them to these builds. So...

you may have a specific build that you want tested for a specific group of people. And so you can assign it to that group. Right. And then in there too, you get some, you know, obviously on the page, you can get some stats like sessions, how many people have pulled that one down, how many times it's crashed, but,

But really, go use the analytics, right? And the tools in Xcode for that kind of thing. But it's a good way of knowing, okay, someone at least has downloaded it and we're off and running. So that is how you set up

your initial usage of basic setup on TestFlight, you're now ready to rock and roll and away you go. Time for a break. Hey, everybody. It's Peter Whittem here from the Compile Swift Podcast. I want to tell you about Setapp. Setapp is a service that provides a subscription fee of just $10 a month, and you get access to over 200 Mac applications, and it's also available now on iOS as part of that deal.

I use the service because it just has a ton of really good first-rate apps that I use all the time. For me, it's invaluable as a developer to have access to tools for things like APIs, for planning projects, writing emails, writing documentation. You get all of these things, including database apps, all of that kind of stuff right there on the Setapps service for just $10 a month. You can use as many or as few applications as you need.

If you're interested in checking this out, go to peterwhitam.com, P-E-T-E-R-W-I-T-H-A-M.com forward slash set app, S-E-T-A-P-P. And you can see the details there. And it's got a link that you can go over and start using the service and see how it works out for you. I strongly recommend this to every Mac user. Break time over.

But, and here's a but, there's always a but, right? Go on, Jeff, give us the but. So the major difference between external testing and internal testing that we haven't really covered yet is beta app review.

So when you're going to internal testing, you can just publish those builds to any given user. With external testing, you have to go through Apple first. And they have to give your app an app review very similar to the actual App Store app review, but a little bit less thorough. Obviously, they're not checking app metadata. They're not checking anything like that. They're really just making sure...

Do you have an actual app? You can't just publish, you know, a sample project to the app store, your hello world. They do make sure that you have an actual app there to publish. Pictures of diamonds and rubies. Exactly. And they're obviously checking to make sure that you're not publishing anything malicious, anything illegal, anything like that.

But yeah, you do have to get this app through beta app review. Now, the interesting thing about how this works is you only have to do this when you change the version number. And to clarify, I mean the marketing version number. So you see like a 1.0 or a 2.0. You can then publish more builds with different build numbers under the same name.

version number and Apple generally will not check that again. They reserve the right to, but usually what happens is as long as you're publishing the same app, same version number, different build numbers, you don't have to go through beta app review again. However, next time you rev your version number, you will have to go through that again. Good point. And, and let's talk about those build numbers here for a second, because,

So there is something interesting here that folks should pay attention to because you want to increment your build numbers. And the reason for that is you cannot submit the same version number and build number for an app. It'll come back and say, hey, this already exists and go increment that.

you can just change one of them, right? So you could, you know, pretty common to change a build number, for example. Now I'm talking about iOS here because that's where my most, you know, my experience is with TestFlight and the App Store.

So you can increment your build number manually or if you've got CI/CD, actually, honestly, the best answer is to have CI/CD and let it do it for you so you don't have to remember and keep track of these things. But Jeff, you want to jump in here with something that I did not know.

Yeah, this is true. What you said for iOS, tvOS, visionOS, those are the three platforms that you can have on App Store Connect that add those where it's true. On macOS specifically, you cannot reuse a build number at all.

So on iOS, tvOS, VisionOS, and you may be asking, where's watchOS? Well, you can't submit a watchOS app without an iOS app, so it's under iOS. It's kind of covered. Yeah. It's covered. On iOS, tvOS, and VisionOS, you can submit marketing version 1.0 build number 10. And then you can turn around and you can submit marketing version 1.1 build number 10. And it is totally fine with that.

On macOS, that second one would fail because you have already used build number 10. So instead, on macOS, you would have to do marketing version 1.0, build number 10, marketing version 1.1, build number 11. You cannot reuse that same build number on macOS specifically. That's interesting. I did not. So I've never submitted an app.

to TestFlight or anything like that for the Mac. So I had not come across this and that's good to know. So that is pretty much how you use TestFlight and reasons you would use it. Now, this also, of course, you're going to adapt and use your own workflows as to how you're going to use this. If you're in a team, obviously, it's good to discuss this. But truly, I think

At least from my perspective, don't want to speak for Jeff here. I think the best answer is set up your CICD, right? Fastlane or whatever your choice is. Once you've gone through the pain of having it set up and just let it take care of all this for you, the signing and everything else. We didn't even talk about that, but I think, you know, it would be fair to say, if you're listening to this podcast and you're a developer, you know the pain of signing apps, right? It's as simple as that. Yeah.

We've got everything in here, right? We've got it set up. The test flight is going out to folks. Folks are using it. If you've ever used an app, by the way, folks, on test flight, when you install it, you know, you will see that screen that says, hey, you know, developer hopefully puts in some notes saying, I want you to look at this, this and this. And then it says, hey, you can take a screenshot and you can send them feedback. So what is that feedback? And

What information can you put in there and how does that work, Jeff? Yeah, so what the developer gets back from that is obviously the screenshot that was sent and then a bunch of useful information about the user's experience at the time. And so it'll have stuff like what device are they using? What version number are they using? What battery level is there? How much disk space do they have free? So just a bunch of little useful analytics stuff.

Um, the user can obviously include their screenshot and also include a little bit of commentary. And then you're given all of this as like a bundle and it includes, um,

who actually submitted this information to you. And so you're able to use that information and go through and see if you can figure out, you know, what was the bug that was done there. Yeah, there's a zip bundle. It includes some JSON. You can also open it in Xcode. I'm not entirely sure what that does for the screenshot feedback.

For the crash feedback, it's a little bit different, but I haven't gotten into the crash feedback. Yeah, I love the crash feedback because it'll take you right to it. Yep. Well, I don't like it because I don't want to get any. You don't want to get crash feedback. Okay, folks. So I'm going to give you an example here, right? So I'm on the TestFlight beta for Jeff's barcodes app. And what happens here is, right, I've got the app on my device here, and I can take a screenshot or not.

I always recommend folks giving as much information to the developer as you can. Screenshots are priceless. Let me just say that. But anyway, I go into TestFlight. And when I'm looking at the app listing in TestFlight, you'll see that there's a send...

Beta, beta, beta, English, I know, feedback button. And when I tap on that, what's going to happen is there's a little menu comes up, says include screenshot, don't include screenshot, right? And so I'm just going to, since this is an example, I'm just going to hit don't include screenshot. And then it says, you know, share your email address. And it is optional. I would recommend if you have gone to the time and trouble of...

testing this app for a developer and you found something, me as a developer, I would say, please put your email in so that the very least, not only can I respond to your comments, but I can say thank you for sending me this message. I put in the email address and then basically it says, the text box underneath, tell us about your experience. In there, you're going to put as much detail as you possibly can. Help the developer out.

And then you hit submit and off it goes to the portal. So with that, once it hits the portal, Jeff, yeah, let's talk about that package. Yeah. So once it hits the portal for screenshot feedback, you get the screenshot itself. If it was included, you get all of the information that the user attached and filled into this form along with their email address. You also get a bunch of kind of built in information that Apple has included in

automatically by default. So you get the app version, both the version number and the build number. You get some information about their device, what device are they running on, what version of iOS, some more obscure information like battery level and how much disk space they had and what version of internet they were connected to, whether they're on wifi or are they on cellular, that kind of thing. And all of that information is kind of wrapped up and sent to you as a single piece of feedback that

In theory, you can download these. It doesn't seem to be working for me right now, but you should be able to get all of that information in another form as well. I believe, if I recall correctly, it's like a JSON form plus your screenshot plus some of the other information there. That is another way that you can access this information without having to be on the App Store Connect portal just to see this. For a crash, however, you get very similar things. You can't really see too much on the portal itself.

But what you get is user's email, the information that they included with it, all of that same app and device information. And then if you do download that, you also get the actual crash log. And so this is the same sort of crash log that you would see any other time. It's got your stack trace. It's not symbolicated by default, but you can open it in Xcode. Xcode will symbolicate it for you. Get all of the information that you need to see where did this crash happen.

And that is the priceless part right there, right? I mean, that is why, you know, you want to give the developer as much information as you can because the details that they get in the logs and everything else can guide them to the problem in the app. They're sitting there staring at it. But me as the developer...

I know what should happen at this stage in the application, and I need to be painted a really clear picture what happened to you as the user. The only way I can do that is for you to give me as much information as possible. I always say to folks, like, hey, there is no such thing as too much information. Even something that may seem incidental to you can suddenly have a whole lot of weight. You might be

one of 10 or one of 100 people saying the same thing. That is how also as developers, we try to figure out what's the most important bug to fix here. It might not seem like a big deal to you, but if you're one of 100 people reporting it, it's a big deal to us.

Yeah, yeah. You may have that one extra bit of information that cracks the case. Yeah, yeah. Because the idea here is all of this is supposed to make the world better before we go to production. This is the last step, right? And you can go through this, you know, as we were saying earlier about the cycles, the build numbers.

and the version numbers. We can go through this many, many times until we get to the point where we're like, okay, release time and fingers crossed. Let's switch that up and what does that look like? This is the next part that's straightforward.

You've already got your app set up in the App Store Connect, right? And so when you're getting ready to distribute, and we're not going to talk about distribution here, but we'll just sort of briefly give you an idea of how you transition from one to the other. So what happens is you go through, you set up your version for distribution, and you can select a binary, right, based on however many is listed.

via TestFlight. So you might have 1.0 build 127, right? 1 through 127. And that's where you're going to select your specific build. It doesn't necessarily have to be the last one you pushed up. And that's an important point because I've been there, right? Where it's like, oh, actually, we don't want to do the latest one. The one before was better. We want to ship that one. So you do get to choose and pick it there.

That is pretty much the process. Jeff, is there anything else we want to cover here? I feel like we've got, hopefully, given a pretty good walkthrough and explanation to folks who are wondering, what is this test flight and how do I use this to my advantage? Yeah.

Yeah, no, I think we've covered pretty much all of the things that you might want to know about TestPlate. Awesome. And this is so timely because I'm going to predict that at least 10 apps need to be updated this week with iOS 18 and so on and all the different platforms, right? So hopefully, you know, folks, go install your updated OSs and listen to the podcast while that's happening. You've got time. Trust me. You've got time. Yeah. Yeah.

All right, so that's what we got for you this week, folks. Just want to say again, thank you to all the Patreon supporters. You're awesome, right? You know, and we've been putting out some extra content for you folks to say thank you for supporting the podcast. It really does make a difference. You want to be a member, go to patreon.com forward slash CompileSuite. We'd love to have you there. And we will put links in the show notes for the Discord where you can come and join the fun as well. But Jeff, where can they find you?

And you can find everything that I have to do at Cocotype.com. There you go. You can find me at CompileSwift.com. Don't worry, folks. You'll remember these. If we say them enough times, it's just going to become a thing, right? All right, Jeff. Thank you, buddy. I'm hoping next time we can tell folks of the wonderful, wonderful experience you had where life just got better for you on your store. Lovely.

Good luck, my friend. And with that, folks, we will speak to you in the next episode. Goodbye.