Moving off Diawi in one afternoon: links, UDIDs, CI scripts, testers

Nov 2, 2026 · 7 min read

Teams leave Diawi for a few common reasons: builds outgrew 20 MB, a client opened a link after it expired, the CI pipeline only makes .aab files, or the Jenkins plugin shows a security warning. Whatever the reason, the move is small. Diawi has no tester accounts to export and no SDK in your app. You have links, a list of iPhones, some CI steps, and testers who need to know where to look. This checklist takes them in that order. It uses AppForShare as the destination because that is the tool we make; the first two steps work for any target. The product guide with screenshots is Move from Diawi.

What moves and what does not

Item	On Diawi	What to do
Live links	Expire on their own rules	Leave them. Upload only the current build again
iPhone UDIDs	Listed per build; really in your Apple account	Copy the list from your latest .ipa and import it
Upload scripts (curl, Node)	upload.diawi.com API	Change the URL and token, or use the CLI
fastlane	Community plugin	Official AppForShare fastlane plugin
GitHub Actions	Community action	Official AppForShare GitHub Action
Jenkins, Bitrise	Community plugin or step	A step that runs the AppForShare CLI
Testers	No accounts, just links	Send one channel link once

Step 1: leave old links alone

There is nothing to migrate for builds that are already out. Diawi links follow Diawi's rules and stop on their own, counted from the last install (see how Diawi link life is counted). Installed apps keep working until their own profile ends. Upload only the build testers should be on now, and send them the new link with the next release.

Step 2: bring your iPhone UDIDs

Devices are not held by Diawi. You registered them in your own Apple Developer account, and every Ad Hoc profile you made includes them. Your builds will install on the same phones from any link. What you want is the list, so the new tool can warn you about missing devices and so you can export it later.

Open your latest Ad Hoc .ipa in the free IPA inspector. It reads the file in the browser and lists every provisioned UDID. Use copy all.
In AppForShare, open the Devices page and import the list: one UDID per line with an optional name, or Apple's Register Multiple Devices file. Up to 1,000 devices per import, on every plan with an account.
Testers who check their iPhone at /udid and tap Remember this device will see on every install page whether a build includes their phone. See checking an iPhone before you send the link.

Step 3: switch your CI and scripts

Most of the work is here. Pick the row that matches your setup.

Your own curl or Node script

On Pro and Team, AppForShare has a Diawi compatible endpoint that takes the same multipart fields (token, file, password, comment, callback_url, callback_emails) and answers with Diawi's job and status codes. Change two URLs and the token:

https://upload.diawi.com/          -> https://appforshare.io/api/ci/diawi
https://upload.diawi.com/status    -> https://appforshare.io/api/ci/diawi/status
DIAWI_TOKEN                        -> your AppForShare API token (afs_...)

One request carries up to 100 MB. For bigger builds use the CLI, which uploads in resumable 32 MB parts. The full walkthrough, including the community diawi-nodejs-uploader package, is in the Diawi API with curl and Node.

The CLI, for anything else

export APPFORSHARE_TOKEN=afs_your_token
npx appforshare upload app-release.ipa --notes "Build 142" --channel beta

It prints the install link and the channel link. Add --fail-on blocked to fail the job when the store readiness check finds a blocker.

fastlane

The original Diawi fastlane plugin's versions were removed from RubyGems; the community fork fastlane-plugin-diawireborn was last released in May 2023. Replace it with the maintained fastlane-plugin-appforshare:

# fastlane add_plugin appforshare
lane :beta do
  gym(export_method: "ad-hoc")
  appforshare(api_token: ENV["APPFORSHARE_TOKEN"], channel: "beta")
end

GitHub Actions

Replace the community Diawi action with the official one:

- uses: appforshare/appforshare-action@v1
  with:
    token: ${{ secrets.APPFORSHARE_TOKEN }}
    file: app/build/outputs/apk/release/app-release.apk
    channel: beta

Its outputs include url and channel-url for later steps.

Jenkins and Bitrise

Diawi's Jenkins plugin is community made, about six years old, and its plugin page shows an open 2019 warning about credentials stored in plain text. Remove it and add a stage that runs the CLI with a Secret text credential: see the Jenkins guide and the Diawi Jenkins plugin advisory. On Bitrise, use a Script step with the paths Bitrise already exports: see the Bitrise guide. An AppForShare Jenkins plugin and a Bitrise step are coming; today the CLI step is the supported way.

Other CI systems are covered in CI uploads. If your pipeline only makes bundles, upload the .aab: AppForShare turns it into one APK (see Diawi and .aab files).

Step 4: give testers one link, once

On Diawi every upload is a new link. The point of the move is that testers stop hunting for the latest one.

Use a channel. On Pro, a channel such as Beta has one address that always opens the newest build put into it. Pick a readable address, for example /c/acme-beta; if you rename it, the old address redirects for 30 days. iPhones get the iOS build and Android phones the APK from the same link.
Email it once. Pro can email a build's install link to up to 5 addresses, one plain email per build and address. Diawi scripts that send callback_emails keep doing this through the compatible endpoint.
On Team, invite testers. Private projects, tester groups, new build emails and per tester status replace the chat thread.

Tell testers in plain words: "From now on, bookmark this link. It always has the newest build."

Step 5: keep an eye on installs

Diawi's install notifications send an email per install on paid plans. On Pro, AppForShare offers a daily install email instead, opt in per project: one email with the installs since the last one, by build, device and country, and which invited testers installed. Install analytics on the build page show devices, OS versions and countries, and webhooks can post installs to Slack, Microsoft Teams or Discord.

Step 6: run both for one release

Send one release through both tools. When the next one goes only through the new link, say so in the release notes. Cancel the Diawi plan after the last link you care about has expired.

What you give up

A cheap entry plan with an API. Diawi Starter is EUR 2.99 a month. AppForShare's API, CLI and integrations start with Pro at $12 a month.
Pay as you go extras. Diawi sells an extra month of link availability for EUR 0.49 and extra installs for cents. AppForShare has plans only.
Comments on free uploads. Diawi shows a comment to testers on any plan. AppForShare release notes are Pro.
Link life counted from the last install. On AppForShare Free, a link lasts 7 days from upload, and you can keep one link live for 60 days for $2, one time. Pro and Team links live while you subscribe.
Cheap branding add-ons. Diawi's custom domain and custom pages are small add-ons on Premium. On AppForShare they are part of Team.

For everything side by side, see AppForShare vs Diawi and pricing.

Common questions

Do iOS testers need to register again?

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

Can I keep my Diawi script unchanged?

Almost. On Pro or Team, change the two URLs and the token. The field names and status codes stay the same.

What happens to my Diawi links after I cancel?

That is up to Diawi's rules. Plan the cancel after the links you need have run their course.

Does AppForShare import my Diawi builds?

No. Upload the current build again. Older builds rarely need to move.