Add Expo SDK 56 peer compatibility for @config-plugins/ios-stickers

[safaiyeh]

Summary

@config-plugins/ios-stickers@13.0.0 is still published with an expo peer dependency of ^55. In an Expo SDK 56 app, this can make package managers resolve an extra Expo 55 peer graph just for the stickers plugin.

I hit this while upgrading an app to Expo SDK 56 (expo@~56.0.3, React Native 0.85.3) that still uses the iMessage sticker pack plugin.

Current behavior

Installing @config-plugins/ios-stickers@13.0.0 in an SDK 56 app reports/uses the package peer:

"peerDependencies": {
  "expo": "^55"
}

With Bun, that peer mismatch produced a separate Expo 55 install under the peer context for @config-plugins/ios-stickers. expo-doctor then reported duplicate native modules such as expo, expo-asset, expo-constants, expo-file-system, and expo-font.

A root override can force all expo references back to SDK 56 locally, but the package still advertises an incompatible peer range.

Expected behavior

There should be a published @config-plugins/ios-stickers version that accepts Expo SDK 56, for example by widening its Expo peer range to include SDK 56 if the plugin is compatible.

Monorepo note

I noticed the package source uses:

"peerDependencies": {
  "expo": "catalog:"
}

and the root pnpm-workspace.yaml catalog currently has:

expo: ^55

Since bumping the catalog may affect multiple packages in this monorepo, I’m opening an issue rather than sending a narrow PR that changes the shared catalog without maintainer guidance.

Would you prefer a package-specific compatibility update for ios-stickers, or should SDK 56 compatibility be handled as a coordinated release across the config plugin packages?

[hassankhan]

Hi @safaiyeh, I'll be updating all config plugins for SDK 56 compatibility together in this repo shortly

[stefan-schweiger]

@hassankhan any update on this? I mean just putting an override in the package.json always works, but those config plugins are always a big holdup when upgrading expo versions.