They were telling us
«Bubble.io is not for mobile app development».
«Use Adalo or Glide».
«It will be low-quality and slow app performance».
«Apple prohibits publishing projects created from an app generation service or a commercialized template».
We also had the same objections and doubts in our minds early on.
Everything changed after exploring the results and getting feedback from the early adopters. The quality that we have achieved with no-code is better than 90% of mobile apps out there in the App Store and Play Store.
SWOP Niels Brock — clothing marketplace that helps users to exchange clothing with the mission to reduce the amount of CO2 emission and remain a sustainable environment for future generations.
Took us about 4 weeks to finish MVP and additional 3 months to implement feedback from user interviews, fix bugs, polish structure, and prepare for being approved by Apple and Google.
After months of development, we got a lot of unique knowledge that can come in handy upon sharing publically. There is already a lot of “how to create a mobile app” content about the theme on the Bubble forum or Youtube, but this post is special since written based on custom experience.
This article describes a summary of 15 brief and valuable tips that we wish we knew before started building a mobile app using no-code app builder bubble.io and the BDK Native framework.
1. Native is not always good.
Native feel of the application is extremely important. Luckily, we have an opportunity to do this using plugin made by the BDK Native team ❤️.
The plugin enables us to add native functionality and brings us closer to looking more like a mobile application rather than webview.
However, in some cases, simple Bubble’s elements work better than BDK Native plugin components.
For example, simple Bubble’s “Picture Uploader” has much better image resolution and faster upload speed than “BN - Take photo” and “BN - Select photo” from the BDK library.
2. Don’t reinvent the wheel for transitions between pages.
Being new to BDK Native, it is not obvious that in some use-cases there exist native alternatives to the feature that you are building.
The same situation happened to us in place of transition between pages. Aims to make the process more intuitive, it is better to show a loading screen while the user is waiting.
We created a custom loader using not BDK Native plugin, but ordinary Bubble’s elements and plugins. This caused a cunning issue that was breaking loader on IOS, but not on Android.
To our happiness, we realized on time that there exists a “BN - Open link” native transition action that works perfectly on any OS.
3. Test on both IOS and Android
As noticed from the previous paragraph, you can come into a trap if ignore certain OS while testing.
IOS and Android are different environments and they do not always work in a similar way.
Working properly on Android doesn’t guarantee the absence of errors on IOS, even though it is the same functionality within the same app.
4. Use browser and BDK Native mobile app for testing.
The quickest way to fix major bugs is to combine testing using a desktop browser and a mobile application developed by BDK Native.
It allows you to get the advantage of using the debugger and detecting issues in the native environment.
Additionally, it can simplify your quality assurance if you are working on a marketplace and need to inspect communication between different user types.
5. Write accurate permission request messages.
Apple review team is strict when it comes to accessing someone’s data. You are required to ask for user permission when you need to access camera, gallery, location, etc.
Don’t worry — you will be able to enable those permission request messages inside your BDK Native account. There is a simple form that needs to be filled out before you get your IOS and Android builds.
Be careful. Making texts for those messages is like walking a tightrope. You need not only stick to Apple guidelines but also be a lucky person. The app review procedure is done by humans and there is a large degree of subjectivity.
Examples of PRMs that were denied:
«Allow access to camera to make instant photos».
«Allow access to microphone to personalize your experience».
«Allow access to library to upload photos and use them to publish items, share products in chats and more».
6. Combat with objectionable content.
Make sure you prevent your app from becoming a toxic place. Otherwise, the application will not pass the Apple app review.
There are a few simple options that you need to include in your app to make sure you are safe when submitting for the review.
- Add option to flag & filter objectionable content.
- If you are building a platform app (e.g. where users can generate public content or communicate with each other), make sure every user can ban others and therefore get rid of unwanted information.
- Include EULA paragraph on your “Terms” page.
7. Don’t forget about Terms & Privacy compliance.
It’s required to provide links to “Terms” and “Privacy” pages to submit application to both Apple App Store and Google Play Store. Moreover, it is better to add references to those pages inside your app.
Count activities for writing those documents to your timeline. But don’t put this too complicated. You can merely use public templates on the internet without hiring lawyers.
8. Deal with “Login with Apple” wisely.
This tricky feature can create additional troubles. Not easy to implement for beginners and there is a risk that it will crash 5 minutes before sending for review. You cannot be 100% sure that third-party will always work correctly. Learn the basic rules:
- Add the “Login with Apple” feature when submitting to App Store and when you have Single-Sign-on for other third-parties (f.e. Google or Facebook).
- Work on adding Single-Sign-on features only after you are published. This is not mandatory, but useful.
9. Ignore browser app access.
It can be confusing that your application can be launched via the link in the browser. Just ignore it. This sounds simple but when you are building for the first time it can make you doubting and frightening to submit for review.
Apple review team doesn’t care about the browser and what is the technology under your app. What really makes sense to them is how does your app function and does it fit their policy.
10. Move your app to a custom domain.
After the app goes live it will be a challenge to move it to a custom domain name. Crashing the application to propagate a new DNS destination for even a few minutes can be harmful to your business.
Users don’t see the domain name. However, you will definitely need it to send custom marketing emails and to integrate your SendGrid account.
Move your app to the custom domain name before you send it for the app review and forget worrying about the problems in the future.
11. Launch “External testing” by Testflight if struggling to pass app review.
Let’s imagine that you have promised your investors to finish the application by Wednesday and see that you don’t fit the timeline.
In this case, you can create a public link referring to which will auto-install your app to the user’s device. It can be achieved by using “External testing” by Testflight, no strict review required, it can be done instantly.
12. Purchase IOS and Android build when it is the right time.
The build is a file that 100% replicates the app that your future users will download from App Store and Play Store.
You can get it even before sending it for the app review and use it for mobile app testing instead of BDK Native mobile application.
Don’t perceive the purchasing of IOS and Android builds too solemnly. This process can go in parallel with your development and doesn’t affect it.
However, you must do this not earlier than 90 days before the date of being published to the App Store and Play Store.
On top of that, if you need to change PRM or animation or any other app info after acquiring builds, you will need to pay about 39$ for the rebuild.
The first rebuild within 14 days after acquisition is free of charge.
13. Be aware of payment functionality requirements.
It is mandatory to use specific payment methods for certain use-cases. There are 2 options to enable payments:
In-App purchases (In-app billing)
- use when selling digital goods inside the app.
- very expensive compared to 3rd-party payment processors.
- limited functionality.
Example use-case: software-as-a-service app selling subscriptions.
3rd-party payment processors (Stripe / Paypal / MobilePay)
- use when selling goods outside the app.
- cheap.
- broader functionality.
Example use-case: marketplace, where parties connect via the platform but make transactions offline on sight.
Regrettably, mobile app developer can do a little to skirt paying steep commission. Nevertheless, there exist ways to do this. For example, Spotify forces its users to pay for subscriptions outside of the application on their website. Risky, but saves tons of money if done successfully.
14. Make secure and intuitive login and registration.
There's nothing worse than not being able to enter the app.
The most common mistakes are missing to adding the “Confirm password” field to registration, not showing error messages, omit the “Forget password” feature.
Ignoring will cause a negative outcome of the application review.
15. Add “Delete account” and “Reset Password” features.
Disregarding simple “Delete account” and “Reset Password” is like riding in a vehicle without wearing the seat belt.
Open any successful mobile app, go to the “Settings” section and you will definitely notice both.
Add them and decrease the risk of app rejection.
What to do if you got rejected?
- Don’t panic, you can resend for a new review instantly unlimited amount of times.
- Stick to Apple feedback & instructions and implement them.
- Refer to developer community forums. There is no difference between app reviews made using classical coding & no-code.
Take your attention that in some cases you need to purchase paid rebuild for about 39$. For instance, if you need to update PRM or “Log in with Apple”.
Sadly, but rejection feedback doesn’t list all issues. A new reviewer can find new intrinsic flaws. Consequently, you need to count these risks into your timeline.
Summary
Native mobile app development with no-code tools isn’t effortless but much easier than using coding. You can always hire a programmer, but does it worth spending more money and time? Not on your nelly.
Applying rules from this article will help you avoid obstacles and get more smooth building process. In case you need help or want to delegate your bubble.io no-code development fully or to create a mobile app — feel free to book a call with the WeMakeMVP team using a Calendly link.
Thanks for reading and wish you to be published in stores from the first attempt! Let’s skyrocket the no-code movement to the moon!
P.S. Figure out why no-code development is better than classic custom development and off-the-shelf software.
Bonus
Check out a video version of our retrospective building mobile apps using no-code platform bubble.io.
