My first test app got through on Google Play but rejected on iOS. This is nothing to do with Adalo (the process with Adalo was excellent and I really enjoyed making it) but more my content and planning/layout of the app.
So I guess lessons learned from this is to think about:
the originality of your app and make sure it includes some functionality (not just design) that is different.
Maybe even upload as quickly as possible to get in the store then flesh out the app and dedicated more time to it once you know it’s approved?
No love lost for me. I was just testing to see how long it would take to make in Adalo, use an API (horoscope) and submit to the appstore. I won’t be appealing or redesigning as there’s not much I could add as it’s a simple app.
I’m moving on to the next app but if this can save anyone’s time then hope it helps!
This time was most likely for requiring a login. I used the standard setup of a login on the first screen. The app itself can function without requiring a login, but I need the login to store the “likes” of posts in my app.
So I’m thinking of either:
removing the like function / swapping it for a collected polled like (leaderboard)
have the signup:login part just above the Like screen but that’s not so great for UX
I guess the lesson learned from this is that Likes is maybe not enough functionality to justify account creation.
Make sure you add further features that justify an account (like saving other data).
I’ll be updating this app as 1 or 2 above but makes me nervous for other apps I’ve made ready for submission. I may need to add more functionality to justify the account creation.
Incidentally, the new Adalo demo on e-commerce probably won’t be successful either as requires login before store browsing. I think we may need to rethink the position of the account creation page or store more data locally on a user’s phone/ local storage.
See attached on reason for rejection, any ideas appreciated!
This is very good information to know. It will require a lot more screens if that is truly the case. Screens for non-users (without an account) and screens for users (have an account)
Yep. While I was doing a project for Bose for an internal app, Apple was a bit overzealous with their app submission process. While it’s frustrating as an app dev… it makes me happy they’re putting so much emphasis on quality control for a premium end user experience.
Agreed @HazNoSoul! I didn’t realise they were so strict as I’ve downloaded some junk in my time
I’m guessing if some current apps were uploaded today they might not get through.
Anyway, I got my app in - wahooo! I just removed the login/registration and it worked.
For future apps I’ll have to make it so compelling to have the registration that they won’t be able to refuse it. Food for thought.
Awesome! Good to hear. I’m attempting to make some custom business applications that allow end users and business management to have a uniform experience. It would be interesting to see if it’s possible to deploy these apps through an MDM solution such as Intune. PowerAPPS was just announced and so Adalo will have to keep on their game to stay ahead of the integration offered through Azure.
I really don’t understand the guidelines. Is it specific to the type of your app? Because, there are lots of apps on the app store that requires sign-up before accessing any kind of content. Am I missing something?
But if I apply that to my app the only thing I was adding of value with the username registration was liking of images. And there were 4 or 5 other screens that could function without a login. So I guess the interpretation of this is to make sure several of your app screens are using customised/user profile data or inputs to make the registration essential so they can’t quiz it.
But agreed, I have downloaded apps that I would have thought would have failed this guideline too. But rather than fight it I just adapted the app and will bear this in mind for future apps.
