DEV Community: DataStack

iOS App Development Requires More Than Just Tech Stack: Enhancing Toolchain for Efficiency

DataStack — Sat, 27 Jun 2026 09:06:12 +0000

Many people, when organizing essential elements for iOS App development, list a long series of technologies: Swift, network requests, databases, cloud services, testing frameworks... These are all valid, but in actual development, it's easy to overlook one thing—these technologies ultimately need to be integrated into an executable development workflow.

In other words, technologies are scattered, but development is continuous.

If you push an App from an idea to running on a phone, it goes through several very specific stages. Rather than looking at each technology individually, it's better to follow the development process and connect these capabilities in sequence.

Interface and Interaction: Where Code is Written and How to Quickly Validate

UI is the first part where results can be seen.

For example, whether writing native interfaces with Swift or building cross-platform UI with Flutter, developers face the same question: After making changes, how long does it take to see the effects?

If every UI adjustment requires a full build and run, the pace will noticeably slow down.

Some tools optimize the "feedback path" here. For instance, supporting fast compilation and direct deployment to devices allows interface changes to be validated more quickly.

In an IDE like Kuai Xie, code modifications can directly trigger builds and installation to the phone, making UI debugging more seamless.

Programming Language: Not Just Syntax, but Also Tool Support

iOS native development primarily uses Swift, and Objective-C projects may also be encountered.

If the project involves cross-platform development, Dart (Flutter) or JavaScript (React Native) might be used.

The languages themselves aren't complex; what truly impacts development efficiency is: Whether the tools support the project structures and build methods corresponding to these languages.

In some development environments, different languages mean different tools; whereas in IDEs that support multiple project types, different tech stacks can be handled in the same environment.

Kuai Xie supports Swift, Objective-C, and Flutter projects in this regard, reducing interruptions caused by environment switching.

IDE: The Core Tool That Determines Development Pace

IDE is the convergence point for all technologies.

Common choices include:

Xcode: Comprehensive but heavy
VSCode: Lightweight but requires additional configuration
Other IDEs: Each has its own focus

IDE is not just an editor; it also determines:

How projects are organized
How compilation is triggered
How debugging is conducted

Some new tools attempt to combine "editing experience" and "build capabilities." For example, based on the VSCode architecture while embedding compilation tools.

Kuai Xie follows this approach: editing experience similar to VSCode, while providing full iOS build capabilities.

Version Control: The Foundation of Collaboration Beyond Code

Git is almost standard in iOS development.

Whether for personal projects or team collaboration, it involves:

Code version management
Branch merging
History backtracking

This part isn't closely related to specific IDEs, but whether an IDE supports good Git integration affects the smoothness of daily operations.

Data Storage: Coordination Between Local and Remote

Apps need to handle data during runtime, typically divided into two categories:

Local storage (e.g., SQLite, Realm)
Cloud data (e.g., Firebase, backend APIs)

During development, changes in data structures often require repeated validation.

If the debugging workflow is smooth, data read/write correctness can be confirmed more quickly. For example, after modifying data models, rerunning the app and directly viewing effects on the device.

Network Requests and Data Processing: One of the Most Frequently Debugged Parts

Communication between the App and servers is common.

Developers need to handle:

HTTP requests
Data parsing (JSON / XML)
Exception handling

The characteristic of this part is "frequent validation required."

If every modification to request logic takes a long time to see results, it will significantly impact development efficiency.

Therefore, the convenience of debugging tools directly affects the experience in this stage.

Backend and Cloud Services: Reducing Self-Built Complexity

In some projects, cloud services are used to handle:

Data storage
User management
File uploads

For example, AWS, Google Cloud, Firebase, etc.

This is more about architectural choices, but during the development phase, interfaces and data need to be continuously validated through the App.

Security and Authentication: A Must-Complete Step After Features

User authentication, data security, and other issues are generally added gradually after features are completed.

For example:

OAuth login
Token validation
Data encryption

These functionalities need to be tested in real environments, thus still relying on complete running and debugging workflows.

Testing and Debugging: Exposing Issues

Testing isn't just about writing test code; it also includes:

Manual debugging
Log viewing
Behavior validation

In iOS development, these operations often depend on device runtime environments.

If the debugging process can be completed within one tool, it reduces distractions from switching back and forth.

Build and Release: The Endpoint of the Development Workflow

When features are completed, installation packages need to be generated.

This stage involves:

Building release versions
Generating installation files
Distributing to testers or submitting for review

Some tools make the build process simpler, such as providing one-click build capabilities, making the transition between development and release smoother.

Kuai Xie also offers application build functionality in this regard, allowing direct generation of installation packages.

For the question of essential elements for iOS App development, if you only look at the technology list, it appears fragmented.

From another perspective, starting from the development workflow makes it easier to understand the role of each capability.

2026 iOS Certificate Management: Say Goodbye to Keychain Dependencies and Build a Reproducible Signing Environment

DataStack — Mon, 15 Jun 2026 09:47:22 +0000

In some projects, certificate issues do not surface during early development but suddenly appear during team collaboration, switching computers, or integrating CI.

For example, new colleagues cannot build after pulling code, CI builds fail but work locally, or signatures become invalid after provisioning profile updates. The common point of these problems is that certificates are not managed but remain on a specific device.

This article explains how to make the iOS signing environment reproducible, migratable, and reusable.

First, Clarify That a Certificate Is Not a Single File

iOS signing involves three types of files:

Type	Purpose
`.cer`	Public key certificate
Private key	Generated locally
`.p12`	Certificate + private key

The key points are:

.cer cannot be used alone
.p12 is the complete, migratable format

If team members only share .cer, the result is:

The certificate exists
But signing is impossible

Avoid Each Person Generating Certificates Individually; Instead, Generate and Distribute Uniformly

Follow these steps:

Step 1: Generate a Certificate (Once)

Create the certificate in a tool, not manually in the keychain.

Using AppUploader (Happy Upload):

Open certificate management
Click Add
Select type (development or distribution)
Enter certificate name
Set P12 password
Generate and download .p12

The result of this step is:

A complete P12 file
No dependency on a specific Mac

Step 2: Save the Certificate

Store .p12 in:

Private Git repository (encrypted)
CI Secret
Internal file service

Step 3: Use Uniformly

Import in various environments:

macOS → Keychain
CI → Script import

Synchronization Method for Provisioning Profiles

Certificates are only part of signing; provisioning profiles are also needed.

Provisioning profile binding:

Bundle ID
Certificate

Generation process:

