Implementing your own crypto is likely to be error prone, so please don't do that.
If you are trying to encrypt data in transit between your app and your backend (i.e. provide confidentiality for that transmission), then using a HTTPS connection is likely to be entirely sufficient. Both the app and the server will then see the unencrypted message.
Note that all certificate authorities trusted by the device running the app can issue certificates for your site. This is frequently used in business networks to intercept any encrypted traffic, but is generally done with the knowledge of the end user. You can prevent this if the app pins the correct certificate, but that may break the app if you need to change the certificate on the server. This is not something you should generally do, but it is important to be aware of the limitations of HTTPS in case you are dealing with highly sensitive data: HTTPS provides confidentiality but not necessarily authentication.
HTTPS works roughly like your second example. The server provides a public key. This key is signed by a certificate authority (CA). The CA is supposed to verify that this public key belongs to the domain you are connecting to. The key is accepted when the end user device trusts the signing CA. Now the client can send messages to the server using the server's public key, and only the server is able to decode this message. That is used to negotiate a short-lived symmetric session key which allows for more efficient communication. Now that the secret session key has been exchanged, the server and client can talk to each other over an encrypted channel.
A private key should never be transmitted. The whole point of public/private cryptography is that you do not have to share a secret key in order to decrypt messages.