App Center is gone: how to move test build distribution
· 7 min read
Visual Studio App Center was retired on March 31, 2025. Sign in stopped, the API stopped, and the appcenter distribute release step in a lot of pipelines started failing on the same day. Only Analytics and Diagnostics got more time, and that extension runs to the end of March 2027.
If your team used App Center mainly to get test builds onto phones, the good news is that this part is the easiest to replace. This guide walks through what App Center did, what replaces each piece, and how to move the distribution step in an afternoon.
First, split App Center into its parts
App Center was several products under one login. Most teams used two or three of them. Before you pick a replacement, write down which ones you actually relied on:
- Build: cloud builds for iOS and Android from your repository.
- Distribute: upload a build, send it to tester groups, give them an install link, and optionally prompt them in the app when a new version is out.
- Test: run UI tests on real devices in a device cloud.
- Diagnostics and Analytics: crash reports and usage events from an SDK inside the app.
- Store publishing: push a build to the App Store, Google Play or Intune.
There is no single product that replaces all of these, and trying to find one usually means paying for parts you never used. It is simpler to replace each part with a tool that is good at it.
What replaces each part
| App Center part | Common replacements |
|---|---|
| Build | GitHub Actions, Azure Pipelines, GitLab CI, Bitrise, Codemagic, or Xcode Cloud for Apple only projects |
| Distribute (install links for testers) | AppForShare, Firebase App Distribution, and for store betas TestFlight and Google Play internal testing |
| Test (device cloud) | BrowserStack, AWS Device Farm, Firebase Test Lab |
| Diagnostics and Analytics | Firebase Crashlytics, Sentry, Azure Monitor Application Insights |
| Store publishing | Fastlane deliver and supply, or your CI provider's store steps |
Microsoft's own advice is TestFlight for iOS test releases and Google Play Console testing for Android, with Azure Pipelines doing the upload. That is a fine route for builds that are going to the stores anyway. It does not give you what Distribute gave many teams: a plain link that installs an Ad Hoc iPhone build or an APK on a phone, with no store review and no extra app for the tester.
Moving the Distribute step to AppForShare
AppForShare does the install link part of App Center and nothing else. You upload an .ipa or .apk, you get a link and a QR code, and testers install over the air from the phone's browser. Here is the move, step by step.
1. Check how your iOS builds are signed
This is the one thing that catches people. A link install on iPhone only works for builds signed Ad Hoc, Enterprise or Development. If your App Center pipeline already sent Ad Hoc builds to testers, nothing changes. If it exported App Store builds, those cannot be installed from any link, and you need an Ad Hoc export for testing. AppForShare does not re-sign builds.
Ad Hoc builds install only on devices whose UDID is in the provisioning profile. App Center collected UDIDs during tester registration. On AppForShare, send new testers to the free UDID finder, which reads the UDID from Safari and lets them email it to you. Add it in the Apple Developer portal, refresh the profile and build again.
Not sure what a given .ipa is signed with? Drop it in the IPA inspector. It runs in your browser, the file is not uploaded, and it shows the profile type, expiry and the list of provisioned UDIDs.
2. Create an upload token
Uploads from CI are part of the Pro and Team plans. Sign in, open Dashboard, then Settings, and create a token. Store it in your CI as a secret named APPFORSHARE_TOKEN.
3. Replace the upload command
Wherever your pipeline called the App Center CLI, call the AppForShare CLI instead. It needs Node 18 or newer and prints the install link when the upload is done.
# before
appcenter distribute release --app my-org/MyApp-iOS --file build/MyApp.ipa --group "QA"
# after
npx --yes appforshare@1 upload build/MyApp.ipa --notes "Fixes the login crash"In GitHub Actions it looks like this:
- name: Share build
id: afs
run: npx --yes appforshare@1 upload app/build/outputs/apk/release/app-release.apk --notes "${{ github.event.head_commit.message }}"
env:
APPFORSHARE_TOKEN: ${{ secrets.APPFORSHARE_TOKEN }}
- run: echo "Install link: ${{ steps.afs.outputs.url }}"For Azure Pipelines, GitLab CI, Bitrise or Codemagic, it is the same npx line in a script step. Add --json if a later step needs the link, version or expiry. If you used the App Center Fastlane plugin, swap that action for one sh line after gym. All of this is on the CI docs page. Large builds go up in chunks and resume after a dropped connection, so flaky CI networks are less of a problem.
4. Map tester groups
App Center groups decided who could see a release. There are two ways to do this on AppForShare:
- Shared links: on Free and paid plans, a link can be password protected. Good for a small team or a client who just needs the latest build.
- Private projects (Team plan): only invited testers can open the builds. Testers get an email when a new build lands, and you can see who installed it.
5. Tell the team where new builds show up
App Center sent an email for each release. On AppForShare, webhooks can post every new build to Slack, Discord or your own endpoint (see the webhooks docs), and the AppForShare web app can send push notifications for new builds to people who turn them on.
What does not carry over
Being clear about the gaps saves you a surprise later:
- History: App Center sign in has ended, so old releases cannot be exported or imported. Upload again the builds you still need.
- In-app update prompts: the App Center Distribute SDK could tell testers inside the app that a new version was out. AppForShare has no in-app SDK. Testers learn about new builds from the email, the push notification or the link itself.
- Crashes and analytics: AppForShare does not collect crash reports or in-app events. Use Crashlytics, Sentry or Application Insights for that. AppForShare install analytics (Pro and up) show installs by device, OS version and country, which is about the build, not about what happens inside the app.
- Cloud builds: AppForShare does not build your code. Keep or pick a CI service and add the upload step at the end.
A sensible setup after App Center
A setup that works for many small and mid sized teams:
- CI of your choice builds on every merge.
- Each build goes to AppForShare with release notes from the commit message. QA, designers and clients install from the link, on iOS and Android, the same way.
- Before a store release, the same pipeline sends the store build to TestFlight and Google Play internal testing for a final round.
- Crash reporting comes from a dedicated SDK.
A side benefit: every build uploaded to an AppForShare account also gets a store readiness check, for example the iOS SDK version, privacy manifest and required reason APIs, Android target API level and 16 KB page size for native libraries. It flags problems before the store does. It is guidance, not a promise of approval.
What it costs
Guests can upload without an account, and the Free plan covers small teams with 7 day links. CI uploads, release notes, webhooks and install analytics start on Pro at $12 a month, and the Team plan at $39 a month adds roles, private projects with invited testers, a custom domain and a white label install page. Paid plans keep links live while the plan is active. Every limit is on the pricing page, and a side by side view is on AppForShare vs App Center.
