My goal is to distribute different release versions of the same app to different enterprise customers (based on business licensing). i.e. Different customers have paid for version X or Y of our one app, and we need to be able to install those different versions of the app at different customers, if they buy new devices, for example.
SO posts like this and this are actually about graphics resource delivery or file size.
This post is close, but essentially deals with different app resources for the same app version, rather than different app versions for different people.
There are delivery options such as sending an APK via email or hosting the APK on a company website, but these require customers to enable trusting unknown sources, which cheapens the experience.
The Google delivery options include:
Google Play Public apps
Private apps via Google Play (here and here), including their Enterprise Mobility Management (EMM)
This option also describes publishing internal apps for another organization
Option 1 would require a different package name per version, and wouldn't allow for upgrades.
Option 2 Seems to suggest that you can only deploy to users in your G-Suite
Option 3 Seems to require that the target customer uses G-suite for their mobile management, and then making any bug fixes to a particular released version would require updating each target customer's private enterprise app.
None of these options is attractive. Is there another option that I've missed?
Related
To distribute different versions of our apps (Android and iOS) we build different flavours.
Each of those flavours would have its own unique app identifier so we can install them next to each other on the same device.
We would also distribute them through Google Play and the App Store via a beta track and Test Flight.
This went fine until last week.
Now Google is telling us we can't have 3 apps (PRD, TS & QA) that are almost exactly the same (only app icon and backend url are different) in Google Play.
Obviously we don't intent to make the TST and QA version publicly available, but I get it that it's potentially possible.
Alternatively I've looked into App Center and Firebase App Distribution.
Which seems fine for Android, but as I understand you can only release AdHoc builds for iOS and you would have to manage all the devices for the provisioning profiles yourself.
I was wondering how others are dealing with this, or is there something completely different that can be done to separate between environments al together?
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 have a app created in xamarin forms, I already know how to create the APK, the app is to be used internally, i dont want to publish to the appstore, how can the app be update when is available a new version ?
Depending on your resources at hand and requirements, you have a couple of options. These options include, but are certainly not limited to:
Visual Studio Mobile Center (link): probably the most obvious choice. Out of the box support for Xamarin, and 'just works'. You can set up different groups of users, add analytics and crash reporting, etc. In the future you might be able to take your configuration to its big brother: VSTS. But beware! The product is in preview right now. Preview in Microsoft-land means free for now, but doesn't have to be in the future. While I expect it not to cost much/anything for basic functionality, it is something to be aware of. Not sure on this, but I think you need to invite your users by hand, so you have to know who you want to invite.
Google Play Store (link): It's kind of a mis-use, but you could of course leverage the Google Play Stores capabilites for Alpha/Beta testing. Also here you have the ability to create groups and have some basic reporting options. In terms of delivering your app you have some nice options here like A/B testing and unlike Mobile Center (again, I didn't verify this) you can setup a link with which people can enroll themselves. Depending on your needs, this might be nice. In terms of costs, this will set you back 25 dollars once. And you could develop and distribute other apps if you'd like.
Manual: send the APK file manually or hosting it on a shared location. I would prefer this least of all. People are not notified of any updates and you don't have any insights apart from something you might have incorporated in your app. Also you don't have any control over who installs or sees the app, etc.
But of course the prefered way would be to do it through the Google Play enterprise program. See this website. This provides you and your end-users with a private app store basically. Or as they say:
A managed version of Google Play is used by enterprises and their employees to access a rich ecosystem of work and productivity apps.
You can have private apps, only available for your targeted audience and still leverage the power of the Google Play store. The experience for your end-users will be unified with the regular app store.
I couldn't find a straight answer, but it seems the private apps will also cost just 25 dollars once and is included in the regular Play Store developer license.
You have a good way to do that : Use Beta this a service provided by Fabric, you can upload your app with different versions and get access to different teams in your company. It's easy to use and quick to manage.
Hope it helps.
You have multiple options at your hand:
use Bitrise or Visual Studio Mobile Center (aka HockeyApp) to build and provide a downloadable version of you app
in addiont to Bitrise or VS Mobile Center you can set up your own store. Take a look at Relution for example
build locally on your machine and push it to:
a fileshare
an FTP-site
the user by mail.
I have a need to have multiple versions of the same Android application running in production. Different customers use different version, based on their profile. For business reasons (which I cannot disclose), it is mandatory not to include any changes in for example user group X's application while the application must be developed in general though for different user groups. The application version used by group X should only be updated to fix critical bugs. The user groups are not based into geographical location or device, but are divided into groups by business needs (can be thought as different customers).
I'm aware that that multiple instances of the same app can be uploaded to Google Play, given that the package and name of the app is changed. But how do Google Play policies react to this?
I'm also aware that the application could be distributed from another source, via HTTP for example. Then the users must enable installing apps from untrusted sources. We also have an iOS application and as far as I know this is not doable on iOS.
What is the best practice to distribute multiple versions of the same application?
Google Play doesn't support this, you need to either release multiple apps (where user chooses the correct app to download) or implement this behavior inside your app ("Hmm... this is the lowest group, so use this old class instead of this new one")
EDIT: Theoretically, you could use closed beta and alpha channels for this, so that all users get the base version, people you add to testers list for beta will get beta version and testers for alpha will get alpha - that means you could do up to three groups. But managing it would be a hell
I would like to distribute a beta version of my application to a small group of users. Ideally this would be done through the market to make it easier for the beta testers.
Is there a way to restrict an app's presence in the market? The only solutions I could come up with were:
1 - Have users download the .adk from the web and install manually
2 - Release the beta version as a separate app in the market
The first option isn't ideal as you have to potentially walk the user through allowing apps from unknown sources. Not to mention from a user perspective, you're then downloading an app from an untrusted source.
The second option isn't ideal as you then are potentially confusing other users by having multiple versions in the market, one of which might be flaky. And then there's the inevitable comments about how something doesn't work in the market. I guess you could add some sort of password to that version that you only distribute to your beta testers.
Are there any better solutions?
Market is for public apps only so there is not any good ways to do this. Our app was distributed by email as apk when we where doing beta-testing. Use android forums to get beta-testers.
But, if you insist on using android market. I suggest re-name your app and package-names, and put it into the demo category. But again, I would not used android market for beta-testing.
Perhaps put a relatively high price on it and refund the beta users' money.