Open AppUploader
Go to provisioning profile management
Create new provisioning profile
Select type (App Store / Development)
Bind Bundle ID
Select certificate
Download .mobileprovision

Save the provisioning profile together with .p12.

Load Certificates in CI

When integrating CI into a project, the build environment needs to load certificates.

Example (Fastlane):

import_certificate(
  certificate_path: "cert.p12",
  certificate_password: "password"
)

Provisioning profiles can be handled via:

mkdir -p ~/Library/MobileDevice/Provisioning\ Profiles
cp profile.mobileprovision ~/Library/MobileDevice/Provisioning\ Profiles/

This allows CI to complete signing directly.

A Detail to Avoid Certificate Invalidation

Certificates themselves have an expiration date (usually one year).

But in a team, what truly matters is:

Whether provisioning profiles use old certificates

After updating a certificate, you need to:

Regenerate provisioning profiles
Replace files in CI
Rebuild

If you only update the certificate without updating provisioning profiles, signing will fail.

Handling in Cross-Platform Development

In Windows or Linux environments:

Keychain cannot be used
But .p12 can be used directly

For example:

HBuilderX packaging
CI builds
Command-line uploads

Certificates exist only as files, without dependency on system tools.

How to Determine If the Current Certificate Is Usable

You can verify via:

Method 1: Xcode

Check if the certificate includes a private key

Method 2: Command Line

security find-identity -v -p codesigning

Method 3: Build Verification

Whether IPA can be successfully exported

The complexity of certificate issues is not in the creation steps but in how they are saved and used. If certificates are uniformly managed in .p12 format, many problems will be reduced.

Reference link: https://www.appuploader.net/blog/237

Can You Do iOS Development Without a Mac? Cross-Device Development Workflow

DataStack — Thu, 11 Jun 2026 09:47:00 +0000

In the field of iOS development, needing a Mac is almost a default prerequisite. Project creation, code compilation, and device debugging all revolve around macOS and Xcode. However, in some practical scenarios, such as temporarily taking over a project or verifying functionality on non-Mac devices, this prerequisite can become a limitation.

Recently, while helping a friend with a small project, I tried a different approach: completing the writing and running of an iOS application without using the traditional Mac development environment.

The project wasn't complex, but the workflow was complete, making it suitable for verifying the feasibility of this development method.

Creating an iOS Project in a Non-Traditional Environment

After opening the Kuai Xie IDE, you can directly access the project creation interface. The interface offers several project types:

Swift
Objective-C
Flutter

Select a Swift project, enter a name, and click create; the IDE will generate the project directory.

The project structure already includes basic code files and resource directories. Opening the entry file allows you to start writing code without additional initialization steps.

At this stage, no environment-related issues were encountered. The IDE has prepared the necessary tools for compilation, so after project creation, you can directly proceed to the development phase.

Writing a Simple Feature to Validate the Project

To test the development workflow, I wrote a simple page:

A button
A text area

Upon clicking the button, local data is read and the result is displayed on the interface.

During code editing, the IDE provides auto-completion and syntax hints. When entering class names or methods, a list of options pops up. After saving the file, the IDE checks the code structure and marks error locations.

The editing experience is similar to common code editors, with relatively complete keyboard operations and plugin support.

Connecting an iPhone and Executing the Application Build

After writing the code, it needs to be run on a real device.

Connect the iPhone to the computer, and the IDE starts the build process.

The build process involves:

Compiling the source code
Building the application
Installing it on the phone

After the build completes, the app icon appears on the phone's home screen. Clicking to open the app shows the interface displaying normally.

Clicking the button successfully updates the text area with the read data, indicating the code executed correctly.

Modifying Code and Running Again

During development, code adjustments are constantly needed.

I added some processing logic to the button click, then saved the file and clicked the run button again. The IDE recompiles the application and installs the new version.

Opening the phone app shows the updated effect.

The entire process remains consistent:

Modify code → Click run → Compile application → Install on device → View results

No additional export or manual installation steps were required.

Implementation of Compilation Capabilities

In this workflow, Xcode on a Mac is not used.

The Kuai Xie IDE has a built-in set of compilation tools. These tools are configured during IDE installation. When clicking run or build, the IDE calls internal tools to complete code compilation and application building.

Developers in this environment can directly write iOS applications and complete compilation and execution.

For scenarios requiring code verification in non-Mac environments, this method provides a feasible path.

Development Testing Across Multiple Project Types

To further validate the IDE's capabilities, I created a Flutter project.

After writing the Flutter page, connecting the device and clicking run allows the IDE to complete compilation and install the application.

Subsequently, an Objective-C project was tested and also ran normally.

In the same development environment, it can handle:

Swift projects
Objective-C projects
Flutter projects

This is convenient for cross-project development needs.

Building Installation Packages for Distribution

After application development is complete, an installation package needs to be generated.

In the Kuai Xie IDE, you can generate application installation files through the build function. The IDE executes compilation and outputs the installation package.

Build logs are displayed in the output panel; if compilation issues arise, detailed information can be viewed.

The generated installation files can be used for testing or distribution.

For developers, this method can be used in specific scenarios, such as temporary development, feature verification, or when environments are limited.
Reference link: https://www.kxapp.com/blog/15

What are the iOS Developer Tools? How to Use Xcode, AppUploader (Happy Upload), and Fastlane

DataStack — Sat, 06 Jun 2026 09:52:59 +0000

When discussing iOS developer tools, many people immediately think of Xcode. However, in a project, development, signing, packaging, and publishing can be accomplished by a variety of tools working together.

1. Code Development Phase: Xcode and Dependency Management Tools

iOS project development is typically done in Xcode.
After creating a project, the first thing to handle is often dependency libraries.

If the project relies on third-party libraries, you can use the following tools:

Swift Package Manager (SPM): Built-in dependency management in Xcode
CocoaPods: Suitable for projects already using the Pods ecosystem

For example, using CocoaPods:

pod init

After editing the Podfile, execute:

pod install

This generates an .xcworkspace file, and then open the project through this workspace.

Once this step is complete, development work is mostly done in Xcode, including:

UI development
API interface calls
Debugging and running

2. Creating an App Identifier (Bundle ID)

When the app is ready for the testing phase, you need to create an app identifier in Apple Developer.

Operation steps:

Log in to Apple Developer
Go to Identifiers
Click Add
Enter the Bundle ID

This ID will be used for:

Certificates
Provisioning profiles
App Store Connect app records

If the project's Bundle ID differs from the backend configuration, the build will not be recognized after upload.
You can also create it in AppUploader:

