Key takeaways
- A proxy between the device and the network is the only reliable way to see native app traffic.
- You must install and trust the proxy certificate on the device or HTTPS calls stay opaque.
- Certificate pinning defeats this deliberately, so expect some apps to refuse to connect.
Why would I want to investigate the traffic that is made from a native iOS application ?
There are several reasons for which you would like to be able to see which are the requests a native application is making to the server side:
– to debug an issue that is happening in the application when you don’t have access to the server logs
– to check how the application is built in terms of the APIs that they are calling
– to check the security of an application
– to retry and make the same requests manually or automatically from an automation framework, or to replay them as a load test: Charles can save a session as a HAR file, which the HAR to k6 converter turns into a k6 script
– more details on how to debug native and HTML5 apps
How can I debug the traffic coming from a native application ?
The answer is very simple. All you need for being able to inspect the traffic is:
– have access to a WiFi network where both a laptop and the device that has the application are connected
– install an application called “Charles Web Debugging Proxy”
How to configure the iPhone device so that the traffic appears in Charles ?
There are a few steps that you need to do to get to the point where you can see the traffic in Charles.
1. First find the IP address of the laptop where you installed Charles. You can find that pretty easily by using the
following commands from the terminal:
"ifconfig" for Linux/MacOS
"ipconfig" for Windows2. On the iPhone, go to Settings -> Wi-Fi and tap the (i) icon next to the network you are connected to. The screenshots in this post are from iOS 10 in 2017; the menus have moved a little since, but the steps are the same.
3. Scroll down to the HTTP Proxy section (Configure Proxy on current iOS versions), choose Manual, enter the IP of the laptop as the Server and 8888 as the Port, and leave Authentication off.
4. Now open an application on your iPhone.
5. You should see a prompt in Charles when you first make a connection from the iPhone, asking you to allow the traffic.
6. Now you will be able to see the traffic that is coming from your iPhone in Charles.
7. Remember to disable the HTTP Proxy in your Settings when you stop using Charles, otherwise you’ll get random network failures in your applications!
How can I see what is sent in the request that are made over https ?
For being able to see the content of the requests made over Https you need to follow the below steps:
1. On your iPhone, after you have set up Charles as proxy, open Safari and browse to https://www.charlesproxy.com/getssl. Safari will prompt you to install the SSL certificate.
2. Install the downloaded profile in Settings, then turn on full trust for it: go to Settings > General > About > Certificate Trust Settings and, under “Enable full trust for root certificates”, switch on the Charles certificate. Since iOS 10.3 an installed certificate is not trusted for SSL until you do this (support.apple.com, November 2026), so without this step Charles cannot decrypt anything.
3. Now you should be able to access SSL websites with Charles using SSL Proxying.
4. Go into Charles at Proxy -> SSL Proxying Settings and add the host of the call that you want to see the content for, with port 443. Use an app you build or test yourself: in 2017 this worked with Instagram (host i.instagram.com, as in the screenshots), but apps that pin their certificates, as many large consumer apps now do, reject the Charles certificate and stop connecting.
5. Now go back to the iPhone and open the application again.
Now the traffic that is coming from the application will be shown as decrypted in Charles.
Hope this will help you debug your native applications more easily.
Frequently Asked Questions
Why inspect a native app’s traffic at all?
To debug behaviour you cannot see from the server side, to learn which APIs the app calls, to check how it handles security, and to replay a request yourself.
What do I need to see HTTPS calls?
A proxy between the device and the network, plus its certificate installed and trusted on the device. Without that trust step the traffic stays encrypted and you see nothing useful.
Why do some apps refuse to work through the proxy?
Certificate pinning, which is doing its job. The app only accepts its own certificate, so an intercepting proxy is rejected by design and that app cannot be inspected this way.
