Appcenter: Distribute multiple app-ids from same AppCenter app

[kimbirkelund]

Problem

We're using a single AppCenter app to distribute alpha builds (from feature branches), beta builds (from develop branch) and RC builds (from master branch). Alpha, beta and RC builds have different app-ids, to enable them being installed side-by-side.

However when the Distribute SDK detects a new version it doesn't check the app-id and so simply installs the latest version available regardless of whether it is the current app or not. This results in the added problem of missing versions, because only the latest version is checked, and the newest build hides any builds with different app-ids that might be newer than the currently installed one.

And to take this up front: we're using a single AppCenter app because the amount of apps would explode otherwise. We're building a white-label app using Xamarin. So one app per build-type would result in brands * platforms * types => brands * 2 * 4 apps. It's bad enough that iOS and Android has to be separate apps, handling this many would be quite prohibitively.

Wanted solution

We'd like for the Distribute SDK to take app-id into account when check for new versions.

Alternative solution

Expose API for querying releases (filtering on app-id) and install specific version in the Distribute SDK, so this feature can be implemented manually.

[ghost]

Hi @kimbirkelund
I am one of the developers from the AppCenter and trying to understand and investigate the problem you stated.

I am assuming that

1. You are using an app-secret associated with an app-id on AppCenter for each build type. Means for an alpha build you created an app in the AppCenter and used an app secret of that, for Alpha builds, while used an app secret for beta app from the AppCenter for builds of beta builds.

1. You are setting a bundle id (ios)/ package name (Android) per build type so that each build type is installed separately on mobile devices. This is for a device to create different apps instead of overriding them.

2. You are not cross uploading builds with other app's secret. Means you are not uploading beta build of your app with app secret of alpha build etc.

Please let me know if my assumptions are wrong and more info to diagnose it is appreciated.

[kimbirkelund]

We're building our app in Azure Pipelines and distributing it using AppCenter. Specific branches are designated alpha, beta or release candidate and app packages are build with ids to reflect that status. All of these app are distributed to the same AppCenter app, and we have groups to direct each release to the appropriate testers.

As long as a user is only in one group (and thus getting one type of release) there is no problem. But when a tester is in two groups they get updates for two different app ids, and the SDK is designed to expect there to only be 1 app id for a given AppCenter app. Thus when checking for updates in one app its detects an update with another app id, and installs that. This leaves the app that discovered the update unupdated and when launched again keeps discovering the update.

To be clear I'm not saying there's a bug. I'm sure it's working as intended. It's just that we're using it differently to avoid creating a bunch of AppCenter apps.

[joshfriend]

This is a great idea. I usually distribute *.internal test builds, *.external builds for external testers and then the release builds, which requires three separate apps in appcenter. Firebase groups all variants of the app together (including iOS)

[ghost]

Thank you @kimbirkelund for quick reply.
I am going to forward your request to our product management team for adding your request to the roadmap.

[StargazerNC]

Hello,

Is there any news on this subject? I was searching for this exact same thing since it's our approach also...Thanks.

[msftbot[bot]]

This issue has been automatically marked as stale because it has not had any activity for 60 days. It will be closed if no further activity occurs within 15 days of this comment.

[msftbot[bot]]

This issue will now be closed because it hasn't had any activity for 15 days after stale. Please feel free to open a new issue if you still have a question/issue or suggestion.

[joshfriend]

can this be repopened? just because nobody has commented doesn't mean we aren't still interested