3. Generating Signing Certificates

iOS apps need to be signed for installation or publishing.

Certificate types include:

Development (for debugging)
Distribution (for App Store publishing)

Certificates can be generated via the Apple Developer website or managed with tools.

For example, using AppUploader (Happy Upload):

Open AppUploader
Log in with your Apple Developer account
Go to "Certificate Management"
Click Add Certificate
Select the certificate type (development or distribution)
Set the certificate name and P12 password

After completion, download the .p12 file.

This file can be imported into Xcode or a CI build environment.

4. Creating Provisioning Profiles

After generating certificates, you need to create a Provisioning Profile.

A provisioning profile includes:

Bundle ID
The certificate used
Device permissions (for development versions)

In AppUploader, you can perform the following operations:

Go to "Provisioning Profile Management"
Create a new provisioning profile
Select the type
- Development
- App Store
Select the Bundle ID
Bind the certificate

This generates a .mobileprovision file.

This file will be used during the packaging phase.

5. Building the IPA Installation Package

When app development is complete, you need to generate an IPA.

Building with Xcode

In Xcode, execute:

Select Any iOS Device
Click Archive
Wait for the build to complete
Export the IPA as App Store type

This generates a .ipa file.

Automated Building with Fastlane

If the project is integrated with CI, you can use Fastlane:

lane :build do
  build_app(
    scheme: "AppScheme",
    export_method: "app-store"
  )
end

Execute:

fastlane build

After the build completes, the IPA is generated.

6. Device Installation Testing

Before uploading, you can install the IPA on a real device for testing.

Installation methods include:

Xcode Devices
Apple Configurator
AppUploader installation testing

In AppUploader:

Open "Installation Testing"
Select the IPA file
Connect the device
Click Install

If the app launches normally, it indicates that the signing and provisioning profile configurations are correct.

7. Uploading the IPA to the App Store

After the IPA is built, it needs to be uploaded to App Store Connect.

Common upload methods include:

Xcode Organizer
Apple Transporter
Fastlane deliver
AppUploader upload tool

To upload the IPA in AppUploader:

Open "Submit Upload"
Enter your Apple account
Set the App-specific password
Select the IPA file
Click Upload

After a successful upload, you can see the new build version in App Store Connect.

iOS Developer Tools

Common tool usage:

Phase	Tool
Project Development	Xcode
Dependency Management	CocoaPods / SPM
Certificate Generation	AppUploader
Provisioning Profile Management	AppUploader
Automated Building	Fastlane
IPA Upload	AppUploader / Transporter
Review Submission	App Store Connect

iOS development is not just about writing code; it also involves signing, packaging, and publishing processes.

HTTPS Packet Capture Process: Proxy Capture, Direct Device Connection via Cable, and TCP Data Analysis

DataStack — Tue, 14 Apr 2026 08:41:03 +0000

In interface debugging, you may encounter the following issue:

The login interface in the app returns an exception
The server logs show no obvious errors
The client logs are incomplete, making it difficult to identify the problem

In such cases, one approach is to capture HTTPS requests to inspect the data.

However, another problem often arises:

HTTPS from browsers can be captured normally
HTTPS requests from the app fail directly

The issue lies in whether the packet capture direction is correct.

1. First, Use Proxy Capture to Verify the HTTPS Environment

The first step is to use a proxy capture tool, such as:

Charles
Proxyman
SniffMaster

The goal is to confirm whether HTTPS can be decrypted.

Set Up the Proxy Environment

Steps:

Start SniffMaster
Check the listening port, e.g., 8888
Connect the iPhone and computer to the same Wi-Fi network
Configure the proxy address and port in the iPhone's Wi-Fi settings

After saving, return to the home screen.

Install the HTTPS Certificate

On the iPhone, perform the following steps:

Use Safari to open the certificate address provided by the proxy tool
Download the profile file
Install the certificate
Enable certificate trust in the system settings

Once completed, the proxy tool can decrypt HTTPS.

Verify Successful HTTPS Capture

Open Safari and visit an HTTPS website.

If SniffMaster displays:

Request URL
Headers
Response content

It indicates that the HTTPS capture environment is established.

2. Capture App HTTPS Requests

In the same proxy environment, open the target app.

Trigger login or data loading operations.

Observe SniffMaster:

If request records appear → you can view the complete HTTPS data
If no requests are recorded → further troubleshooting is needed

3. Common Symptoms of HTTPS Capture Failure

In this case, the following occurred:

Safari requests could be captured
App requests had no records at all

This indicates:

The proxy is functioning normally
The app's network requests are not using the system proxy

4. Switch HTTPS Capture Modes

When the proxy cannot capture HTTPS requests, switch to a different capture method.

Here, use SniffMaster's HTTPS brute-force capture.

This method does not rely on proxy certificates.

Use SniffMaster to Capture HTTPS

Steps:

Connect the iPhone to the computer via USB
Keep the device unlocked
Tap "Trust This Computer" on the phone
Start SniffMaster
Select the iPhone from the device list
Follow prompts to install iOS drivers
Install the profile file
Enter HTTPS Brute-Force Capture Mode
Click Start

Then trigger app requests on the phone.

Observe Capture Results

In SniffMaster, you can see:

Request domain
Request path
Request headers
Response data

Even if the app does not use the proxy, HTTPS requests are still visible.

5. When HTTPS Data Is Incomplete

During capture, you might encounter:

URL visible
Headers visible
Request body empty

This indicates:

HTTPS has been captured
But the app is not signed with a development certificate

Solution:

Obtain the app's IPA file
Re-sign it using an iOS development certificate
Reinstall the app
Capture again

After completion, the request body and response body will display normally.

6. Aspects of HTTPS Capture Unrelated to Ports

During capture, you may observe:

api.example.com:443
api.example.com:8443

Whether it's port 443 or a custom port:

As long as the TLS handshake succeeds
The capture tool can parse HTTPS

Ports do not affect decryption capability.

7. Limitations of Modifying HTTPS Requests

If you need to modify request parameters, such as:

Rewriting interface data
Simulating different return results

You must use a proxy capture tool.

In Charles or Proxyman, you can:

Use Rewrite
Use Breakpoints

SniffMaster also supports interceptors, but only available in HTTPS proxy mode.

Device-level capture modes do not modify data.

8. Analyze HTTPS Issues with TCP Layer Analysis

If HTTPS requests experience:

Timeouts
Connection drops

You can export the data to Wireshark.

