Exercise 3: Why Changing a Bundle Identifier After Users Install the App Is Genuinely Risky — Possible Solution
=======================================================================================================================

A real bundle identifier isn't just a piece of internal project
configuration visible only to the developer - it's the exact real
string the operating system, App Store Connect, and every real
installed copy of the app on a real user's device all use as the
app's own unique, canonical identity. iOS uses that identifier to
know which installed app a given update actually belongs to, which
app owns a given set of locally stored data (documents, SwiftData's
own real persisted store, user defaults, keychain entries), and which
real App Store Connect listing a submitted build should attach to.

If the bundle identifier were changed after real users had already
installed a version of the app under the original identifier, the
system would genuinely treat a subsequent update carrying the new
identifier as an entirely SEPARATE, different app - not a real update
to the one already installed. A user's own existing installation,
along with every real piece of local data specific to it (their
persisted TaskFlow tasks, in this course's own case), would be left
behind, orphaned under the old identifier, while the "updated" app
would actually need to be installed fresh under the new identifier
with no real, automatic way to migrate the old data across on the
user's own behalf.

This is a genuinely different, much higher-risk kind of change than
most other project settings this chapter covers (like the display name
or the launch screen's own colors), which can be adjusted freely at
any time with no real consequence to already-installed copies of the
app - the bundle identifier specifically is the one setting tying every
future update back to what's already really installed on a real user's
device.

ANSWER: The bundle identifier is the real, canonical string the system
and App Store Connect use to recognize an app across updates and to
tie locally stored data to a specific installation. Changing it after
real users have already installed the app makes any later update look
like a genuinely separate, unrelated app to the system, leaving
existing installations and their own real local data (like persisted
tasks) orphaned behind, with no automatic way to migrate them - a
genuinely higher-risk, harder-to-reverse change than most other project
settings.

WHY THIS WORKS AS AN ANSWER
------------------------------
This explains the real, concrete mechanism (the system's own identity
tracking across updates and local data) that makes changing the bundle
identifier late in a real app's lifecycle genuinely risky, rather than
treating it as an arbitrary inconvenience.