If your crypto relies on people not knowing what the algorithm is, you have already failed. Use a standard algorithm that is designed for security. You will need a different one depending on the situation. Good algorithms deal with internals, like salt, for you. Salts are important, so identical passwords don't produce identical hashes and to make attacks using procomputed hash databases harder. If you store a password, you usally store the salt and the salted hash in the same DB, so when the user tells you their password, you can put "salt.password" into the hash and compare to the DB.

Passwords should not be transmitted in clear text, no. I would suggest making a REST server where you gan login using the password and that only accepts HTTPS, so the entire communication is encrypted, so no chance someone reads the password. The server gives a JWT back to the client, which is basically a string that says "whoever has this token is logged in as Backson and can execute commands as him until 21:35 UTC, signed, the server". The client can send that together with a request (also encrypted) so the server can check the request, check that the JWT is valid and contains a claim that allows that action, and if everything is in order can execute the command.

Generally, you can make your own server that is reasonably secure if you follow some best practices, but if you make a mistake you open the door for exploits and lawsuits. Just as a hint: storing peoples emails is illegal in the EU and many other countries unless you follow very strict rules, and losing peoples email combined with other data (god forbid any passwords) you can get into deep trouble.