# AppBox: shipping development IPAs to testers over Dropbox and a link

> AppBox is a macOS Swift tool that deploys Development, Ad-Hoc and In-house Enterprise builds of an iOS app directly to devices by uploading the IPA to a Dropbox account and handing out a link, with a dashboard, webhook integration and a fastlane plugin. It suits a small team testing a build on real hardware, and it depends on a Dropbox account and a second machine to install from.

**getappbox/AppBox-iOSAppsWirelessInstallation** — AppBox is a tool for iOS developers to deploy Development, Ad-Hoc, and In-house (Enterprise) applications directly to the devices from your Dropbox account. Check WebServices Status - https://status.getappbox.com

- Repository: https://github.com/getappbox/AppBox-iOSAppsWirelessInstallation
- Website: https://getappbox.com
- Stars: 697 · Forks: 110
- Language: Swift
- License: NOASSERTION
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/getappbox-appbox-iosappswirelessinstallation

## Four steps, and Dropbox is the storage layer

The usage table in the project documentation is the whole workflow, and it is short enough to read in one pass.

Step one is to link your Dropbox account with AppBox. Step two is to select or drag the IPA file and click upload. Step three is to send the link to your testers, clients, friends, or even use it yourself. Step four is that the recipient opens the link in the browser on the device and clicks install.

The design decision hiding in that table is that there is no storage service of AppBox's own. The IPA lives in the linked Dropbox account, and the link you distribute points at that file. Everything else in the feature list follows from that choice.

The three build types in the description are Development, Ad-Hoc and In-house (Enterprise) applications. Those are exactly the three that Apple will install on a device without going through the App Store, and they are exactly the three where the provisioning profile has to be in the developer's hands. So the tool is aimed at the gap between Xcode's device list and a full distribution channel, which for a small team is a real and annoying gap.

The primary language is Swift, the tool runs on macOS, and the topics list upload-ipa and xcodebuild, which is the pipeline vocabulary of someone who has dealt with the provisioning dance. The homepage is getappbox.com, and the repository has a status page for the web services at status.getappbox.com.

## The features that come from making the link permanent

The feature list is grouped around one idea: the installation link is a stable address, and the file behind it can change.

Unlimited app installations and no upload app size limit together mean there is no per-installation counter and no cap on how big the build can be. There is no uploaded app expiration, so a link does not quietly die. And the same installation link is kept for the same app, which means a tester who has the link once keeps a working link as you push new builds. A previous version can be installed with that same link.

That last pair is the part that changes how a team works. The usual flow for internal iOS testing involves either TestFlight, with its own review and build processing delays, or a messaging app where each build is a new file to redistribute. Here the link is the artefact, and the builds behind it are replaceable.

The rest of the list is operational. The app distribution link is sent by e-mail automatically. The upload restarts by itself after a network change or a failure, which is the difference between a build tool you can leave running and one you have to babysit. There is an easy setup assistant to get started in a few minutes, a dashboard to manage uploaded apps, and webhook integration for Slack, Microsoft Teams and Hangout Chat, so a tester receiving a build can post into the team channel without anyone copying a URL.

There is also a fastlane plugin, published as a separate repository, which puts the upload into the lane you are probably already running your releases through.

## Installing it, and the macOS 15 floor

The requirement is stated before anything else: AppBox requires macOS 15 Sequoia or later. That is a hard floor on the machine that runs the tool, which matters for a CI runner or a build box that has not been updated.

There are three installation routes, and the first is a one-liner:

```bash
curl -s https://getappbox.com/install.sh | bash
```

The second is Homebrew:

```bash
brew install --cask appbox
```

and it is updated later with brew upgrade --cask appbox, which is the route to pick if you want the tool on several machines and want them to move together.

The third is the manual one, for when the commands above cause trouble: download AppBox.dmg, open the DMG and drag AppBox.app into your Applications folder.

Every release also attaches the artifacts directly. AppBox.dmg and AppBox.app.zip come with each release, along with appboxcli.zip for the standalone command-line tool, so the CLI can be picked up without installing the graphical application. The documentation points at the releases page for those downloads.

The three routes together point at a design that assumes a Mac you control rather than a build server you configure. A cask, a drag-and-drop DMG and a shell installer are all the shape of a developer tool for a person at a desk, and a team that wants the upload to run in CI would be using the fastlane plugin or the CLI instead of the app.

## The configuration is two keys, and the secrets are generated at build time

The example environment file in the repository is short, and its comments are more informative than the values.

It carries a warning: copy it to .env and fill in the values, never commit .env, and note that Scripts/generate-secrets.sh turns it into the gitignored AppBox/Generated/AppBoxSecrets.swift at build time. So the file is not read at runtime by the application, it is consumed by a build step that produces a Swift source file, and the Swift file is the one excluded from version control. That is a deliberate way of keeping a token out of the repository while still having it in the binary.

