Is it legit to sign two apps with two different keystores, if need to be distributed under one company name?

Question

I have a situation, where I might use two keystores for two different applications made in the same company, one with Android and one with Unity. But I have never seen any company to use more than one Keystore for signing their apps, I have verified this comparing Google, Facebook, etc apps. So, is it legit according to the market and logical according to the devs to have two keystores for the two apps made by the same company.

Note : We need to distribute the apps over the world.

Answer 1

You can sign two different apps usign two different keystores, it is a perfectly valid way to do it. Or you can use the same keystore, but if you do this you have to use different aliases for different apps. I used different keystores to sign different apps for the same company, there is nothing wrong with that.

A keystore can be compared to a safe with keys: You can have multiple safes, but only one key per app. If you store multiple keys in one safe or have multiple safes with one key each.

And in technical terms: One alias is the key for an app, and a keystore is a safe. So essentially, it doesn't make any difference, as the aliases used are different. Doesn't matter how you store them, as the keystore (AFAIK) doesn't hold any kind of value except hold the aliases. The alias is the key it signs with, and the alias is unique for each app. If you store it in this or that keystore doesn't matter - the aliases are still unique.

TL:DR; The apps are signed using aliases meaning it doesn't matter if you store those aliases in this keystore or that keystore, the aliases are unique and for an app each.

---

The keystores are keySTORES, which can be understood as key storage. Anyone who has ever signed an app knows this isn't done using the keystore itself, but an alias in the keystore. The key in the storage. Whether you use this or that keystore, the aliases are still unique for each app. So each app is signed using a separate alias, and it doesn't matter what keystore it is in.

---

As for advantages one over the other, I personally go by this setup:

• One keystore for each app
• -> Lite and full version (if applicable) are in the same keystore
• But app A and B are stored in two different keystores.

Why? If I lose a single keystore for an old app, it doesn't matter (old app = dead app, not receiving updates, etc) as I still have the keystores for the ones I am maintaining. I am not sure how it is with corruption of the files, but if it is possible (and happens) one app is affected instead of all.

And as mentioned by @BillyFerguson, if you sell one app you can send a single keystore instead of the whole thing.

But you would have to keep a track of a large amount of files, which can be hard to do, and you risk losing track of the keystores.

Though the advantage with having a single keystore is the fact that you know you have all apps in there, and you don't need to keep track of possibly hundreds of keystores. But this would need regular updates in the backup system, as the file updates instead of having new files added.

Answer 2

It is perfectly legal to do so, however more annoying. You can use the SAME keystore to sign any number of apps and there is absolutely no issue in doing so. The only argument I can think of in regards to why you would want to use more than one keystore is if you were planning on selling one of those apps to someone else. Then using a separate keystore per app is useful as you could just give them the keystore/password used to sign the app and you wouldn't have to worry about changing the keystores for all of the other apps you used that keystore with.

Does that make sense?

Answer 3

Google Play identifies your app using the key used to sign it. If you use two different keys to sign an APK generated from the same code base, Google Play will treat it as two different apps. I am not sure why you would do this, but I am not aware of any policies that prohibit it, either.