Moving test builds off AppsOnAir: links, testers and CI

Nov 3, 2026 · 9 min read

Moving test builds off AppsOnAir (by Logicwind) is a smaller job than it looks, because you usually move only one of its products. AppsOnAir bundles OTA build distribution with CodePush, deep links, push notifications, a force update SDK and a feedback SDK. Most of those live inside your app and can stay where they are. What moves is the build sharing: a few live share links, the testers and groups who get them, a CLI step, and the habit of writing feedback in the AppsOnAir app. This checklist takes them in order. It uses AppForShare as the destination because that is the tool we make; the first two steps work for any target. The short product guide is Move from AppsOnAir.

AppsOnAir details are as read on their pricing page, OTA page, OTA documentation and CLI page on November 3, 2026.

What moves and what stays

On AppsOnAir	What to do
Builds and share links	Leave old links to expire. Upload only the builds still in testing
Several share links per build	Extra links per build on Pro (up to 3) or Team (up to 20)
Link expiry and passwords	Password per build on every account; stop date, pause and install cap on Pro and Team
Groups such as QA or Clients	Tester groups on Team, or one channel link per audience on Pro
AppsOnAir tester app	Nothing to install; Team has a home screen web app
Feedback in the app, AppRemark SDK	Install page feedback and the in-app feedback link, no SDK
CLI step	Swap for the AppForShare CLI, GitHub Action or fastlane plugin
Google Chat notices	Google Chat, Slack, Microsoft Teams, Discord or a webhook
CodePush, AppLink, push, AppSync	Stay on AppsOnAir if you use them

Step 1: upload the builds still in testing

There is nothing to export. Share links already out keep following AppsOnAir's rules, up to 30 days on Free and up to 90 days on paid plans, as listed on November 3, 2026. Apps already installed from them keep working until their own profile or certificate ends; a link only controls new installs.

Upload the current build of each app. For one or two, the web upload box is enough, and a guest upload needs no account at all. For many, or for both platforms at once, use the CLI on Pro or Team:

export APPFORSHARE_TOKEN=afs_your_token
npx appforshare init
npx appforshare upload --ios-notes "Login fix" --android-notes "Login fix, Android 15 layout"

init finds where your iOS and Android builds land in Flutter, React Native and native projects and writes appforshare.config.json. upload with no file then sends the newest build of each platform in one run (CLI 1.11.0). You can also pass a folder, and the newest .ipa, .apk or .aab in it is sent. If you used appsonair init ota and appsonair-ota upload, this is the same idea.

Three things to check while you upload:

Size. AppsOnAir Free takes 300 MB. AppForShare Free takes 150 MB and guest uploads 50 MB, so a build between 150 MB and 300 MB needs Pro (2 GB) on our side. See sharing a large IPA or APK.
Password. If the old link had a password, set one on the new build. Every account, Free included, can.
Android bundles. AppsOnAir lists .apk and .ipa. If your pipeline makes .aab files, you can now upload the bundle itself on Free and up; it becomes one APK testers can install. See .aab upload.

Step 2: bring your iPhone UDIDs

AppsOnAir never held your devices. They are registered in your Apple Developer account and included in your ad hoc profiles, so your builds install on the same iPhones from any link. You want the list so the new tool can tell testers whether a build includes their phone.

Open your latest ad hoc .ipa in the free IPA inspector. It reads the file in the browser and lists every provisioned UDID. Copy all.
Import the list on the Devices page: one UDID per line with an optional name, or Apple's Register Multiple Devices file. Up to 1,000 per import, on every plan with an account.
Send new testers the free UDID finder, and ask everyone to tap Remember this device. From then on, every iOS install page says whether that iPhone is in the build before they tap Install.

On Pro, with an App Store Connect connection, you can register saved UDIDs on your Apple account and remake the ad hoc profile from the Devices page. On Team, hands free device setup does that for devices that come through the onboarding link. You still build again. See iOS device registration.

Step 3: links, expiry and several links per build

AppsOnAir sets an expiry on each share link: 7 days to 3 months. AppForShare works the other way round. Pro and Team links stay live while you subscribe, and you decide when one stops:

Stop date, pause and install cap per link, on Pro and Team. See install link controls.
Several links per build. If you sent one build to several clients with separate links, add extra links to the build: up to 3 on Pro and up to 20 on Team. Each has its own label, password, stop date, install cap and install count, and removing one leaves the others alone. See several links per build.
On Free, links last 7 days. If one review runs long, $2 once keeps that build's link live for 60 days, one link per account at a time.

