Skip to content

Migration to the SDK version 4

This document provides an overview of the changes introduced in SDK version 4. It includes:

  • updates in the management of user data — completion states, consents, and historical records;
  • image ownership and changes the backend processes for deleting images upon user requests, which now take into account the ownership of the images;
  • the general changes made to the configuration and features.
Why does version 4 come after version 1?

The Aiuta Flutter SDK has transitioned directly from version 1 to version 4, skipping versions 2 and 3. This decision aligns with our new policy to ensure that all mobile platforms — Android, iOS, and Flutter — are delivered simultaneously with the same functionality and based on a unified scheme. By synchronizing the version numbers across all platforms, we aim to provide a consistent and cohesive experience for developers working with our SDKs. The choice of version 4 as the next release was determined by the least common version number across Android, iOS, and Flutter, ensuring that all platforms are now aligned under the same versioning system. This unified approach simplifies the development process and ensures feature parity across different mobile environments.

Platform & Build Requirements

  • Android

    minSdk: 23
targetSdk: 35
ndkVersion: 26.1.10909125

kotlin: 2.0.20

com.android.application: 8.6.0

  • iOS

    iOS: 12+
swift: 5.10
Xcode: 15.3+

Data management

Onboarding completion state

In this version, onboarding and the consent pages are not so tightly coupled. There are several configuration options when the SDK cannot determine whether to not show onboarding again based on the consent status only. Therefore, a dataProvider has been added to manage the onboarding state.

Learn how it works and how to implement it:

How to determine this status for current users?

For existing users, you can set isOnboardingCompleted based on whether main consent was previously obtained, as consent was a mandatory final slide of the onboarding process in the first version.

User consents

This version significantly expands the possibilities of how, when, and what to ask the user for consent. This required adding data models for consents and operating them with identifiers.

For full context, see

How to map existing data?

If you did not have internal identifiers for consents and only stored the status, create one, for example, main and provide it in the list of received consents for the SDK depending on the state flag you stored earlier.

If you already have internal identifiers, simply provide them to the SDK.

Users' History Images

Image data models have two key updates:

  • Uploaded images and generated images are now distinguished by class - generated images must store their associated product IDs.

  • Both data models now have an owner type - this is to distinguish users' personal images from model images provided by Aiuta.

    Do not delete aiuta owned image files

    You should only link/unlink those images in the user's history. Read more about owner type

To understand this change, see history images schemes

How to determine product identifiers for old images?

If you have not previously saved the connections between products and generated images, this data cannot be restored. But don't worry, just pass an empty list to the SDK, and this will only result in the absence of accompanying text/links when the user wants to share a previously generated image.

Resources