Your question revolves around preventing HTTPS attacks in the middle (MITM) against iOS apps. Using Fiddler or other HTTPS proxies is a form of naive MITM attack, which unfortunately often works.
HTTP is built on top of a secure transport protocol called TLS (and before that, SSL). The connection is encrypted using public and private keys between trusted parties. And this is what things tend to go wrong. The concept of trust is central to the security of TLS and SSL in front of it. The server your application connects to provides cryptographic credentials that must be evaluated to establish trust.
Think of it like a passport or a driver’s license. In most cases, the license is checked. Then you will get one named McLovin. If you don’t really look at the name, date of birth, number, photograph, hologram, etc., you can simply blindly believe that Maklovin is who they say. And then you have a problem.
Do not trust McLovin.
Most applications trust McLovin :(
To protect your application from these types of attacks, you must implement a more rigorous set of critical and trust ratings. Apple has a technical note, Technote 2232: HTTPS Trust Evaluation , which details this.
A good start is to implement SSL Pinning . The attachment checks the credentials of the remote host at a known value - all or part of this certificate. The iOS application has some copy of this certificate, and when connected to this host, it checks the credentials provided by the host for this "known good" certificate. Some applications simply verify meta information, others try to verify the certificate (AFNetworking does this), while others perform a full trust check using a well-known good certificate against credentials. Apple describes this process in detail at the WWDC 2014 Enterprise and Education Application Development Session. If the remote host does not use the expected credentials, the connection is terminated. There is no traffic for the attacker interceptor. If your server certificate changes frequently, this may be a problem, which is one of several reasons why he prefers to check the server’s public key instead of meta information or a hash. Unfortunately, some server administrators often change public keys. Some people think this is safer. This is not true.
Now, obviously, this requires the iOS application to have a copy of the "good" certificate or some part of it. You can include the certificate in your application or implement your own key exchange method. Secure key exchange has long been a subject of cryptographic research, and this is not something that should be taken lightly. Including a certificate in your application is the solution that most people use. You can decide whether it is important to protect this certificate from someone who could compromise or block the device. You have several different options for this. Obviously, you can include it as a resource and encrypt it. You can also include it directly in the application binary, which can be much more difficult for an attacker to access. This can be done using the xxd tool with Xcode , as the build phase of the script, or typically the build. Obviously, you can implement additional protection.
If the device was compromised or the application was tampered with, the “known good” credentials may have been changed. This is where the iOS application sandbox can work to your advantage. You can discover many of these scenarios to check checks for your application . Assuming your app is distributed through an Apple channel, such as the iOS App Store, when it is installed, it includes a receipt. This can be verified and can be used to implement protection against unauthorized access for many common scenarios.
These are all methods that can be implemented in the client to protect communication via HTTPS from MITM attacks. The server can also expose the client in different ways, and the server should be regularly checked for vulnerabilities. Use only known strong cryptographic algorithms, do not forget about current publicly available vulnerabilities, etc.
Of course, if your application is something that can connect to random HTTPS services that you do not control, like a web browser, your options are more limited. In such cases, the best thing you can do when the credentials of the remote host are in doubt is giving the user the ability to trust or not trust the credentials. In iOS there is no user interface for this provided by system frames, this will be what your application would have to implement.
This is just one small aspect of the iOS app’s support, but your question was specific to humans in medium attacks.