App Fair
The App Fair / Developers

App inclusion criteria

Apps distributed through the App Fair must meet a high standard of quality and trustworthiness. Each release is reviewed to verify that it is free, open source, and designed to serve the end user’s interests rather than advance the developer’s interests at the user’s expense.

These requirements apply to every app and update submitted through the App Fair. The app rules summarize the same expectations for users. Passing automated checks does not establish eligibility or replace review.

Price and monetization

  • Apps must be free to download and use, without paid feature unlocks, subscriptions to unlock app features, or in-app purchases.
  • Advertising is prohibited. Do not include advertising SDKs, ad placements or ad-supported modes.

Privacy and behavior

  • Do not include analytics, tracking or telemetry SDKs, including disabled SDKs or dependencies that bring them in transitively.
  • Do not collect or transmit usage data for analytics, tracking or telemetry through custom code either.
  • Request only permissions needed for documented app features. Describe network services, data use and retention in the privacy information.
  • Provide accurate store descriptions and working privacy and support links. The app’s behavior must match them.

License and dependencies

The app’s source code must be publicly available under a license that meets the Debian Free Software Guidelines (DFSG). No particular license is required. The DFSG are criteria for free-software licenses, not a license themselves.

All dependent software, including every transitive dependency, must also have publicly available source under a DFSG-compliant license. This includes libraries, SDKs, plugins, native components and code copied into the project. Their terms must permit inclusion and distribution with the app under its chosen license; meeting the DFSG alone does not establish compatibility between licenses.

  • Binary dependencies, such as Maven JAR dependencies, are permitted only when their corresponding source is publicly available under a DFSG-compliant license and the released binary can provably be reproduced by building that source. Provide the exact source revision, build instructions and environment, and verification evidence linking the rebuilt output to the binary used. A source archive or a listing in a trusted package repository alone is insufficient.
  • Review the complete dependency tree for each release. Closed-source components and publicly visible code without a DFSG-compliant license are not permitted.
  • Include the applicable license texts and preserve required copyright, attribution and source notices. Retain any applicable license exceptions. These requirements do not change the license of existing code.
  • Have the necessary rights to distribute included images, fonts, sounds and other assets; retain their licenses and attribution.

These component requirements apply throughout the app’s dependency tree. They do not require the host operating system or its native system frameworks to be open source.

Automated lint checks license files and source notices; it does not establish DFSG compliance, license compatibility, complete dependency coverage or binary reproducibility. Reviewers must verify those requirements using the source and evidence supplied for the release.

Project and publication setup

  • Use a conventional Day project in a public GitHub organization and repository named for the app token. Start with the standard Day app template or adapt an existing Day project, then add the App Fair publication configuration.
  • Keep the source, dependency lockfile, license notices and release history available for inspection and review.
  • Install the App Fair Publisher in the organization and grant it access to the app repository. Keep that access enabled for distribution through the App Fair. Installation is required for first submissions and updates; it lets the Publisher attach signed packages and promote approved pre-releases.
  • Keep the Day-generated GitHub Pages site published at its expected address. A custom domain is permitted; a separate landing page does not replace the required generated site.
  • Keep the submitted mobile targets and web-dom in Day.toml; use targets: all in .github/workflows/ci.yml, or explicitly include those targets. Day uses the web target to publish the required site. Preserve store IDs across updates.

Before submitting

  1. For a new app, open a discussion describing its purpose, users, maintainer and source repository. Link it from the first catalog pull request. Updates do not need a new introductory discussion.
  2. Replace the template’s screens, icon and listing. Maintain a dayscript walkthrough that tests behavior and captures the screenshots used by the stores.
  3. Run lint and tests, review CI screenshots, and commit the app changes. Use day metadata --version-bump patch --git-push to create the next version and tag.
  4. Wait for CI to create the public pre-release and attach the required packages and screenshots. Leave it marked pre-release until publication through the App Fair succeeds.
  5. Open a catalog pull request identifying the release tag, full source commit and requested stores. Respond to review comments and report publication failures in the existing submission.

Follow Getting started for the first submission and Releases & updates for subsequent versions. The catalog reference documents submission fields and checks. Approval by the App Fair and subsequent store review are required for new apps and updates.