Snikket Android app temporarily unavailable in Google Play store [RESOLVED]

We initially shared this news on our social media page, thinking this was a temporary issue. But we’ve had no response from Google for several days, and want to explain the situation in more detail.

Update 16th April: Over a week after this began, Google have reinstated the Snikket app on the Play Store and everything works again. Thanks to everyone who gave us encouragement and support during this time! Feel free to read on for details of what happened.

Summary

We merged some changes from our upstream project, Conversations, and we submitted the new version to Google for review. Before responding, they removed the existing published version from the store. We have submitted a new version (on 10th April) that we believe should satisfy Google, but they have not yet published it or provided any feedback.

This means that it’s not currently possible for Android users to install the app using Google Play. We recommend that you install it via F-Droid instead.

Workaround for Android users

If you receive an invitation to Snikket, the Play Store link in the invitation will not work. The best course of action is to install the app using an open-source marketplace instead: F-Droid.

1. Follow the instructions on f-droid.org to download and install F-Droid.
2. Install Snikket using F-Droid.
3. After the Snikket app is installed, open your Snikket invitation link again.
4. Tap the ‘Open the app’ button.
5. Follow the Snikket app’s instructions to set up your new Snikket account.

The full story

I’m Matthew, founder of Snikket and lead developer. This is the story of how we arrived at this situation with Google.

It all began when…

A few months ago, Snikket, along with a number of other XMPP apps, found our updates rejected by Google’s review team, claiming that because we upload the address book entries of users to our servers, we need a “prominent disclosure” of this within the app. The problem is… we don’t upload the user’s address book anywhere!

The app requests permission to read the address book. Granting this permission is optional, and the reason is explained before the permission is requested. If you grant the permission, the app has a local-only (no upload!) feature that allows you to “link” your XMPP contacts with your phone address book contacts, allowing you to unify things like contact photos. Contact information from your address book is never uploaded.

Many messaging apps, such as WhatsApp, Signal, and others, request access to your address book so they can upload them to their servers and determine who else you know that is using their service. Google have decided that’s what we’re doing, and they won’t accept any evidence that we’re not.

We don’t have telemetry in our app, but we assumed that this feature is probably not used by most people, so we decided to remove it from the Play Store version of the app rather than continue fighting with Google.

Amusingly, Google also rejected the update that removed the ‘READ_CONTACTS’ permission. Multiple times. It took an appeal before they revealed that they were rejecting the new version it because one of the beta tracks still had an older version with the READ_CONTACTS permission. Weird.

I fixed that, and submitted again. They rejected it again. This time they said that they required a test login for the app. Funny, because we already provided one long ago. I assumed the old test account was no longer working, so I made them a new one and resubmitted the app. They rejected it again with the same reason - saying we had not provided valid test account credentials.

“You didn’t provide an active demo/guest account or a valid username and password which we need to access your app.” – Google reviewers

The weird thing was, when I logged in to that account to test it, I saw that they had logged in and even sent some messages. So they were lying?!

We submitted an appeal with all the evidence that the account was working, and their reviewers had even logged in and used it successfully. After some time, they eventually responded that they wanted a second test account. Why couldn’t they just say that in the first place?!

After adding credentials for a second account, and using the Snikket circles features to ensure they could find each other easily, we resubmitted.

Rejected again.

This time the rejection reason was really the best one so far: they claimed the app was unable to send or receive messages. Rather funny for a messaging app that thousands of people use to send and receive messages daily.

Wait, a messaging app that can’t send messages?

Once again, I logged into the test account we had provided to Google, and once again saw that they had successfully exchanged messages between their two test accounts. We submitted another appeal, with evidence.

Eventually they responded, clarifying that their complaint was specifically about the app when used with Android Auto, their smart car integration. I do not have such a car, and couldn’t find any contributor who had, but I found that Google provide an emulator that can run on a PC, so I set that up on my laptop and proceeded to test.

You won’t be surprised to learn at this point that the messaging functionality worked fine. We responded to the appeal, including a screencast I made of the messaging functionality working with Android Auto. They informed us that they were “unable to assist with the implementation” of their policies. Then at the end of their response, suggested that if we think the app is compliant, that we should resubmit it for review.

So we resubmitted the app, which by this point had already been rejected 7 times. We resubmitted it with no modification at all. We resubmitted the version they rejected. They emailed us later that day to say it was live.

How would I rate the developer experience of publishing an app with Google Play? An unsurprising 1 star out of 5. If I could give zero, I would.

The removal

But this was all a couple of months ago. Everything was fine. Until I merged some of the nice things Daniel has been working on recently in Conversations, the app upon which Snikket Android is based. We put the new version out for beta testing and everything was going fine - the app passed review, and a few weeks later with no major issues reported, we pushed the button to promote the new version from beta to live on the store.

On the 8th April we received an email from Google with the subject line:

“Action Required: Your app is not compliant with Google Play Policies (Snikket)”

I was ill this day, and barely working. For reasons that, if you have read this far, you will hopefully understand, I decided to take up this fight when I was feeling better. Confusingly, a couple of days later we received another email with the same subject. At this point I realised with horror that the first email was not about the new update - they had reviewed the current published version and decided to remove it entirely from the store.

With Snikket unavailable, anyone trying to add a new Android user to their Snikket instance (whether hosted or self-hosted) is going to have a hard time. This is not good.

Their complaint was that the privacy policy was not prominent enough within the app. They had previously hit Conversations with the same thing. Daniel had already put a link to the privacy policy in the main menu of that app and this was already in the update waiting for their review. They didn’t reject the update until a couple of days later, and for a different reason.

Unknown to me, Daniel had tried to re-add the ‘READ_CONTACTS’ permission to Conversations, hoping that with the new privacy policy link and other disclaimers in place, that would be enough. They had already rejected that, and he had removed the permission again. But he did this after I had already started testing the new beta release of Snikket. The order of events went something like this:

• Daniel experimentally re-adds READ_CONTACTS permission to Conversations
• I merge Conversations changes into Snikket, and begin beta testing
• Conversations update gets rejected due to the permission, and Daniel reverts the READ_CONTACTS change
• Without knowing of the Conversations rejection, I promote the Snikket beta to the store.
• Google rejects the Snikket update

What’s interesting is that Google rejected only on the permission change. The contacts integration itself was still disabled in Snikket. This is strong evidence that Google just assumes that if you have the permission (and presumably network permission too) then of course you must be uploading the user’s contacts somewhere.

As soon as I realised the problem, I merged the new changes from Conversations and rushed a new upload to Google Play. However at the time of writing this, several days later, Snikket remains unavailable in the store and no feedback has been received from Google.

This is an unsustainable situation

During this period we have had multiple people sign up for hosted Snikket instances, and then cancel shortly after. This is almost certainly because a vital step of the onboarding process (installing the app) is currently broken. This is providing a bad experience for our users and customers, negatively affecting the project’s reputation and income.

We are grateful that alternatives such as F-Droid exist, and allow people access to open-source apps via a transparent process and without the tyranny of Google and their faceless unaccountable review team. We need to ensure these projects are supported, and continue to improve their functionality, usability and user awareness.

Finally, we also welcome the efforts that the EU has been working on with things like the Digital Markets Act, to help break up the control that Google’s (demonstrably) arbitrary review process has over the the success and failure of projects, and the livelihoods of app developers.

Google, are you there?