Distribute Apps with Public and Private App Stores

Applivery provides a powerful way to distribute Apps through Public or Private App Stores that support multiple security, access control, and branding configurations. You can also have different configurations for each App and each Audience.

App Stores

Applivery supports both Public and Private App Stores.

Public App Stores:

• Your App Store is publicly available under your URL (yourname.applivery.com or your Custom Domain).

• Anyone who knows the URL can access the list of published Apps, as long as they are not unlisted or inactive.

• Your App Store and its content may be indexed by search engines like Google or Bing.

Private App Stores:

• Your App Store is not available to the general public. Users must authenticate to access the App list.

• Users can log in using their Applivery account and/or your Workspace's Single Sign-On (if configured).

• The App Store homepage may be indexed by search engines, but content requires authentication.

In both cases, users will be able to add the App Store to their Home Screen to have more direct and easy access to your Workspace Apps. You can follow the steps described in our articles for both iOS and Android.

Published Apps

For each App project in Applivery, you can create one or more Published Apps to control how different Builds are made available to Collaborators, employees, and external users through the App Store.

There are four key configuration areas for each Publication:

1

Build selection

Defines which Build(s) are surfaced by the Publication:

Mode	Behavior
Manual	Distributes a specific Build from your Build list. Build history is not available in this mode.
Tags	Distributes any Build matching a custom tag or set of tags.
Git Tag / Git Branch	Deploys Builds matching a specific git branch (e.g. develop) or git tag (e.g. 3.2.1).
Last	Always points to the most recent uploaded Build for each OS.

2

Visibility

Controls whether and how the Publication appears in the App Store:

Option	Behavior
Inactive	Not accessible to anyone.
Active	Visible to everyone in the App Store.
Unlisted	Not listed in the App Store, but accessible to anyone with the direct URL.

3

Security

Controls the authentication method required to access the Publication:

Option	Behavior
Public	No authentication required. Anyone with the link can access and download.
Private	Requires login via Applivery account or your Workspace's SSO.
Password	Requires a password you define. No user account needed.
OTP (One-Time Password)	Access is granted via a time-limited code sent by email to a pre-approved allowlist. No SSO or Applivery account required.

4

Access control

Optional rules that further restrict who can access a Publication, independent of the security mode:

• User Groups our Audiences: For Private Publications, limit access to specific User Groups or defined Audiences within your Workspace.

• Country restrictions: Allow or block access based on the user's geographic location.

OTP (One-Time Password) access

OTP access is a security configuration available for Private Publications that allows you to share Builds securely with external users who are not part of your organization — freelancers, external studios, external QA testers, and similar collaborators — without requiring them to have an Applivery account or go through your SSO.

This is especially relevant for organizations with strict SSO-only policies that need to share Builds externally without relaxing their global authentication configuration.

OTP access is configured per Publication and does not affect any other Publication or the global App Store authentication settings.

How it works

From the Admin side

From the external user's side

Configuration options

When to use OTP access

Advanced configuration

Restricting access to certain User Groups or Audiences

When configuring Private Published Apps (either using Applivery Login or Single Sign-On), you can also specify which User Groups or Audiences will have access to the App itself. To do so, add the list below the Access selector and then click Save.

Blocking or allowing access by Country

You can define which countries are allowed or blocked from accessing a Publication. Add the country list in the Access Control setting of the Publication and save.

Best practices

Use separate Publications for different Audiences

When distributing to different groups (internal testers, QA, customers, partners, external studios), create a separate Publication for each Audience. This keeps access control and visibility independent, and makes it easy to revoke or modify access for one group without affecting others.

Use Last Build for continuous updates

If you upload Builds frequently, avoid creating a new Publication for each one. Instead, set Build Selection = Last and enable Show build history. This gives you a single Publication that always points to the latest Build, while still providing access to previous versions through the Build history.

You can also share a specific Build directly by appending the following to the Publication URL:

demo.applivery.io/{pubSlug}/{OS}/{buildId}

Combine OTP with Expiring Publications for time-limited external access

For maximum control when sharing with external users, combine OTP access with Expiring Publications. This ensures that access is both identity-verified (via OTP allowlist) and time-bounded (via Publication expiry) — without any manual cleanup required once the deadline passes.

Keep your SSO Policy intact when sharing externally

If your organization enforces SSO-only authentication globally, use OTP access for external collaborators rather than relaxing your SSO Policy or creating exceptions. OTP operates independently of your global authentication settings and does not interfere with how internal users authenticate.