Updating Your Mobile SDK Version

Attentive ships regular updates to the iOS and Android SDKs. New versions add features, fix bugs, and keep pace with what Apple and Google require to publish an app. When Attentive asks you to update the SDK version, we're asking your engineering team to change one number in one line in your app's code and rebuild — usually a few minutes of work, followed by your normal app-release process.

📘

The short version

Updating the mobile SDK means changing a version number in your app and shipping a new app build to the App Store or Play Store. It's a small change for the engineering team. The longer part is your own release process (testing, review, rollout).

Why Attentive asks you to update

The most common reasons Attentive asks you to bump the SDK version:

• A new feature was released that you want to use.
• A bug fix shipped that affects your integration.
• Apple or Google changed a requirement. iOS and Android periodically require SDKs to support new OS versions or drop old ones. Staying on an old SDK version eventually blocks you from submitting app updates.
• Security or compliance. A vulnerability was found and fixed in a newer version.

If you're wondering "do we have to update?", the honest answer is usually yes, eventually — but the urgency depends on which of the above is driving the ask. Your Attentive contact can tell you which.

What "updating the SDK" actually means

The Attentive SDK is a small piece of code that lives inside your app. Your engineering team pulled it in from Attentive's iOS GitHub or Android GitHub when they first integrated. Each release is tagged with a version number.

When we ask you to "update to version X," we're asking you to point your app at the newer version. In practice, your engineer opens the file that lists your app's dependencies, changes the Attentive version number to the one we specified, and rebuilds. That's the change. Everything else — testing, submitting to the App Store or Play Store — is your normal release process, not Attentive-specific.

Which version to update to

Two options:

1. The latest version (default). This is usually what we recommend. Every Attentive release is backwards-compatible with the previous one unless we explicitly say otherwise, so upgrading to the newest release is the safest and simplest path.
2. A specific version we provided. Occasionally we'll direct you to a specific version — for example, "please move to 2.0.17-beta.1, not the very latest" — because we're rolling out a beta feature and want early adopters on that exact build. If Attentive gave you a specific version number, use that one.

Your engineer can find the current version numbers on the GitHub releases pages:

• iOS — attentive-ios-sdk releases
• Android — attentive-android-sdk releases

📘

Always check GitHub for the current number. SDK releases ship regularly, so any specific version number quoted anywhere else is likely to go stale. The GitHub releases page is the source of truth.

What the engineer actually does

At a high level, here's the change on each platform. You don't need to memorize this — it's here for anyone who wants to know what the dev team actually has to do.

iOS

Your engineer opens the file that lists your app's dependencies and changes the Attentive version number. Depending on how they installed the SDK originally, that file is one of:

• Swift Package Manager (recommended). Your engineer opens the project in Xcode and updates the Attentive SDK package version through Xcode's package manager UI. One field, one number.
• CocoaPods. Your engineer opens the Podfile, changes the Attentive version number on one line, and runs pod install.
• Manual XCFramework. Your engineer downloads the new release from GitHub and drags the framework into the project. Slightly more work than the above two, but still routine — should only realistically take a couple of minutes.

The iOS SDK README has the exact instructions for each method.

Android

Your engineer opens the build.gradle file, finds the Attentive dependency line, and changes the version number. One line, one number. They then rebuild the app.

The Android SDK README has the exact instructions.

How long it takes

The code change itself is a few minutes.

The full round trip — including testing and app store review — is usually one of two tracks:

When you're asking "how much work is this?" the honest answer is: the code change is small, but the release process around it depends on your team's cadence. Attentive can't shortcut that side.

What can go wrong (and what usually doesn't)

To set expectations honestly:

• Almost always fine. Attentive releases are backwards-compatible. In the vast majority of updates, the engineer changes the number, rebuilds, tests, and ships. Nothing else changes in the code.
• Occasionally requires small code changes. If we've deprecated an old method or renamed something, the engineer may see a compiler warning pointing them at the new method. This is documented in the SDK's release notes on GitHub and, when material, in a MIGRATION_GUIDE.md file in the repo. If your engineer flags migration work, let your Attentive contact know and we'll support you through it.

If you're worried about updating, the concrete reassurance is:

The SDK is used by many other Attentive customers on the same version. Every release is tested before it ships. Your engineering team is doing a routine dependency bump, not a rewrite.

In a nutshell

Updating the Attentive SDK means your engineering team changes a version number in your app's dependency file and rebuilds. It's a small change on their side — the longer part is your normal app-release process (testing and store review). We recommend the latest version unless we've told you otherwise, and the exact numbers live on our GitHub. If anything unexpected comes up, we'll help.

For something more concrete, share the appropriate GitHub link with your engineering team:

• iOS: github.com/attentive-mobile/attentive-ios-sdk
• Android: github.com/attentive-mobile/attentive-android-sdk

Your engineering team will recognize the format and know exactly what to do from there.

When to escalate

Open a support ticket through the normal support process for questions about:

• Whether a specific version has a known issue.
• How to move from v1 to v2 of the mobile events SDK (this involves more than a version bump — it's a code migration, and we have specific guidance).
• Timing of an upcoming release, or requesting a fix be prioritized for a patch release.
• Any error message your engineer surfaces that isn't obviously in the release notes.

For anything that's just "how do I change the version number," this page and the SDK READMEs are enough.