DEV Community: Anh Vu

How to Capture HTTPS Traffic on iPhone (On-Device, No Desktop Proxy)

Anh Vu — Fri, 19 Jun 2026 16:14:14 +0000

If you build or test mobile apps, you have almost certainly hit this wall: your app calls an API, something breaks, and you have no idea what actually went over the wire. To debug it properly, you need to capture and inspect the HTTPS traffic your iPhone is sending and receiving.

Traditionally that meant tethering your phone to a computer, running a desktop proxy, and fiddling with certificates and Wi-Fi proxy settings. This guide shows a faster, mobile-first approach: capturing decrypted HTTPS traffic directly on the iPhone itself — no Mac, no jailbreak, and no desktop proxy.

Why HTTPS Traffic Inspection Matters

Nearly all modern app traffic is encrypted with TLS — great for security, inconvenient for debugging. Being able to decrypt and inspect it on demand unlocks problems you would otherwise be guessing at:

API debugging. See the exact request URL, method, headers, query parameters, and body, plus the raw response.
Authentication issues. Verify bearer tokens, cookies, and API keys are present, correctly formatted, and not expired.
Backend troubleshooting. Confirm whether a failure is a 4xx/5xx response, an unexpected payload, or a timeout.
QA testing. Reproduce edge cases by mocking responses or rewriting payloads.
Network analysis. Audit which third-party SDKs are phoning home, how often, and with what data.

The Mobile-First Approach

Moni Proxy runs the proxy on the iPhone itself, using iOS's native VPN and certificate APIs to capture, decrypt, and render traffic locally. Everything happens on-device and the traffic never leaves your phone.

No desktop required. No Mac running a proxy, no same-network requirement.
No jailbreak. Supported system VPN profiles and a local certificate authority.
Less setup. Install, run the certificate wizard once, and start capturing.
Inspect anywhere. Debug on a real device on cellular, on the train, or in the field.

Step-by-Step Tutorial

1. Install Moni Proxy

Download Moni Proxy from the App Store and open it. A one-time wizard installs a local certificate authority (CA) on your device — generated locally, never shared.

Install the profile in Settings → General → VPN & Device Management, then enable full trust in Settings → General → About → Certificate Trust Settings. You only do this once.

2. Start a Capture Session

Tap Start. Moni Proxy spins up a local proxy and routes your device traffic through it using a system VPN profile.

3. Generate Traffic

Switch to the app you want to debug and use it normally — log in, refresh, submit a form. Each network call is intercepted in real time. Works for any stack (URLSession, Alamofire, a Flutter HTTP client, or a React Native fetch).

4. Inspect Requests

Tap any entry to see the full URL, method, status code, headers, query parameters, and request body — syntax-highlighted for JSON. Most API bugs reveal themselves here: a missing Authorization header, a wrong content type, or a malformed payload.

5. Inspect Responses

Switch to the response tab for the status line, response headers, timing, and the decrypted response body. Pretty-printed JSON makes it easy to confirm whether the bug is on the backend.

6. Debug APIs

Beyond read-only inspection, you can mock a response, rewrite headers or body fields on the fly, or replay a captured request after editing it — reproduce an error state, test a 500, or simulate an empty list, all without touching the backend.

Common Issues

Bodies are unreadable. The certificate is installed but not trusted. Go to Settings → General → About → Certificate Trust Settings and toggle full trust on.
A specific app's traffic is missing. Some apps use certificate pinning, which rejects any certificate other than the developer's. That's a security feature, not a bug.
Nothing is captured. Confirm the capture session is running and the VPN profile is enabled (iOS shows a small VPN indicator in the status bar).

Conclusion

A mobile-first workflow removes the desktop proxy, the Wi-Fi configuration, and the same-network requirement — leaving a fast loop of capture, inspect, and mock that works wherever your bug actually happens.

Moni Proxy is free to try on iPhone, Android & macOS → moniproxy.com

Why Mobile API Bugs Take Days to Reproduce

Anh Vu — Fri, 19 Jun 2026 00:41:24 +0000

QA has screenshots.

Frontend can't reproduce.

Backend can't find the request.

A 5-minute bug turns into a 3-hour investigation.

After dealing with this problem repeatedly, I built a tool to capture and export HTTPS traffic directly from mobile devices.

Along the way I learned that most debugging delays aren't caused by bugs.

They're caused by missing context.

https://moniproxy.com/blog/why-mobile-bugs-take-days-to-reproduce

Why Mobile API Bugs Take Days to Reproduce

Anh Vu — Fri, 19 Jun 2026 00:41:24 +0000

QA has screenshots.

Frontend can't reproduce.

Backend can't find the request.

A 5-minute bug turns into a 3-hour investigation.

After dealing with this problem repeatedly, I built a tool to capture and export HTTPS traffic directly from mobile devices.

Along the way I learned that most debugging delays aren't caused by bugs.

They're caused by missing context.

https://moniproxy.com/blog/why-mobile-bugs-take-days-to-reproduce

Why Mobile Bugs Take Days to Reproduce (And How We Fixed It)

Anh Vu — Thu, 18 Jun 2026 14:43:06 +0000

One thing surprised me after years of building mobile apps.

The bugs that consumed the most engineering time were rarely the most difficult bugs.

The fixes were often simple.
The investigation was the expensive part.

A Typical Conversation

QA:
"Login is failing for some users."

Frontend:
"I can't reproduce it."

Backend:
"I don't see anything unusual in the logs."

