AppForShare: Pros and Cons of IPA Sharing vs. App Store Distribution
By Nimrah Bilal · · 4 min read
Sharing an app file directly (an .ipa for iOS or an .apk for Android) is fast and needs no review, which makes it the right choice for testing, client previews and internal builds. The App Store and Google Play are the right choice for public releases, because they handle discovery, payments, updates and user trust. Most teams use both: direct sharing through a service like AppForShare while building, and the stores when shipping.
A note on terms: this topic is sometimes searched as "IPK sharing". The iOS app package is an IPA file. IPK is a package format used by some embedded Linux systems and is not used on iPhones or Android phones. This article compares direct IPA and APK sharing with store distribution.
What direct sharing means
With direct sharing, you upload the build file to a hosting service and send testers a link. On AppForShare, each upload gets an install link and a QR code, and testers install over the air from their phone.
- Android: the tester allows installs from unknown sources for the browser once, then installs the
.apk. - iOS: the
.ipamust be signed Ad Hoc (with the tester's device UDID in the provisioning profile), Development or Enterprise. App Store and TestFlight builds cannot be installed from a link.
Pros of direct sharing with AppForShare
No review, no wait
A test build reaches testers as soon as it is uploaded. There is no store review, which matters when you are fixing a bug and want confirmation today.
Low cost to start
You can share a build without an account (up to 50 MB, link live for 3 days). A free account allows 150 MB per file and 7 day links. Pro costs $12 per month and Team $39 per month, with longer link life and more storage and bandwidth. See pricing.
Every build has its own link
Each upload to a project becomes a new build with its own link, so a tester can compare the current build with an earlier one while both are live. On Pro, you can attach release notes so testers know what changed.
Control over who installs
Builds can be password protected on every account plan. On Team, private projects can only be opened by invited testers. On iOS, Ad Hoc signing also limits installs to registered devices.
Fits into a build pipeline
On Pro and Team, CI upload tokens let a CLI, GitHub Action or Fastlane upload builds automatically, and webhooks can post new builds to Slack or Discord. See CI uploads and webhooks.
Cons and limits of direct sharing
Not a public storefront
Apps shared by link are not listed or searchable anywhere. AppForShare is not an app store: there is no discovery, no ratings, no payments and no automatic updates. To reach the public you still need the App Store and Google Play.
iOS device limits
Ad Hoc builds only install on devices registered in your Apple Developer account, and Apple caps registrations at 100 devices per device type per membership year. Enterprise signing is only allowed for an organization's own employees. Neither is a way to distribute to the general public.
Links are not permanent on every plan
Guest links last 3 days and Free links 7 days. Pro and Team links stay live while the plan is active. Old builds should not be treated as a permanent download archive. See how long links are available.
Testers must trust the source
Installing from a link asks testers to trust the person who sent it. That is fine for your team and clients, but it is not how most consumers expect to get apps.
Manual updates
Testers install each new build from its link. There is no background auto update like the stores provide, and no rollback of an installed app. Testers can install an older build from its link if it is still live.
You handle signing and feedback
AppForShare does not sign or re-sign builds and has no crash reporting or in-app feedback. Use your own tools for those.
Pros and cons of App Store and Google Play distribution
| Direct sharing (AppForShare) | App Store / Google Play | |
|---|---|---|
| Best for | Testers, clients, internal builds | Public release |
| Review | None | Required |
| Time to reach a tester | Minutes | After review |
| Discovery and search | None | Yes |
| Payments and subscriptions | Not provided | Built in, with store fees |
| Automatic updates | No | Yes |
| iOS device limits | Ad Hoc: registered devices only | Any compatible device |
Which should you choose?
- Use direct sharing during development, for QA, for client approval, and for small internal groups.
- Use TestFlight or Google Play testing tracks for larger beta groups close to release.
- Use the App Store and Google Play for the public release and ongoing updates.
For more on picking a route for iOS, read choosing the right path for iOS app distribution.
Frequently asked questions
What is the difference between IPK and IPA files?
An IPA is the package format for iOS apps. IPK is a package format used by some embedded Linux systems and is not used on iPhones or Android phones. For phones, you share an .ipa for iOS or an .apk for Android.
Can I distribute my app to the public with AppForShare instead of the App Store?
No. AppForShare is for sharing test builds with testers, clients and internal users. It is not an app store, and iOS Ad Hoc builds only install on registered devices. Public releases go through the App Store and Google Play.
Is direct sharing faster than the App Store?
Yes. A build uploaded to AppForShare can be installed within minutes because there is no review. Store releases require review before users can install them.
Can testers install App Store or TestFlight builds from an AppForShare link?
No. iOS only installs builds from a link if they are signed Ad Hoc, Development or Enterprise. App Store and TestFlight builds install only through Apple's apps.
