Publishing same app with different names in the Play store - android

I know it is technically possible to put the same application into the app store with 2 almost identical APKs (different package names and titles), although probably a bit dodgy - I imagine this would not be allowed by Google, but I don't see anything in their Ts & Cs that prohibit this
https://play.google.com/about/developer-distribution-agreement.html
E.g. "My cool app free" And "The awesomest app trial"
Question: Is this allowed?
Reason: A colleague and I were debating the effect of titles and descriptions of downloads (based on different indexes/user searches) and wondering if people ever post a game/app with 2 different ones to see which is more successful

You can if the package name of the app is different, as you said. This is done quite often for apps with trial and paid version. Regarding your question, we have right now around 6 apps in Google Play which are different branded versions of the same app. This means, they have their own package name, splash screen, and some database data, but the app is really the same. So far we didn't get any trouble with Google, so I would say it's possible.
Just for reference, in case you are interested in doing something similar, the best option in terms of maintainability of your app, consists in using an Android library project.
Basically you have one main big project with the "Android Library" option checked in Eclipse. You have all the main code there.
On the other hand, you create two additional projects linked to your library. They will just need their manifest.xml and some activity to call the main activity of the library. Their package names must be different if you want to publish both apps in Google Play.
Additionally, you can override some resources for every project. For instance, you could have a boolean in /res/values indicating whether the project is a trial or paid version, with different values for them. Then, in the library you could check this boolean to show advertisements if it's a trial version.
Another useful thing you can do is using a custom splash screen for every app, by having different image resources in every project with the same name.

As far as I know, it is allowed and certainly has been done in the past (malware masquerading as popular games). Provided the app you're publishing is your own work (and really only the name is different), then I can't see anyone reporting it either.

It is prohibited according to Play Console Developer Program Policy (effective October 21, 2020).
We don't allow apps that merely provide the same experience as other apps already on Google Play. Apps should provide value to users through the creation of unique content or services.
Here are some examples of common violations:
Copying content from other apps without adding any original content or value.
Creating multiple apps with highly similar functionality, content, and user experience. If these apps are each small in content volume, developers should consider creating a single app that aggregates all the content.

Related

Can I put a second version of my app on Google Play Store

Because of how my app has evolved I want to split it into two different play stores so I can better describe it.
I can't find info on if this is allowed by Google or not. It would be more or less mostly the same application, but with a different title and description.
Secondly since there are a lot of paid versions of applications, is it fine for me to do this if I make one of the versions a paid version?
Thanks
Yes, you can do so, but it requires your app to use a different package name (i.e. a different application id). It will basically be a different app.

same app with difference cosmetic features, depending on where it was downloaded?

