Inclusion Criteria

The App Fair distributes global digital public goods. Every app in the catalog is expected to meet the criteria below; review them before any significant development effort is undertaken. The philosophical underpinnings of these criteria — including the Four Cornerstones every App Fair app is built around — live separately in Philosophy.

Provisional

This is a provisional version of the inclusion criteria. The rules below may be refined as the project matures. Questions about whether a specific idea fits should be raised on the forums prior to development.

Prohibited content and functionality

Apps that include any of the following are not eligible for the App Fair catalog.

Advertisements

App Fair apps may not embed advertisements of any kind. This includes banner advertising, interstitials, native advertisements, sponsored content, affiliate links presented as recommendations, and any other mechanism whose purpose is to direct user attention to a paying third party.

Embedded ads versus ads in content

This prohibition applies to advertising that the app itself embeds. It does not apply (and cannot apply) to advertising that appears within third-party content the app displays. A web browser that renders web pages may show pages that contain advertising; a podcast player may play audio that includes advertisements or product endorsements; a video player may play content that includes commercials. The relevant test is whether the advertising is introduced by the app, or by the content the app is presenting on the user's behalf.

Tracking

App Fair apps may not track users in ways the user has not knowingly and explicitly consented to. This prohibition covers behavioural tracking SDKs, device fingerprinting, cross-app or cross-site identifiers, attribution services, and similar mechanisms.

Apps that legitimately require user-data transmission to provide a user-facing feature (e.g. a sync service) are permitted, provided that the data flow is necessary for the feature, the user has clearly opted in, and the data is not used for profiling.

Analytics

Third-party analytics SDKs are prohibited. First-party telemetry beacons are prohibited. “Anonymous usage statistics” features that report screen views or feature engagement back to the developer are prohibited. Crash reporting is permitted only if it is opt-in, contains no user content, and is anonymous.

Gambling

Real-money gambling is prohibited. Simulated gambling that maps to real-money mechanics is prohibited. Loot boxes, sports betting interfaces, and social-casino patterns are prohibited.

Cryptocurrency

Cryptocurrency wallets, on-chain integrations, NFT functionality, token-reward systems, and “play to earn” mechanics are prohibited. The App Fair considers cryptocurrency integration incompatible with the goal of providing trustworthy software to a general audience.

Encouraged characteristics

The following are not strict requirements, but applications that exhibit several of these characteristics are more likely to be approved and to flourish within the catalog.

Suitable for all ages

The catalog targets a general audience. Content should be appropriate for all ages, interfaces should accommodate users with a wide range of abilities, and the UI should not presuppose an adult, English-speaking, technically sophisticated user. As a guideline, an App Fair app should be one that a school librarian could recommend without reservation.

Platform applications

Applications that are wide in scope and serve as a foundation for a range of related tasks are referred to as platform apps. Examples include a general-purpose ebook reader, a generic media player, a flexible note-taking application, and a feed reader that supports multiple formats. Platform apps tend to be more durable, more reusable, and more likely to attract a contributor community than apps with a narrow single purpose.

Narrow-scope apps are not excluded, but where a choice exists between an app that performs one specific task and an app that performs that task as part of a broader platform, the broader option is generally preferred.

Standardized over proprietary services

When an application interacts with external services, it should prefer standardized, interoperable protocols over single proprietary services. An RSS/Atom reader is preferable to a single-vendor news client. A WebDAV/CalDAV/CardDAV client is preferable to a wrapper around one specific cloud service. An OPDS-based ebook reader is preferable to a client for a single bookstore.

The general principle: an App Fair app should preserve the user’s freedom to choose providers rather than locking them into one. Where an open protocol exists, it should be supported. Where one does not, support for several competing proprietary services is preferred to support for a single one.

Broad and durable utility

Apps should aim for broad and durable utility: useful to many people, in many locations, in many languages, over many years. Apps tied to specific events, current cultural moments, or content that will become stale are discouraged.

Licensing

App Fair apps must be licensed under the GNU General Public License version 2.0 or later (GPL-2.0-or-later). It exists to guarantee that the source for every shipped binary remains freely inspectable, and to allow the broader community to maintain, fork, or rescue the project if the original maintainer becomes unavailable.

The top-level application may depend on libraries released under any GPL-compatible OSI-approved license, including Apache 2.0, MIT, BSD, and MPL 2.0.

Dependencies

All non-platform dependencies of an App Fair app must themselves be completely free and open source, and must be released under an OSI-approved license. “Platform dependencies” refers to the operating system itself and the SDKs supplied by the platform vendor (Apple’s SDKs on iOS, Android’s SDKs on Android); these are not subject to the requirement. Every other dependency, whether direct or transitive, must satisfy it.

