Use case:
We have a container App which comes without the needed content preinstalled.
Only after installing the App, users choose which items they want to install. The items here are "city packs", that is data for rendering maps, routing offline etc.
It would be very attractive for several reasons to be able to create Appstore entries for specific cities. However we don't want to get into a mess by really duplicating the App (maintenance overhead, fragmentation, potentiall confusing for users).
That's why I was thinking about something like this:
The additional Appstore entries install a minimal App (I'll name it client App) which essentially just launches the main App with some parameters. On Android that should be possible with Intents, on iOS with custom URL schemes.
Since I don't know of any App using that approach, I wonder if they exist and if it's possible.
There are however 2 potential issues I see with that approach:
If the main App isn't installed when one of the client Apps wants to launch it, the client App can still open the App page in the Appstore. At that point however the client App will lose control and I guess will not be able to have the main App launched with a parameter set. Is that correct?
Would Apple accept such an App?
I'm not sure if what you want to do is possible, but with my experience with Apple it is unlikely that they'd be happy with many different parts of the app being separate... I may be wrong, but that's how I think it'll go...
Have you thought about using in-app purchases? Even if the packs are free i'm sure you can set the cost to 0 and have the data download then?
Related
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.
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.
When developing an iOS app one can register or claim an app name by creating an entry in iTunesConnect and supplying placeholder descriptions and screenshots. Is there a similar process in the Android app store?
I'm not interested in squatting on app names. I'm just porting an iOS app to Android and I'd like to have an identical app name.
I dont think there is an equivalent in the android ecosystem. Here are a couple of suggestions which may not guarantee the name, but may help in some ways.
1) You can publish a bare minimum app with the correct package name (like com.company.appname). But I think the actual app name part will still be pretty open.
2) Another way may be to buy a .com domain for your app (if it is still available). It may sound far fetched but I believe (I may be wrong) people take that into account to avoid getting into trademarks & copyrights issues. If you have an app that is good enough for being published in multiple platforms, then buying a domain makes sense.
When you visit the market place web site on a desktop browser and log in with your account it knows about your devices and what apps do and do not work on it. Fairly understandable how they do this.
What is intriguing is the feature whereby you can click the install button on the web site and the app is then automatically downloaded and installed on the phone. Now that is magic! How does this push notification work?
Is it something that can only be done via the market place web site or is it a feature that can be used by third parties to trigger installations? My use case is to drastically simplify the use of a QR code to install an application. The QR code take the user to a mobile web page that has informative content (e.g. about a painting in a museum) and also has a button to allow the user to install the corresponding application that has the same but offline content. The app would installed without going via the market place and thus losing the user's immediate attention.
I expect that the answer is "you can't do that" but rather than live under that presumption I thought that I'd ask. Is there another way to achieve my use case?
In general much work was done to ensure any applications being installed require explicit action to be taken by the user(i.e. view the permissions and press the install button). This behavior that the Market service exhibits is one of the few things that sort of sidesteps this process but I would assume the logic behind it is that the user viewed the permissions and agreed to the install on the web front end so it would be redundant to make them do it again.
As far as I am aware the use case which you mentioned (user is browsing on PC and installs app to one of their devices from there) is the only situation where it works like this. I don't believe the market offers any way for 3rd parties to tie into this and distribute their applications in this manner (other than the market web front end).
So in short, no there isn't really any other good way to push applications like that.
Im sure you could set up something that behaves similarly but it would rely on something extra being done to or installed on the device and as such it wouldn't work on stock devices which means 90% or more of people wouldn't be able to use it.
I do agree with your motivation though, it seems like a trivial process to some of us to install an app from a QR, but the general public is not yet at a point where you can count on them get it it all done correctly and quickly enough that their attention is still focused on whatever it was, in your case the item in the museum.
There are certain security measures which prevent automatic installs from unknown sources.
Outside of Android Market, downloading & installing are two separate steps. The QR code which takes a user to a web page, that bit is easy: Just embed a URL in a QR code. When the user goes to the page, they can download the APK file as an attachment (just link to it somewhere on the page).
However, the user then needs to manually select the APK from their downloads section, and explicitly indicate they wish to install it (just a button click). The user also needs to enable downloading from "unknown sources" on their device. This can be enabled in the Settings App, usually in a security area. The feature may be disabled by certain carriers. Note that any "Market" type app or mechanism for downloading APK's which didn't come pre-installed on the device is going to count as an unknown source (websites are counted as unknown sources)- For instance, using the Amazon Market app requires a tick in that checkbox.
I've been training myself up in Android development. I have an idea for a series of apps that all relate to the same basic data store which stores similar/related hobby data. I suppose in my mind access to this data should be similar to how many apps make use contacts. So I started reading up on content providers but from what I can see they don't actually provide the flexibility I require.
What I want is to create say 4 or 5 hobby related apps that record similar and related data however a customer might decide they only need a specific one to start with. Later they might decide that one or more of the other apps might also be useful.
The data the apps store is very similar, the core data is the same. So the obvious choice is a content provider. However I can't see the providers offer the flexibility I require. Firstly how does the 2nd app purchased figure out that a content provider is already available and if so not install its own (this seems to be hardwired in the manifest and there is no programatic control). Secondly how would an app realise there is no content provider and install one (related to point one). Thirdly a new app installed might have a more up to date provider or an older provider!
So I don't think the providers offer what I need. I also notice that the databases are sandboxed and providers seem to be the only method for apps to share persisted data, or is there something I'm missing. It actually makes me wonder how for none default installed content providers how useful providers are!
I suppose an alternative method would be for a customer to purchase and app and then later ad on extra functionality but I'm not sure if this is possible and if so where the information is.
Any help would be appreciated.
Steve
Note to moderators: at first I thought I'd consider this an argumentative question, but now that I think again I think it's a design problem. A good one that shall stay here.
The data the apps store is very similar, the core data is the same. So the obvious choice is a content provider.
Yes.
Firstly how does the 2nd app purchased figure out that a content provider is already available and if so not install its own (this seems to be hardwired in the manifest and there is no programatic control). Secondly how would an app realise there is no content provider and install one (related to point one). Thirdly a new app installed might have a more up to date provider or an older provider!
Many apps do this by having a "library app" available in the Market that provides the common functionality that other apps from you may need. You should ask the user, in any of those apps, to download that library app to enable the underlying functionality of the "UI apps". I don't know, maybe I would take that route... after all, you need to consider the namespace conflict of your content provider(s), hence the "library app".
I suppose an alternative method would be for a customer to purchase and app and then later ad on extra functionality but I'm not sure if this is possible and if so where the information is.
Yes, that's what the in-app billing is for. However, that assumes you'd have one app with different features.
Truth is, it's a good question. It certainly caught me thinking. I believe it's up to you to provide one app featuring a suite of features added by in-app billing, or many apps that share a common functionality provided by one central app also available in the market.
About this last problem, I would do what feels more natural do the user. If the apps are really unrelated, subject-wise, I'd provide different apps. If it's a suite-like product (think Office suites, for example), I'd implement in-app purchases. There is also a small security issue regarding the code visibility (enabling by software versus per-download).
Anyway, in-app purchases are definitely simpler and easier to maintain, in my opinion. But if your apps are that big, it could be a waste of space... not efficient.
My 2 cents.