The two values are the APPBOX_CLIENT_TOKEN and the DROPBOX_APP_KEY.

The client token is described as a static client token for the AppBox backend, the install-helper, and it must match the server's APPBOX_CLIENT_TOKEN environment variable. The Dropbox key is the OAuth client_id, a public app key, and it must match the app's db-<key> URL scheme in AppBox/Info.plist, taken from the Dropbox App Console.

The distinction matters for what you should treat as a secret. The Dropbox client_id is a public app key, and what it is paired with is the URL scheme registration, which is how a browser callback gets back into the app. The AppBox client token is a static token shared between the desktop app and the backend, and the requirement that it match the server side means the two have to be provisioned together.

The repository structure supports the picture: an AppBox.xcodeproj, an AppBox/ directory for the application, AppBoxCLI/ for the command-line tool, AppBoxCore/ for the shared code, AppBoxTests/, a Scripts/ directory, docs/ and an mkdocs.yml for the documentation site.

## Where AppBox is the wrong tool

The first limit is the distribution model. This is for Development, Ad-Hoc and In-house builds, which means the people installing it need the right provisioning and, depending on the type, the device registered or the profile installed. It is not a path to the App Store, it does not replace TestFlight, and it does not do anything for a public release. A team that wants to ship to end users is looking at the wrong tool entirely.

The second is that Dropbox is the transport. The link you send a tester is a link into your own Dropbox account, so the practical questions are about your account rather than about the tool. Can the recipient open a Dropbox-shared file without a Dropbox account, and if they need one, is that acceptable to them? Does your account's sharing settings allow the link? Can you revoke one build without affecting the others, and does revoking it affect the link the tester still has? None of these are documented here, and they are the questions that determine whether the flow works for your testers.

The third is the security posture of sharing a link that points at your account. A test link is a link into your storage, and if it is a shared folder link rather than a per-file one, the recipient may have more access than the one IPA. The tool does not describe how the link is scoped.

The fourth is platform. macOS 15 or later, Apple silicon or Intel as the platform allows, and an Xcode installation for the provisioning workflow that a Development or In-house build requires. A team that wants to distribute to Windows or Android testers, or to a mixed device fleet, gets nothing here.

The fifth is the build type wall. A development build expires, and an Ad-Hoc build expires, because the provisioning profile says so, and the documentation is careful to say no uploaded app expiration, which is about the file in Dropbox rather than about the profile on the device. A tester who installs an expired build gets a failure that has nothing to do with the tool, and the fix is on Apple's side.

## Conclusion

AppBox is worth installing for an iOS developer or small team that needs to get a build onto a tester's phone without Apple TestFlight, because the flow is four steps, the IPA goes into a Dropbox account the team already controls, and the install link stays the same across versions so a tester does not have to re-register. It is the wrong tool if you need to distribute to the public or to a large uncontrolled audience, since it is explicitly for Development, Ad-Hoc and In-house builds. Before you adopt it, check the three things the project states: that it requires macOS 15 Sequoia or later, which is a hard floor on the machine that runs the tool; that you need a Dropbox account linked before you can upload anything, because the storage is Dropbox rather than a service of its own; and that the distribution link you share is a link into a personal Dropbox, so what you are sharing with testers is access to your own account's file, which is a decision about your account configuration rather than a technical detail of the tool.

## FAQ

### How do I install AppBox on macOS?

You can run curl -s https://getappbox.com/install.sh | bash, or install the cask with brew install --cask appbox and update it later with brew upgrade --cask appbox. If neither works, download AppBox.dmg, open it and drag AppBox.app into your Applications folder. AppBox requires macOS 15 Sequoia or later.

### How does AppBox deliver a build to a tester's iPhone?

You link your Dropbox account, upload the IPA, and send the installation link. The tester opens that link in the browser on the device and clicks install. The same link is kept for the same app, so a previous version can also be installed through it, and a build does not expire while it sits in Dropbox.

### What configuration does AppBox need before it will work?

The example environment file calls for two values. APPBOX_CLIENT_TOKEN is a static token for the AppBox backend install-helper that must match the server's APPBOX_CLIENT_TOKEN variable, and DROPBOX_APP_KEY is the Dropbox OAuth client_id that must match the app's db-<key> URL scheme in AppBox/Info.plist. The file is not committed, and Scripts/generate-secrets.sh turns it into a gitignored Swift file at build time.

## Sources

- [getappbox/AppBox-iOSAppsWirelessInstallation on GitHub](https://github.com/getappbox/AppBox-iOSAppsWirelessInstallation)
- [Issues](https://github.com/getappbox/AppBox-iOSAppsWirelessInstallation/issues)
- [Project website](https://getappbox.com)
- [README](https://github.com/getappbox/AppBox-iOSAppsWirelessInstallation/blob/master/README.md)
- [Releases](https://github.com/getappbox/AppBox-iOSAppsWirelessInstallation/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/getappbox-appbox-iosappswirelessinstallation