In Wireshark, you can view:

TCP connection establishment process
Data retransmissions
Reasons for connection closure

This layer does not involve certificate issues.

In practical debugging, follow this sequence:

Use proxy capture to verify HTTPS
If the proxy cannot capture app requests, switch to device-level capture
If data is incomplete, handle signature issues
If connection issues are involved, analyze TCP data

Reference link: https://www.sniffmaster.net/tutorial/zh/1/1.html

Viewing iPhone Hardware Component Energy Consumption History and Energy Usage

DataStack — Fri, 20 Mar 2026 11:10:49 +0000

In mobile app development, rapid battery drain is a challenging issue to troubleshoot.
Testers often provide vague descriptions, such as:

Significant drop in phone battery level
Device heating up after using a feature for a while
Abnormal power consumption during background operation

Without detailed device data, such problems are difficult to pinpoint. Battery level itself is just an outcome; the actual energy consumption comes from device hardware components like CPU, display, audio, network, etc.

This article introduces several methods to view iPhone hardware energy consumption and how to combine various tools for analysis in different scenarios.

Which Hardware Typically Causes iPhone Energy Issues

In iOS devices, power consumption mainly comes from several hardware components:

CPU
Screen (display)
Audio components (speaker, microphone)
Network module
Bluetooth and location services

When an app frequently uses these hardware components, energy consumption increases noticeably.

Therefore, when troubleshooting issues, it's more important to observe which hardware is consuming power rather than just checking battery percentage.

First Level: System Battery Statistics

The simplest method is to check system battery statistics.

Navigate to:

Settings → Battery

Here you can see:

Power consumption percentages for each app
Data from the last 24 hours and 10 days

This helps confirm:

Whether a specific app has abnormal power consumption.

However, system statistics only show app-level power consumption and cannot analyze specific hardware usage.

Second Level: Developer Tool Analysis

In a development environment, you can use Xcode Instruments.

Instruments' Energy Log can display:

CPU activity
GPU usage
Network activity

This method is suitable for development phases but has two limitations:

Requires connection to a Mac
Not convenient for long-term historical data observation

Therefore, during testing phases, many teams use device monitoring tools for supplementary analysis.

Using Keymob Assistant to View Hardware Energy Consumption History

In project testing, I typically use Keymob Assistant to view historical hardware usage on devices.

This feature allows direct viewing of energy consumption records for various hardware components and enables time-based analysis.

Preparation

Before viewing hardware energy consumption, you need to obtain device data.

Steps:

Connect iPhone using a data cable
Open Keymob Assistant
Wait for device recognition
Follow prompts to retrieve device usage records

Initial data setup is required on first use.

Viewing Hardware Energy Consumption Ranking

Navigation path:

Left navigation → Usage Records → Hardware Energy Consumption

In this interface, you can see energy consumption for various hardware components, such as:

CPU
Display
Bluetooth
Speaker
Microphone

Data is sorted by energy consumption.

This allows quick identification of which hardware consumes the most.

Viewing Detailed Hardware Usage

To further analyze a specific hardware component, click Details.

For example, select:

Audio Speaker

After entering, you can see:

Daily energy consumption bar chart
Usage patterns across different time periods

Clicking on a specific day shows energy consumption data for different time periods that day.

This helps analyze:

Whether abnormal usage occurred during a specific time period.

Practical Case

During a test, testers reported:

"Battery drains quickly during background operation."

Troubleshooting process:

First step: Check system battery statistics.

Found target app had high power consumption percentage.

Second step: Use Keymob Assistant to view hardware energy consumption ranking.

Found abnormal energy consumption in audio components.

Third step: View detailed audio records.

Found audio activity persisted during background periods.

Final confirmation of cause:

The app did not properly stop audio playback in the background.

After fixing and retesting, energy consumption returned to normal.

Multi-Tool Combination Process

In actual projects, I typically troubleshoot power consumption issues in this order:

Check system battery statistics
Use device tools to view hardware energy consumption
Analyze code logic with development tools

This approach allows gradual narrowing down of the problem scope.

Hardware Energy Consumption Records Are Valuable

Compared to instantaneous performance data, hardware energy consumption history has two advantages:

Can view usage over past days or even months
Can precisely pinpoint time periods when issues occurred

This enables correlation between user-reported time points and device behavior.

iPhone battery drain issues are typically related to specific hardware components rather than just battery problems. By combining system statistics, development tools, and device monitoring tools, you can progressively analyze how apps use hardware resources during operation.

Reference link: https://keymob.com/tutorial/zh/27/27.html

How to Perform Proxy Packet Capture and Data Flow Analysis on Mac

DataStack — Fri, 20 Mar 2026 10:11:27 +0000

When debugging networks on macOS, packet capture is usually the first step.
For example:

App fails to request an API
An API returns abnormal data
Need to confirm parameters sent by the client

For these issues, relying solely on code logs makes it difficult to judge network behavior; packet capture allows direct viewing of requests and responses.

Below, through a debugging process, several common methods for packet capture on Mac are introduced.

1. First, Capture Network Requests from the Mac Itself

If you need to view network requests from programs on the Mac itself, such as:

Browser accessing APIs
Desktop applications calling interfaces

The simplest method is to use proxy packet capture tools, such as:

Charles
Proxyman
SniffMaster

These tools run locally and intercept requests via proxy.

Configuring Proxy Packet Capture

Steps are as follows:

Start Charles or SniffMaster on Mac
Check the proxy listening port, e.g., 8888
Enable system proxy in macOS network settings
Set HTTP and HTTPS proxy to the local address
Save settings

Once done, local network requests will first pass through the proxy tool.

Installing HTTPS Certificates

If requests use HTTPS, you need to install proxy certificates.

Steps:

Access the certificate address provided by the proxy tool in a browser
Download the certificate
Install the certificate in macOS Keychain
Set the certificate to Always Trust

Once done, the proxy tool can decrypt HTTPS requests.

Verifying Successful Packet Capture

Open a browser and visit an HTTPS website.

If request records appear in the proxy tool and response content can be viewed, the packet capture environment is established.

2. Capturing iPhone Network Requests on Mac

If you need to debug network behavior of an iOS App, you can route iPhone traffic through the Mac.

The common method is still proxy packet capture.

Setting Up iPhone Proxy

Steps:

Connect iPhone and Mac to the same Wi-Fi
Open iPhone Settings → Wi-Fi
Tap the current network
Under HTTP Proxy, select Manual
Enter the Mac's IP address
Enter the proxy port (e.g., 8888) Save and return to the home screen.

