So in this video, we'll just quickly show you guys how to actually deploy the app to the App Store.
So let's say it's in TestFlight, it says 156, and this is build 242.
And if I click on the App Store here, you'll see that we're at 241.
So we're a version behind on what's actually public.
This TestFlight is just kind of a developer version that we can kick around and test.
It's still all tied to a production database, but the way we've got it configured,
but it's not actually in the App Store.
So just because we got it into TestFlight doesn't mean it's in the App Store yet.
So we'll go to the App Store.
This will be the process.
You actually click up the new version.
So now we're going to be 2.4.2.
Hit Create.
You just want to make sure those line up.
And then it allows you to change anything with the app.
So if we wanted to change the screenshots, if we wanted to change the description,
we would take a second here and just say what's new in this version.
So we would say, I put your speed improvements, and now users can...
Instead of saying users, I'd say now you can like other people's posts or something like that.
Just something simple, written in plain English.
This is not a time to put all your dev developer notes in there.
We typically push the developer notes into Notion.
So under Notion...
Why is this not saying it?
Okay.
I think this is on a different computer.
Okay.
So if you just search for wisdom release, app releases,
and we do a little release notes like this,
and you'll see like, I'll just make a 2.4.1.
We added this.
Like now admins can do this group thing, make these improvements.
So a lot of the like behind the scenes stuff, like, oh, we changed the local state
to API to now use the Firebase field for the API token.
Like the users don't care about that.
And to be honest, the client doesn't even care about that.
But just so that we don't forget that we did that in this version,
that would be something we'd want to go and just note in these release notes.
And we just put the version and the date it was released.
And then I typically do like a new features, an improvements area, and a fixes.
So stuff you couldn't do before that now you can do.
Things that you had the feature, but now it works a lot better.
And then fixes is like straight up bug issues.
And then developer notes is just all the techie stuff that we just want.
So here, like exactly what we just did.
New Firebase JWT, remove tribe user ID, and put the Firebase user ID.
So now I can just track that that was a 2.0 update.
And because of that massive rework of the auth and everything,
we also added a bunch of new like things to this, new assignments tab.
We had to use a lot of like Flutter flow.
I mean, Firebase related data now.
I went ahead and jumped it from 1.0 to 2.0,
because it was kind of like architectural.
It was totally different.
Whereas 1.5, 1.6.
So you can see all the way back to our first little release here.
Or at least when we started writing the notes.
Yeah.
So that's the workflow to get into here.
And then what you would do is you would scroll down here.
We would hit add build.
We would choose the build that we want to publish with this.
And then we still have, like this should be all pre-filled,
but we have to have this user account and this password work.
So that when Apple goes to test it, that they have an account to test it with.
And then in the notes, you can just write some things in here if you want.
Like, hey, we, you know, change the authentication, you know, et cetera.
And then you can say, we want to manually release this.
So once it's approved, it'll hold it until we push the deploy button.
Or you can just say like, when it's approved, push it to the store immediately.
Which typically I'll do that for these smaller releases.
We don't do phased releases, right?
We don't have so many users that we have to like phase in the new version.
We just release it to all users.
And we don't need to, you know, if we did such a major update,
we could reset the rating, which means it would lose all the comments
and all the ratings of the app.
Sometimes it's helpful if you have like a really bad version
and then you make a really good version and you're like, honestly,
and it's some of this kind of happened with this app.
If you went and looked at it, it's like a 3.9 right now out of five.
Um, so we had, you know, early on, we had a lot of bugs in the app.
So the first, you know, week or two that it was out, we, we had a lot of complaints, not a lot.
I mean, like five or six, but when someone comes in and rates the one star, it really hurts.
Yeah.
Yeah. So then you would hit save here and then you would hit add for review.
And then this final step, so now it's kind of prepping it, it's getting it ready.
And then you would hit submit to the app review up here.
So just make sure you hit this final submit.
Typically, this is something I've just been doing, um, because I'm typically working
directly with that, but I definitely want to hand this off so that if you want to publish
a version, you can do that yourself without me.
Um, and that's how to do it in the app store.
And then I'm going to stop this and start this again for the Android as well.