Use a hash-function twice
I read that something like this might be insecure as hashes become less secure the more often you hash them again.


While this is technically true, you shouldn't worry about it. This paper has precise bounds on how bad it is to iterate a random function and with the iteration count $r&lt;10$ as you are worrying right now this is a non-issue for security.


  This would prevent someone who somehow got a (doubled) hashed password
  from our database from logging in into our api (since he needs to
  provide the 1st hash) and also would allow the app to not store the
  passwords of the user in plain text.


This is a good idea and also the ideal model of how client-side password hashing is supposed to work: You compute an (expensive) password hash on the client, send it to the server who then hashes (or somehow else one-way processes) it so that an attacker leaking the database doesn't get all the log-in hashes for free.


  Should I maybe use different hash-algorithms for both actions?


Yes. As explained in the previous paragraph, you want to use a slow password-hashing scheme on the client, like Argon2 and then you can use a fast (normal) hash function on the server, like SHA3-256.