Bubble Mobile Apps Editor Roadmap and Timeline

Hi everyone! Thanks for the great feedback. Jumping in to address some of the questions that have come up so far. I’ll try and group these by theme…

Web + Mobile apps

  • Mobile apps will be able to be added to existing projects, which means you’ll be able to share data, backend workflows, and many styles across your web + mobile app. Web pages and mobile views will be separate, however, which includes any page level workflows. That being said, you’ll be able to copy and paste certain visual elements and page workflows over to mobile views.
  • Because Bubble mobile apps render native code and use native components, we think you’ll actually want to rebuild a lot of your wrapped pages to take advantage of the native components, surfaces, and navigation patterns and get better performance / native look & feel.
  • You can also choose to create a mobile only project, if you would like, and have no need for a web app. In this case, you will still need servers and a hosted database for your web app, you just wouldn’t add any web pages.
  • As far as app plans go, projects that have both a web + mobile app will be on the same app plan, not separate plans.

App Preview

  • In addition to loading your app on your device via BubbleGo, you’ll also be able to preview your app on the web in an updated web preview experience - which includes selecting different device types. This is not true device emulation, however.
  • If you want true device emulation, you can always load your app onto testflight or android studio on your desktop.

Plugins

  • The native mobile apps editor will not launch with a plugin editor, but will be a top priority for the remainder of the year. Because we are building react native apps, we will be able to deliver a much more seamless plugin experience.
  • It will not be possible to inject native code onto a mobile view, however, like you can today with the HTML element. That being said, the plugin platform should alleviate the need to do so.

Android Support

  • Building and publishing Android apps will be supported out of the box with no additional work required on your end

Device hardware and SDKs

  • To start, we’ll be supporting camera access, location services, FaceID, push notifications, and offline support.
  • We will continue releasing high priority integrations like in-app payments, sensors, contacts, etc.
  • Permissions for these integrations and SDKs come out of the box. For example, the prompt asking a user to enable location services on their phone when the app is launched, will come for free. After that, you’ll be able to handle any errors when trying to access functionality that does not have the proper permissions. That being said, there are strict rules about pestering your users to turn on notifications or camera access etc. that must be followed

Deploy / App Store permissions

  • After entering some basic project information, you will be able to submit new app builds to App Store Connect and Google Play Console right from the editor. From there, there will be a few steps that must be taken in these developer consoles to submit for review.
  • Subsequent builds will also be sent to your developer consoles, where you can decide to submit for review, retire older app versions, etc.
  • There will also be the option when deploying to submit an over the air update (OTA). This allows you to skip the app store review process and update your latest app version directly. That being said, this feature must be reserved for small changes and bug fixes per Apple app store guidelines.
  • We will not be providing a direct code export, but you will get the raw iOS and Android build files whenever you bundle a new version of your app.

Background

  • Background app access depends on the permissions set by your user

Offline support

  • For now, we will only support helping you define the read-only behavior of your app when it is offline
  • In the future, we hope to support Read & Write operations while the app is offline, with conflict resolution / data synchronization, but this is a huge amount of work

Swipe Actions

  • Swipe actions on lists are a common pattern in mobile development. Take for example your gmail app - when you swipe on an email in your inbox, you reveal more actions that you can take like archiving or marking as read. This functionality will shop out of the box with Lists, that will be far more performant than repeating groups on web today.
36 Likes