Skip to content
Semaloop Docs

Common errors

Here are some of the most common errors we see in Semaloop, and how to avoid them:

  • Agents lose access to your build. If you’ve chosen to connect your application via TestFlight, this usually happens when agents are removed from your TestFlight group, invites run out, or a new version ships to a different track. We uninstall the app after every run, so losing TestFlight access means losing access entirely. Keep all agents in your group and on the track you want tested.

  • New TestFlight builds don’t reach Semaloop. Your app’s home page in Semaloop shows the latest build’s version and build number, so you can compare it with App Store Connect. A missing build is almost always one that isn’t available to the group our agents are in. Check that:

    • It’s in the app and group our agents joined. Adding a build to one group doesn’t add it to others.
    • For an external group, it’s approved and testers are notified, so its status is Testing. If Automatically notify testers was off, click Notify Testers on the build’s row.
    • For an external group, it wasn’t uploaded as TestFlight Internal Only.
    • For an internal group without automatic distribution, or a build from Xcode Cloud, it was added to the group by hand.
    • It hasn’t expired. TestFlight builds expire after 90 days.
    • Its version or build number is higher than the last build we received. We don’t pick up builds that go backwards.
    • The public link is still enabled and not full, or, for internal testing, no agent invitation has expired in Users and Access.
    • Receive builds is on for TestFlight in Settings → Test runs.

    If all of that checks out, contact us with the app, the group, and the version and build number, and we’ll check our agents’ access on our side. For the full setup, see connecting your app.

  • .ipa signing failures. If you’ve connected your app pushing builds via CLI rather than TestFlight, real-device runs require the .ipa to be signed with Semaloop device UDIDs before you upload. A build signed without those UDIDs uploads fine but fails to install at run time. Contact us to get our UDID list.

  • APK rejected on upload. We only accept a single, standalone .apk. An XAPK or APK-set container, or one piece of a split APK, is rejected when you finalize the upload. Upload a single installable APK instead — see uploading an APK.

  • .aab rejected on upload. An Android App Bundle isn’t accepted. Export a single APK from it, with Gradle or with bundletool. See exporting an APK from an app bundle.

  • APK rejected for its architecture. Android tests run on emulators that need native libraries for x86_64 or arm64-v8a. An APK whose native code is only for another architecture, such as 32-bit ARM (armeabi-v7a), is rejected when you finalize the upload. Build it for x86_64, arm64-v8a or both.

  • APK uploads but fails to install. Android tests run on Android 15 emulators. An APK whose minimum SDK is above Android 15 uploads fine and then fails at run time with APK installation failed.

  • Not enough sandbox accounts. Sandbox accounts are claimed exclusively per concurrent run, so if you’re running more parallel tests than you’ve provisioned sandbox accounts for, later runs queue or fail waiting for one to free up. Provision sandbox accounts to match your peak concurrency, not your average.

  • Secret not assigned to a test. A test referencing a secret in its spec (e.g. “log in with a premium account”) will fail if that secret hasn’t been explicitly assigned to the test in the test editor. The secrets manager holding the value isn’t enough on its own, and assignment is a separate required step.

  • Credential contention across parallel runs. Because agents never reuse the same credentials from the secrets manager across tests running in parallel, too few credentials in a secret relative to your concurrent run count bottlenecks tests waiting for one to free up.

  • “This API key is not authorised to upload builds for the bundle ID”. An API key belongs to one app, and the build you pushed has a different bundle ID or package ID, such as an internal or beta variant. Use a key from the app that matches, or contact us to add the variant as its own app. See staging, beta and production builds.

  • The CLI says you don’t have permission to upload. The API key wasn’t recognised. Check it was copied in full and hasn’t been disabled in Settings → API keys.

  • “An upload with that version label and name already exists”. You’ve already uploaded a build with this version and build number. If you rebuild the same version regularly, pass --allow-duplicate-version to semaloop build push (CLI 1.6.0 or later) to upload it as a new build.

  • A request is missing from the network log, or fails once. We capture network traffic through a proxy. If your app pins its certificates, the first request to a pinned host fails, and we then let traffic to that host through without inspecting it. Later requests succeed, but they don’t appear in the network log. If a test fails on that first request, rerun it.

  • A run stays pending. A run waits in the queue when:

    • Your plan’s limit on runs at the same time is reached. It starts as others finish.
    • The test uses a secret whose accounts are all claimed by other runs. Add more accounts to the secret.
    • The only devices free to run it can’t install your build, for example because only some of our agents are in your TestFlight group. Add every agent we sent you.

    If none of these apply, check the status page for an ongoing incident, then contact us with a link to the run.