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.
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.
Google Play is not the first time insistently offers to use the App Bundle application.
I started to understand, but did not see many criteria and reasons to use it in my project, so please tell me who has already encountered or managed to notice more than me.
One of the main criteria that I managed to identify for myself is the ability to load functions On Demand. By the way which are very well described here.
But based on this, the only criterion that comes to my mind is that you can load those or modules as needed.
It is also not clear how the choice of screen extensions/specific platform when downloading the application from the Google Play Store.
App Bundle allows your app to be split up along different lines.
https://developer.android.com/platform/technology/app-bundle
It's easy to switch. You don't need to refactor your code to start benefiting from a smaller app. And once you've switched, you'll benefit from modular app development and customizable feature delivery.
Therefore like you mention
One of the main criteria that I managed to identify for myself is the ability to load functions On Demand. By the way which are very well described here.
So Google can be clever and send a subset of your app to the device. (The benefit being faster download times for your app. More acquisition, less user drop off on install).
If your app targets tablets and phones, google can be clever and only send the tablet resources to the tablet. Same example can be said for languages and other resource types.
Documentation benefits:
They give 6
TLDR: 1 file to upload when making an app
Build one artifact that includes all of your app's compiled code, resources, and native libraries for your app. You no longer need to build, sign, upload, and manage version codes for multiple APKs.
TLDR: smaller downloads for users
Google Play's Dynamic Delivery uses your Android App Bundle to build and serve APKs that are optimized for each device configuration. This means your users enjoy a smaller app download without the unused code and resources needed for other devices. Track the size of your app in the new app size report in the Google Play Console.
TLDR: smaller downloads for users
Customize and control your user experience by delivering features to the devices and users you choose, as and when they're needed, instead of at install time. This means that adding features no longer has to result in adding to your app's size at install time. Use conditional delivery to deliver features to countries, device types, or devices running a minimum SDK version. Use on-demand delivery to deliver features on demand, which can be installed and uninstalled as needed.
TLDR: More maintainable code
The Android App Bundle enables modular app development so you can design, build, debug and test your app's features as independent modules that can be added to your main app when ready. You'll see fewer merge conflicts and disruptions because you no longer have to have an entire engineering team working on the same monolithic app with complex and bloated code.
TLDR: Faster build speeds
Build systems, such as the Android Studio build system using Gradle, are optimized for modular apps so they are significantly faster to build than large, monolithic apps. You'll spend less time sitting around waiting and more time designing, coding, and testing your app.
TLDR: Better user acquisition
Instant-enable your Android App Bundle or instant-enable specific dynamic feature modules to give users a frictionless way to experience your app. Users can launch your experience from the Try Now button on Google Play and web links without installation.
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?
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.
I want to upload the same application twice to the Android Market. One version will have AdMob messages and the other version of the same app will cost a pair of bucks.
Should I make two applications with differents packages names in order to upload them or is there any trick to do it with the same project.
Thanks in advance.
Every application at Android Market must have unique package name, so you have to place your apps into different packages (one be a subpackage of another though, i.e. com.app and com.app.ads). You can share common code in a library project.
You will need two different package names. You might also consider to exclude certain parts of your code in your free version, because Android Market is known for not being the most secure distribution channel. But if the only difference is the additional ads in your free version, it is not worth the effort.
There is another possibility, which unfortunately, I don't know how to do, but I'd like to find out. You can put all the functionality into one app and then create a second app which acts as a "key". Users download your first app for free, but it has limited functionality unless the "key" app is also present. You would charge users to download the "key" app.
This solution has the advantage of not having to maintain two code bases for every app, which is what I do and it drives me nuts.