Differentiating iOS app from web version: rejected by Apple

Hi All,

I just wrapped my Bubble application for Google Play and Apple. It was approved by Google, but Apple rejected it due to lack of differentiation from a simple web browser experience. And yes, I’m already using push notifications.

“Including iOS features such as push notifications, Core Location, and sharing do not provide a robust enough experience to be appropriate for the App Store. To resolve this issue, please revise your app to provide a more robust user experience by including additional native iOS functionality.”

I can make some things only accessible thru the app. My question is, how do I do this to the extent that Apple recognizes that it’s officially only an app feature? Are there conditions I can set (button is visible only when ___) ? And is that enough for Apple to approve?

P.S. Do the features have to be different from those on Google Play?

Thanks,
Jamie

2 Likes

This is good feedback for the community, thanks for sharing. First off, I would not worry about Google at this point. Apple doesn’t care what’s in your Android app, so don’t overthink this aspect. If it’s good on Google, just go with it.

I think this is an important thing for people using Bubble for mobile apps. I’ve been against using webviews since forever, but we need to noodle on putting together a consistent, community supported method of building actual NATIVE, not hybrid, mobile apps.

Some options to explore:

  • Jasonette - requires JSON by hand to build the UI, can leverage Bubble backend
  • Thunkable X - has a visual editor, can likely leverage Bubble backend
  • Creo - Mac only, has a visual editor, can leverage Bubble backend
  • Dropsource - Expensive, but has a visual editor and can leverage Bubble backend
  • Kinetise - Haven’t tried, but has a visual editor. Unclear if we can use Bubble backend
  • Supernova Studio - Mac only, currently requires Sketch, need to write code to integrate with any backend
4 Likes

Thanks for your response and these ideas. I’m not familiar with the products you mentioned but just visiting the Creo website a moment ago made my head spin! Not sure I’m on that level. I’m also really trying to live by the 90% solution / 10% of the work/money mantra at this stage of my business and was thus hoping to go the less expensive and time consuming route of wrapping.

If anyone knows of any ways to make certain features only available in an Apple store version without using one of these native options, I’d love to hear them! Magic conditions? Plugins?

P.S. If it needs to be said, I’m also happy to only have a promo / informational homepage accessible on a web browser, and make the entire application other than that index page only accessible thru the app. Just not sure how to do that, and how to ensure that Apple knows I’ve made it only accessible thru their store.

I don’t think that’s what their issue is. Their issue is you built a web application, then wrapped it, then put it on an app store. Fundamentally, even if you have features only accessible on the iOS app, it’s still NOT an iOS app. The app isn’t using their best practices, it isn’t using their device APIs, and it isn’t meeting their standards.

In their rejection notice, they cite “native iOS functionality.” Having more web-based features behind the login isn’t going to achieve that goal, I’m afraid.

1 Like

Hey there. Having been through this particular mess myself with one of our apps, I can tell you how we were able to solve it, and what eventually stalled the release of our app on iOS. Like you, we did the webview wrap. We used GoNative, and it was an expensive, but good solution. We got through Google with no problem, and then got exactly the same message from Apple. We added push notifications, and got the same thing back. What finally got us through this part was just making a change to the very first page that displays on mobile, and taking away the browser bar.

So, we compiled a second build on GoNative (they don’t charge to do more builds of the same app) and set the landing page to an iOS specific login page that was created in bubble as a mobile page with the “native app” checkbox checked. We then set the app to remove the browser bar. I don’t know what solution you used to wrap your app, but GoNative had an option to remove the browser bar from the webview. They also have option for “native iOS functions”. We switched on the one for Native navigation menu, and set the URLS for each button of the menu to the specific pages of our app that they’re supposed to point to.

All of this so that when the user logs into the app it LOOKS just like any native app. No browser bar, and nice iOS style navigation menu for everything. We didn’t even need the push notifications. It’s that the user experience has to look like it’s a native app, and not a website.

What actually kept us from releasing in the app store, as of now, is payments. We have a subscription service, so Apple requires us to have Apple Pay integrated to accept payments. Even if users can only sign up for the service at our site, and don’t accept payments of any kind in the app itself, Apple requires us to have that option available to users. And, of course, so they can take their cut of every subscription. At this moment in time it wasn’t something we were willing to do from a business standpoint, or a technical one. So, for now, we’re happy on the web and in Google Play.

So, just to your main question, if you can remove the browser bar in your build, and add native navigation, that was all it took for Apple to approve us past the “need more native functionality” point.

Here’s a few screens of the app with the bars removed, so it looks like any native app.


2 Likes

Hi guys, thanks for your messages. @andrewgassen, that is rough, sigh. Thanks for your advice.

@jcindy81, thanks for the details you shared too. I’m using Deploy by copilot (cobubble) and did choose the “remove browser bar” equivalent in the setup.

I’d like to use your method re: setting the mobile landing page to an iOS specific login page created as a native app page. Honestly I created the entire application with the intent to create a mobile app. It’s just available on web now because I didn’t think it would be an issue.

Can you tell me if I’m on the right track with this new plan…

mywebsite.com (bubble index page) = landing page for non-mobile
–> contains button to download iphone app (redirect to app store app listing)
(aka, you cannot physically log into this page. You can only learn about the app and click download buttons for google play or apple)

mywebsite.com/app = native mobile app page (checkbox checked for native app)
(So Apple app is set to mywebsite.com/app. There is no way to access mywebsite.com/app unless you have downloaded the app.)

The above might sound ridiculously simple but I hadn’t really thought about it this way before so I’d just like to ensure I understand.

Also, copilot/cobubble told me that my issues are likely about the simplicity of my design (they sent me a link to pttrns.com for ideas). I spotted “nativizer” on the plugins page and will try that. Didn’t realize the look would be an issue.

I’m sorry about your issue with apple subscriptions, that stinks. Hope you find a solution soon!

Thanks,
Jamie

1 Like