AppForShareOpen Settings

Docs

Re-sign iOS builds with a new profile

Added test iPhones to your ad hoc profile? Re-sign the build you already uploaded with the new profile, no rebuild. AppForShare signs a copy with your workspace's certificate and saves it as a new build, so the devices in the new profile can install it. Pro and Team.

  1. 1. Add the signing certificate once

    An Owner or Admin opens Settings, iOS re-signing, and adds a .p12 file with its password: an Apple Distribution (ad hoc or enterprise) or Apple Development certificate, exported with its private key from Keychain Access. One certificate per workspace.

    The file and its password are encrypted with Google Cloud KMS, opened only to sign your builds, and never shown again. The dashboard shows the certificate name, the Apple team, the kind (distribution or development), its SHA-1 and when it expires. Replace or remove it at any time; both are lines in the activity feed.

  2. 2. Pick the profile on the build page

    Open an iOS build and find the card "Re-sign with a new profile". Choose where the profile comes from: "Profile from the connected Apple account" lists the active ad hoc, development and enterprise profiles of your App Store Connect key for the bundle ID, or "Upload .mobileprovision" takes the files from your computer.

    Uploading? Add the app's profile plus one per app extension (or one wildcard profile). With a connected Apple account, extensions without an uploaded profile get the best matching profile from that account.

  3. 3. Check, then re-sign

    Press Check. AppForShare reads each profile and shows its kind, app ID, number of devices and end date, how many devices were added or dropped against this build, and anyone who sent their iPhone through the onboarding link but is not in the profile yet. Problems are named, for example a profile of another Apple team or one that does not include the certificate.

    When the check is clean, press "Re-sign as a new build". The card follows the job: Waiting, Signing, Checking the new build, then Ready with a link to the new build.

The result is a new build

The re-signed copy is a new build of the same app with the same release notes and password and a new SHA-256. Bundle ID, version and build number do not change. The source build, its link, its SHA-256 and its sign-offs stay as they were, so a client approval always points at the exact file it approved. The new build goes through the normal upload steps, including the Security scan and the malware check, and enrolled testers get the install email when it is ready.

What is refused

Up to 30 re-signs a day per workspace, and each re-signed build counts toward your storage.

CLI

appforshare resign <id|slug> [--profile <file.mobileprovision|name>] [--merge-entitlements] --yes. A --profile value is an uploaded file or the name of a profile on the connected Apple account; repeat it for app extensions. Without --yes it runs the check only and prints the profiles, the devices added or dropped and any problem. With --yes it waits for the new build and prints its link (--no-wait returns at once).

# the check only: profiles, devices added or dropped, problems
npx appforshare resign AbC123 --profile "Shop Ad Hoc"

# re-sign with an uploaded profile per target and keep the app's own entitlements
npx appforshare resign AbC123 \
  --profile Shop_AdHoc.mobileprovision \
  --profile ShopWidget_AdHoc.mobileprovision \
  --merge-entitlements --yes

# leave out --profile to use the best profile of the connected Apple account
npx appforshare resign AbC123 --yes

MCP server

The tool resign_build lets your AI coding assistant re-sign a build for you. Without confirm it runs the check only; with confirm: true, which the assistant should ask you for first, the re-sign is queued. It needs the Developer role. build_info then shows the job as resign.lastResign and, on the new build, which build it was re-signed from. See MCP server.

Automatic re-signing in Hands free (Team)

With Hands free on, AppForShare registers new iPhones on Apple and remakes the ad hoc profile. If the project has no GitHub iOS build connected, it then re-signs the newest iOS build of the project with that profile, using the workspace certificate, and each enrolled tester gets the install email when the new build is ready. If it fails, the owner gets one email. With a GitHub build connected, Hands free starts that build as before. See Hands free device setup.

Questions

Which plans include re-signing?
Pro and Team, by hand from the build page, the CLI or the MCP server. On Team, Hands free can also re-sign the newest build after it remakes the ad hoc profile with new devices.
Does re-signing change the bundle ID, version or build number?
No. They stay as they are. The new build has the same release notes and password, and a new SHA-256 because the signature changed.
What happens to the original build?
Nothing. The source build, its link, its SHA-256 and every sign-off on it stay as they were. The re-signed copy is a new build named "Re-signed by AppForShare with profile <name> from build X".
Which entitlements does the new build get?
Those of the profile. Tick "Keep the app's own entitlements where the profile allows them" (or pass --merge-entitlements) to keep the app's own values where the profile allows them.
Is there a limit?
Up to 30 re-signs a day per workspace. Each re-signed build counts toward your storage like any upload; when storage is full, delete old builds first.
Does the new build go through the usual checks?
Yes. It goes through the normal upload steps: the readiness and install checks, the Security scan, the malware check, and the install email to enrolled testers.
Who can re-sign?
Members with the Developer role or higher. Adding or removing the certificate needs the Owner or an Admin.

Overview: re-sign iOS builds. Related: iOS device registration, re-sign an IPA with a new provisioning profile, find a UDID.