Ionic Deploy no longer allowed by Google Play?

#1

I have four apps in production that use ionic deploy but just this week I submitted a new app and google immediately suspended it because of a ‘Malicious behaviour policy’:

“Per policy, an app downloaded from Google Play may not modify, replace or update its own APK binary code using any method other than Google Play’s update mechanism.”

I had to appeal the decision on the grounds that I was not aware of the policy change and that I used a popular framework - Ionic - which provided the remote update functionality as part of it’s enterprise services. They accepted my appeal but are requiring that I remove the remote update function.

Does this mean we can no longer use Ionic Deploy with Android apps?

Here’s the screenshots they sent of the functionality not allowed. Note that I use the Deploy API to manually handle updates.

20192307_010100_PDT_san

1 Like
#2

Wow. I’m not sure why this hasn’t got a single reply. Isn’t this potentially a major issue?

#3

We too received a suspension today for an app we launched 3 months ago. It was due to their ‘Malicious behaviour policy’, citing:

Apps that cause users to download or install applications from unknown sources outside of Google Play are prohibited.

I just appealed the decision on similar grounds as @clucani, and am awaiting a response.

We use Ionic v2 and deploy live updates with Ionic Appflow for Android and iOS. Last live update was 2 weeks ago. No issue with the iOS store up to this point.

#4

Hi there! Sorry it’s taken so long to reply. So @clucani the reason your app is having issues is the UI/prompt you’re showing is against store policies. Both google and iOS have notes saying that updates should not show a prompt or indicate to the user that an update is happening, it should just get updated.

As far as not being able to use Ionic deploy, Deploy is allowed by both google and apple as part of the terms of service. Since the content of the app is html/css/js, the terms state that they can be updated as long as they do not fundamentally change the purpose of the app.

In this case, the manual API from deploy should happen in the background without any issues. I’d rework your update flow or potentially move the update to happen automatically

#5

@arwid are you using a similar update method as @clucani? If see, my response above is relevant to you. If not, can you describe how your update is being handled?

#6

Hi @mhartington, thanks for the clarification on the terms. We do trigger the update flow automatically – auto-downloading in the background and refreshing seamlessly between angular state changes or on app resumes. Another thing we suspect is we did have a brief white screen flicker during the refresh and have just changed it to show the native splash-screen instead during the sync.

#7

Great, thanks @mhartington - that’s really good news! I don’t understand why there should be any difference between a background update and a manual/UI update if the end result is the same. In fact I went with the manual update route because I thought it would be a better user experience since it puts the user in control of when the app gets an update.

So perhaps @arwid’s issue is just reviewer-specific, and the appeal should make reference to the terms allowing html/css/js being updated? I’ll have a dig through the terms to find the reference unless you easily have it to hand?

#8

@mhartington can you or somebody point at exact developer agreement clause that states what you said about html css js update?

Would be good to have a templated answer for appeal if rejection happens

#9

We are in standstill with the Google Play Team – they sent us a generic response twice that they’re not able to provide any more information.

Perhaps it is indeed reviewer-specific and sending them a reference to their exact developer agreement clause would help. Although, I have yet to find it.

#10

Just curious @arwid - did you ever get it through?

#11

Edit: I found the clause in the “Apple Developer Program License Agreement” that relates to this. As of today, section 3.3.2 states:

3.3.2 Except as set forth in the next paragraph, an Application may not download or install executable code. Interpreted code may be downloaded to an Application but only so long as such code: (a) does not change the primary purpose of the Application by providing features or functionality that are inconsistent with the intended and advertised purpose of the Application as submitted to the App Store, (b) does not create a store or storefront for other code or applications, and © does not bypass signing, sandbox, or other security features of the OS.

An Application that is a programming environment intended for use in learning how to program may download and run executable code so long as the following requirements are met: (i) no more than 80 percent of the Application’s viewing area or screen may be taken over with executable code, except as otherwise permitted in the Documentation, (ii) the Application must present a reasonably conspicuous indicator to the user within the Application to indicate that the user is in a programming environment, (iii) the Application must not create a store or storefront for other code or applications, and (iv) the source code provided by the Application must be completely viewable and editable by the user (e.g., no pre-compiled libraries or frameworks may be included with the code downloaded).

Furthermore, an excerpt from Microsoft’s CodePush service (which does the same as Ionic Pro’s “Deploy” API) states:

NOTE: While Apple’s developer agreement fully allows performing over-the-air updates of JavaScript and assets (which is what enables CodePush!), it is against their policy for an app to display an update prompt. Because of this, we recommend that App Store-distributed apps don’t enable the updateDialog option when calling sync , whereas Google Play and internally distributed apps (e.g. Enterprise, Fabric, HockeyApp) can choose to enable/customize it.

I haven’t found anything on this from Google though, but I imagine it’s probably a very similar story.

This seems like a dark, dark grey area to me… It seems like neither of them actually want to allow hot code updates, but they need to still cater for resource updates, probably for the sake of not needing to bundle all translations in the initial app release.

Edit 2: Google’s version of this is much more open, quite simply stating:

An app distributed via Google Play may not modify, replace, or update itself using any method other than Google Play’s update mechanism. Likewise, an app may not download executable code (e.g. dex, JAR, .so files) from a source other than Google Play. This restriction does not apply to code that runs in a virtual machine and has limited access to Android APIs (such as JavaScript in a webview or browser).

Hey Mike, could you perhaps provide some links to the notes you mentioned here? I’ve been searching for it myself, but considering how common and generic the word “update” is, I’m finding everything except what I’m actually looking…

I currently have a rather long-winded debate with some managers where I work about this process; they insist that the user should be able to tap a “Check for Updates” button and I’m trying to convince them it should just happen silently in the background.