1
Specifically, it's about "powerful" permissions like QUERY_ALL_PACKAGES or REQUEST_INSTALL_PACKAGES.
The request in itself is understandable and reasonable.
However, the automated detection of these permissions doesn't seem to work that well (for me), leading to false positives in my case.
Both permissions were detected in one of my apps, although one was never used and the other was removed in time. Still, I got a warning by email after the permission was already removed.
Anybody has similar experiences here?
Currently, review time of Apple App Store, Samsung Galaxy Store and Huawei AppGallery is about 1-3 days which is not great but tolerable. However, review time in Google Play is a notable 4-10 days.
Google's review time does make bugfixing quite impossible to deal with.
Especially, GUIs are often impossible to test exhaustively. The obvious solution is continuous delivery which fixes issues identified by users in a timely manner. Unfortunately, app store reviews are leading to the worst deployment experience possible.
How are you dealing with this problem?
IMO, there should be a possibility to submit bugfixes immediately. That is, releases with increased patch number according to SemVer should be approved immediately.
Sure, app store providers won't do this because it will definitely be exploited.
There has to be another way. I find continuous delivery to be one of the most powerful weapons of a developer, and it is just not possible in the app store ecosystem.
Take this apple purchase api documentation for example: https://developer.apple.com/documentation/appstorereceipts/responsebody.
Attribute "is-retryable" is documented as boolean, but in fact it is an integer (0 or 1), which is only explained in the description text.
Also, you almost never get the information if an attribute is nullable (or optional). Why not just document nullable like e.g.
1.) Type (nullable), or 2.) Option<Type> like in Rust
I guess, a strict api documentation standard would help tremendously to save quite some debugging time.
Now, three months later, our app was suspended again for exactly the same reason, against which we had already successfully appealed.
We tried to appeal once again, which was declined this time. The only difference from a few months ago: the person in charge for our case has changed.
It seems that you are completely dependent on the person assigned to your case, leading to arbitrary instead of consistent decisions.
It even went so far that our app was in a quantum state for some time because it was approved and suspended at the same time. This seems to be an indication, that the organizational process for app suspensions at Google doesn’t work quite right.
Do you have any suggestions how to move forward?
In general, I’m quite unhappy how app suspensions work for the Google Play Store. When your app got suspended, developer access to your app is terminated as well. This means, you can’t implement any changes requested by Google. Instead you have to upload a new app id, losing all downloads and reviews, and have to start all over again from the ground up.
Compare this to suspensions in Apple’s App Store: The relevant update of your app is held back until things are clarified. Then the update will either be released or you will have to implement some changes. However, you won’t lose the reputation you have built up to this point. Using Linux since decades, I'm not suspected of being an Apple fan boy. But in this case, this seems to be a process which is more developer friendly.
I’m also looking for alternatives to the Google Play Store for Android. Is F-Droid also recommended for closed source apps? I was also checking out the Huawei store, to reduce the dependency on Google at least a little bit. Anything else?