(not the op so this is jmo)

  > Do you now have a BFF for each client type? Who owns it then ? Don't you now need more fullstacks ?

everyone has an opinion, but ideally you'd have 1 bff for all clients from the start

  > there's confusion. Now you have 2 sets of contracts (API-BFF, BFF-clientIOS, BFF-clientAndroid, ...). You now have more human synchronization overhead. Changes take longer to percolate throughout. More scope for inconsistencies.

yep, i have literally experienced the chaos this can cause, including the endless work to unify them later (usually its unify behind the web/html bff which breaks all kinds of assumptions form the poor html bff team such as assuming you can return html for any arbitrary http call etc)

  > Isn't is better to have the API team own the single source of ownership ?

it depends on what it means "api team"; do they provide access to a databse only or also business logic? or do they just mediate biz logic access and handle formatting it for display (as json for ex.) and handle transient state (checkout function etc) also?

ideally with a bff the idea is that what you get back is basically ready for display (including localization), and if you have some stateful api it will let your client know what it can do next if necessary (checkout, change payment etc)

its sort of like having the view model as a server... that way multiple clients can be dead simple and just map the bff response to a ui and be done with it

(thats the ideal as i understand it anyways)