Installing iOS HTTPS Certificates

In iPhone Safari, access the certificate address provided by the proxy tool:

Download the profile
Install the certificate
Enable certificate trust in iOS Settings

Once done, the proxy tool can decrypt iOS HTTPS requests.

Testing App Network Requests

Open the App and trigger network operations, such as:

Login
Loading a list
Submitting a form

In the proxy tool, you can see:

Request URL
Headers
Request body
Response content

3. When Proxy Fails to Capture App Requests

Sometimes, this situation occurs:

Safari requests can be captured
App requests have no records

This indicates the App is not using the system proxy.

In this case, further adjusting proxy settings won't change the outcome.

Device-level packet capture is needed.

4. Using Device-Level Packet Capture Tools on Mac

Device-level packet capture directly reads network data from the device side.

In this scenario, you can use SniffMaster.

Using SniffMaster to Capture iOS Traffic

Steps:

Connect iPhone to Mac via USB
Keep the device unlocked
Tap Trust This Computer on the phone
Launch SniffMaster
Select iPhone from the device list
Follow prompts to install the profile
Enter HTTPS Brute Force Capture Mode
Click Start

Then trigger network requests on the phone.

Corresponding HTTPS requests will appear in the capture interface.

Viewing Only a Specific App's Traffic

Device-level capture includes system network traffic, such as:

DNS requests
Apple service connections

To more easily locate target requests, you can:

Click Select App
Check the target application
Trigger network operations again

The capture list will only show that App's requests.

5. Analyzing TCP or UDP Network Issues

If debugging involves network connection issues, such as:

Request latency
Connection drops
Packet loss

Data flow packet capture can be used.

SniffMaster supports capturing:

TCP data streams
UDP data streams

After capture, data can be exported to Wireshark for analysis.

In Wireshark, you can view:

TCP three-way handshake
Data retransmissions
Connection closure reasons

6. Use Cases for Different Packet Capture Tools

In network packet capture, different tools serve different purposes:
| Tool | Capture Method | Main Use Case |
| ------------ | ---------------- | ---------------------- |
| Charles | Proxy Capture | HTTP / HTTPS Debugging |
| Proxyman | Proxy Capture | HTTPS Debugging |
| SniffMaster | Device-Level Capture | iOS Network Data |
| Wireshark | Network Layer Capture | TCP / UDP Analysis |

When debugging networks on Mac, you can follow this sequence:

Use proxy capture tools to view HTTP / HTTPS requests
If proxy fails to capture requests, use SniffMaster for device-level capture
If network connection analysis is needed, export data to Wireshark

This approach covers most packet capture scenarios.

Reference link: https://www.sniffmaster.net/

Complete Guide to H5 Mobile Debugging: Full Practice from Browser Simulation to Real-Device WebView Debugging

DataStack — Fri, 05 Dec 2025 10:19:29 +0000

In the world of frontend development, "perfect on desktop, broken on mobile" is a classic scenario almost every engineer has experienced.

A page works fine in Chrome, but on mobile:

Elements are misaligned, animations drop frames;
It works on iPhone but shows a white screen on Android;
Network requests hang, the console is silent.

The difficulty of H5 mobile debugging isn't that there are many bugs, but that the problems are invisible.

In this article, we'll systematically explain how to build an efficient, reproducible H5 mobile debugging system from a frontend practical perspective, covering browser simulation, real-device debugging, WebView analysis, network monitoring, and performance optimization.

1. Why is H5 Mobile Debugging More Complex Than Desktop?

The essence of debugging is "visually understanding system behavior," and on mobile, the biggest challenge is:

H5 pages run not in a browser, but in a WebView.

Dimension	Desktop Browser	Mobile WebView
Kernel	Unified (Chromium)	Varies by vendor (WebKit / Blink / X5 / UC)
Debug Interface	Fully open	Closed or restricted
Log Output	Visible in console	Invisible within container
Network Requests	Easy to monitor	Affected by proxies, SDKs
Performance	Stable hardware	Limited by device performance

Thus, the same page may behave completely differently across different phones, apps, and OS versions.

2. Desktop Simulation Debugging: The First Step in Initial Troubleshooting

1️⃣ Chrome DevTools: Essential Basics

Chrome's device simulation mode is the starting point for mobile debugging.

Key Features:

Simulate device dimensions and DPR;
Simulate touch events;
Switch network speeds (3G, Slow 4G);
Simulate user agent (UA).

Applicable Scenarios:

Responsive layout validation;
Media query breakpoint testing;
First-load and lazy-load logic checks.

Limitations:

Only visual simulation;
Cannot reflect actual WebView behavior.

Desktop simulation debugging = "pre-debugging phase," not the end goal.

2️⃣ Firefox / Edge Debugging

Firefox offers more intuitive visual debugging for CSS Grid and Flex layouts;
Edge inherits the Chromium ecosystem, providing a synchronized DevTools debugging experience.

Conclusion:

Chrome simulation + Firefox layout analysis is a classic combination.

3. Real-Device Remote Debugging: Entering the "Real Environment"

When issues occur on real devices, simulators are no help.
At this point, real-device remote debugging tools are needed.

1️⃣ iOS Platform: Safari Remote Debug

Setup Steps:

Open Mac's Safari → Preferences → Advanced → Check "Show Develop menu";
Connect iPhone to computer;
Open H5 page → Safari → "Develop" → Device → Page;
Real-time debugging is available.

Viewable Content:

DOM, CSS, JS debugging;
Network requests;
Console logs.

Limitations:

macOS only;
Supports only Safari / WKWebView.

2️⃣ Android Platform: Chrome Inspect

Operation Method:

Enable Android Developer Options → USB debugging;
Connect to computer → Enter in Chrome address bar:

   chrome://inspect/#devices

Click "Inspect" to open the remote debugging panel.

Advantages:

View page DOM, JS, network requests;
Synchronous debugging in real environment.

Disadvantages:

Only works with Chrome WebView;
Cannot detect custom kernels like WeChat, Alipay, UC.

4. WebView Scenarios: The Biggest "Blind Spot" in Mobile Debugging

Most mobile H5 pages don't run directly in a browser,
but are embedded in WebViews within various Apps.

Issues in these environments typically include:

White screen with no console output;
Requests intercepted by SDKs or proxies;
JS errors without accessible logs;
Inconsistent behavior between iOS and Android.

Traditional DevTools "can't see inside" in such scenarios.
Here, more specialized WebView debugging tools are needed.

