Do you build my app on your servers?

No. Every build runs on GitHub Actions in your own GitHub account, on your minutes. AppForShare writes the workflow, stores the secrets it needs and receives the result.

Can I read the workflow before it runs?

Yes. It arrives as a pull request with one file, .github/workflows/appforshare-ios.yml or appforshare-android.yml. Nothing runs until you merge it, and it only runs when someone starts a build.

Does it work with React Native and Flutter?

Yes. Pick the Node.js version and add setup commands such as npm ci, pod install or flutter pub get. The build steps after that are the same as for a native app.

Which plan do I need?

Pro includes builds for up to 2 repositories. The iOS and Android setup of one repository count once. Team has no repository limit.

AppForShare Create a free account

iOS and Android builds on GitHub Actions, without writing the workflow

Pro (up to 2 repositories) and Team (no repository limit)

Writing a mobile build workflow is a week of trial and error: signing, profiles, build numbers, Gradle signing properties, upload steps. AppForShare writes it for you from a short form, stores the secrets in your repository and opens one pull request. You read it and merge it.

The builds run on your own GitHub Actions minutes. Your code stays in your repository and your runner; AppForShare never builds on its own machines and never reads your code.

Start free See plans

Example

acme/shop-app

iOS, TestFlightBuild 2611011042 uploaded
Android, Play internalVersion code 58 sent
iOS, testersRunning, 6 min
Runner minutesYour GitHub account

Status by GitHub webhook. Up to 3 runs at a time per repository.

Made for

Small teams and solo developers who want a real pipeline without becoming CI experts
Agencies that build several client apps and want the same setup in every repository
React Native, Flutter and native projects (Node.js and setup commands are part of the form)

What it ends

Copying a workflow from a blog post and fixing signing errors for days
Building on one laptop, so nobody else can ship when that person is away
Remembering to bump build numbers and version codes by hand
Uploading the .ipa or .aab yourself after every build

How it works

Step 1
Install the GitHub App
Install "AppForShare Builds" on the repositories you pick. We check with GitHub that you can see that installation before it joins your workspace.
Step 2
Fill a short form
iOS: scheme, configuration, Xcode version and where the build goes. Android: Gradle folder, module, variant, Java version and where the build goes. Pick the branch, the Node.js version and how build numbers are set.
Step 3
Merge one pull request
We store the secrets and open a pull request from our own branch with one workflow file. We never push to your other branches and never merge.
Step 4
Start a build
Press Build in the dashboard with release notes and a channel. Status comes back from GitHub as the run moves, and the result lands where you chose.

Where a build can go

iOS builds go to your testers as an AppForShare install link (ad hoc export, with every registered device in the profile), or to TestFlight with your App Store Connect key. Android builds go to your testers as an .apk link, or to a Google Play track as an .aab: internal, closed, open or production.

For Google Play, the runner uploads the .aab straight to Google. The file never passes through AppForShare servers; we open the upload and check the version code and SHA-256 in Play before the release is saved. A production release is always saved as a draft that you roll out in Play Console.

Signing that you control

iOS can use Xcode automatic signing with your App Store Connect key, or your own Apple Distribution certificate as repository secrets with manual signing on the app target. With manual signing we keep the matching profile in a secret before each run.

Android signs with your upload keystore, which you add as four GitHub secrets yourself. AppForShare never sees the keystore or its passwords. If your Gradle files already sign, choose that instead.

Build numbers without thinking

Keep the number from the project, use the time (yymmddHHMM in UTC) or the run number, and override it for a single run when you need to. On Android the version code and version name are set by a small Gradle init script, so your Gradle files do not change.

Good to know

Builds use your GitHub Actions minutes. On private repositories GitHub counts macOS minutes at 10 times the Linux rate.
Manual iOS signing covers one app target for now, without app extensions.
AppForShare does not roll out Google Play production releases: they are saved as drafts for you.
Removing a setup deletes the secrets we stored and revokes the token. The workflow file stays in your repository until you delete it.

Questions

Do you build my app on your servers?: No. Every build runs on GitHub Actions in your own GitHub account, on your minutes. AppForShare writes the workflow, stores the secrets it needs and receives the result.
Can I read the workflow before it runs?: Yes. It arrives as a pull request with one file, .github/workflows/appforshare-ios.yml or appforshare-android.yml. Nothing runs until you merge it, and it only runs when someone starts a build.
Does it work with React Native and Flutter?: Yes. Pick the Node.js version and add setup commands such as npm ci, pod install or flutter pub get. The build steps after that are the same as for a native app.
Which plan do I need?: Pro includes builds for up to 2 repositories. The iOS and Android setup of one repository count once. Team has no repository limit.