App Fair
The App Fair / Developers

Create an App Fair app

Process overview

From a project to the app stores. Select a stage to open its instructions.YOUR REPOSITORY01Choose a tokenA unique project address02Create & testDay + the App Fair template03Host the sourceOrganization / repository04Publish the websitePages + CI walkthroughs05Tag a releasePackages + screenshots06Submit for reviewOne catalog pull requestTHE APP FAIRReview → sign → submit → App Store & Google PlayFrom a project to the app storesChoose a token, create and test the app, host the source, publish the website, tag a release, and submit a pull request. The App Fair reviews, signs and submits to Apple and Google. Each step links to its instructions.YOUR REPOSITORY01Choose a tokenA unique project address02Create & testDay + the App Fair template03Host the sourceOrganization / repository04Publish the websitePages + CI walkthroughs05Tag a releasePackages + screenshots06Submit for reviewOne catalog pull requestTHE APP FAIRReview → sign → submit → App Store & Google PlaySubmission steps. Each card links to its instructions.YOUR REPOSITORY01Choose a tokenA unique project address02Create & testDay + the App Fair template03Host the sourceOrganization / repository04Publish the websitePages + CI walkthroughs05Tag a releasePackages + screenshots06Submit for reviewOne catalog pull requestTHE APP FAIR: REVIEW & PUBLICATIONApp Store & Google Play
Start setup
Unique GitHub organization and matching repository.
Development Computer

Bash/zsh commands; Git Bash on Windows.

Read the inclusion criteria before starting. For a new app, open a discussion before submitting it.

00Install prerequisites

Day compiles Rust against each platform’s native SDK. Development Computer selects your host’s tools and commands; it does not limit the platforms your app can support.

Only local builds need local SDKs. GitHub CI supplies its own build environment.

macOS

01Install Day

Cargo installs the Day CLI. It creates projects, builds native apps and runs dayscript tests. day doctor checks whether the required tools are available.

For VSCode users, the Day extension adds build and launch controls; rust-analyzer adds Rust completion and navigation. The extension commands are optional and use VSCode’s code CLI.

Any directory

cargo install day-cli
day doctor

VSCode extensions (optional)

Run only if you installed VSCode and plan to use it. Skip these commands for CLI-only development.

code --install-extension daybrite.day-vscode
code --install-extension rust-lang.rust-analyzer

02Create the Orbit-Notes organization on GitHub

The app token is an arbitrary, unique identifier. It need not match the app name. This workflow uses the token for both the GitHub organization and its repository: Orbit-Notes/Orbit-Notes. The refresh button suggests a name; it does not reserve it.

Installing the App Fair Publisher is required. Grant it access to the app repository when you create it, and keep access enabled. It attaches signed packages and promotes approved pre-releases. Store credentials remain with the App Fair.

GitHub

03Create the app

The App Fair template supplies starter screens, store metadata, a dayscript walkthrough, a website and GitHub Actions workflows. The default platform selection is included.

Day-appfair.toml holds the generated store identities; these must remain stable after publication. The template’s license texts and source notices stay with the project.

Parent directory for your new project

day new app 'Orbit-Notes' --title 'Orbit Notes' --template https://github.com/appfair/day-appfair --no-input
cd 'Orbit-Notes'

04Build and test locally

Day projects include mobile and desktop targets by default. The App Fair currently distributes only the iOS and Android versions through the Apple App Store and Google Play Store.

Remove unwanted desktop targets from both [app] targets in Day.toml and targets in .github/workflows/ci.yml. Keep ios-uikit and android-mdc for both mobile stores, and keep web-dom: the template uses it to publish the required project website. Keeping at least one desktop target is useful for fast testing and iteration.

day launch builds and runs the selected target. The dayscript walkthrough checks behavior and captures screenshots; keep dayscript/demo.yaml in step with UI changes.

Inside Orbit-Notes/

