I don't know about the specifics of iOS, but the principle should be the same.
In theory, if you get your clients to install and trust your CA certificate, then any certificate it issues will be trusted by those clients. A man-in-the-middle attack should not be able to forge these certificates, unless they grab hold of your CA private key. So in that respect, your solution should be protected against man-in-the-middle attacks.
The downsides of using such solution, as opposed to getting a certificate issued by one of the trusted root CAs is with:
- Deployment : With your approach, you'd have to manually installed your own CA as trusted on all your devices. Users with other devices (without your CA certificate) won't have this installed and either won't connect, or will manually have to accept an unknown (and therefore untrusted) certificate. In which case, the man-in-the-middle attack is a real possibility.
- Revocation : What happens if your CA or server private key gets exposed somehow. How can you tell all your devices not to trust it any more, and instead trust a new certificate? 3rd party trusted CAs usually provide service to perform revocation checks to avoid this. You might be able to do something similar on your own, but it increases the complexity dramatically
- CA Security : Whilst this is not guaranteed, trusted certificate authorities are likely to have stricter security in place. This is their core business after all.
- Price/Hassle : I imagine the cost of issuing a certificate to your server with a 3rd party trusted CA should be significantly lower than running this whole thing by yourself. This of course depends on your circumstances, e.g. how many devices, what security/resources you already have etc.