Docs

Move from AppsOnAir

Moving test builds from AppsOnAir (by Logicwind) takes an afternoon: upload the builds still in testing, give each client its own link, give testers one link for later builds, swap the CLI step and point notifications at your chat. CodePush, deep links and push can stay where they are. This guide covers each step and what it needs.

1. Step 1, Every plan

   What changes

   There is no workspace or app to set up before the first upload: drop an .ipa, .apk or .aab and you get a link and a QR code. Passwords work on Free. On Pro and Team links stay live while you subscribe, with no 90 day limit per link. Testers install from the phone browser and need no app and no account.

2. Step 2, Every plan, CLI on Pro and Team

   Upload the builds still in testing

   AppsOnAir links stay on AppsOnAir, so upload each build your testers still need again: from the web page, or with the CLI when there are many. Files up to 150 MB work on Free; bigger builds need Pro (2 GB) or Team (4 GB).

   For Flutter and React Native projects, run init once: it finds where your iOS and Android builds land and writes appforshare.config.json. Then one upload sends the newest .ipa and the newest .apk or .aab, each with its own notes. upload also takes a folder and sends the newest build in it.

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

   All CLI commands

3. Step 3, Pro and Team

   One link per client, with its own password and end date

   AppsOnAir gives a build several share links, each with its own expiry. Here each build has its own link, plus extra share links: up to 3 per build on Pro and 20 on Team. Each extra link has a label only you see, its own password, stop date, install cap and install count. Turn one off and the build and the other links keep working.

   For the whole build there are link controls: pause it, give it a stop date or an install limit. They apply to every link of the build.

   npx appforshare link add 12345 --label "Client A" --password "$CLIENT_A_PASSWORD" --stop 2026-12-31 --max-installs 25
   npx appforshare link list 12345

   Several links per build

4. Step 4, Pro and Team

   One link for every future build

   Put builds into a channel such as Beta and send its link once: it always opens the newest build in the channel, iPhones get the iOS build and Android phones the Android build. Pick your own address such as /c/acme-beta. One channel per audience also works as a simple stand-in for AppsOnAir groups on Pro.

   npx appforshare upload app.ipa --channel beta
   npx appforshare channel-address acme-beta --channel beta --app com.example.shop

   Beta and Live channels

5. Step 5, Team

   Groups and testers

   AppsOnAir groups such as QA or Clients become tester groups. Give a group its projects in one step, make projects private so only invited testers open them, and see for each tester who installed the newest build. Testers are emailed on new builds. Import them from a CSV file.

   Tester groups and status

6. Step 6, Every plan, onboarding link on Pro and Team

   iPhone testers

   There is no tester app to install. Send testers the free UDID finder at /udid and ask them to tap Remember this device: from then on every iOS install page says whether the build includes that iPhone. On Pro, each iOS project has an onboarding link that saves the device to your list, and with an App Store Connect connection you register it on Apple from the Devices page.

   Remember my iPhone

7. Step 7, Every plan with an account

   Tester feedback without an app

   Feedback in AppsOnAir is sent from its mobile app or the AppRemark SDK. Here testers press Send feedback on the install page, or your test build opens the in-app feedback link from a debug menu or a shake. They write what happened and add up to 5 screenshots they can draw on; no SDK and no sign in. The project's Testing tab has shake samples for Swift, Kotlin, React Native and Flutter.

   In-app feedback link

8. Step 8, Pro and Team

   Swap the CLI step

   Replace the appsonair-ota upload step with the AppForShare CLI and an APPFORSHARE_TOKEN secret made in Dashboard, Settings. In GitHub Actions the action can leave file empty to use appforshare.config.json (or take a folder), with notes per platform, and gives you ios-url and android-url. A fastlane plugin is there too.

   - name: Share builds
     id: afs
     uses: appforshare/appforshare-action@v1
     with:
       token: ${{ secrets.APPFORSHARE_TOKEN }}
       ios-release-notes: "Login fix"
       android-release-notes: "Login fix, Android 15"
   - run: echo "${{ steps.afs.outputs.ios-url }} ${{ steps.afs.outputs.android-url }}"

   CI guides

9. Step 9, Pro and Team

   Notifications

   Post new builds, installs, tester feedback and store events to Google Chat, Slack, Microsoft Teams, Discord or a signed webhook. For Google Chat, paste the space's incoming webhook URL under Integrations.

   Google Chat steps

10. Step 10, Pro and Team

    Pull a broken build

    When a build turns out broken, retire it with a note. Its link takes no installs and sends testers to the newest build of the app, channels skip it, and the in-app update check tells your test build. Apps already installed keep working.

    npx appforshare retire 12345 --reason "Crashes on login"

    Retire a test build

11. Step 11, Your choice

    What stays on AppsOnAir

    CodePush, AppLink deep links, push notifications and AppSync are separate AppsOnAir products for apps in the stores. AppForShare has none of them. You can keep them and move only the test builds.

Weighing the two first? Read AppForShare vs AppsOnAir. For the upload commands, see Upload from CI.