Submit to app stores

Applications built from the hello-pear-electron template can also be distributed through platform-specific application stores. This guide covers the two Linux store flows the template supports: Flathub (Flatpak) and the Snap Store. Mobile apps built on pear-mobile submit through the standard iOS App Store and Google Play flows—see iOS and Android below.

Both flows start from the Linux distributables produced by npm run make—see Build desktop distributables first. Store distribution complements, rather than replaces, peer-to-peer distribution: apps installed from a store still update over the air through Pear OTA.

Flathub

Flathub packages applications as Flatpaks. This section covers preparing a Flatpak manifest and submitting releases for review.

Prepare the submission

Fork the flathub repository in your GitHub organization, clone it, and create a branch targeting the repository's new-pr branch:

git clone git@github.com:<org>/flathub.git
cd flathub
git checkout -b my-app-submission -t new-pr

Create these files in the flathub directory:

• a metainfo file generated with the AppStream web form, like com.pears.HelloPear.metainfo.xml
• a Flatpak YAML manifest, like com.pears.HelloPear.yml

Test the Flatpak locally

Install the Flatpak tools:

sudo apt install flatpak
flatpak remote-add --if-not-exists --user flathub https://dl.flathub.org/repo/flathub.flatpakrepo
flatpak install flathub org.flatpak.Builder

In the project directory, build the app for Linux and serve the generated Flatpak artifacts over HTTP:

python3 -m http.server --directory out/make/

In the flatpak directory, build and install the Flatpak:

flatpak run --command=flathub-build org.flatpak.Builder --disable-rofiles-fuse com.pears.HelloPear.yml
flatpak install --user ./repo com.pears.HelloPear

Repeat the build command after making any changes to the manifest.

Launch the application from your desktop environment or run it from the CLI:

flatpak run com.pears.HelloPear

Uninstall using:

flatpak uninstall com.pears.HelloPear
rm -rf ~/.var/app/com.pears.HelloPear

If the builds take up too much disk space, clear the build files from the flatpak directory:

rm -rf builddir repo .flatpak-builder

Submit for review

After confirming that the Flatpak works:

1. Upload the Flatpak artifacts to a publicly accessible location with versioned URLs, like this site, and update the artifact links in the Flatpak YAML.
2. For verification, upload an empty file to your app website at https://<app-website>/.well-known/org.flathub.VerifiedApps.txt.
3. Open a PR on the flathub repository from your branch, like this PR, and address the review comments.
4. Comment bot, build to test building the Flatpak on the Flathub CI.
5. Once the submission is accepted, the Flathub maintainers create a repository in the flathub organization from your submission branch, like this repository.
6. Log in to the Flathub Developer Portal to manage the app, and complete verification by copying the token from that page to https://<app-website>/.well-known/org.flathub.VerifiedApps.txt.
7. In a few hours the app should be available on Flathub, like this app.

If the app doesn't show up on Flathub:

• If the Flathub bot opens an issue on the repository containing build errors, address it.
• If it's unrelated, comment bot, retry or open an issue in Flathub for assistance from the maintainers.
• Follow the build status at builds.flathub.org; app-specific status is at https://builds.flathub.org/status/<app-id>.

Automate new releases

To have the Flathub bot open PRs when new versions of the app are available on your website, follow the external data checker guide and configure it on the type: archive source, matching the format of your download site:

x-checker-data:
  type: html
  url: https://static.keet.io/downloads/
  version-pattern: href="((?:\d+\.)+\d+)/"
  url-template: https://static.keet.io/downloads/$version/Keet-arm64-flatpak.tar.gz

Snap

Snap packages applications for Linux and distributes them through the Snap Store. This section covers preparing a Snap package, testing it locally, and publishing releases.

Build and test the Snap

Install the Snap tools:

snap install snapcraft --classic
snap install lxd
sudo usermod -a -G lxd $USER
sudo lxd init --auto

In the project directory, build the app for Linux—this creates a .snap package in the out/make directory. Install it:

snap install out/make/hellopear_1.0.0_arm64.snap --devmode