QA sends screenshots.
Frontend asks for more details.
Backend asks for request payloads.
Someone records a video.
Someone else tries to reproduce the issue.

Hours pass.
Sometimes days.

Eventually, the root cause turns out to be something trivial:

An expired token
A missing header
A malformed request body
A backend validation rule

The fix takes five minutes.
The investigation took two days.

The Real Problem Isn't The Bug

The real problem is visibility.

When an issue happens on a mobile device, every team sees only part of the picture.

QA sees the error
Frontend sees the code
Backend sees server logs

Nobody sees the complete request and response that caused the problem.

As a result, teams spend most of their time collecting evidence instead of fixing the issue.

Screenshots Aren't Enough

For years our workflow looked like this:

Screenshot from QA
Screen recording
Console logs
Slack messages
Guessing

The problem is that screenshots don't contain enough information.

A screenshot cannot tell you:

Which headers were sent
Which payload was submitted
Which response was returned
Whether authentication failed
Whether the request even reached the server

Yet these are exactly the details engineers need.

What Changed Everything

The biggest improvement came when we started sharing traffic logs instead of screenshots.

Instead of saying:

Login failed.

QA could share:

Request URL
Headers
Request Body
Response Body
HTTP Status Code

Now frontend and backend engineers were looking at the same evidence.

✅ No guessing
✅ No interpretation
✅ Just facts

Suddenly issues became much easier to reproduce.

The Impact

The result wasn't fewer bugs.

The result was faster investigations.

Instead of spending hours asking questions, teams could immediately focus on solving the actual problem.

What surprised me most was how often communication, not code, was the bottleneck.

The technical fix was usually straightforward.
Getting everyone aligned on what actually happened was the difficult part.

What We Changed

After running into this workflow repeatedly, our team started capturing and sharing traffic logs directly from mobile devices.

The goal wasn't better debugging tools.

The goal was reducing the time it took QA, frontend engineers and backend engineers to understand the same issue.

Once everyone could see the exact request and response, investigations became dramatically faster.

The feature was traffic inspection.
The outcome was better collaboration.

Final Thoughts

Many engineering teams spend far more time investigating bugs than fixing them.

If your bug reports still rely on screenshots, screen recordings and Slack threads, there may be an easier way.

The most valuable debugging information is often the request and response that triggered the issue.

Everything else is just context.

How does your team currently handle API-related bug investigations?

Do you rely on screenshots, logs, traffic captures, or something else?

canonical_url: https://moniproxy.com/blog/why-mobile-bugs-take-days-to-reproduce

How to Capture HTTPS Traffic on iPhone Without a Mac

Anh Vu — Wed, 17 Jun 2026 16:59:19 +0000

As a mobile developer, I spend a lot of time debugging API requests.

Most of the time, the workflow looks something like this:

Open Charles Proxy or Proxyman on a Mac
Configure proxy settings
Install certificates
Connect devices to the same network
Start inspecting traffic

These tools are excellent and have become essential parts of many developers’ workflows.

But recently I found myself in a situation where I only had my iPhone with me.

No MacBook.

No desktop setup.

I simply wanted to inspect HTTPS traffic from a mobile app.

That raised a simple question:

Why is mobile network debugging still so dependent on desktop tools?

⸻

The Problem

Modern mobile applications communicate with dozens of APIs.

When something goes wrong, developers often need to inspect:

Request headers
Authentication tokens
Request payloads
Response bodies
HTTP status codes

For years, desktop proxy tools have been the standard solution.

The problem is that they assume you always have access to a computer.

For quick testing, QA validation, or debugging on the go, that assumption doesn’t always hold true.

⸻

Existing Solutions

Today, many developers rely on tools such as:

Charles Proxy
Proxyman
HTTP Toolkit

They’re powerful and battle-tested.

However, they are primarily designed around a desktop-first workflow.

I started wondering what a mobile-first debugging experience would look like.

⸻

Building a Mobile-First Workflow

That curiosity eventually led me to build Moni Proxy.

The goal wasn’t to replace existing tools.

The goal was simply to make network debugging easier when working directly from mobile devices.

The core requirements were straightforward:

✅ Capture HTTPS traffic

✅ Inspect requests and responses

✅ Remote debugging support

✅ Minimal setup

✅ Native mobile experience

The ideal workflow became:

Open Moni Proxy
Start a session
Connect a device
Inspect traffic in real time

No desktop required.

⸻

A Typical Debugging Scenario

Imagine you’re testing a mobile application and an API call suddenly fails.

Without traffic inspection, you’re often guessing:

Was the request sent?
Did the token expire?
Did the backend return an error?
Was the payload malformed?

Being able to inspect raw requests and responses immediately answers those questions.

For mobile developers and QA engineers, this can save a surprising amount of time.

⸻

Lessons Learned

Building developer tools is interesting because developers already have good solutions.

The challenge isn’t creating another tool.

The challenge is improving a specific workflow.

In my case, I focused on one question:

How can network debugging feel native on mobile devices instead of being an extension of desktop software?

The answer is still evolving, but the journey has been incredibly rewarding.

⸻

Looking for Feedback

Moni Proxy is now available on iOS and macOS.

I’m actively looking for feedback from:

iOS Developers
Android Developers
Flutter Developers
React Native Developers
QA Engineers

What does your current network debugging workflow look like?

If you regularly inspect HTTPS traffic, what is the biggest pain point in your setup today?

Website:

https://moniproxy.com

I’d love to hear your thoughts.