I think we are in the extreme here, but noted…
Wait… then its not about WebView… its falls under their content policy. Sorry guys. Not falling for that one.
Take care and do your thing they way you want to do it
I think we are in the extreme here, but noted…
Wait… then its not about WebView… its falls under their content policy. Sorry guys. Not falling for that one.
Take care and do your thing they way you want to do it
Why wrap your web app and not leave it as a web app? Especially if you’re only validating an idea.
The only reason these days for a mobile app is to access user device features.
My experience is that is not related to webview, it’s the content. If your app is a wrapper of an existing website without any app-only section then it will probably get rejected. If you add features that are enabled only in the app and it can be seen during the screening process then the app will probably get accepted. So have some page/section that does something meaningful in the app but stays hidden in the browser, in a way that can be seen, and you have better chances of getting the app approved.
Of course it’s just my experience, yours can be different.
Also there are a lot of good reasons to use a native app instead of a wrapper
Nooooo… you have a lot higher chance of users opening up your app ifs it’s local. Typing a web app address in, is a barrier.
For simple idea validation a bubble web app can do! You are absolutly right
Then wrap it (which is not that hard once done 1-2 times) and you can test user interaction on the app stores and develop the app closer to end-user-needs. Once its modeled to user needs, continue with the wrapped version or rebuild in the editor.
Early stag web app = aquire / test (unless you have a brand, think LinkedIn etc.)
Native / wrapped app = usage / retention
I am validating a platform and its design - not ideas. My case is a bit special - A validated multi tenant concept with low tech (video content) requirements. Wrapping here is the right approach.
My argument is that wrappers are not “hell”. They bring a whole new level of possibilities to the product development table and very useful for developing the product. And in many cases, far good enough for most users. So why bother building two versions. Or 3 counting desktop.
Either sticking with the wrapped app (and save a lot of effort - And potentially money) or rebuilding for higher performance - depends on your product requirements.
Yeah I wrote it without noticing the huge increases in Growth and Team plans. I’m not really bothered by the difference from web to mobile. You’ve got plugins that barely do anything yet charge the same price per month.
Bubble’s mobile pricing is probably based on more than just the current state of the product. We don’t know their exact costs, but there’s likely a lot happening under the hood things like maintaining a cross-platform runtime, building out native bridges (camera, GPS, notifications, storage, etc.), Apple and Google compliance, app build infrastructure (compiling and packaging), and all the support tooling that comes with native deployment. That’s all way more complex and expensive than running browser-based web apps on a server.
They’re probably also trying to cover the cost of maintaining parallel mobile infrastructure, pushing updates, fixing OS-specific bugs, managing certificates and build queues, and ensuring secure OTA (over-the-air) delivery. None of that’s cheap especially at scale.
Plus, their investors are expecting growth and return they’ll be pricing mobile for long-term margins, not just parity with web. So even if it’s in beta and feels half-baked right now, they’re pricing it based on what it could become positioning it as a full-on no-code mobile development platform, not just a wrapper for web apps. Their pricing structure makes sense for them and their shareholders.
That said, I totally get why people are frustrated especially when the web platform is more mature, cheaper, and far more capable. The key thing is whether Bubble will be responsive to user feedback and make it worth the extra cost. If they listen and keep improving, it might justify the price. But yeah, they’re going to need to prove that fast. They’ve proven that they’re responsive with their change on the web pricing issue we all had (albeit took a lot of us very strongly to make that change).
We all have to remember that they do A LOT of research and KNOW the backlash they’ll receive getting it wrong after last time. They’ve had very indepth conversations internally, and with shareholders. I wouldn’t be surprised to find out that @randomanon is right and they’ll adjust the pricing nearer October or push charging us to December+ if they’re unable to push out certain features as expected.
Nevertheless, I love Bubble and the team. It’s a joy to use, I’m just glad they’re not forcing us all to pay more and mobile is included as standard, that would suck. I’m very very happy to hear they’ve not done that. If you want it, pay the price. If you don’t, thank God it hasn’t changed!
Just stopping by to thank everyone so far for sharing your opinions! There will be a lot of lessons learned and improvements driven by this community’s feedback so it’s great to see you all taking the time to share.
Keep it coming!
[Citation needed]
Updated
I agree.
It’s not something most understand though until they’ve worked with dozens and dozens of apps.
The app stores give zero credibility. If they did there would be more than the less of 1% that are even remotely successful.
It all has to do with what your app does for the user.
They are charging more and offering less, they should increase the WU limits. They are hurting users, who pay more to use less, which could reduce the user base in the long run.
I don’t disagree that wrapping a web app is not as hard as most think it is.
So far my clients prefer webapps over native (where possible) because both they and their end users range between teens to seniors.
It also makes it easier for them to use their own redirects (QR Codes etc) to point to customizable parts of my webapp since it’s just a URL and their end users won’t have to download an app just to interface with a link.
I do intend to build a companion native app for notifications, Oauth with biometrics, one touch approvals and comments. Telegram is great but it gets tangled up with other Telegram messages.
I had clients wanting web apps only as well. Good point with QR codes. Can be a mess to set up so that it works smoothly with native apps.
I have mostly given up on that, using the web app for redirects and QR codes and leaving the native as they are.
I get the same feeling. Also, the mobile editor is an additional codebase / plugin system etc to maintain for bubble,… but have no insight into the financials or resources required for that so will
Leave it there.
I had hoped for a comprehensive semi-native wrapper with more native feature libraries, offline data etc. keeping things in one place.
And still missing 100eds of fixes and improvements to the existing editor… mostly looking forward to that, but worried about resource allocation the coming year. Might shift back a bit when the native hype cools off and they have steady dev procedures for the mobile editor.
The hackathons they did on the editor was amazing. Chipping off a lot of feature requests from the idea board.
They need to do a “Bubble build day” like every month.
Hello again, I thought it would be a good idea to share a couple of screenshots from the livestream for everyone’s benefit here:
And before anyone asks: the mobile team is current shaping all projects for the roadmap. Once they are finished we’ll have dates and more specifics to share