After making changes to the Snap configuration, rebuild the application and reinstall the generated Snap.

Launch the application from your desktop environment or run it from the CLI:

hellopear

Uninstall using:

snap remove hellopear

If the builds take up too much disk space, clean the build container:

cd out
snapcraft clean

Refer to the Electron Forge Snap Maker documentation to configure the Snap.

Publish to the Snap Store

After confirming that the Snap works:

1. Create your developer account at login.ubuntu.com and log in.
2. Log in from your terminal with snapcraft login.
3. Register your Snap using the name with snapcraft register <snap-name>, or snapcraft register --private <snap-name> for a private Snap.
4. Publish with snapcraft upload --release=stable <my-snap>.snap.
5. Check the release status with snapcraft status <snap-name>.

Snapcraft will guide you with the next steps if a release fails. Once released, the Snap is available on the Snap Store at https://snapcraft.io/<snap-name>:

snap install <snap-name>
<snap-name>

Automate Snap releases

To publish from CI, first create a credentials file:

snapcraft export-login <credentials-filename>

Set the contents of the file as a secret in your automation pipeline and authenticate Snap with:

export SNAPCRAFT_STORE_CREDENTIALS=$(cat <credentials-filename>)

Upload a new Snap release to the desired channel (for example, stable):

snapcraft upload <snap-name>.snap --release stable

iOS

hello-pear-react-native carries no App Store submission tooling—no bundled EAS or CI release workflow, and signing/provisioning are project-specific. This section covers the Pear-specific parts of getting a build to the App Store; the submission mechanics themselves are standard Expo/React Native tooling.

Prepare the submission

The ios/ project is generated by npx expo prebuild and carries the pear-runtime-react-native boot-control patch—regenerate with --clean before archiving if the plugin version changed. app.json checklist: ios.bundleIdentifier and icons, the same brand checklist as Build the OTA payload. package.json version drives CFBundleShortVersionString at prebuild—see Version synchronization.

Build and test

npm run production:ios

Exercises the same release path the store binary will use, so boot-control and OTA selection can be verified before archiving. Archive from the generated ios/ project with Xcode (Product → Archive), or via EAS Build if the project uses Expo's managed build service—EAS is not pre-wired by the hello-pear-react-native template.

{
  "scripts": {
    "eas-build-post-install": "npm run bundle:bare"
  }
}

Submit for review

Standard App Store Connect flow: upload the archive (Xcode Organizer or Transporter), complete the listing, submit.

Pear-specific timing: set pear.json updates.minver to this release's version before staging any OTA payload that depends on it, and remember store review can take days—a payload staged during that window must not require the unreleased native build.

Automate (optional)

No CI release workflow ships with the template. EAS Submit or Fastlane are the standard options if automating, configured the same way they would be for any Expo/React Native app—nothing Pear-specific to add.

Android

Prepare the submission

The android/ project is generated by npx expo prebuild and carries the boot-control patch to MainApplication.kt. app.json checklist: android.package, minSdkVersion (29, set via expo-build-properties—see Expo setup), and icons. package.json version drives versionName at prebuild.

Build and test

npm run production:android

Then a signed release build:

cd android && ./gradlew bundleRelease

Or eas build --platform android on the managed build service—if you do, the same eas-build-post-install worker-bundle hook from the iOS section above applies here too; the worker bundle is gitignored regardless of platform.

Submit for review

Standard Google Play Console flow: create the app listing, upload the .aab, submit. Same minver/timing caveat as iOS.

Automate (optional)

Same as iOS: EAS Submit or Fastlane—not pre-wired by the template.

See also

• Build desktop distributables—produce the Linux artifacts these store flows package.
• Deploy your application—the peer-to-peer release flow that store installs update through.
• Deploy your mobile application—build the mobile OTA payload before submitting to the App Store or Play Store.
• Pear Mobile OTA—the pear-mobile API and the minver gate that store timing has to respect.
• Distribute as a binary—direct binary distribution without a store.
• Pear OTA—how store-installed apps keep updating over the air.