App Quality and Publishing Readiness

Quality and production-readiness criteria for publishing apps in the VARIO App Store.

An app submitted to the VARIO App Store must be ready for real customer use and provide a clear, working use case.

This page defines the quality criteria VARIO uses to determine whether an app is ready to enter and successfully complete the review process.

These requirements focus on the quality and reviewability of the app. Legal, commercial, and general operational obligations are governed by the Framework Agreement and the applicable App-Specific Agreement.

Clear purpose and customer value

The app must have a clearly identifiable purpose within or in connection with VARIO Cloud.

A reviewer and a potential customer should be able to understand:

• what problem the app solves;
• who the app is intended for;
• which business process it supports, extends, or automates;
• how VARIO Cloud is involved in that process;
• what result the user can expect from using the app.

An app is not ready for publication if its purpose or its relevance to VARIO Cloud cannot be clearly understood from the app, its documentation, and its App Store listing.

Complete core use case

The primary use case described in the App Store listing must be fully functional at the time the app is submitted for review.

VARIO must be able to complete the core workflow under realistic test conditions.

The review must not be blocked by:

• unavailable pages, services, or endpoints;
• broken navigation or actions;
• 404, 500, or comparable technical errors;
• missing permissions or inaccessible functionality;
• incomplete installation or configuration steps;
• missing third-party test accounts;
• placeholder content;
• functionality that has been announced but not yet implemented.

Supporting or secondary functionality may have documented limitations as long as these limitations do not prevent the advertised core use case from working.

A good test is simple: a reviewer should be able to install the app, complete the documented setup, execute its primary use case, and verify the expected result without undocumented assistance from the App Provider.

App behavior must match its description

The functionality available in the submitted app must be consistent with the App Store listing and the documentation provided for the app.

The app must not:

• advertise functionality that is not available in the submitted version;
• materially behave differently from what is described;
• hide requirements that are necessary to use an advertised feature;
• conceal relevant limitations or dependencies;
• suggest a level of automation or integration that the app does not actually provide.

Features that are planned but not yet available must not be presented as part of the current functionality.

If future functionality is mentioned, it must be clearly identified as planned or part of a roadmap.

No unfinished or placeholder experience

Customer-facing parts of the app must appear complete and intentional.

The submitted version must not contain:

• Lorem ipsum or comparable placeholder text;
• test navigation items;
• unfinished settings or empty configuration sections without explanation;
• developer-only controls visible to ordinary users;
• internal project names or implementation notes;
• links to unfinished or unavailable documentation;
• controls for functionality that cannot yet be used.

If a feature is intentionally unavailable in a particular situation, the app should explain why instead of displaying a broken or apparently unfinished interface.

Predictable and reliable behavior

The same user action under the same conditions should produce a predictable result.

The app must handle expected situations such as:

• valid input;
• invalid or incomplete input;
• missing configuration;
• unavailable external services;
• insufficient permissions;
• empty result sets;
• failed processing.

Errors must not leave the user without information about what happened or whether an action was completed.

Detailed requirements for user-facing error messages and status information are covered in User Experience and Design.

No silent failure

Background processes, imports, exports, synchronizations, or other automated operations must not fail silently.

Where processing can occur outside the immediate user interaction, the app must provide an appropriate way to determine whether the operation:

• is waiting to be processed;
• is currently running;
• completed successfully;
• completed partially;
• failed.

Where appropriate, failed operations should provide enough information for the user to understand the problem and take the next reasonable action.

Detailed requirements for processing status and data integrity are covered in Permissions and Data Quality.

Production readiness

Apps published as generally available in the VARIO App Store must be suitable for productive customer use.

Before submission, the App Provider should have tested at least:

• initial installation;
• required configuration;
• the primary user workflow;
• relevant error cases;
• interaction with required third-party systems;
• repeated execution of automated processes;
• uninstallation;
• reinstallation where applicable.

The app must not depend on a developer manually correcting data, changing a database, or modifying the customer's VARIO environment in order to complete an ordinary customer workflow.

If manual implementation or configuration work is intentionally part of the product, this is permitted but must be clearly communicated in the App Store listing.

Beta apps

An app may only be published as a Beta after prior agreement with VARIO.

A Beta app must still provide a stable and reviewable core use case.

Its App Store listing must clearly identify:

• which functionality is already available;
• which relevant limitations remain;
• which users or scenarios the Beta is intended for;
• any limitations that customers should consider before productive use.

Labeling an app as Beta does not make incomplete security, privacy, tenant isolation, or data integrity acceptable.

VARIO may apply additional review criteria or limit the availability of a Beta app depending on its functionality and potential impact on customer processes.

Coming soon listings

VARIO may allow an app to be presented as Coming soon before it is available for installation.

A Coming soon listing is a product announcement only.

It must not:

• allow customers to activate or use an app that has not completed the required review;
• present unfinished functionality as already available;
• create the impression that the app has already been approved for productive use.

Before the app becomes installable, the regular submission and review process must be completed.

Consistency across the app experience

The following information should be consistent wherever it appears:

• app name;
• app version;
• supported functionality;
• required services or accounts;
• supported systems;
• relevant limitations;
• setup requirements.

Material inconsistencies between the app, its manifest, documentation, review materials, and App Store listing must be resolved before publication.

What VARIO reviews

During the quality review, VARIO may verify in particular whether:

• the app's purpose and core use case are clear;
• the advertised core functionality can be completed successfully;
• the app behaves consistently and predictably;
• incomplete or placeholder functionality is visible to users;
• expected error situations are handled;
• automated processes provide sufficient status information;
• the actual functionality matches the submitted description and documentation;
• the app is suitable for the publication status requested by the App Provider.

Passing the quality review does not replace the requirements described in the other sections of these Guidelines.