Wouldn't you leave the API key, in the server and proxy thru? That's what I was taught to do, and you give your own tokens to clients to track which client is making that request and block that client if needed. It seems very dangerous to pass on the reddit API key to the client.

with Oauth2, the API credentials don't give you access to other users' accounts or data or anything of that sort - so the only problem with the client id/secret being in the client is malicious people pulling it and abusing the service while using those API credentials. In general this hasn't been a problem, but once it costs (for example) Apollo $x per million API calls, it could be a money drain, and it could cause headache for the service that now has to try to do abuse prevention via IP reputation / other tracking techniques.

And proxying api calls isn't an end-all solution. This introduces a large burden for the developer to not just run a scalable proxy for the API calls, but also must introduce and manage some abuse prevention system, maybe with their user account system with reputation ratings based on number of times they've hit a rate limit or how many different subreddits they try to access every day.

It also is generally not good for users to have to deal with a proxy like this, since it means the app developer has the ability to log all of their users' usage, and could be compelled by law enforcement / courts to hand over user PII or activity logs.

How would those api keys be exposed if it’s an app?

Inspecting the app's content or the network traffic.

Decompiling apps even on iOS is not too hard, typically API keys would either be in resource files or exposed via strings in the binary itself.