adapty_flutter should support a core-only installation without AdaptyUI / Builder dependencies

[alectogeek]

Summary

We use adapty_flutter for custom paywalls only, without Adapty Paywall Builder / AdaptyUI rendering.

According to the Flutter docs, Adapty consists of:

• Core Adapty
• optional AdaptyUI module for Paywall Builder

Docs:

• https://adapty.io/docs/sdk-installation-flutter

However, in the current Flutter SDK, AdaptyUI-related native dependencies are linked unconditionally, even when the app does not use Builder UI and activates Adapty with withActivateUI(false).

This makes app size significantly larger than necessary.

Version

• adapty_flutter: 3.15.5

What we use in our app

We only use the core SDK APIs:

• Adapty().activate(...)
• getPaywall(...)
• getPaywallProducts(...)
• makePurchase(...)

We do not use AdaptyUI views / Builder rendering APIs.

We also explicitly keep UI activation disabled:

• ..withActivateUI(false)

Why this looks wrong

The docs describe AdaptyUI as optional for Paywall Builder usage.

But in the published Flutter SDK source for 3.15.5, the native dependencies include UI modules unconditionally:

iOS

ios/adapty_flutter.podspec declares:

• Adapty
• AdaptyUI
• AdaptyPlugin

Source:

• https://raw.githubusercontent.com/adaptyteam/AdaptySDK-Flutter/3.15.5/ios/adapty_flutter.podspec

Android

android/build.gradle declares:

• io.adapty:android-sdk
• io.adapty:android-ui
• io.adapty:android-ui-video

Source:

• https://raw.githubusercontent.com/adaptyteam/AdaptySDK-Flutter/3.15.5/android/build.gradle

So even apps that only use core purchase / profile / paywall-fetch APIs still ship Builder-related binaries.

Real size impact from our app

We profiled our release iOS app after aggressively optimizing assets, so the SDK cost is not hidden by large media files.

Final iOS release app size

• Runner.app: 81.2 MB

Breakdown inside the final app

• Adapty family: 17.6 MB total
• App.framework/App (our compiled app code): 14.8 MB

So the Adapty-related binaries are larger than our own app code.

Adapty-related frameworks inside the final iOS app

• AdaptyUIBuilder.framework: 8.8 MB
• Adapty.framework: 5.2 MB
• AdaptyPlugin.framework: 1.5 MB
• AdaptyUI.framework: 0.94 MB
• plus wrapper/logger pieces on top

In practice, the Builder/UI part alone is a very large chunk of the total app size for apps that do not use it.

Why this matters

For apps that build their own paywalls:

• there is no benefit from shipping AdaptyUI / Builder binaries
• runtime flag withActivateUI(false) does not help binary size
• app store download size and install size are both unnecessarily increased

Expected behavior

There should be a supported way to install core Adapty only in Flutter apps that do not use Builder UI.

Possible solutions

Any of these would help:

1. Split the Flutter package into:
   • adapty_flutter_core
   • adapty_flutter_ui
2. Add a core-only install mode with build-time dependency selection
3. On iOS, use subspecs / separate pod products so AdaptyUI is optional
4. On Android, avoid linking android-ui / android-ui-video unless UI APIs are actually needed
5. Publish clear migration guidance for apps using custom paywalls only

Request

Would you consider adding a supported core-only installation path for Flutter?

This would be very valuable for apps that:

• use custom paywalls
• need to keep binary size under control
• do not want to ship Builder UI code they never use

[x401om]

Hi @alectogeek, thanks for the detailed write-up and the profiling numbers.

A core-only installation path is a reasonable ask, and we'll consider it. A few notes on the shape of the work:

• It's not just a podspec/gradle change — the native plugin code currently calls UI APIs unconditionally, so a clean split requires either two pub packages with a shared core or conditional compilation on both platforms.
• On iOS, this overlaps with SPM support (Add Swift Package Manager support #184), since SPM products map onto an optional UI module more cleanly than Pod subspecs. We'd likely sequence it after that.

No concrete timeline yet. We'll update the issue as things move.

Thanks again for raising it.