The Apps SDK is constantly evolving. We try to make changes in backwards compatible ways, but sometimes it's necessary to deprecate existing features in order to improve the platform.

This page describes everything you need to know about how we handle deprecation.

TL;DR

This deprecation policy only applies to the public, stable version of the Apps SDK.
When a feature is deprecated, it remains available for at least a further 6 months.
Canva communicates deprecations at multiple points in time, via multiple channels.
There may be exceptions to this policy, like in the case of security incidents.

Applicability

This deprecation policy applies to the public, stable version of the Apps SDK.

If an app uses private or unstable APIs, such as those released in beta, breaking changes may occur at any moment and without warning. You should not rely on unstable APIs remaining the same.

Deprecation period

The deprecation period for the Apps SDK is 6 months.

Once a feature has been deprecated, it will remain available for at least 6 months. When the deprecation period ends, the feature may be removed from the Apps SDK at any point in time.

Communication

Developers are notified when features are deprecated and when they're made obsolete. This communication happens via a number of channels, including but not limited to:

An email sent directly to the developer.
An announcement in the developer community.
Alerts in the documentation and Developer Portal.

Breaking vs. non-breaking changes

There isn't a universal definition of what constitutes a breaking versus non-breaking change. This section explains how Canva defines these terms.

Breaking changes

A breaking change is one that's backward incompatible, meaning that it either alters or removes an existing API.

Some examples of breaking changes include:

Adding required properties to methods
Renaming methods or types
Removing values from enums

When a breaking change is made, the developer must update their app by the end of the deprecation period.

Non-breaking changes

A non-breaking change is one that's backward compatible.

Some examples of non-breaking changes include:

Adding methods to the SDK
Adding optional properties to methods
Adding values to enums

When a non-breaking change is made, the developer is not required to update their app.

Exceptions

Canva is committed to having a stable deprecation policy that developers can rely upon, but there are exceptions that need to be accounted for.

For example, if a security issue is discovered and a breaking change is required to fix it, the deprecation period for that change will not be observed. We will, however:

Communicate the change as quickly as possible.
Provide resources to help minimize disruption, such as a migration guide.

We do not make exceptions lightly. They're reserved for truly exceptional circumstances.

Tips & tricks

When a feature is deprecated, here's what we recommend:

Upgrade the app as soon as possible. To help make this process painless, we always provide migration guides, support via the developer community, and support via our ticketing system.
Don't submit apps that use deprecated APIs. We won't automatically reject apps that do this, but it's easier to upgrade the app as part of the same submission.