I have a company that develops different android applications for its different customers (each of them are a different company ) but almost all apps subject are same. For example android applications for different car firm companies.
Now, the question is that: Is it recommended that I sign this applications with same key, or for each company that ask an android application I should create a different key-store?
Thanks in advance,
I'd say that the answer is no.
I had the case, where after I had developed an application with a single keystore for multiple customers, one of them asked for the key, so that they could continue the devlopment in-house. The result was a giant mess. I would not wish that upon anyone.
Seting up different keystores is not that hard, and as I see it, besides the organization advantages, there is no other reasons to sign different apps with the same key, unless you have some elaborate lock-in strategy in mind.
TL;DR - Yes, use a seperate keystore for each one of you client companies.
You can store multiple aliases (with different passwords) into a single keystore. I recommend you to read Signing Strategies.
Related
Context
We have an app (for both iOS and Android) that we would like to style differently for different customers. What I mean by this is that the functionality, features, navigation, layout etc. of the app will remain exactly the same but what will change is - fonts, icons, colours, button shapes,font sizes etc. which would be specific to the customer's brand. We also want to have a different store listing per brand and the app may be called with a different name per brand like XXX App
Probable Solutions
We have considered the following solutions
Have completely separate code bases for the app / customer - Advantage would be ease of publishing but super high maintenance costs would be the biggest disadvantage
Have single code base but do some sort of themeing solution / customer - In this case, not sure how the publishing process would work in terms of the bundle ids, store listing etc.
Have single code base with packages or libraries. Create different shell apps for different customers and import the core packages or libraries
Have a single app which is listed as our company's app, and each brand can use that - which is the prescribed solution on the stores, but it doesn't seem very commercially viable as a brand paying money would want their brand to be reflected in the app and their respective listing on the store
Using some homegrown bash script mechanism to configure things at build time?
something other mechanism...?
Questions
I would like to know
What would be the acceptable (by App store and Play store policies) mechanism to publish such an app for different customers.
In case of one store listing per customer, could the applicationID (android) or bundleID (ios) be same for all the listings on the stores? or would they have to be different?
In case of one store listing per customer, for iOS would the app require different SKU for each listing?
In case of one store listing per customer, for iOS would the app require different SKU for each listing?
Thanks
According to App Store review guidelines, you MUST publish the app with the apple id of your customers because it has the name and brand of them. Or, you could publish by yourself with a legal written statement that says that you can use their brand to publish the app.
The guideline 5.2 talks about this with more details.
https://developer.apple.com/app-store/review/guidelines/
For google play the thing is the same, but the implementation came more recently. I personally dont tried to submit an app for a customer after google published this new rules, but I did it once (2 months ago) and no problems so far.
You can look at this rules in more details here:
https://play.google.com/about/ip-impersonation/ip/
Now, talking about the bundle id and app id, they must be different. For the name of the app this wouldnt be a problem, but for the app id and bundle they must be different.
For your solutions, all work fine. But in my experience a very maintained app that relies on config files to customize the interface for each client is more prone to work. I know that each client will ask for custom modifications, but for that you can use branches for each one and maintain always updated to the master branch.
I am developing an SDK/API that will be used by apps not written by me.
I want my code to generate a private key once and store it on the device.
This key should be unique per device, I don't mind it being erased on factory reset, and I don't need to extract it from the device.
Sounds an ideal case for the KeyStore (preferably with a StrongBox).
I do want, though, different apps to use the same key to sign (or ask my API to do so)
I could not answer two concerns:
If my API is a library linked (statically) into the app, different apps using my code wouldn't be able to use the key, because the keystore requires
If I package my API as a separate android app, and have the other apps use it using Intents, I'll have to have the user install it manually, because as far as I could tell, Android/Play does not allow for dependencies between apps.
What is the most graceful way to resolve this situation?
Our company currently has several APPs for Android in Google Play Store, developed by different software providers.
What would be the best approach for this situation?
Having one keystore for all the APPs from our company?
Having one keystore for each provider? For each APP?
What would be the main benefits and drawbacks from each approach?
Thanks.
In my opinion having one keystore for each provider will be better approach in this situation. Afterall it is signing and instead of signing all the apps with one keystore, multiple signs will be better. However, if your company have 200 apps with 100 different provider then it would be unwise to have different keys. It is about your scale and choice. Yet, i don't think there will be so much difference between two approach.
You can use flavor for different-different app version and app.
I would STRONGLY recommend having a different certificate for each app.
I would also STRONGLY recommend using Google Play App Signing rather than signing the app yourself.
The benefits of the first case is future commercial flexibility. App developers often want to sell their app to another company, spin off a division to a separate company, or separate responsibility for app signing keys so they don't have a single point of failure. If you have a single key then:
If you sell the app to another company then you have to give them the signing key and they can sign any of your apps, thereby producing fake versions
if you want to spin out a division the same problem occurs
if you want one team to be able to sign their own app for testing, then they can sign any app for the company.
Having a separate key solves all these issues.
If you want to know why you should use Google Play app signing you should search StackOverflow for questions saying things like "help I have lost my signing key/password/had a computer stolen, what can I do?". There are hundreds of them, and the problem has hit even some of the biggest developers. If you use Google Play App Signing then Google Play will keep your key safe, and Google Play support can help you if you lose it.
To comment on the answer that cites the Android Studio page they misunderstand it. That is just about having a single signing key per app, not across apps.
There are some reasons to use the same signing key for multiple apps. On the Android system this gives the apps some abilities to trust each other in certain ways on things like RPCs, but it is very rare to need this.
I have Google Developer account and I published my first application.
Now I need to publish my second app. Should I sign with the same keystore of my first app.
Please let me know if I'm not clear.
Using the same keystore/key pair is fine for as many apps as you like. I have several that share a keystore/key.
Here is how you should decide if you need a separate key/keystore, in order of importance/concern:
Having more than one key or keystore requires remembering passwords and their locations along with securing them. This can be a real pain if you don't update your apps for quite some time. If you lose these, you cannot update/republish your app.
It is probably a good idea to use separate keys and the same keystore. This can reduce the likelihood that a hacker could hack both if either is ever hacked. However, this concern is minimal since this scenario is unlikely unless you have a very popular app.
If you want to "sell" any of yours apps at some point, you will need to provide a keystore and key to the buyer. Thus, the buyer will know your other app's keystore/key information if they are shared. If you would likely sell apps together, then a common key/keystore is not an issue. If you want to sell them separately, then you should probably have separate keystores and keys. HOWEVER, this is very unlikely to ever be a consideration.
Good luck!
A keystore can old multiple keys.
Use one key for one application.
Now, you can use the same keystore and add a key to it, or create another keystore.
What is the best practice for an organization that will need to sign multiple Android apps?
Do we create one key and use that on all of the Android apps that we build? My initial thought is that this is a good approach.
Or, do we create a new key for each Android app?
Does anyone know how an organization like Google or Rovio handles this issue?
One of my clients uses a different key for each set of related apps. So apps that are usually used together share the same key, but unrelated apps have a different ones. They feel that segregating the keys this way is a good balance between ease of key management and minimizing exposure if a key ever gets disclosed (by a disgruntled employee, etc.).