Bundle identifiers, updates and app data

The bundle identifier is the stable name iOS uses to distinguish one app from another. For example, com.example.myapp. Signing tools may preserve it or replace it to fit a provisioning profile.

Updating in place

To update an installed sideloaded app while preserving its local container, the newly signed build generally needs:

• the same effective bundle identifier;
• a compatible signing identity and provisioning profile;
• a version/build combination iOS accepts;
• compatible entitlements and application groups.

Install the new build over the old one. Do not delete the existing app first if its local data matters.

The Arctic support material repeatedly found that changing the bundle identifier caused iOS to install a second copy rather than update the first. SideStore likewise advises installing the same or updated IPA without removing the original when preserving data. See the SideStore FAQ.

After a new certificate

A new certificate from the same developer team updates in place. One from a different team changes the prefix of the app's application identifier, and iOS refuses to install over the old copy (MismatchedApplicationIdentifierEntitlement). Export the app's data, delete the app, then install the new build. Ask your provider whether a replacement comes from the same team.

Why data can still disappear

Matching the visible app name is irrelevant. A changed bundle identifier creates a different container. Changed keychain access groups or App Groups can also make data appear missing even when the app itself updates.

There is never a universal guarantee that an unofficial or modified update will migrate correctly. Back up important information using the app's own export or sync feature before changing builds, signers or certificates.

Original versus custom identifiers

Keeping the original identifier can help features tied to it, but only when the provisioning profile authorises that identifier and required entitlements. Using an original App Store identifier is not automatically valid merely because the source app used it.

A custom identifier often avoids collision with an App Store copy and may be required by an explicit profile. The trade-off is that push notifications, associated domains, keychain groups, widgets or URL integrations may not behave like the original app.

A practical record

For any app whose data matters, record:

• IPA source and version;
• bundle identifier used during signing;
• signer and certificate/profile pair;
• enabled or removed extensions;
• whether the current install contains data not synced elsewhere.

That small record is far more useful than trying to reconstruct the configuration after an update installs as a blank second app.