Abhinav:
Bubble for native mobile apps is now available. You can build an app that runs on iOS or Android phones and submit it to the App Store or Play Store — all from inside of Bubble.

This is a huge step in making Bubble a truly end-to-end no-code platform. Today, we're going to show you how it works and give you a tour of the product so that you can see it in action.

Abhinav:
If I swipe over — so this is something that's unique to mobile — these are different types of native mobile navigation.

Jeremy:
This one right here is called the stack navigation. What this allows you to do is actually go deeper into your app while keeping track of where you came from. So, you can go 10 levels deep if you wanted to.

Abhinav:
Like views on top of one another?

Jeremy:
Exactly — views on top of one another. And this is really good for maintaining context to things when we go up and down.

This is a modal navigation where you can kind of see the previous view in the background, where we came from. And this is really good for temporary information.

So this is just set up for demo purposes, but when you load a view this way, you're kind of just loading something really quickly because it's really easy to close out of it — swipe away from it. That's the modal navigation.

Abhinav:
So I mean, correct me if I'm wrong — my understanding is that the operating system is what dictates that functionality, right? Like how that plays out on your screen? Or is that something that you could edit in Bubble?

Jeremy:
So, you have control. You have control over when you're going to a view if you want to send it as a stack or you want to send it as a modal — in the editor.

Abhinav:
In the editor?

Jeremy:
Yeah, you do. You don't have full control over it — so like, the way we saw it on Android, it's going to behave differently from iOS. But let's take a look at this real quick in the editor.

So here, when we're going to apply screen number two, we're doing so in the stack. So when I click this, you can see I'm going to this stack navigation. So right here, we are targeting the navigation type — either stack or modal.

Abhinav:
Oh very interesting, okay.

Jeremy:
And the difference again is that a stack is going to maintain its history. So that’s why you have the ability to reset the navigation stack, if you needed to. And there's this helpful little text box here that says it'll prevent it from going back and remove it from all the other stack hierarchy.

So if you needed to go like 10 levels deep and maintain that context, you're going to want to use a stack. If you have some temporary information to show — that's almost like an alert or something — you're going to want to do a modal. Because people will swipe away that modal navigation very quickly.

This just gives you a different option. So instead of just like popping up a sheet for quick information, you can actually go to views this way.

Abhinav:
When you're doing the stack navigation on web — you can go back, you can see the history as to where you came from. The functionality of the back button is preserved?

Jeremy:
Yeah, the stack is there. It just doesn't look as native — because it's not.

The modal navigation is going to just appear. So you're not going to see that modal navigation on the web preview at all. You're still going to be able to go to your view — just not in the same way.

Abhinav:
All the more reason to make sure that at some point in your testing process, you are testing via Bubble Go.

Jeremy:
Yeah, it's extremely important that you test via Bubble Go once you're ready. Once you're done with the web preview stuff and you're really ready to see what this looks like — jump into Bubble Go. It's available for iOS or Android. Log into your Bubble account and then preview your app.

Abhinav:
There are other aspects of the native mobile experience that I'm sure aren't available to easily test on a web preview. Can you talk a little bit more about some of those other native features?

Jeremy:
Yeah, absolutely. Great question.

There are other elements that are available for native only that you need Bubble Go to preview. Those are:

These will not show up on web preview but they will show on Bubble Go. So if you are building an app with those things in mind, make sure you're testing both on Android and iOS to make sure everything is working — but also to see that functionality in action.

Abhinav:
Just something else I want to kind of call out here — because you can switch from web to mobile so easily, it doesn't mean that you can copy and paste elements that don't exist.

So, for example, if you had a repeating group element and you wanted to copy it and then paste it over here, it might show up in the editor but it's not going to work in any of these previews. It's not going to work on web preview, it's not going to work on Bubble Go.

Jeremy:
Yeah — best to probably rebuild it from scratch.

Abhinav:
Yeah.

Jeremy:
It is best to do it that way. And if you wanted to think about how you can start building with mobile in mind — start using more backend workflows for things.

Because a lot of the frontend workflows are going to have to be rebuilt with taps and presses anyway. But backend workflows can exist between both apps. So they'll be shared as you're building — that way your app’s backend stays the same.

Abhinav:
So what about accessing data or saving data? This is something that I’ve seen be very challenging for mobile apps in the past — especially when you're building something that should work offline, or should work in low-connectivity environments.

Jeremy:
Yeah, that's a really good callout.