If testers get a new build every few days, give them a channel instead. On Pro, a channel such as Beta has one stable link that always opens the newest build put into it, iPhone and Android alike, and you can roll it back to an older build. See Beta and Live channels.

Step 4: groups and testers

AppsOnAir groups such as QA or Clients decide who sees which release. Two ways to carry them over:

Team: tester groups. Add testers by email or CSV, give a group its projects in one step, make projects private so only invited testers can open them, and see per tester status: invited, opened the link, on an older build, has the newest build. Testers get new build emails in their language. See tester groups.
Pro: one channel per audience, for example Beta for QA and Client for the client, each with its own link.

Testers do not install anything. On AppsOnAir, the mobile app was where they saw builds and got push notices. On AppForShare they open the link in the browser. On Team, the tester app is a home screen web app with every build shared with them and push for new builds; it is not in the App Store or Google Play. If your testers liked the native app, that is a real difference; we say more under what you give up.

Step 5: feedback without an app or SDK

On AppsOnAir, build feedback is written in their mobile app by a signed in member, and AppRemark is an SDK in your app. On AppForShare:

From the install page. Testers pick Bug, Idea or Other, write up to 4,000 characters and add up to 5 screenshots with drawing. Device and OS come along. Every account plan, no sign in. Screen recordings are Pro and Team. See tester feedback.
From inside the test build. Turn on the in-app feedback link for the project and open it from a debug menu or a shake. The card has shake samples for Swift, Kotlin, React Native and Flutter that pass the version, build and screen. There is no automatic screenshot; the tester attaches one.

If you remove AppRemark, do it in a test build first and keep it until the new path works for your testers. Reports land in a feedback inbox, and on Pro and Team one click sends a report to Linear or Jira.

Step 6: CI and notifications

Replace the AppsOnAir CLI step with the AppForShare CLI and an APPFORSHARE_TOKEN secret, or use the GitHub Action or fastlane plugin. All need Pro or Team. A GitHub Actions example:

- name: Share builds
  run: npx --yes appforshare@1 upload --channel beta
  env:
    APPFORSHARE_TOKEN: ${{ secrets.APPFORSHARE_TOKEN }}

This relies on the appforshare.config.json from step 1 being in the repository. Guides for GitLab, Bitbucket, Codemagic, Bitrise and others are in the CI docs.

For notices, AppsOnAir lists Google Chat and a generic webhook. AppForShare Pro and Team post new builds and tester feedback to Google Chat, Slack, Microsoft Teams, Discord or a signed webhook (webhooks docs).

Step 7: decide what to do about force updates

AppSync is for store apps: it shows a forced update or maintenance mode to your users. Keep it if you use it. For test builds, AppForShare has two lighter tools on Pro and Team:

Retire a test build. Mark a broken build as retired: its link takes no more installs, its page sends testers to the newest build, channels skip it, and the update check reports it. See retire a test build.
In-app update check. A few lines in your test build ask the channel for the newest build and show your own message. Code snippets only, no SDK, and only for beta builds, never for store builds. See in-app update check.

What you give up

A bigger free tier. AppsOnAir Free allows 300 MB and links up to 30 days for one app; ours is 150 MB and 7 days.
Unlimited downloads. AppsOnAir lists downloads as unlimited. AppForShare plans have a monthly download allowance: Free 10 GB, Pro 40 GB, Team 150 GB.
Native tester apps in both stores.
CLI on the free plan. AppsOnAir includes it for now; ours is Pro and Team.
Five members on the middle plan. AppsOnAir Pro has 5; on AppForShare that is Team at $39 a month.
An automatic screenshot from a feedback SDK.

For everything side by side, see AppForShare vs AppsOnAir, AppsOnAir pricing and our pricing.

Common questions

Can I keep CodePush on AppsOnAir and move only the builds?

Yes. CodePush, AppLink, push and AppSync are separate products inside your app. Moving build sharing does not touch them.

Do iPhone testers need to register again?

No. Their devices are already in your Apple account and profiles. Importing the UDID list only tells AppForShare about them.

Can I bring my AppsOnAir links?

No. Links stay with the service that made them. Upload the current build and send the new link, or a channel link that will not change again.

Do testers need an AppForShare account?

No. They open the link and install. Invited testers on Team confirm by an emailed link, with no password.