5. WebDebugX: Making WebView Debugging "Visible"

WebDebugX is a cross-platform WebView remote debugging tool that can debug iOS and Android WebView pages on Windows / macOS / Linux.

Its goal is simple: make debugging H5 pages in Apps as seamless as in Chrome.

Core Features

Feature Module	Description
DOM Debugging	Real-time view / modify page structure and styles
JS Debugging	Supports breakpoints, variable inspection, stack traces
Network Monitoring	Packet capture, interception, replay, response simulation
Performance Analysis	View FPS, memory usage, CPU time
Log Capture	Collect console.log and error info in WebView
Multi-Platform Support	One tool for all platforms

Real Project Case

A WeChat-embedded H5 activity page randomly showed a white screen on Android phones.

Using WebDebugX, debugging revealed:

JS executed too early during WebView initialization;
Some scripts were blocked by CSP policies;
After adjusting load order, the issue disappeared completely.

Traditional DevTools couldn't see this information at all.

Integration with Other Tools

Tool	Role	Scenario
Chrome DevTools	Desktop simulation	Initial development
Charles / Fiddler	Network capture	Integration phase
vConsole / Eruda	Log output	WeChat-embedded pages
WebDebugX	Real-device WebView	Terminal testing & performance optimization

6. Performance Debugging: Making H5 Pages "Fast and Smooth"

Performance issues on mobile often hide in JS and the rendering layer.

Lighthouse (Desktop)

Analyze first-load, interaction delays;
Automatically generate performance scores and optimization suggestions.

WebDebugX Performance Module (Real Device)

View FPS curves, rendering block points;
Detect memory leaks and long tasks;
Identify bottlenecks in image, font resource loading.

Desktop performance ≠ real-device performance. WebDebugX makes performance optimization data more realistic.

7. Building a Complete Mobile Debugging System

A mature frontend team should integrate debugging into the engineering system, not treat it as "emergency firefighting."

Phase	Tool Combination	Goal
Development	Chrome DevTools + vConsole	Logic and style validation
Integration	Charles / Postman	Interface and network troubleshooting
Real Device	Safari / Chrome Inspect / WebDebugX	Mobile debugging
Performance	Lighthouse / WebDebugX	Load and render optimization

Treat debugging as a process, not a temporary action.

8. Debugging Mindset: Hypothesize First, Then Verify

Frontend debugging isn't "by feeling," but "hypothesis-driven verification."

Thought Process:
Reproduce issue →
Hypothesize cause →
Locate level (logic / network / WebView) →
Choose right tool to verify →
Quantify results and document.

The biggest benefit: even after a bug is fixed, you retain traceable debugging knowledge.

iOS Performance Tools Review: Comparison and recommended mixes of six common solutions (2025).

DataStack — Thu, 04 Dec 2025 03:37:09 +0000

In the era of mobile applications, competition has shifted from feature wars to performance wars. Whether it's gaming apps, social applications, or financial tools, performance smoothness and resource consumption directly determine user retention. For iOS developers, finding a suitable performance monitoring tool often means debugging and optimization efficiency can be improved several times.

This article is based on the latest iOS 26 system and selects six widely used performance monitoring tools in the developer community for in-depth evaluation: Xcode Instruments, Firebase Performance, New Relic, KeyMob, TestFlight Metrics, PerfDog. Through comparisons in dimensions such as functionality, accuracy, ease of use, and platform support, it helps developers choose the performance monitoring solution that suits their team.

1. Evaluation Standards and Test Environment

Test Platform: iPhone 15 Pro (iOS 26.0)
Test Application: A social app with complex animations and network requests
Evaluation Dimensions:

CPU / Memory / GPU / Network / Energy consumption monitoring capabilities
Monitoring accuracy and real-time performance
Cross-platform compatibility
Log analysis and export capabilities
Long-term operation stability
Support for development processes (CI/CD)

All tools were tested under the same environment to ensure data consistency.

2. Xcode Instruments — The Official Benchmark Tool

Type: Official development tool
Applicable Stage: Development and local debugging

Core Functions:

CPU and call stack analysis (Time Profiler)
Memory allocation and leak detection (Allocations, Leaks)
GPU rendering efficiency (Core Animation)
Battery and energy consumption analysis (Energy Log)

Advantages:
Extremely high sampling accuracy, suitable for low-level performance analysis
Perfect integration with Xcode, smooth debugging experience
Can directly view symbolized call stacks

Disadvantages:
Cannot cross-platform
Affects performance during runtime, cannot sample for long periods
Does not support online or non-development signed applications

Applicable Scenarios: Code-level performance debugging, short-term sampling analysis

3. Firebase Performance — The Preferred Cloud Performance Monitoring Tool

Type: Cloud monitoring tool
Applicable Stage: Beta testing and official release stages

Core Functions:

Startup time and network latency monitoring
Page rendering and interaction performance analysis
Regional distribution and device difference reports
Automatic collection of user-side performance data

Advantages:
Can continuously collect real user data
No additional operations required, automatic reporting
Perfect integration with Crashlytics

Disadvantages:
Limited sampling frequency, cannot obtain frame rate and GPU metrics
Cannot view detailed CPU usage inside the app

Applicable Scenarios: Online performance trend analysis, performance regression verification after release

4. New Relic Mobile — Enterprise-Level Performance Visualization Platform

Type: Commercial monitoring solution
Applicable Stage: Enterprise versions and long-term operation analysis

Core Functions:

Real-time performance dashboard
User interaction and error path visualization
Network request performance tracking
Multi-version comparative analysis

Advantages:
Supports centralized monitoring of multiple apps
Intuitive dashboard, suitable for large team collaboration
Can integrate with CI/CD, Jenkins

Disadvantages:
Complex installation and configuration
Higher cost for individual developers
Cannot monitor GPU/frame rate and other visual performance metrics

Applicable Scenarios: Large teams, continuous performance analysis of online versions

5. KeyMob — All-in-One Performance Monitoring Tool from a Developer's Perspective

Type: Cross-platform performance and file analysis tool
Applicable Stage: Development, debugging, testing

Core Functions:

Real-time CPU, GPU, memory, network, FPS monitoring
Lag detection, energy consumption analysis, log export
Supports app file decryption and historical performance records
Supports multiple frameworks such as Swift, Flutter, Unity, Cocos2d

Advantages:
Can run on non-jailbroken devices
Supports Windows, macOS, Linux
Intuitive data visualization, clear historical curve comparison
Can cross-app monitor mini-programs and container performance

