If we go ahead with this change, keys for Blogging Prompts and Blaze will be dynamically generated. I see how this can help provide a direct mapping between DashboardCards and their persistence key without having to make that mapping explicit. However, I'm not aware of any other advantages.

The biggest disadvantage I see is that the raw key is no longer searchable in the codebase. This could come up when inspecting NSUserDefaults' content and figuring out where the keys found there are defined in the codebase. The other downside is that "key migration" logic is needed for the prompt key. There's no perfect time to remove this logic to clean up the code base, someone will have to figure out when few enough devices are using the old key that it's safe to clean this up.

What are you thoughts on these points?

I was also debating whether to keep the constants or generate the keys dynamically. The advantage of generating them dynamically is that there are fewer changes needed when new cards that require personalization are added. The disadvantage, as you pointed out, is that they keys are no longer visible in UPRUConstants.

The biggest disadvantage I see is that the raw key is no longer searchable in the codebase.

I can suggest two options how to address it:

1. Add static keys (one per card) to UPRUConstants and create a DashboardCard → key mapping
2. Move makeKey(for card: DashboardCard) method I added to UPRUConstants, so it's more visible

I'll be happy to change it to what you think is the best option. I think making these keys visible/searchable is a good idea, but there are dozens of UserDefaults keys defined outside of UPRUConstants, so I assumed these constants were only for the keys used in UserPersistentRepositoryUtility.

The other downside is that "key migration" logic is needed for the prompt key.

The data migration is not needed because I added .prompts as an exception:

private func makeKey(for card: DashboardCard) -> String {
    if card == .prompts {
        // This key was defined statically in the previous versions, and the
        // naming convention wasn't matching the other keys, so it had to be
        // special-cased to avoid losing data.
        return "prompts-enabled-site-settings"
    }
    return "\(card.rawValue)-card-enabled-site-settings"
}

I think we can keep it like this indefinitely: it's a small exception and is documented.

The disadvantage, as you pointed out, is that they keys are no longer visible in UPRUConstants.

I want to clarify that the disadvantage I pointed out above relates to seachability, not visibility. I don't think making the keys searchable requires them to be defined in the same place.

I think making these keys visible/searchable is a good idea, but there are dozens of UserDefaults keys defined outside of UPRUConstants, so I assumed these constants were only for the keys used in UserPersistentRepositoryUtility.

I don't have an issue with defining the keys for the Blaze, Prompts, etc. cards in a different place.

The data migration is not needed because I added .prompts as an exception:

Thanks, I misunderstood it the first time around. The prompt key remains unchanged, so no migration 👍

1. Add static keys (one per card) to UPRUConstants and create a DashboardCard → key mapping

If you don't think the dynamic keys are required for this implementation, going with the above seems like a good option for now. Dynamic keys can always be revisited if it's clear they make adding cards significantly easier.

I think I got your point about searchable. I tried adding the keys to UPRUConstants, but there were private, which I didn't want to change. So I added the static strings directly to makeKey and retested the migration (or lack thereof) – looks good now. Commit with the change.

The disadvantage, as you pointed out, is that they keys are no longer visible in UPRUConstants.

I want to clarify that the disadvantage I pointed out above relates to seachability, not visibility. I don't think making the keys searchable requires them to be defined in the same place.

I think making these keys visible/searchable is a good idea, but there are dozens of UserDefaults keys defined outside of UPRUConstants, so I assumed these constants were only for the keys used in UserPersistentRepositoryUtility.

I don't have an issue with defining the keys for the Blaze, Prompts, etc. cards in a different place.

The data migration is not needed because I added .prompts as an exception:

Thanks, I misunderstood it the first time around. The prompt key remains unchanged, so no migration 👍

1. Add static keys (one per card) to UPRUConstants and create a DashboardCard → key mapping

If you don't think the dynamic keys are required for this implementation, going with the above seems like a good option for now. Dynamic keys can always be revisited if it's clear they make adding cards significantly easier.