Is there any way to make my app "aware" of where it is downloaded from?
To clarify, they will not be going through the app store, they will be downloading the actual apk or plist (I think .plist is the extension for iOS?) file directly from my website.
Background
My situation is: You go to my company website, you get involved with one of our contractors, and you download our app from our website. However, depending on which contractor you have a relationship with, the app is branded with different UI elements specific to that contractor. I want there to only be a single app, but when you download it, the app is "aware" of which contractor you downloaded it from, and then uses some logic, (likely calls to a webservice, but the implementation of that is not important here) to display branding specific to that contractor.
I am trying to do this for both android and iOS, so solutions for both or either one would be appreciated. I want there to just be a single app (1 for iOS, 1 for android) because it is not desirable to create a new app everytime we get a new contractor, and because we would only want to have to register 1 app for push notifications.
Asked before
I realize my question is a duplicate:
It is essentially the same as this question: (One iPhone app with different template based on the URL it was downloaded from)
I want to give my iPhone app to different distributors for
distribution.
When a user will download the app from one of the distributors and
open it the app should connect to our servers and ask for the unique
settings of this distributer.
The question is, how each app can "tell" from which distributer it was
downloaded from?
I don't want to compile a different application for each client.
I am reasking it because the answers were unsatisfactory and did not at all address the issue, and the question is old (over 3 years old)
The first answer:
Do you want an app or iOS WebApp? if you want iOS app, I do not think
you can distribute to other distributors, because Apple is the only
distributor of iOS applications, so all the downloads come from there.
if you want a WebApp, you create a download link redirected to your
webapp to read the link to the server it pulls everything you need,
layout, information, etc ...
They completely missed the point, it has nothing to do with the question. The second part explains how one would get the different UI elements, but does not answer how the app is aware of which UI elements it should be requesting in the first place.
The second answer:
I did some research into this and the only way I found to do it is
just to create different targets for each app then share the source
code across both the apps, but this still means that you would have to
do two submissions still.
This does not answer the question either: AFAIK, multiple build targets help to have a single code base, but you still would be maintaining multiple apps, not a single app.
For Android, for a self-distributed app, you have two main options for creating "branded" editions of that app.
One is to use Gradle product flavors, where you create one flavor per contractor. Each flavor can have what amounts to an "overlay" sourceset, where you can replace stock resources (strings, icons, colors, etc.) with ones for that flavor. When you build the app (Android Studio, CI server, manual command-line builds, etc.) and have it build one or all flavors, you get a per-flavor APK with the per-flavor resources. If, at a later point, you elect to have per-contractor application IDs (so N contractors' apps can be installed at once), making the change will mostly be a matter of adding one line per flavor to your Gradle build file (identifying the application ID for that flavor) and updating your GCM API key for each application ID.
The older approach would be to change files in assets/ of a standard APK to make a branded edition. This approach is aggravating, as you can't take advantage of Android's resource system, and you have to arrange to re-sign the modified APK, but it will work.
In both cases, you have dedicated APK files per contractor, so you arrange for your download link to point to the right one for the contractor for this particular customer.
The com.android.vending.INSTALL_REFERRER solution probably is not a great solution for you. Besides the dependency on the Play Store, your app would have to have branding for every contractor "baked in". Certain elements (application icon, application name) cannot be changed at all and would have to be the same for all contractors. Other elements (launcher icon, launcher name) could be changed, but on some devices will take a reboot to take effect. And if you don't ever get that broadcast, or it is not for a recognizable referring URL (e.g., the user just found your app in the Play Store and installed it), you're in trouble.

Android App name conflict

I am about to launch an android app and I have decided the name "Math addict" for it.
The problem is -
There is a website named mathaddict.com which has their software called Math addict but I couldn't find copyright documents on their website.
An app exists on Apple App store with the exact same name.
But there is no app with such name on Google Play as of now. Moreover I haven't copied anything from any lf these apps/softwares.
Is it advisable to use this name for my app? My apps have been suspended on Google Play in the past and hence I am little more apprensive this time.
Please suggest what can be done.
I also suggest you jse a different name, let's assume someone search's Math addict in google it is highly possible that the web site you mentionned and the app from app store will be shown at first so yours will be the last except if you do some good work on keywords optimisation,
You instead use something like Math addict app , mathapp, appmath
IANAL. As long as you are not trying to impersonate these other products, you should be fine. However, in the extreme case this can quickly lead to some ugly court battles if your app is in competition with these other websites and products. Assuming that you are a single developer, you probably don't have to worry about this. However, if you have a large success, then you might need to be concerned. The legal battles between Apple Computers and Apple Music are quite famous for fighting over the legal right to a name.
I really don't think you need to be worried about the legalities here. On the other hand, you want your app to be found and not to be confused with other similar apps. At this point, I think differentiating yourself from the competition is probably a much higher concern.
According to Google Play policy:
Impersonation or Deceptive Behavior: Don't pretend to be someone else,
and don't represent that your app is authorized by or produced by
another company or organization if that is not the case. Products or
the ads they contain also must not mimic functionality or warnings
from the operating system or other apps. Products must not contain
false or misleading information in any content, title, icon,
description, or screenshots. Developers must not divert users or
provide links to any other site that mimics or passes itself off as
another app or service. Apps must not have names or icons that appear
confusingly similar to existing products, or to apps supplied with the
device (such as Camera, Gallery or Messaging).
Source
So I will highly suggest you to select a different name for safety.

Android: Managing Ad-Free and Ad supported version. Move to in-app purchase?

I currently have an Android app which is distributed as two applications an Ad supported version and an ad-free version. The Ad-Supported version has over 10,000 users and the Ad-Free version has a couple of hundred. Currently both projects are completely independent making updates a fairly tedious task.
Ideally I would like to just updated one project and build be able to build both versions.
After looking online it seems I have two options:
Make a library containing most of the class files and then just extend this for the two versions (changing only the files that are different). As the project is fairly big this may be a large task and may cause some serious headaches.
Just release one version and use in-app purchases to remove the ads. This seems the easiest route but how do I allow my existing ad-free users to remove the ads via in-app purchase without paying?
Hopefully someone has been in a similar predicament before and can point me in the right direction.
Where I used to work we had the 2nd option. It helped us a lot since you just need to maintain 1 code/app/apk. In your case, I suggest you to do the same thing.
In order to migrate all your users to a single App, you can give a random code (generated with the email they are using and an algorithm to create it) via your "Ad-Free version" app. Then, in your All-in-one app you can ask for that code or activate the "In-App-workflow" in order to remove all Ads.
Edit:
Check this link:
How to get the Android device's primary e-mail address
I am always recommend SO user to used android inapp purchase.
Benefits:
1) Easily track manage your playstore user.
2) If updation require then update code on one place.
3) Secure payment with google policy.
4) many more feature.
#bencallis as per your question i recommend to you option 2 is better.
if you require any inapp information then put comment.
You're in a similar boat with me, though I've taken one step already.
I made an app for a small group of people that are close to me, free and ad-free, and released it. I then created another app for a wider group of people, free but with ads. The two applications were almost the same, except a few things that had to be app-specific (like strings, resources, and a few variables). After getting frustrated with updating both of them, I decided to go with the library approach. It might give you headaches in the beginning, but it will truly cut down on your updating. You'll only have to update the library file, then just compile and check the actual application.
Because of how you describe your situation, I think you'll have an easier time than me. Turn one of your applications (probably the ad-free one) into a library, then in the ad-supported version simply overwrite the layouts that show the ads.
I can't suggest your second option, only because, as far as I know, there is no way to do what you want.

