Okay, so in this video, I'll just tell you,
let's say we've got all of our bugs worked out or ready to go.
We have run a test project.
So I've got one right here.
I've opened it up.
I've tested it, feel like it's pretty good.
At this point, we can go down to
settings and we can go down to mobile deployment.
So there's two options here.
We can deploy it to the App Store,
which is our main thing we want to,
that's where we're going to send it, test it on an iPhone.
We can also test it on an Android,
which platform are you on?
Android.
Okay, okay, cool.
So Android is easy because everything in Flutter Flow
is built for Google.
It's on Google Firebase.
Flutter is a Google coding language.
So you could just click download APK
and immediately have this.
You can also go to the top here and just hit download APK
and just push this right to your phone
and test it on a real device.
For iOS, there's a bunch of keys
and things that have to happen.
So the process here is we always want to increment
the build number to plus one.
And then depending on if we've added,
just a few bug fixes, I would bump this to three.
If we were adding a feature,
I would bump this to five and then back to zero.
For this one, we actually haven't done anything.
I'm just going to do another build just for the fun of it.
And then we just hit this, oh, sorry.
And one little thing I found works better
that I just click off the page and click back on.
And it seems to save these numbers better
than if I just immediately hit deploy.
That may just be a placebo effect that makes me feel better.
So we hit deploy and you can also deploy this.
It's not going to actually deploy it
and it's going to fail right here.
But what it'll do is it'll update this APK
to be the latest with that build number
and that version number.
So if I, because whenever I click here,
it's just going to download the latest built one.
So if you want to get all those changes we just made,
hit the deploy,
and then you can always click check status here.
And that's saying it's finished.
I don't think it's even deployed.
It's not even been submitted yet.
So we'll let it come back.
And I think if you-
How long does it take?
So this can take about 10 to 15 minutes to build it.
And then, you know, another five to 10 minutes
for it to show up in the app store.
So the workflow as well, you know,
whether you're on Android or iOS,
you're on a Mac though, right?
Or are you a PC?
No, I actually have a PC.
I might switch.
I'm really like wanting to be different.
Complicated, but I might really switch.
Yeah, I need to-
But I'm pretty sure we switched Lucien from,
he was on a, he was actually on Linux,
I think, when he started.
Yeah, I have Linux too.
Now he's got a little Mac,
he's got a MacBook Air and I think he likes it a lot.
So we log into this, you know,
we'd be in the developer account
and here we could choose between all of our clients
up here, we jump into my apps.
I would come into the app that I wanted to work on
and then go to test flight
and that will actually publish right into this version.
And then the final thing you'd want to do
is you're going to get this little like
missing compliance issue.
I haven't worked out how this needs to be solved
on Flutter flow side,
but the way you solve it is you hit manage,
you hit standard, you hit,
is it going to be in France?
So sorry, it's not going to be in France.
Why is that so complicated?
Why in France?
I don't know why.
Yeah, it's probably some EU, you know, law
that something about privacy.
So we just do that to get it through this little test.
And at this point, it'd be available to download
on your iPhone for testing.
There are much faster workflows
if you have an Android
and I do have an Android for testing.
So if you were going to be extensively doing this
and I'll probably make this in a different video,
there's a way to push the code to a GitHub repository
and then pull it down to your local machine
and then immediately run it through Android Studio
on your device.
And that from like push code to showing it up on your device
you can get it to about two minutes,
which is pretty cool.
So that's where I'm like, I'm editing stuff over here.
And from any page, you can just jump up here,
push the repository, you know, give your commit notes,
hit push, and it pushes it to that branch immediately.
that you now have a backup of all your code from Flutter Flows.
That's a really big deal.
Because most of the no-code tools
don't let you take your code, the source code,
and go and do something else with it in the future.
So I do that on all of our projects.
And I just do 2.4.2, that's 157, push.
And it's just going to push that up to GitHub.
Now we have a backup.
Let's say, like, Flutter Flow loses something,
or, I mean, not that they would.
But let's say we shut down our account,
or they go out of business, or something.
Like, all of our project is now on GitHub.
And it's backed up to GitHub to another source.
So that's just a good piece of mind that it's set up.
So before deploying, you're always pushing to GitHub?
Typically, I will.
That's a good, that would be a good workflow, yes.
All of our projects have that set up already.
So it would be smart to do that.
I wouldn't do it on this project yet,
because we'd obviously want to fix the bugs
before we do any of that.
And then the last thing as well, like, we did the,
that's all mobile.
And if you go down to GitHub here,
this is where you would actually tell it which repository
to push code to.
And then the last piece is just the web publishing.
So only for this particular app are we doing this.
But you would just see here, like, oh,
the last time it was deployed was six days ago.
I just hit publish, and off it goes,
pushing it right now to the web.
So this part is very easy, I think.
And it's very manual.
So you can have each one just deployed as needed.
And so, yeah, that should kind of send this off like this.
And if I check build status, it should be preparing now.
And if I check build status, it says building.
So these are both in progress right now.
And I can come back here and check in 10, 15 minutes
and see.
And then it should show up right into the test flight
here when it's done.
I would say, as the developer, to when
you are finished a version, when you're finished building it,
when you feel like, cool, I'm going
to hand this off for the day, or I'm handing it back
to someone to go test, or you added a new feature,
go ahead and just send the build.
Send the build to the App Store, because then me or Carolina
can just, with one tap, we can just pull it into our device
and start testing it.
It's a little painful as someone who's testing it.
I know Carolina does this as well.
It's like, you guys are like, oh, this new features
version is working, or whatever.
And then we go into it, and you're like, oh,
we have to deploy.
And then we have to wait 15 minutes, 20 minutes.
So typically, my workflow is push it to the App Store
when I'm done for the day.
And then I can just close out of everything,
and it will just push it when it's done.
And then Carolina can even pick it up here and just
do the quick compliance thing.
And then she can test it off on her phone immediately.
But that way, if we're going back and forth,
just passing it between team members,
it's good if you just leave it.
Since this is kind of the last good thing, you hit Deploy.
You can hit Deploy on both of these and the repository.
It's kind of like just closing out for the day,
committing all your changes somewhere.
That's a good process.
Workflow, yeah, for sure.
Yeah.