Backend-for-Frontend (BFF) pattern: one per client or shared?

We're re-evaluating our API strategy, and the Backend-for-Frontend (BFF) pattern has come up. Currently, our web, iOS, and Android clients all hit the same set of APIs, which often leads to bloated responses or inefficient data fetching for specific clients. The question is, should we build one BFF per client (web BFF, iOS BFF, etc.) or try to have a more generic shared BFF that uses flags or request parameters to customize responses? Does GraphQL effectively replace the need for multiple BFFs, by letting clients define their own data needs? What are the operational overheads of maintaining several BFFs versus one more complex one? I'm particularly interested in experiences with scaling and evolving these patterns in a rapidly changing product environment.