Unfortunately while this thing helps it doesn't actually conclusively stop any speculation. If I wanted to spy on you via app, I would encrypt the data inside the HTTPS stream and only decrypt it on my server.
Pretty sure anything you encrypt client side can be decrypted client side, as long as you have control over the binary and OS/hardware. It's just a matter of effort.
Not the case with asymmetric encryption, you could encrypt with a public key and only the server's private key would be able to decrypt it. Not even the client could.
I think the person you're replying to perhaps meant that if you have total control of the hardware and the binary you can pull the value prior to being sent to the encrypt function.
Asymmetric encryption is very computationally expensive - there's a reason that it's typically only feasible to use for signing a hash or as part of a key exchange to agree upon a shared symmetric key.
Envelope encryption works for that - client generates a random symmetric key, encrypts the data symmetrically, then asymmetrically encrypts just the key (which is then thrown away on the client). Both the symmetrically encrypted body and asymmetrically encrypted key are sent.
They only need the server's public key to encrypt it client side. But if all you want is to see if they're spying on you, you could go one step above and see if they're calling system APIs to your mic/camera/keyboard, instead of observing the network activities.