Experiences From Publishing An Android App
I’ve been working as a software engineer focused mainly on Android development since I graduated but I haven’t published my own app since college and things have changed a LOT since then. Most notably there are many more restrictions and policies that you need to be aware of and satisfy to even be able to submit an app for review. This post is just sharing some learnings from releasing my fidget app Aimless.
Privacy Policy
The requirement to create a privacy policy was a daunting one as I was initially unsure of what format these needed to take since there’s not much in the way of guidance from Google for what they expect. Thankfully this isn’t actually as bad as it seems, at least for an app that doesn’t collect user data.
There are some online tools for generating privacy policies such as this one which presents you with a questionnaire and helps you to assemble the final document though I didn’t use this myself so I can’t say much about how it works. Instead I found an example from an existing app which also doesn’t collect data and roughly followed the structure of theirs. This was fairly easy to do as it just contains a bunch of redundant sections all saying the app doesn’t collect information.
The final piece in this puzzle is hosting the policy as it needs to be accessible by users and your app needs to be able to link to it. The most common hosting option I could see was people using Github Pages to host it since you have access to it for free once you have a Github account. While I have my own page setup there I opted to use my Squarespace site instead which also appears to be accepted by Google just for the easier editing experience and the ability to have the policy hidden from the normal navigation. I would assume that any other platform like Wix or Wordpress would also work if you have websites created on those.
Feel free to use my privacy policy as an example if you need to create your own for a new Android app.
App and Package Naming
Naming an app is hard. It’s a juggling act of keeping it simple but also expressing the idea of the app. Longer names tell the user more about what you’ve built and probably makes it easier to search but makes life more difficult for design because you have more content for the same amount of screen real estate. I’m less concerned about having hugely descriptive names because I like keeping the name short and simple but this opens you up to potentially clashing with existing names and brands.
Originally I had name the app Twiddle intending for it to mean something along the lines of twiddling your thumbs when you are bored. This also meant that I had also included “twiddle” in the package name. This was all fine up until I sent the app for review and after a few days received a rejection for violating the impersonation policy. Unfortunately I had only been checking the app store for clashes without realising there was a band called Twiddle. At least I think that’s the cause because Google doesn’t explain why I was in violation of their policies and I don’t think it was because of similarity to something like Twitter.
Ok a name change isn’t so bad I just needed to brainstorm ideas and change the copy in the app to reflect the new name. So I set about renaming everything in the code for consistency including the package name. And this is where the mistake was made. Publishing new versions of an app requires the package name to be the same even if you haven’t yet released the app. At this point I was already settled on having everything renamed so I needed to create a brand new app in the play store and fill out all of the details again but I am now stuck with the original app sitting unpublished in my play console forever.
This just serves as a reminder to myself to avoid using the actual app name in the package name for future apps. This would have avoided all of the hassle of creating a new app just because I wanted to be consistent with the package name.
More details about the app itself can be found in my projects gallery
