Migration Pathway: Wrapper (BDK) > Bubble Native Wrapper > Full Bubble Native

I just wanted to put down some of my thoughts around this, as our internal team has been discussing this at length.

The position that we’re in (and I believe many others) is we have an app built on BDK, which is starting to fail, and there is no longer any support for it. The moment Bubble announced they were building native, all the wrappers that primarily served Bubble apps (including BDK) stopped investing in their solutions, so we can’t just move to another wrapper solution without the same risks involved that we already have with BDK.

We have almost 1,000 B2B active users on our app, so we have to have it working and reliable. This situation is forcing us to move to a new mobile app solution quickly, within the next 90-120 days, to ensure we can continue to serve our users.

Our current options are:

A. Rebuild a native mobile app outside of Bubble (React Native/Flutter).
B. Make a transition to Bubble Native before it is ready for the complexity we have in our native experience.

Because we already have so many users, we cannot remove functionality that our users are relying on in our app. So, the only way for us to move to option B is for us to use Bubble Native as a replacement wrapper (using webviews) in the short term. Then, we can rebuild portions of our app slowly over time as Bubble Native matures and can handle the complexity.

My current hope and proposition for the Bubble Native team is for them to prioritize supporting this migration pathway from existing wrappers into a Bubble Native wrapper, just to keep apps in the eco-system. Otherwise, they’re going to lose a lot of serious existing apps (like ours) that are on wrappers and can’t wait around any longer.

I think there’s a really cool journey we can go on together, where the Bubble Native team launches new features, and we can be refactoring parts of our mobile web apps into the native functionality over time. This feedback from existing production app publishers is going to be much more educated and valuable than you’ll get if you’re only able to support new builders.

The only thing that I see standing in the way of this is:

  1. Lack of states exposed on webviews (Nick says this is coming soon. TY!).
  2. Ability to publish apps with iPhone and iPad support to match our wrapper app, and because our users have to have this (more on this below).

If we’re using Bubble Native just for its Webviews initially, then there should be no issues with us launching for iPad, regardless of whether you guys have optimized the native features for iPad yet. All you guys need to do is allow this to happen (with a big warning on it so people know the downsides/risks).

Does anyone have thoughts, or outlooks on this?

I would love to hear from @nick.carroll on this concept in general. Is using Bubble Native as a replacement wrapper something you guys even want to encourage/support?

If this just isn’t something you guys want at all, then we’ll just rebuild outside of Bubble entirely and forego using Bubble Native.

If you guys do want to support this migration pathway, can we have the option to publish for iPad sooner rather than later? In the next 90 days?

Can your users just use a webapp on the browser? This is the way i think im going for now.

If you don’t really use any native phone functions, you can go with a PWA for the current Bubble app. Pretty much everything should be the same

There is absolutely no way for us to move to a PWA after being on a native mobile app for four years.

This is an app for Android and iPhone with live users since 2021. We actually convert substantial users from a competitor because we have an actual app and not a PWA like they do.

We use native push notifications, location, and camera functionality. We also need access to callkit longterm, but not immediately.

We’re a complex CRM platform with built-in phone, email, and texting functionality. Most of our users use us on the go, so the mobile app is our primary deployment. Not something we can just throw on a PWA as an afterthought.

1 Like

Sounds like were building the same app haha

lol, what vertical are you in?

Heating and air, home services

We’re roofing. Stay on your side of the fence now :rofl:

We’ve looked at HVAC before. It is very different from exterior renovation, different business model entirely. Didn’t make any sense for us when exteriors is already a huge market.

Service Titan is trying to make the jump right now from HVAC to Roofing, but they’re getting destroyed over here on the roofing side.

1 Like

Haha yeah titan sucks. I own an hvac company so i said screw it im buikding my own. Everyone that uses titan hates it.

1 Like

Thats awesome though man. Good job. Keep up the great work. Everyone hates titan just remember that. Fires me up that someone has built a similar app that works great using bubble.

2 Likes

Yeah man, building since 2021 in Bubble and it’s been our secret weapon for sure. We’re taking over this vertical right now.

It hasn’t all been smooth sailing. Scaling is so hard and even on dedicated there are issues. But nothing we haven’t been able to overcome.

3 Likes

This is really helpful feedback (and congrats on the success!). The main consideration for restricting to explicit iphone only support for the app store review process is to avoid a situation where apple is requiring something that we cannot provide to the user because they would be now be explicitly reviewing the app on an ipad.

To be honest, we havent done much investigation into what the specific requirements are from Apple in terms of iphone & ipad review, but will need to do so in order to know if its a setting we can realistically offer in the near term or not.

2 Likes

One of the best threads I’ve read for ages. @aj11 and @jacob2 with real apps and real users, dealing with real problems.

Sorry to hear your pain.

I wonder if you could do a deal with BDK or others to take over their platform and support yourselves for the interim?

Poor Nick is in a very tough spot, people demanding when it will be ready, and then the career suicide of launching a very high profile buggy release, that Bubble has bet the farm on. :grimacing:

2 Likes

Following this thread as I am currently in the same position. To clarify, using bubble native as the wrapper with web views while slowly migrating, currently supported and strong for iphone, just not ipad? @nick.carroll

2 Likes

They are only worried about the UX based on my experience with it. If the app is just a web-view then all requirements would just be based on what is inside that webview (what we have control over). I understand you gotta do due diligence on this first though.

Ok that makes sense. This might be a dumb question, the web view pages are still testable in Bubble Go? So we can see the UX prior to deploy?

Yep! BubbleGo will show the webviews. Just note that webviews, if they aren’t set to have a min height, should be used on a not scrollable view

Is this found in the alpha documentation/is there specific documentation that talks about web view setup?

the mobile docs can be found here: Native mobile apps 🔒 | Bubble Docs

1 Like

Have you guys checked out https://www.buildnatively.com ?

While waiting for the Bubble native builder to be a complete solution I have built and wrapped two apps using their service. I’m using in-app purchases with Revenuecat, push notifications etc…

It’s super easy to set up and implement in your bubble app and when you need a new build to be uploaded it takes 10-15 minutes instead of the many days I had to wait for BDK to do the same…

While not perfect I find this solution to be SO much easier and better than BDK and they publish updates often + my experience is that they have really good customer service and also a discord forum where you can get help…

Maybe this can be a temporary solution for you guys? :pray:

2 Likes