So when you're building mobile apps, it's important to understand that apps live on your device. So you might not always have internet access. If you're in an elevator or you're on the subway, your app might still be running — but you won't have a connection to Bubble’s database.

So we had to create a way to save and store data locally. And that's called local storage.

Now, local storage is not for everything. You're not going to save your entire user’s profile and account here — but you might want to store something like the current view, the selected color, whether a user has finished onboarding — like a little flag.

So those are some use cases for local storage.

Abhinav:
Got it. So you're not storing large amounts of data. You're storing flags, states, conditions…

Jeremy:
Yeah, exactly.

And we have new actions to support that. So if you're creating a workflow and you want to save something locally, you can do that.

Later, you can reference it with conditions — just like you're used to.

Jeremy:
To make sure that you are connected to those stores — both stores have fees associated with them. So when you create your account, you pay the fee, you get your keys, and then you're set up.

This is a very complicated topic and it's one where it's really easy to mess things up.

So what I have prepared for you is an actual publishing guide, and I highly encourage you to go through this step by step. Make sure you walk through the guide for your settings — so there are some global settings to set up.

Pick the store that you want to deploy to and follow those steps verbatim. That’s going to be the easiest path.

Once you’re all set up, there’s a difference that I want to make sure everyone understands between deploying and publishing.

Deploying in a web context — it happens instantly. That’s what we’re used to. You click deploy, and there’s your change.

That’s never the case with mobile.

Jeremy:
When you actually deploy here, you’re creating a build. A build is a packaged version of your app that can be installed on a mobile device and then submitted to an app store.

What’s really cool here is that builds are labeled automatically, and it's done so in this semantic format.

So, if you have a major version of your app, you'll notice here that there's a new version. If you have a minor version, it's going to change that second number. And if you have a patch, it's going to change that final number.

Abhinav:
I never knew that that was the logic behind those numbers whenever I'm updating my apps.

Jeremy:
Yep, that's the logic! It goes major.minor.patch — and that's really important just for your own reference, so you know where you are and how you're deploying.

So you package your app into a build, you submit your build for approval, you set up your keys and everything like that…

Abhinav:
And then I assume at this point the ball is kind of in the court of the app store to approve you?

Jeremy:
Exactly.

Abhinav:
Yeah, I’ve heard that the Apple Store at least is pretty clear on — if they reject you — they'll provide very specific reasons why. I don't know if you have any experience with that or can speak to that at all?

Jeremy:
Yeah, both stores have pretty clear guidelines. So if you happen to not meet the criteria, they’ll tell you.

Abhinav:
One of the benefits of deploying on web is that if I make an update to my app that I want to push to my live users, when I hit deploy and update it — that happens instantly, like you said.

But you’ve just described this process of deploying to a build, and then that build needs to be pushed to the app store and approved.

If I already have a mobile app on the app store but I deploy to a new mobile build — presumably, I have to go through a similar approval process to get it published.

What happens if there's a really small little update — like a typo or something — in my mobile app that I want to fix? Do I have to go through such a rigid process?

Jeremy:
Well said. You don’t, actually.

So what you’re describing — if you had something that is a very small change — you actually have the ability to make an over-the-air update, also known as an OTAA update.

And this over-the-air update saves you from accidentally shipping something that is like a typo, or a bug, or just a color change — like very small things. You can then update over the air to the latest live version of your build.

Abhinav:
Okay, so we’ll get into that in a second. But I also just want to go back and clarify — when you are clicking deploy, you are creating that build, and then it’s up to the app store and you to then publish that from the app store. So that's the difference between deploying in web and deploying on mobile.

You're really deploying it to create a build, which you are then publishing.

With over-the-air updates, you are always updating the latest live version of your app.

Can you clarify what you mean by “latest live version”?

Jeremy:
Yeah, let’s talk about the live version.

A live version refers to the version of your app that users are currently running on their device. So each live version is tied to a specific build, which is then connected to a version of your app’s backend.

It’s this way of juggling simultaneous versions of your app as you're developing and continuing to develop it — while users are actually using it.

Abhinav:
So let me make sure I understand this correctly:

I deploy my mobile app to a build, I get that build approved and published to the app store, it is now live and users are signing up and using my mobile app.

I then deploy a second build — but I don’t publish it live yet, because maybe I’m still just testing it?

Jeremy:
Yeah, exactly.

So when you make that second build, that is now the latest live version.

So officially, that’s what will get over-the-air updates.

Abhinav:
Oh — even though you're still testing it and it's not public, it's still the latest live version?

Jeremy:
Correct.

Abhinav:
So live meaning on the app store — live doesn’t necessarily mean published and public?

