Add reorder in StickerManager

[Thomas-Leung]

First time contributor checklist

• I have read the README and CONTRIBUTING documents
• I have signed the Contributor Licence Agreement

Contributor checklist

• My commits are rebased on the latest main branch
• My commits are in nice logical chunks
• My contribution is fully baked and is ready to be merged as is
• I have tested my contribution on these devices:

• iPhone 13, iOS 26.3
• iPhone 17 Pro simulator, iOS 26.2

---

Description

This PR adds manual reordering for installed sticker packs on iOS.

Installed packs were previously shown by dateCreated. This change introduces a persisted custom order that users can manage via drag and drop in Manage Stickers, and the same order is now used in Sticker Picker.

This feature has been requested by the community since 2021:
https://community.signalusers.org/t/ability-to-reorder-sticker-packs-desktop-ios/29124
and brings iOS in line with Android’s existing sticker-pack reordering behavior.

Scope note: this is a client-only iOS change with local persistence (KeyValueStore) and no protocol or backend changes.

Behavior details:

• Reordered pack IDs are stored locally in KeyValueStore (installedStickerPackOrder).
• New installs are prepended to preserve current default behavior.
• Uninstalled packs are removed from saved order.
• If saved order is missing or incomplete, ordering falls back to dateCreated and appends missing packs by recency.

Testing

• Verified users without saved order still see dateCreated ordering.
• Verified drag-and-drop reordering in Manage Stickers.
• Verified order persists after app restart.
• Verified Sticker Picker reflects the same reordered list.
• Verified new installs prepend and uninstall cleanup keeps remaining order valid.

Demo

Attached demo showing drag-and-drop reorder and matching Sticker Picker order.

Simulator.Screen.Recording.-.iPhone.17.Pro.-.2026-02-28.at.01.55.39.mov

[naoki-deva]

This is really awesome

[Thomas-Leung]

@naoki-deva Thank you! Glad you liked it.

[sashaweiss-signal]

Thanks for this! This is something we're interested in adopting, but since it has persisted-data implications (and eventually may be something we want to sync across clients), we'll need to give this a more thorough evaluation. For example, we might want to use a different mechanism for the persistence than KeyValueStore.

I can't guarantee when we'll slot that in, but I'm going to leave this PR open until we do!