Difference between a transformed web app and a mobile app


Is there a notable performance difference between creating an app with bubble an then convert it in a mobile app (with Thunkable,…) or programming it with Java?


IMHO, there are several good options for mobile app development, and each has its benefits and drawbacks when it comes to performance, cost, and maintenance over time. I’ll try to summarize, but I’d encourage you to search the forums to get a sense of how the community is using bubble with respect to mobile development.

(This ended up being longer than I thought, so please forgive me for not having time to make it shorter)

There are 3 main divisions when it comes to mobile development: a Web-based mobile app, a “builder”, and “native” or “pseudo-native” development.


Using technologies like PhoneGap/Cordova let you “wrap” a web-based app and create an “app” that allows some native functionality (like camera access, geolocation, etc). This offers the least “native” feel for users, and while there are some fantastic examples of high-performing, beautiful interfaces, it’s not good for all user-cases. Content-based apps (blogs, menus, restaurant ordering) are fairly well-suited. I’ve built several hybrid apps this way, and it’s definitely a fast way to wrap an existing web app. YMMV.


Builders (bubble is a builder as well) are fantastic for many use cases. There are few drawbacks from a “native look and feel” perspective, and accessing native features is reliable (although sometimes limited). I haven’t personally used Thunkable, but I’ve employed similar tools for campaign-based, rapid-development projects. The main drawbacks are pretty obvious: additional expense, “lock-in” to a platform, and being at the mercy of upgrade cycles (when a new Android or iOS version is released, you may not be able to use new features immediately. The benefits are usually stability, being able to update quickly, and not needing a mobile development capability, which can be very expensive. You’re amortizing the cost of development across all customers of the builder.

"Native" and "Pseudo Native"

This is the most expensive, requires the most direct cost, and can yield the best experience for your users and customers. The languages used for mobile development range from common (iOS: Swift, Objective-C, Android: Java, C++, Kotlin, Samsung Wearables: Tizen, which is Linux-based, and a handful of others). In order to support each platform and its unique idiosyncrasies and features, a developer needs specific tools and knowledge. These platforms can be very different from one another when it comes to simple implementations, and that’s why builders and services have popped-up to smooth over the engineering frictions.

Even within this option, however, are a few key technologies: React Native/Expo allow for JavaScript-based development and smooth over quite a few differences. NativeScript is another JS-based option although it has some performance issues because of how it is built. I have stronger experience and opinions here, but I’ll keep my feelings to a minimum and simply say “it’s an option, and it still has limitations when compared to native development.”

Purely-native development is the best experience. Think about all of the wonderful music, video, medical, and augmented reality experiences - these are best created with purely-native development. It’s the most expensive, and you get what you pay for.


If you’ve made it this far, thank you for reading! All of this said, an app is only as good as the some of its parts: the concept, the branding, the design, the user experience, and the implementation. Each of these is critical to making a “good app”, and you can easily spend tons of money and botch the execution - finding your team, your brand voice, your visual identity, your user-experience, and your value-proposition should be paramount. Choosing your tech stack is secondary until you’ve outgrown the approach.

Cheers, and I hope this helps.



If I could give some advice, I’d say to explore the web-based and builder options first - those are the fastest and cheapest in the short- to mid-term. I’m examining a “pseudo-native” approach for bubble apps, and if I can get a plugin going, I’d be happy to reach back out.