Application code change behavior

Application code change behavior

This page explains what happens across the whole platform (SDK, backend, and message delivery) when the application code configured for an app changes on a device that was previously registered with a different application code.

Application code should ideally never change for a given application. It's tied to the application (and, transitively, to your app's package name/bundle ID), not to which Infobip plugin/SDK you use. If you migrate your mobile integration from one framework to another (for example, from Cordova to React Native, or from a native integration to Flutter) while keeping the same package name/bundle ID, the existing application code continues to work unchanged — there is no need to create a new one. Treat an application code change as a deliberate, rare operation, not a routine step of a plugin migration.

Table of contents

• Fresh install vs. application code change
• What the plugin does locally
• What happens on the backend
• Effect on sending and targeting
• Practical guidance

Fresh install vs. application code change

A brand-new installation that has never had an application code stored locally is unaffected by anything on this page — it simply registers normally against whichever application code it's configured with. Everything described below only applies to an existing installation whose application code changes from a previously stored value to a different one (e.g., a client build is repointed from an old application to a new one).

What the plugin does locally

This plugin does not implement its own application-code-change detection or cleanup logic. On init, it checks the native Android/iOS SDK's own application-code-changed flag to decide whether the native module needs to be restarted (stopped and started again with the new code); the actual data cleanup (registration ID, cached user data, message-sync state, and — on iOS — the resulting attempted-and-rejected delete of the old registration) happens entirely inside the native SDK.

For the exact mechanics of what gets cleared and what's preserved, see the native SDK wiki pages:

• Android SDK: Application code change behavior
• iOS SDK: Application code change behavior

What happens on the backend

• A push registration ID is permanently bound to a single application code on the backend. The device's next registration under the new application code always creates a brand-new registration ID — there is no way to move an existing registration ID to a different application.
• That new registration always creates a brand-new anonymous LEAD person profile. Registration alone doesn't carry any user identity (external user ID, phone, email), so there's nothing to automatically link the new profile to the one that existed under the old application code.
• The old registration and its old person profile are not deleted or deactivated automatically. It simply becomes orphaned and stays live until it naturally expires from inactivity, or until it's explicitly deleted.
• The new registration only converges with the old person profile if the app explicitly re-personalizes with the same external user ID/phone/email as before — that's the normal personalize/merge flow, and it does not happen automatically just because it's the same physical device.

Effect on sending and targeting

Sending to the new application only reaches devices that have already completed a fresh registration under the new application code — practically, that means users who have opened the updated app at least once after the change (registration happens automatically on next SDK init).

Sending to the old application can, in principle, still reach the orphaned old registration, since it isn't actively cleaned up server-side. This is an easy-to-miss edge case when auditing delivery numbers after an application code change — a stale registration may continue to receive old-application sends for a while after the device has effectively moved to the new application.

Practical guidance

• Avoid changing application code unless truly necessary. Migrating between Infobip mobile plugins/SDKs with the same package name/bundle ID does not require it.
• If a clean cutover is required (e.g., for compliance or to stop stale sends to old-application registrations), don't rely on automatic cleanup alone — plan the migration so old-application registrations are retired intentionally as part of the rollout, rather than expecting the SDK to clean them up for you.
• Encourage end users to open the updated app so their device completes the fresh registration under the new application code.