That scenario is not exactly making any sense to me and I do AppSec, pentesting, and threat models all day, forgetting the malicious use case and first understand there is a big confusion here that needs to be cleared up
It is not clear if you want to have the iOS App (a client) have it's Certificate presented to a server, and that server trust the client Certificate by giving the Server a CA Certificate that is not part of the TLS Trust ecosystem (you created it in isolation), OR;
You want to self-sign a Certificate that a server will use and have your iOS App make a call to the server using your Certificate (not part of the TLS ecosystem) and trust it because your own private CA certificate exists on every iOS device because you were able to tell users to install your private CA on their devices.
Before I clarify each scenario, let me first expand on the point I made several times about the TLS ecosystem and the trust that exists (because using your own Certificates breaks that trust effectively making your use of TLS rouge and untrustworthy by default)
There is a concept called a 'trust anchor' and for TLS there is a big public key signing event to ensure the trusted CA Certificate (that creates the Root CA Certificates for CAs in the root trust store of devices) is 'trustworthy'.
Your CA is not a trust anchor, and you created it so there is no way for users to know it was created properly, securely, and you will not use it for malicious purposes against them.
This trust anchor for TLS that creates Root CA Certificates is an authority due to the public key signing. So when the trust anchor 'authority' generates 'root CA' Certificates, they are trusted by extension.
Scenario 1)
The Root CA organisations are creating Certificates for all sorts of purposes, they can create you a Certificate intended to create other Certificates (the one you get is a CA Certificate also). If you have a CA Certificate it is part of the TLS ecosystem and inherits trust, so is a perfect choice for the scenario I derived from your question because you can have it's issuer in a Root Trust store (it is a Root CA Certificate that created your CA Certificate) and use your shiny new Certificate to create 'leaf' certificates that you use for servers TLS.
Because the Root CA Certificates end up on all our devices we are trusting that people who attended the public key signing event ensured that our trust anchor is trustworthy. When you have a CA Certificate that you want others to trust and it is not created by a Root CA you have to force it to be trusted by getting it on devices (which as you have learned is not going to work for iOS but many other platforms it will still be hard to do but possible). Or you can install your CA Certificate created by the Root CA for you on your server and deliver it to the clients at the same time as the leaf certificate used by the server (most web servers can send a full Certificate chain), you do not need to get end devices to be forced to trust your CA Certificate (like you do when you self-sign) because it was created by a Root CA already in the trust store of the device!
The most convenient way to do this is find a cloud service (like AWS) that offer a private CA service (AWS ACM Private CA service). The AWS Root CA will be creating your ACM CA Certificate for you, which will then create leaf certificates for your servers.
Scenario 2)
If you're asking about a client Certificate being trusted, which is an entirely separate concept, this involved getting the CA Certificate (that signed the client Certificate), get that CA Certificate on the server, not the iOS device client Trust Store.
A client Certificate is presented to the server by the iOS application, so you have to have the Application use your certificate, not iOS itself. The App is the client, and the client Certificate has no reason to be 'trusted' on the iOS device once it is installed with the App.
The server validates the client Certificate is trust worthy, therefore the server has a trust store and expects the CA Certificate (that signed the client Certificate) it expect that CA Certificate to be in it's trust store. So if you control the server you can install the CA Certificate you used to sign the client Certificate, you can install that on the server's Trust Store. Some servers simply skip verifying client Certificate trust and just match the presented client Certificate serial number against a list of expected client Certificate serials they trust (not best practice, but the most common practice)
The only overlap between scenario 1 & 2 is the moment your client presents a server with the client certificate, that is the moment it seems you're describing but it seems you're not entirely sure where Certificates are installed or verified.
I consider this answer to help reader better understand the 2 options, if you have further questions about either scenario please consider asking a new question and leave this question (and accept this answer) for clarity of other readers.
