Tips: Protect Your Property

A Mobile App Owner Watches Out for This to Avoid Damage

📅 2021.12.09 - 👤 Borbély Viktor

I have collected the main points that you should definitely pay attention to as a mobile app or other digital product developer. It is not enough to launch a product somehow, you also need to know how to operate it. Since a product is long-lived, it is worth laying down foundations at the beginning that will save you many headaches later.

As a preliminary, I would add to the following that I have collected faulty practices seen at several of my clients. These are therefore unfortunately incidents that have occurred, and it’s only thanks to luck that there hasn’t been bigger trouble (yet).

It’s worth playing with the thought that…

What would happen if cooperation with a partner, a developer, or a development company no longer worked so well?

Choosing the application name

There are millions of mobile apps in the Stores. It’s hard to stand out today. A serious campaign must be paid for users to notice it. If we have a name that is ASO compatible (App Store Optimization) and we start to establish it, it’s a big loss if it’s taken from us.

Let’s pay attention to what publisher our money-released app appears as on its data sheet. We can see this in the application details. This section has the company name, contacts, website filled in, in short, the developer’s contact information. If we don’t have the technical knowledge and we develop with an agency, let’s pay attention to this being filled in correctly and pointing to us.

It may be worth agreeing on how long the agency’s name can be out, e.g., until paying X% of development costs. But after that, let’s definitely set it up!

This part can be easily rewritten on the stores’ data sheets. However, there is a part that cannot. This is the package id on Android and bundle Id on iOS. These are names characteristic of the entire (world) stores, of which only one can exist. For example, there can only be one application named com.facebook.app. Moreover, at Apple you can even specify that everything after the com.facebook. prefix is also reserved by us. The point is that this part should also identify us if possible.

Setting permissions

If the app’s affiliation has already been mentioned, then a basic thing is who is the app owner in the store? On Google Play it’s called Owner, and in the Apple Store it’s called Account Holder. Never give these to anyone else!

Every application store knows that many people need to be assigned many different access rights. Appropriate permissions are needed to set them up. Let’s only give the narrowest rights to, for example, a developer, someone providing customer support, or someone handling comments arriving at the app.

Don’t limit this foresight to stores only. On GitHub, GitLab, Bitbucket, AWS, Azure, Google Cloud Platform (GCP), Firebase, Expo.dev (React Native CD/CD), etc., these settings can be found in the same way. Let’s review them!

If needed, let’s request the username, or create a new one ourselves to which we assign minimal rights.

Limit external service providers

From the above list, it’s clear that a tech project relies on many different external tools. This is fine, since we mainly want to develop and sell products. However, we also need to take care of operations!

Let’s check how much we lock ourselves in (vendor locking) by introducing a new service provider? If it’s no longer suitable, can we move? How standard is their solution, and can we possibly use it elsewhere and rebuild it?

The fewer external dependencies and the fewer services, the easier it is to keep things in hand (in mind). Not to mention we always come out cheaper.

Have a checklist!

Based on the above, I share my own checklist so that as a CEO, you always know what’s happening in your house.

Server names, IP addresses, users with passwords
Names of important and main users, email addresses with passwords
Recovery email addresses, phone numbers
Where is the server hosted? Abroad - why? Is it necessary?
Is database access protected? Not using “factory” passwords?
Do you have test and production, possibly other servers you operate? Where - how can they be accessed?
Who sends Push Messages and from where?
Where are the Service keys, API keys for services set and stored?

What to do if there’s already a problem?

It happens in life that a partner changes their mind, or you are no longer satisfied with their work and you would say goodbye to each other.

Presumably, the partner also wants to peacefully close the cooperation and doesn’t put obstacles in your way. Then you need to go through the checklist and jointly spend sufficient time on the separation. Active cooperation must be requested so it can be closed as soon as possible. It’s important that the contract between you legally still binds, and later the law will also help you if any obstacle arises.

The settings in the above-mentioned tools can be made simply. We can do it ourselves, and let’s do it! If we no longer work together, they have no need for data stored on our servers and in our applications.

Migrating apps, precisely because of the above unique name, is more difficult but not impossible. At Apple, this is harder, but there is a developed procedure for this and the app can be transferred to another Account Holder. At Google, the owner needs to be changed (and the store data rewritten).

I hope you find my thoughts on the topic useful. I have gained experience in the above and seen various solutions. If you need help, contact me through one of my contacts.