Latest news about Bitcoin and all cryptocurrencies. Your daily crypto news habit.
Writing an application is a hard and long process. You start with an idea, you try to formulate it into something usable and then you begin the development process. During the development, you constantly find yourself asking, is my application at the point where I want to release it or should I work on some more features? Maybe I should make sure it runs on as many devices as I can test? These are all great questions, but I am here to tell you that instead of worrying about what might have been, you should instead worry about what will definitely happen in the foreseeable future.
What better way is there to prepare yourself for your next application than by learning from other people’s mistakes? And I am here to share mine, without shame, but with a smidgen of regret. You will soon understand why.
Hindsight is 20–20
Our use case for this article will be my most recent application, which I published to the Google Play Store. Some boring stats for your to scroll by:
- It was published more than three months ago
- It uses Firebase for Analytics and Push Notifications
- It is only available for Android and in selected countries
- In it’s peak, it reached more than a hundred downloads
I know this isn’t a high-volume, feature-filled application, but believe me, there is much to learn from my misguided steps.
RTFM
If you don’t know what that acronym stands for, look it up. Google has a strict policy for publishing applications. Part of the process of publishing an application, requires you, the developer, to fill out a Privacy Policy. You cannot publish an application without having one. Failing to adhere to your privacy policy, will get your application removed from the Play store. Just so you can’t say you didn’t know, here is a link to Google’s Privacy Policy Guidance page.
I learned this the hard way. Meaning, my application was removed from the Play store by Google after a couple of months. I got an email stating I have violated section 4.8 of the Developer Distribution Agreement. Sounds terrifying, doesn’t it?
To make sure your privacy policy covers all you need, use this:
Third Party Libraries
If you use them in your application, make sure to understand what those libraries themselves import and what they do on the inside. In most cases, these libraries help us solve something that we don’t have the time to write or the knowledge. But it will be wise to not see them as merely a black box that does magic, but as a box in need of investigation. Some issues that may arise are the fact that the library could not be updated or maintained in the future and it could have security holes or privacy issues.
As I stated earlier, I am using Firebase Analytics in my application. What I did not know, was that apart from sending specific events with specific data, that I configured, Firebase allowed other data that was not relevant to me to be sent as well. Part of that data, breached the Developer Distribution Agreement and as a result, my application was taken down. Touché Firebase, you bested me in this round.
If you want to use Firebase Analytics, but are not interested in collecting the advertising id of your users, use the following code snippet (for Android):
Save Your Application Signature
When you are releasing an application, you must create a signed APK. To do so, you have to generate an upload key and keystore. Do not, for any intents and purposes, lose the keystore file. You will regret this for the rest of your life. Without your keystore file, you will not be able to digitally sign your application. Without signing your application, Google won’t be able to identify you as the owner of the already published application. This will lead to you not being able to update an application you published in the Play store. Having to re-release your application under a different package will be like releasing it for the first time. You will loose all those downloads, reviews and other good stuff.
I don’t think I have to tell you what happened to me, right? You can figure this one out for yourselves.
Photo by Alice Donovan Rouse on UnsplashDon’t Wait
Like I mentioned in the beginning, sometimes you don’t know where to draw the line between releasing the application as it is or trying to add more features. While it doesn’t relate directly to the application we are using as an example, it is still a good rule to release the application once you feel satisfied with what you have currently. The logic behind this is two fold:
- Re-releasing an application is an easy process
- Putting your foot in the proverbial door of the application store will let you have the benefit of making sure your idea was out there first
To quote Napoleon Hill,
Don’t wait. The time will never be just right.
Going forward, I hope you will not make the same mistakes I have. If you have any mishaps of your own, share them in the comments below or reach out to me. You never know when yesterday’s mistake, could be tomorrow’s victory.
What I Should Have Known Before Publishing An Application was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.
Disclaimer
The views and opinions expressed in this article are solely those of the authors and do not reflect the views of Bitcoin Insider. Every investment and trading move involves risk - this is especially true for cryptocurrencies given their volatility. We strongly advise our readers to conduct their own research when making a decision.