Replace the starter screens, icon, listing and walkthrough before testing.

Android

  1. From Android Studio’s welcome screen, open More Actions → Virtual Device Manager. With a project open, use View → Tool Windows → Device Manager.
  2. Select Create Virtual Device, choose a phone and system image, and finish the setup. Download the image if prompted.
  3. Click the device’s Launch button and wait for Android to finish starting.

Android Studio: create and start an emulator

From the app directory, build and launch the Android version:

day doctor --toolkit android
day lint
day launch -p android-mdc
# Close the app before running the walkthrough.
day launch -p android-mdc --script dayscript/demo.yaml

iOS

  1. In Xcode, choose Xcode → Open Developer Tool → Device Hub.
  2. Select an iPhone simulator, or use + to add one with an installed iOS runtime.
  3. Click Start and wait for the simulator to finish starting.

On older Xcode versions, use Window → Devices and Simulators to configure the device, then Xcode → Open Developer Tool → Simulator to open it. Apple’s simulator guide

day doctor --toolkit uikit
day launch -p ios-uikit
# Close the app before running the walkthrough.
day launch -p ios-uikit --script dayscript/demo.yaml

Desktop testing (optional)

If you kept this computer’s default desktop target, use it for quick iterations between mobile tests:

day launch

Build and launch in VSCode (optional)

With VSCode and the Day extension installed, open the project folder containing Day.toml:

code .
  1. Open the Day icon in the activity bar and expand your project’s Targets.
  2. Tick android-mdc to run on the Android emulator. Leave other targets unchecked.
  3. For desktop iteration, select macos-appkit for this computer instead.
  4. Select ios-uikit instead to run on the iOS simulator you started above.
  5. Press Run in the Day view’s title bar to build and launch. Use Build when you only want to compile.
  6. Build output appears in the task terminal; compiler errors also appear in Problems. If a toolchain is missing, run Day: Doctor (check toolchains) from the Command Palette.

05Create the app repository

The App Fair expects a public repository named Orbit-Notes/Orbit-Notes. Source, license files and Cargo.lock belong in the initial commit; credentials and build output do not.

Git manages the local history. The remote can be created in GitHub’s website or with the optional GitHub CLI.

Both methods connect the same local project to the same remote. Choose one; running both would try to create the repository and its origin remote twice.

Inside Orbit-Notes/

Commit the project, then choose one method to create the remote repository.

git init -b main
git add .
git diff --cached --stat
git commit -m 'Create Orbit Notes'

GitHub CLI

Create the repository and connect the local project with the optional GitHub CLI.

gh auth login
gh auth setup-git
gh repo create 'Orbit-Notes/Orbit-Notes' --public --source=. --remote=origin

GitHub website

Create a public repository without a README, license or .gitignore, then connect it:

git remote add origin 'https://github.com/Orbit-Notes/Orbit-Notes.git'

06Enable the website

The template publishes the website through GitHub Actions. The Pages environment must permit deployments from both the main branch and release tags, because a release also updates download links.

Keep the generated site published for validation and review, even if you use a separate landing page. The default GitHub Pages address is sufficient. A custom domain is optional and requires additional setup. It can be added later if you decide to acquire a domain for the project.

GitHub repository settings · before the first push

07Push and inspect CI

A push starts lint, platform builds and the walkthrough across the configured locales and themes. CI produces test results, packages and screenshots, then publishes the website and web app.

A passing run confirms the automated checks. Review its screenshots for layout or rendering problems before releasing.

Inside Orbit-Notes/

git push -u origin main

08Release v0.1.1

A version tag pins the source the App Fair will review. Tagging starts CI and creates a public pre-release containing packages, gallery.json and screenshots.zip. A draft release is not accessible to the catalog; a separate manual release is unnecessary.

The template starts at version 0.1.0, build 1. The patch bump below produces version 0.1.1, build 2; the release link and submission commands use that version. If your project has a different starting version, use the tag reported by Day instead. Once submitted, correct a faulty release with a new tag instead of moving the reviewed tag.

