> For the complete documentation index, see [llms.txt](https://developer.vario-software.de/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.vario-software.de/app-store-guidelines/review-process/app-updates-and-re-review.md). # App Updates and Re-Review Requirements for communicating app updates and determining when VARIO re-review is needed. App Store approval applies to the version, functionality, permissions, data processing, and integration behavior reviewed by VARIO. App Providers may continuously improve and maintain their apps. Not every update requires a complete App Store review, but material changes must be communicated to VARIO and may require re-review before they are released to customers. {% hint style="info" %} The purpose of re-review is not to review every software release. VARIO focuses on changes that materially affect customers, VARIO Cloud integration, permissions, data processing, security, or the information presented in the App Store. {% endhint %} ### Keep the app version identifiable Each released app version must be identifiable through the version information defined for the app. The `appVersion` in the App Manifest should represent the version currently provided to customers. For implementation details, refer to the [App Manifest](https://developer.vario-software.de/documentation/apps/app-manifest). When submitting a relevant update to VARIO, provide a short change summary describing what has changed since the previously approved version. ### Three types of changes For App Store purposes, changes can generally be divided into three categories: | Change type | Typical handling | | ----------------------- | ---------------------------------------------------------------------------- | | Maintenance change | Usually no re-review required | | Listing-relevant change | App Store information must be updated; VARIO may perform an editorial review | | Material app change | Notify VARIO before release; re-review may be required | VARIO determines the required review scope based on the actual impact of the change. ### Maintenance changes Routine maintenance generally does not require another App Store review if it does not materially change the approved functionality or risk profile of the app. Examples may include: * internal code refactoring; * performance improvements; * minor bug fixes within existing functionality; * dependency updates; * infrastructure maintenance; * improved logging or monitoring; * minor visual corrections; * accessibility improvements; * technical changes that do not affect permissions, data processing, or customer behavior. For example: > Version 1.2.3 improves the performance of the existing order import and fixes an incorrect status label. This would normally not require a full re-review if the underlying process and integration behavior remain unchanged. {% hint style="success" %} App Providers are expected to maintain and improve their apps continuously. Routine maintenance should not be delayed merely because the app is published in the App Store. {% endhint %} ### Listing-relevant changes Some changes do not necessarily require a technical re-review but require the App Store listing to be updated. Examples include changes to: * descriptions; * screenshots; * supported languages; * supported countries or regions; * prerequisites; * documentation links; * support information; * relevant limitations; * external service requirements; * pricing information. The App Store listing must remain consistent with the currently available app. If a change materially affects a customer's purchase decision, the listing should be updated when the change becomes effective. See **App Store Listing Requirements** for the applicable content requirements. ### Material changes A material change is a change that may alter the functionality, security, data processing, technical integration, or customer impact of the previously approved app. Material changes must be communicated to VARIO before they are generally released through the App Store. VARIO will determine whether: * no additional review is required; * only the affected area needs to be reviewed; * a broader re-review is necessary. {% hint style="warning" %} Do not assume that a change is covered by the original App Store approval merely because the app name and app identifier remain unchanged. {% endhint %} ### Changes to VARIO permissions Adding or extending VARIO permissions is a material change. Examples include: * adding access to another VARIO resource; * adding `create`, `update`, or `delete` access where the app previously had only `read` access; * expanding access to support a newly introduced feature. Before releasing the update, provide VARIO with: * the new or changed permission; * the functionality that requires it; * the reason why the existing permission scope is insufficient. Removing permissions generally does not require re-review unless the change materially affects app functionality. The requirements for permission scope are described in **Permissions and Data Quality**. ### Changes to app-specific authorization Changes to app-specific authorization may require review where they affect access to sensitive or high-impact functionality. Examples include: * introducing a new administrative permission; * allowing additional users to execute a previously restricted action; * changing the authorization model for destructive operations; * removing an existing authorization check. Minor changes to permission names or descriptions generally do not require a technical review if the authorization behavior remains unchanged. ### New functionality A new feature may require re-review when it materially expands what the app does. This is particularly relevant where the new functionality: * creates or modifies additional VARIO business objects; * introduces new automated processes; * adds another synchronization direction; * performs destructive or high-impact operations; * introduces a new external integration; * requires additional permissions; * processes additional customer data; * changes the primary customer use case. Small enhancements within an already reviewed workflow may not require a separate review. For example: > Adding another filter to an existing order list would normally have significantly less review impact than: > Adding automated creation of invoices in VARIO Cloud. ### Changes to data processing Changes to the categories, purpose, destination, or handling of customer data are material where they affect the previously reviewed data-processing model. Examples include: * processing additional VARIO data; * storing additional customer data outside VARIO Cloud; * introducing a new processing purpose; * transferring data to another external service; * introducing a new relevant subprocessor; * changing the region in which relevant customer data is processed; * materially changing data retention behavior. The applicable privacy information must be updated where required. VARIO may require an updated privacy review before the changed processing is introduced. See **Security and Privacy Review**. ### New external services Adding a new external platform or service may require re-review. Examples include: * a new marketplace; * a new payment provider; * a new shipping service; * an AI service; * an analytics provider; * another cloud service that processes customer data. The review scope depends on how the new service is used. A new service that merely provides an internal infrastructure function may have less review impact than a service that receives customer or business data as part of the app's core process. ### Authentication and security changes Material changes to security-relevant functionality must be communicated to VARIO. Examples include changes to: * authentication; * authorization; * credential storage; * tenant isolation; * externally reachable endpoints; * administrative access; * encryption; * security-relevant infrastructure; * processing of tokens or secrets. VARIO may perform a focused security review of the changed functionality. ### Security fixes Security vulnerabilities should be corrected without unnecessary delay. A critical security fix must not be postponed solely because a formal re-review has not yet been completed. If an urgent security update materially changes previously reviewed behavior, inform VARIO as soon as reasonably possible and provide: * a short description of the issue; * the affected app version; * the corrective action; * any relevant change to functionality, permissions, or data processing. VARIO may perform a subsequent focused review where necessary. {% hint style="danger" %} If a vulnerability creates a relevant risk of unauthorized customer access, credential compromise, cross-tenant access, or manipulation of VARIO business data, remediation takes priority over the ordinary release process. {% endhint %} ### Installation and uninstallation changes Material changes to the app lifecycle may require another review. Examples include: * changing the installation process; * introducing additional setup steps; * changing how tenant credentials are stored; * adding new objects during installation; * changing Webhook registration; * changing uninstallation behavior; * changing which data or configuration remains after uninstallation. The review may include installation, uninstallation, and reinstallation of the updated version. See **Technical Integration and App Lifecycle**. ### Changes to the App Manifest Not every manifest change requires a re-review. However, changes should be treated as material where they affect: * required VARIO permissions; * app-specific authorization; * UI integration points; * installation or uninstallation URLs; * relevant backend URLs; * other behavior that changes how VARIO Cloud integrates with the app. The submitted App Manifest must always represent the version actually being provided to customers. ### Changes to UI integrations Adding a new UI integration point or materially changing how the app interacts with VARIO Cloud may require review. VARIO may verify: * whether the selected integration point is appropriate; * whether authorization is applied correctly; * whether the new interface fits the surrounding VARIO workflow; * whether the app still provides a consistent user experience. Minor visual changes inside an already approved app area generally do not require re-review. ### Changes to business logic Changes to business logic should be evaluated based on their possible effect on customer data and processes. Re-review is particularly relevant where an update changes: * how records are matched; * how duplicates are prevented; * synchronization ownership; * tax- or price-relevant calculations; * quantity handling; * document creation; * inventory changes; * financial transactions; * automated decisions. Changes to high-impact business logic may require a focused data-quality review even where no additional VARIO permission is introduced. ### Updates and migrations Updates must not leave existing customer installations in an inconsistent state. Where an update requires migration of app-specific configuration or registered objects, the migration must be designed for existing installations. The VARIO App Framework provides migration mechanisms for app-related technical changes. For relevant implementation patterns, refer to the Developer Docs, including [App Backends](https://developer.vario-software.de/documentation/apps/app-backends). {% hint style="warning" %} Do not modify an already completed migration step and assume that the changed logic will run again for existing installations. Where a new migration action is required, implement it as a new migration step according to the Developer Docs. {% endhint %} The updated app should be tested with both: * a new installation; and * an existing installation upgraded from the previously released version. ### Backward compatibility App updates should preserve existing customer configuration and data wherever reasonably possible. An update must not unexpectedly: * reset customer configuration; * disconnect existing integrations; * recreate previously configured objects; * duplicate business records; * invalidate mappings; * change automation behavior without notice. If a breaking change is unavoidable, the App Provider must provide an appropriate migration or customer transition process. Material breaking changes must be coordinated with VARIO before release. ### Removing functionality Removing functionality that was previously advertised in the App Store is a material product change. Before release: * update the App Store listing; * update the documentation; * consider the effect on existing customers; * inform VARIO where the removed functionality is material to the app's primary use case. If the removal substantially changes the purpose or value of the app, VARIO may require a new review of the resulting product. ### Changes to prerequisites Introducing a new mandatory prerequisite must be reflected in the App Store listing. Examples include: * requiring a higher external subscription plan; * introducing a mandatory external account; * requiring another VARIO module or function; * restricting the app to particular regions; * introducing mandatory implementation services. Customers must not discover a new mandatory prerequisite only after an update has been deployed. ### Changes to pricing Pricing changes do not normally require a technical app review. However, pricing information shown through the VARIO App Store must be updated and coordinated with VARIO before the new commercial terms become effective. A pricing change must not be introduced through app UI or external billing behavior in a way that contradicts the agreed App Store commercial model. ### When to contact VARIO Contact VARIO before releasing an update if you are unsure whether the change requires re-review. A short change description is normally sufficient for VARIO to determine the required next step. Include: * current app version; * new app version; * summary of the change; * affected functionality; * changed permissions, if any; * changed data processing, if any; * changed external services, if any; * relevant customer impact. {% hint style="info" %} When in doubt, ask before release. A short clarification is usually significantly faster than discovering during or after rollout that a material change should have been reviewed. {% endhint %} ### Preparing a version for re-review Where VARIO requests re-review, provide a stable version that can be tested independently. The submission should include: * the new app version; * a concise change summary; * access to the updated review environment; * updated test credentials where required; * updated review instructions; * updated App Store listing material where applicable; * updated documentation; * explanations of new permissions or data processing. VARIO may focus the review on the changed functionality rather than repeating the complete original review. ### Example: no re-review normally required > **Version 1.4.1** > > * Fixed a display error in synchronization history. > * Improved loading performance. > * Updated internal dependencies. > > No new functionality, permissions, external services, or data processing. This would normally be treated as a maintenance update. ### Example: focused re-review likely > **Version 1.5.0** > > * Adds automatic creation of VARIO invoices after marketplace orders are shipped. > * Adds the VARIO permission required to create the corresponding documents. > * Adds a new configuration option controlling invoice creation. This changes both functionality and permission scope and should be submitted to VARIO before release. ### Example: privacy and security review likely > **Version 2.0.0** > > * Introduces an AI service that receives document content and generates structured metadata. > * Customer document data is transmitted to the new external provider. This introduces a new external data-processing relationship and requires coordination with VARIO before rollout. ### Review outcome After receiving information about an update, VARIO may determine that: #### No re-review is required The update can be released without an additional App Store review. #### Listing update only The app itself does not require technical re-review, but App Store information must be updated. #### Focused re-review VARIO reviews only the changed functionality or affected requirement area. #### Broader re-review The change significantly alters the app and requires a broader review comparable to the initial App Store review. The review depth is determined by the impact of the change, not solely by the version number. ### What VARIO evaluates When determining whether an update requires re-review, VARIO may consider in particular whether the change: * expands app functionality; * changes the primary use case; * adds or extends VARIO permissions; * changes app-specific authorization; * changes customer data processing; * introduces a new external service; * changes authentication or security behavior; * affects tenant isolation; * changes installation or uninstallation; * introduces significant migrations; * modifies high-impact business logic; * changes relevant customer prerequisites; * removes previously advertised functionality; * materially changes the App Store representation of the app. The App Provider remains responsible for ensuring that every released version continues to comply with the applicable App Store Guidelines, regardless of whether VARIO performs another review. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://developer.vario-software.de/app-store-guidelines/review-process/app-updates-and-re-review.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.