Disadvantages:
Cannot directly integrate with cloud statistical systems (requires data export)
Requires manual integration for analysis reports

Applicable Scenarios: Performance debugging, file analysis, performance verification during development

6. TestFlight Metrics — Performance Metric Collection in Beta Stage

Type: Apple's official beta data collection service
Applicable Stage: Test distribution and user experience tracking

Core Functions:

Crash rate and stability statistics
Startup time and response speed
Installation retention and device information statistics

Advantages:
No additional configuration required, automatic data collection
Integrated with Xcode Connect
Secure, reliable, and privacy-compliant

Disadvantages:
Limited metric dimensions (no CPU/GPU monitoring)
Cannot export detailed logs or time-series data

Applicable Scenarios: Performance verification before app release and gray-scale testing

7. PerfDog — Performance Tool for Gaming and Multimedia Apps

Type: Third-party real-time performance testing platform
Applicable Stage: Performance analysis for gaming and high-frame-rate applications

Core Functions:

GPU rendering time analysis
Network jitter and latency detection
CPU/GPU temperature monitoring
Cross-platform performance data collection (iOS/Android)

Advantages:
Clear performance charts, high testing accuracy
Supports long-term operation and comparative reports
Especially suitable for performance tuning of gaming apps

Disadvantages:
Installation depends on a computer-side client
Not suitable for fine-grained debugging of conventional apps

Applicable Scenarios: Gaming performance testing, cross-platform performance comparison

8. Horizontal Comparison of Six Tools

Tool Name	Monitoring Dimensions	Real-time	Cloud Support	Cross-platform	Difficulty	Recommended Stage
Xcode Instruments	CPU/Memory/GPU/Energy	High	No	No	Medium	Development Debugging
Firebase Performance	Startup/Network/Rendering	Medium	Yes	Yes	Easy	Online Monitoring
New Relic Mobile	CPU/Network/Crash	Medium	Yes	Yes	High	Enterprise Monitoring
KeyMob	CPU/GPU/Memory/Logs	High	Manual	Yes	Easy	All Stages
TestFlight Metrics	Startup/Stability	Low	Yes	No	Easy	Beta Testing
PerfDog	FPS/Temperature/Network	High	Yes	Yes	Medium	Gaming Testing

Comprehensive Evaluation Results:

Best Development Stage Tools: KeyMob + Instruments
Best Release Stage Tools: Firebase + New Relic
Best Testing Combination: PerfDog + KeyMob (suitable for high-frame-rate applications)

9. Multi-Tool Combination Strategy Recommendations

(1) Development Stage: Precise Sampling + System Log Analysis
Use Xcode Instruments + KeyMob

Instruments locates function performance bottlenecks, KeyMob supplements system-level CPU, memory, network trends.

(2) Testing Stage: Beta Users and Real Device Verification
Use TestFlight Metrics + KeyMob

Collect performance metrics from test devices, while monitoring real-time data and crash logs with KeyMob.

(3) Release Stage: Real-time Performance Regression
Use Firebase Performance + New Relic

Continuously collect performance trends in the cloud, enabling comparative analysis between versions.

(4) Gaming/High-Performance Scenarios
Use PerfDog + KeyMob

Simultaneously capture frame rate fluctuations and device temperature to identify performance bottlenecks.

10. Conclusion: Best Practices for Performance Monitoring

iOS performance optimization is no longer a matter of single-point tuning but a systematic engineering effort. From Xcode's low-level sampling to KeyMob's real-time monitoring, and Firebase's online trend analysis, a multi-tool collaborative combination is necessary to build a truly reliable performance assurance system.

Performance data is not just "monitoring results"; it is the basis for development decisions. Mastering performance means mastering the initiative in user experience.

Complete Analysis of iOS Submission Process for uni-app: Full Practice from Packaging to Release

DataStack — Sat, 08 Nov 2025 08:02:22 +0000

uni-app, as a cross-platform development framework, has become the first choice for many teams and individual developers due to its "write once, run everywhere" feature.

However, many developers often encounter complex processes, scattered tools, and tedious reviews during the iOS app submission phase.

This article will focus on the iOS submission process for uni-app, combining practical experience to detail the entire process from certificate preparation to TestFlight distribution and App Store release, and provide tool combination solutions for different stages.

1. Preparation Phase: iOS Certificates and Provisioning Profiles

In a uni-app project, to successfully package and submit an iOS app, you must first apply for iOS development certificates and distribution certificates.

Mac users: Can generate a CSR file via Xcode or Keychain Access, then apply for certificates in the Apple Developer Center.
Cross-platform users (Windows/Linux): Can use Appuploader to directly generate p12 certificates and provisioning profiles without a Mac.

Team practical experience:

It is recommended to uniformly export as .p12 files and set certificate naming conventions (e.g., UniApp_Project_Dist_2025.p12).
Store certificates and provisioning profiles centrally in a team repository to avoid packaging failures due to loss of personal computers.

2. Packaging Phase: Generating ipa from HBuilderX

uni-app packaging has two main methods:

1. Cloud Packaging (Recommended for small teams/without Mac environment)

In HBuilderX → Distribution → Native App - Cloud Packaging, upload certificates and provisioning profiles.
The cloud directly generates the ipa file.
Suitable for teams without Macs to quickly deliver.

2. Local Packaging (Requires Mac environment)

Use HBuilderX to export the Xcode project.
Open the project in Xcode on a Mac, perform Archive packaging, and export the ipa file.
More flexible, suitable for teams requiring customized configurations.

3. Upload Phase: Choices for Multi-Tool Combinations

After generating the ipa, it needs to be uploaded to Apple's servers to enter TestFlight or the App Store.

Common solutions:

Xcode upload: Intuitive, but limited to Mac users.
Transporter: Apple's official standalone upload tool, suitable for stable scenarios.
Appuploader: Supports Windows/Linux/Mac, cross-platform upload without Mac.
Fastlane: Command-line tool, suitable for CI/CD automated workflows.

In practice:

Small teams tend to use Appuploader for convenient cross-platform uploads.
Medium to large teams often use Fastlane + Jenkins for automation.

4. Distribution Phase: Internal and External Testing

1. Internal Testing (TestFlight Internal Testing)

Supports up to 25 accounts, with immediate installation.
Suitable for internal team validation.

2. External Testing (TestFlight External Testing)

Supports up to 10,000 users.
Requires Apple review after upload (approximately 24 hours).

3. Alternative Solutions

For small-scale testing, Ad Hoc packages can be used for direct distribution.
Appuploader supports generating QR codes for installation, facilitating temporary experiences.