Inside Orbit-Notes/

Commit app changes first. From a clean working tree, bump the patch version and build number, update Cargo.lock, commit, tag and push in one command.

day metadata --version-bump patch --git-push

09Open the catalog pull request

The catalog entry, apps/Orbit-Notes.yaml, records the release tag, full commit hash and requested stores. The helper generates it from release metadata in a separate fork of the App Fair catalog. Link your first-app discussion in the pull request.

The App Fair rebuilds that pinned commit for review. Metadata corrections stay on the catalog pull request; source changes require a new app release and an updated submission.

A separate working directory · first submission

After release assets are available, choose one method. Both use Git and the Python catalog helper; review the generated file before committing.

GitHub CLI

With gh authenticated, fork the catalog, prepare the entry and open a pull request.

gh repo fork appfair/appfair-apps --clone --remote -- appfair-submission
cd appfair-submission
git fetch upstream main
git switch -c 'add-Orbit-Notes-v0.1.1' upstream/main
python3 -m venv ../appfair-submit-venv
../appfair-submit-venv/bin/python -m pip install PyYAML
../appfair-submit-venv/bin/python scripts/queue.py add 'Orbit-Notes' --tag 'v0.1.1'
../appfair-submit-venv/bin/python scripts/queue.py validate 'apps/Orbit-Notes.yaml'
git diff -- 'apps/Orbit-Notes.yaml'
cat 'apps/Orbit-Notes.yaml'
git add 'apps/Orbit-Notes.yaml'
git commit -m 'Add Orbit Notes v0.1.1'
git push -u origin HEAD
GH_USER=$(gh api user --jq .login)
gh pr create --repo appfair/appfair-apps --base main \
  --head "$GH_USER:add-Orbit-Notes-v0.1.1" \
  --title 'Add Orbit Notes v0.1.1' \
  --body 'Submit Orbit-Notes/Orbit-Notes at v0.1.1. Release: https://github.com/Orbit-Notes/Orbit-Notes/releases/tag/v0.1.1.'
  1. Add your first-app discussion link to the pull request description.

GitHub website

Create a personal fork. Replace YOUR-LOGIN below with your GitHub username; configure Git HTTPS credentials or SSH before pushing.

git clone https://github.com/YOUR-LOGIN/appfair-apps.git appfair-submission
cd appfair-submission
git remote add upstream https://github.com/appfair/appfair-apps.git
git fetch upstream main
git switch -c 'add-Orbit-Notes-v0.1.1' upstream/main
python3 -m venv ../appfair-submit-venv
../appfair-submit-venv/bin/python -m pip install PyYAML
../appfair-submit-venv/bin/python scripts/queue.py add 'Orbit-Notes' --tag 'v0.1.1'
../appfair-submit-venv/bin/python scripts/queue.py validate 'apps/Orbit-Notes.yaml'
git diff -- 'apps/Orbit-Notes.yaml'
cat 'apps/Orbit-Notes.yaml'
git add 'apps/Orbit-Notes.yaml'
git commit -m 'Add Orbit Notes v0.1.1'
git push -u origin HEAD
  1. Open your fork on GitHub and select Compare & pull request.
  2. Use appfair/appfair-apps as the base repository, main as the base branch, and add-Orbit-Notes-v0.1.1 as the head branch.
  3. Link https://github.com/Orbit-Notes/Orbit-Notes/releases/tag/v0.1.1 and your first-app discussion in the description, then create the pull request.

10Track approval and store deployment

After a maintainer approves publication, the App Fair signs and submits the packages through its store accounts. Apple and Google then process and review the app. A merged catalog pull request does not mean the app is live; the store listings confirm availability.

Updates keep the same organization, repository and store IDs. Each version goes through a new release and catalog pull request.

Catalog PR and linked workflow run