They’re built using different development frameworks
Bubble has always ‘generated code’… there’s no change here. Mobile native will generate code, and will still require the proprietary software support that Bubble keeps a close secret. I’m not saying that’s right or wrong, just that there’s no reason why this update would entail code export
From what I have seen is that a Bubble app (at least the frontend) is a big JSON which is turned into HTML and JS using some kind of converter. In that case it might also be possible to generate native code the same way.
@nick.carroll This all sounds amazing. Hopefully you guys have background GPS in mind so food delivery/field technician tracking/taxi apps are possible even when the driver has their phone screen off
Right now I’ve only seen one app wrapper support background geolocation. You trigger the background location from a workflow, then that tells the native app portion to send a webhook every X seconds with an identifier (usually user’s uid) and other location data. You guys could probably do it much more seamlessly and integrated.
I had to look into the differences and found this article pretty insightful
After reading it, seems like the next new big feature of Bubble should be PWAs…give users the choice between Native and PWA as the Pros/Cons and Use cases explored in the article seem to point toward a wide variety of reasons some business may choose one over the other.
I prefer PWAs myself. But unfortunately customers don’t. They feel we are not up there if we don’t have apps in play/app stores. Also, people go there and search for our brand names.
I have built my app as PWA. But struggled a lot to get the “ask user to install” option. Yeah having that and in general support for PWA app would be great.
When I talk to my friends about my ‘app’ they always ask when it’ll be in the app store. To them it’s less abkut capabilities, and more about the approved distribution of the app store.
Excited about these updates a couple of questions,
App Store Submission Challenges**: In the past, submitting apps to the App Store has been tricky due to different requirements for various categories. For instance, apps in the kids category have specific rules regarding third-party analytics and IDFA. Will the new mobile app builder ensure compliance with these IDFA rules?
In-App Purchases**: What are the plans for implementing in-app purchases? Are you considering using an external tool like RevenueCat, or is there a plan to build a solution that works natively with the App Store?
Hi everyone, thanks for the great questions. Will try and answer ones that haven’t already been addressed by my second post or members of the community.
Regarding the plugin editor API, no additional details to share on this yet.
To reiterate, projects can be web only (like today), mobile only, or web + mobile. During the alpha, we are still gathering feedback about pricing and will share more details during the beta.
If you feel a PWA or wrapper is the better choice for your app and use case, you can 100% continue to do so, there will be no changes there. As for hybrid apps, we will be supporting web views at some point, which would allow you to open existing mobile friendly web pages in your application. Just note that these views will not be supported offline like the native views will be.
Location services support will include background geolocation, provided the end user has the proper permissions to allow this. In app purchases will be supported eventually, but no additional details to share at this stage. In general, our approach is to integrate natively rather than use a third party service.
For app store submission, there will always be a nominal amount of work and due diligence required on the user’s end to make sure their app is ready for submission - like any specific regulations depending on the type of app / business. That being said, we aim to make this process easier by surfacing any permissions your app is using that needs to be explained, as well as clear documentation that walks you through every step.
And lastly, to gear up for native mobile on existing apps, the more modular the logic of your current app (especially backend workflows), the easier it will be to integrate a mobile app as a part of an existing project.
Thanks everyone for the excitement! We’ll share more updates as soon as we can.
– Nick
Presumably because this would mean that updating a workflow (e.g signing a user up) would entail updating both the web app + mobile native page workflows, vs if you had a backend workflow, the same could be used for both?
You know the next question, right When can we have a proper (App connector is fairly buggy) call backend workflow from front-end feature that returns data from BE workflows and runs them synchronously? Would be one of the biggest things Bubble could do to support the mobile native transition (among a load of other useful things this allows to happen more easily).
Thanks @boston85719, yeah I missed to read the code export response.
Though I am surprised why it is like that they can’t provide code export here.
In existing Bubble for web, probably architecture is such that they have one common engine which runs on all of our applications using our data schema. In that case, generating a code specific to an application would be challenging (still feasible, but lot of work). (But their AI engine could generate that code maybe? )
But now here, since they are generating build for Android/iOS, I believe it would be more like they would be generating code and then building the build out of it. In that case, export would be quite feasible. It would just be a strategic choice on their part on whether to do it or not, or whether to charge for it or not, etc.
All this is with some guesses and assumptions limited to my understanding on how things work. They can clarify best on how exactly it is.
Regarding other reply, I had actually read that one. In fact I had quoted his reply in my comment itself. But it was still not clear on exactly what would be the behaviour of reusables. Also, the reply says “certain visual elements” and “page workflows”. Now with that it is not clear whether we’d be able to do “copy with workflows” on groups.
After reading the posts and pondering, about whatever information I know so far, for a few days, I have come to realize that it will be a bad idea to copy-paste convert my webapps to mobile. A new build for mobile seems safer.
Not that I have any need to convert to mobile. I’ll be readying the popcorn for the “Why can’t my converted mobile apps work?” posts.
Seem that I’m the only one not really excited by this…
a) You will pay again to build mobile app.
b) It will increase built time and maintenance cost.
c) Increase chance of bugs
d) Bubble is learning how to do mobile stuff integrated with Bubble while we have to deal with bugs often when they do new releases (including small releases…).
e) There’s not a lot of thing in this offer that existing plugin/Bubble wrapper doesn’t already offer. Without the need to built a “mobile” version.
I wondering while I should built a mobile app using Bubble when there’s already a lot of players in mobile app builder, with a lot more experience at this, that could be already integrated with Bubble DB and auth.
After over 10 years of building apps in the ‘code world’ I’m starting to think native apps are fading out in user popularity overall. Just my opinion, and obviously other opinions will differ. Some of the biggest apps are now PWAs.
Some say apps give them more clout because they’re in the app stores. So are millions of others apps that sit dormant. The user only cares about what the site can do for them.
PWAs can be used by users on desktop or mobile and saved to the home screen.
Uber. Tinder. Trivago. Spotify. Starbucks. AirBnb…just to name a few are PWAs.
I think too many times people confuse effort with results. I spent about a year learning Webflow…it’s a nice platform…but came to the conclusion the user doesn’t care if things twirl or spin or load upside down or sideways. They care about the content and what it can do for them. The only people that do care are the business owners that want a website built…and most of those sites sit lonely all year.
I’ve spent about the last year learning Bubble. I love it because it can do so much with so little coding. I can use progressier and for $15 a month get a ton of features for a PWA. Features that would take a long time to code.
So, I’m not excited about the app part, but, I am excited that Bubble is expanding and adding new features for those that want them.
All these apps that you mentioned are PWAs only? They do not have appstore/playstore presence? Or are you saying that they have PWA (or maybe TWA for android) as well apart from their native play/app store apps?
If these PWAs/TWAs/Lite apps are additional apps apart from native mobile apps, then it is a totally different point. It is not Native vs PWA then. Then it is Native vs Native+PWAs.
Either way I think this topic is a bit of a distraction from main point of this thread. Maybe we can have another thread to discuss this topic.