5. App Store Review and Release

Review is the final step in iOS submission and a common challenge for many uni-app developers.

Preparation required:

App name, subtitle, keywords.
Screenshots and videos (can be batch uploaded via Appuploader).
Privacy policy and permission descriptions.

Important notes:

uni-app projects are easily misjudged as "shell apps"; ensure complete functionality and reasonable interactions.
Avoid scenarios where only H5 web pages are loaded, as this may lead to rejection.

6. Team Practical Case: Submission Process for a uni-app E-commerce App

We once assisted a 5-person team in submitting a uni-app-based e-commerce app, with the process as follows:

Operations (Windows): Used Appuploader to apply for certificates and manage them uniformly.
Development (Windows + Mac): Used HBuilderX cloud packaging to generate the ipa.
Testing (Windows): Used Appuploader to upload the ipa to TestFlight.
Product Manager (Mac): Configured information and screenshots in App Store Connect.
Final Step: After collecting feedback via TestFlight external testing, submitted for App Store review.

Ultimately, the team completed the entire process relying on only one Mac.

7. Experience Summary

Centralized certificate management: Avoid packaging failures due to certificate expiration or loss.
Flexible packaging method selection: Cloud packaging suits small teams, local packaging suits customization needs.
Multi-tool upload combinations: Appuploader, Xcode, Transporter, Fastlane each have their scenarios.
Compliant review: uni-app projects must avoid being misjudged as shell apps.

The process of submitting a uni-app app to iOS, though complex, can be significantly simplified by rationally utilizing tools.
Through the combination of HBuilderX, Appuploader, Xcode, Fastlane, TestFlight, both independent developers and cross-platform teams can successfully complete the entire process from development to App Store release.

What Are the iOS Packet Capture Tools? Comprehensive Overview and Functional Comparison of Mainstream Tools

DataStack — Tue, 28 Oct 2025 09:56:44 +0000

In mobile app development and testing, packet capture is one of the most commonly used debugging methods. Whether troubleshooting interface issues, monitoring network performance, or conducting security analysis, developers and testers need an efficient packet capture tool. Especially on the iOS platform, due to its relatively closed system, choosing the right tool is particularly important.

So, what are the common iOS packet capture tools on the market? What are their advantages, disadvantages, and applicable scenarios? This article will provide a systematic overview.

1. Charles

Advantages

User-friendly interface, cross-platform support (Windows / macOS)
Intuitive operation, simple configuration
Supports HTTPS decryption and proxy packet capture
Supports rule filtering and request/response modification

Disadvantages

Requires manual Wi-Fi proxy configuration
Certificate installation and trust steps are cumbersome
Cannot bypass SSL pinning or mutual authentication
Beginners may easily get stuck on certificate trust issues

Applicable Scenarios

Daily development debugging
Quick validation of web interfaces
Simple network testing and analysis

2. Fiddler

Advantages

Classic packet capture tool for Windows
Supports HTTP/HTTPS traffic analysis
Can modify and replay requests
Rich community documentation, low learning curve

Disadvantages

iOS configuration process is relatively complex
HTTPS decryption is not enabled by default
Cannot bypass SSL pinning
Mac user experience is average

Applicable Scenarios

Windows users debugging interfaces
Simple network troubleshooting
Web service testing

3. Sniffmaster

Advantages

USB direct connection to iOS devices, no Wi-Fi proxy or certificate installation required
Automatically decrypts HTTPS, can bypass SSL pinning and mutual authentication
Supports capturing only specified apps, avoiding interference from system requests
Built-in interceptor, can modify requests/responses using JavaScript
Can export data streams for deep analysis with Wireshark
Cross-platform support for Windows / macOS

Disadvantages

Requires additional client installation compared to traditional tools
Initial use requires familiarity with direct connection mode

Applicable Scenarios

Debugging high-security apps with SSL pinning
Mobile network security analysis
Scenarios requiring precise analysis of single-app traffic

4. Proxyman

Advantages

Modern packet capture tool built specifically for macOS
Clean and intuitive interface, experience similar to Charles
Supports HTTPS decryption and rule filtering
Active updates, fast feature iteration

Disadvantages

Only supports macOS
Cannot resolve SSL pinning
Overlaps in functionality with Charles, lacks breakthrough advantages

Applicable Scenarios

macOS developers replacing Charles
Interface debugging and quick troubleshooting

5. Wireshark

Advantages

Network protocol analysis powerhouse
Can capture underlying data like TCP/UDP/TLS handshakes, DNS, etc.
Completely free, extremely powerful features
Suitable for performance analysis and security research

Disadvantages

Cannot directly decrypt HTTPS
Interface is not user-friendly for beginners
High analysis difficulty, steep learning curve

Applicable Scenarios

Network layer troubleshooting
Performance analysis and packet loss detection
Security research and protocol learning

6. mitmproxy

Advantages

Command-line tool, lightweight and flexible
Extensible with Python scripts
Supports custom request/response, suitable for automated testing
Very convenient for simulating interface anomalies (delays, error codes)

Disadvantages

No GUI, steep learning curve
Not suitable for temporary debugging
Also cannot bypass pinning

Applicable Scenarios

Automated interface testing
Constructing anomaly scenarios
Network debugging in continuous integration environments

7. Tool Comparison Summary

Tool	Key Scenarios	Limitations
Charles	Cross-platform, user-friendly, quick debugging	Cannot bypass pinning
Fiddler	Commonly used by Windows users, mature community	Complex iOS configuration, limited by pinning
Sniffmaster	USB direct connection, bypasses pinning, precise app capture	Requires additional installation, learning needed initially
Proxyman	Native macOS experience, modern UI	Limited to macOS, overlaps with Charles
Wireshark	Network protocol analysis, suitable for performance and security research	Cannot directly decrypt HTTPS, high learning threshold
mitmproxy	Scriptable, automated testing, suitable for anomaly simulation	No GUI, steep learning curve

Daily Debugging: Charles and Fiddler are sufficient for most development needs.
Automated Testing: mitmproxy is more suitable for constructing anomalies and scripted validation.
Deep Analysis: Wireshark is a powerful tool for protocol research and performance troubleshooting.
High-Security Scenarios: Sniffmaster is a reliable choice for bypassing SSL pinning and mutual authentication.

For iOS developers, the optimal solution is typically: Charles/Fiddler + Sniffmaster + Wireshark, which enables quick debugging and addresses packet capture challenges in high-security applications.