Jeremy:
Exactly.

Abhinav:
Got it.

Jeremy:
Bubble supports multiple live builds running simultaneously — which means users on older builds can continue to use your app without it breaking.

But in the future, you will need to manually manage and deprecate those older versions over time.

So if you’re already on the fifth version and users are overwhelmingly using the newest version, you can start to deprecate them on the app store.

Jeremy:
So if you just made a new build — you can kind of see here on my screen — when you’re in the Deploy popup, since I haven’t made a new build here, I can select:

“Do I want to make a new build?”
or
“Do I want to make an OTAA?”

Abhinav:
Which one is this?

Jeremy:
So for this, you would select OTAA. You would make a patch release. And if you've only submitted one build — if you haven’t made a second build and, let’s say, you installed this on your device — then yeah, the OTAA update will go to that version and that’ll happen seamlessly.

It’ll take like maybe 15 minutes, something like that. It’ll be as quick as you can possibly get with a mobile deploy — that we're used to on web where it’s just like refresh and it goes.

Abhinav:
What does an OTAA look like on the user side of things? Do they get that little notification that says “Your app is ready to update”? Or do they not even see that?

Jeremy:
Ah, great question!

So when you actually go into the app store and you see like “update your app” — that is a new build. That means a new build was submitted and published.

But an OTAA would be seamless. It would just happen under the hood.

Abhinav:
Happen automatically?

Jeremy:
Exactly. The next time you reload the app, it'll load.

So that’s the OTAA updates. Again, all this is covered in detail in those guides. If you have any questions on them, please refer to those guides.

Abhinav:
Another thing that you kind of touched on there is testing. What does that look like, and how do I get others to test my mobile app?

Because this is a big aspect of the development experience. I might want to package my app so that others can test it — friends, family, co-workers — but they might not be collaborators on my Bubble plan.

Jeremy:
Yeah — and they won’t have access to Bubble Go either.

So what you need to do there is, once you have a build that is on one of these app stores, you want to set up those functionalities within those app stores so you can share your app.

With iOS, it’s something called TestFlight, which is its own app. And it allows you to share up to — I believe — 10,000 testers, which is insane. If you have 10,000 friends (laughs), or if you do want to share it publicly, you can share that link and get 10,000 people to test your app before it hits the store.

Abhinav:
Or maybe if you have a waitlist of people who are already really eager to see what you've built.

Jeremy:
Yeah! That’s more like a good way to drip it in.

And then with Android, you have — I believe — up to 100 testers, and you would just add their email to it and then they'll get a direct link.

So your app's not fully published, but they're able to still access it and test it on their device. And it’s highly recommended that you do this — have it be tested a little bit by other people on different devices.

Abhinav:
So now we've seen everything from start to finish. We've gone through all the differences between web and mobile, highlighted a lot of different things — but you might be left feeling:

"Okay, that's a lot of information… Where do I start?"

Jeremy:
My answer to that is: you should start by looking at mobile designs. Because it's different from web design.

By looking at it, you're going to start to notice things.

So here I kind of called it out — so you can kind of see:

Abhinav:
Sorry real quick — the music player, the second-to-last — is that a sheet?

Jeremy:
Yeah, it is! It really is.

Abhinav:
That's wild.

So that's something that I’m realizing now that's especially helpful with this exercise — is not only am I already intuitively familiar with a lot of these elements, but I'm also probably familiar with many different use cases for those elements.

So like that sheet, for example — is a prime opportunity. You could use that as an entire music player. That sheet is probably going to see a lot of interactivity with users compared to some other screens on the app.

And just knowing the full potential that you have in all of these elements — it just depends on what you want to do and what's right for your app.

Jeremy:
Yeah. And there's so much design inspiration out there.

As you go forward to experiment building your own mobile app, I highly recommend you take a look at some mobile inspiration to get started.

Abhinav:
Awesome. Jeremy, thanks so much for your time. Really, really appreciate it.

Jeremy:
Thanks, Abhinav!

This is just the start of our educational material on Bubble for Native Mobile.

Beginning June 10th, we’ll be releasing — section by section — a comprehensive Getting Started Course for Mobile, taught by the brilliant Matt Nerie.

That course will be produced for people who are brand new to native mobile as well as Bubble in general. Matt will walk us step by step from start to finish, building a native mobile app from scratch using many of the features Jeremy just showed us.

So don’t forget to subscribe to our YouTube channel so you’ll be the first to hear.

We’ll see you then — and in the meantime, thanks for watching.