This requirement is the practical extension of the project’s commitment to verifiable transparency. A user, an auditor, or a future maintainer must be able to read the source of every component that ends up on the user’s device. A proprietary or source-unavailable library, even if it appears to behave well, defeats this guarantee.

Some popular libraries are excluded

The dependency requirement rules out a number of widely used libraries. Notable examples include Firebase (closed-source client SDKs), libraries that depend on Google Play Services (proprietary, available only on Play-certified devices), and most vendor-specific analytics, attribution, and crash-reporting SDKs. The presence of such a dependency, even indirectly through a transitive chain, will block acceptance into the catalog.

Where a proprietary SDK provides functionality that an App Fair app genuinely needs, an open-source alternative or a direct protocol-level integration should be used in its place.

When the licensing or openness of a prospective dependency is uncertain, the question should be raised on the discussion forums before the dependency is added to the project. Identifying a problematic library at the proposal stage costs significantly less than removing it from a substantially developed app.

When a new App Fair project is initialized with skip init --appfair, a LICENSE.GPL file is added to the repository. This file should not be removed.

Naming

Each app has two distinct names that the inclusion criteria treat differently:

• The app token is the immutable identifier used for the app’s GitHub organization and repository (e.g. Faire-Games). It appears in URLs and tooling and never changes for the lifetime of the project. The token only needs to be unique within the App Fair catalog and conformant with GitHub’s organization-name rules.
• The displayed title is the localizable string the user sees on their device home screen and in store listings (e.g. “Fair Games”). It is set in Skip.env and the Fastlane metadata, can differ per locale, and may change over time without affecting the token.

The displayed title is the one that must be distinctive and unique. It must not collide with any existing App Fair app and must not be confusingly similar to any well-known application on the commercial app stores.

Verifying title availability is non-trivial

Confirming title availability worldwide is difficult: the commercial app stores include many name-squatters, and trademark scopes vary by jurisdiction. Displayed titles should be selected with the understanding that they may need to change prior to publication or in response to a later dispute. The app token, by contrast, is private to the App Fair / GitHub namespace and is not subject to commercial trademark conflict — renaming an early-stage token is straightforward, but it is not normally necessary.

External storefront requirements

Conformance to the App Fair’s own inclusion criteria is necessary, but it is not sufficient for an app to reach end users. Every storefront the App Fair publishes to imposes its own additional requirements, and the binary submitted by the App Fair must satisfy each applicable store’s policy on top of the criteria above. Maintainers should familiarise themselves with the relevant guidelines and design their app to meet the strictest applicable rules; where two stores’ rules conflict, the app should comply with both.

The canonical references for each currently active distribution channel:

• Apple App Store. The App Store Review Guidelines cover content, safety, performance, business, design, and legal expectations for every app shipped through the App Store. The corresponding App Store Connect Resources describe the technical submission process.
• Google Play Store. The Google Play Developer Program Policies define analogous content, monetisation, technical, privacy, and policy rules. The Restricted Content and Data Safety sections are the items most likely to surface during review.

Channels on the App Fair roadmap (notably F-Droid and AltStore) will be added here when they go live. See Future channels in Deployment & Distribution.

App Fair maintainers reviewing a submission do not adjudicate every store-specific rule, but a submission that visibly conflicts with a store guideline will be flagged for the developer to resolve before the binary is submitted. Rejections that arrive after submission (from Apple or Google) are surfaced to the upstream maintainer through the channel described in Division of responsibilities.

Submitting a proposal

When the suitability of an idea is uncertain, a proposal should be posted on the discussion forums before development begins. Pre-submission discussion costs significantly less than rejection of a completed project, and the community may identify existing projects that the contributor could join rather than start from scratch.

Once an idea has been evaluated against the criteria above, proceed to Building Your App. When the app is ready to ship, the criteria here are translated into a concrete pre-submission gate in the Submission checklist.

Apps that don't fit can still be published directly

An app that does not satisfy the criteria above is not eligible for distribution through the App Fair, but nothing in the default project layout precludes the developer or organisation from publishing it independently. The upstream source repository remains under the developer's full control, and the Skip project scaffold imposes no encumbrance that would prevent a parallel direct submission to the stores. Direct publication to the Apple Developer Program requires an Apple developer account, and direct publication to the Google Play Console requires a Google developer account. The App Fair operates these accounts on behalf of the catalog, but does not own or constrain the upstream source.