Android App naming convention - does it really matter?

Can Andorid Apps have same name - public name.. or they need to have different names..
i want to ensure that if i create an app and post on google play... someone else sld not copy the app and host it elsewhere with the same name..
please advise if apps can or cannot have same public name..
Your question is about apps having the same name, but your actual concern is about the theft of your application. These are two separate issues.
If someone did a straight copy of your APK and attempted to post it to Google Play, then they would be unable to do so if you had already posted that same APK to Google Play yourself. The reason they would be prevented from posting it, however, would be due to its package name being the same as an existing app, not because of its name.
A more sophisticated thief might be able to change your package name, and if they could do that, then they could also probably (even more easily) change your app's name. In that case, they might be able to post the resulting app to Google Play. You then would might decide to complain about this to Google and ask that the infringing app be taken down. There is a form for this kind of complaint here:
http://support.google.com/googleplay/bin/request.py?contact_type=takedown
I don't know what kind of results you might obtain from such a complaint, but Google has recently become much more focused on preventing infringing apps of this kind, so you might get a good response.
If you're talking about other app stores, outside of Google Play, then you have to look at the policies of those stores. But certainly there is nothing preventing an app that has been posted on Google Play from being posted on these other stores, provided that it meets the policies of the other store. Developers do this themselves (post on multiple app stores) all the time. And of course it can have the same name and the same package.
Regarding the more general question of whether two apps on Google Play can have the same name:
In the past it has been the case that two apps could have the same name on Google Play.
However, in August, 2012 (since you posted your question) Google announced new Developer Program Policies that state that
"Apps must not have names or icons that appear confusingly similar to existing products, or to apps supplied with the device (such as Camera, Gallery or Messaging)."
The full policies can be found here:
http://play.google.com/about/developer-content-policy.html
It may still be possible to post an app that has the same name as an existing app, but if someone did that, there is at least some chance that Google's (somewhat inscrutable by design) automated detection process will flag that app for the above reason. This could lead to a letter from Google and, if the app's name were not changed, an eventual takedown.
These policies are relatively new, and probably nobody, even Google, knows exactly how they are going to play out. How, for example, will Google resolve apps that are already similarly named? Will it go with the first app to use the name, or will it go with the most popular app having the name, or will it ask app owners to negotiate a settlement, or will it just allow the ambiguous names to be grandfathered in? I certainly do not know the answer, but for new apps, for sure, honest developers will avoid naming their apps in a manner that is similar to your app, and malfeasants who use the same name are likely to hear from Google.
Your package name must be unique (ex. com.example.mail.free) to publish an app on Google Play.
I nearly sure that the name is not important. You can have different names on different languages.

Categories

Resources