DEV Community: CoreDataHero

How to Generate AppStoreInfo.plist on Windows / Linux / Mac

CoreDataHero — Tue, 22 Sep 2026 10:01:37 +0000

How to Generate AppStoreInfo.plist on Windows / Linux / Mac: Get the Resource Description File for App Store Submission Without Installing Xcode

One command generates AppStoreInfo.plist from an IPA on any system:

appuploader-cli info -u dev@example.com Payload.ipa -o AppStoreInfo.plist

appuploader-cli is the command-line tool bundled with AppUploader. The info command only reads your package locally and generates the resource description file used in Apple's App Store submission flow. It does not upload anything over the network, and it does not require Xcode.

First, What This File Is Actually For

AppStoreInfo.plist is not a configuration in your project — it is a manifest that describes the package when you deliver a build. Apple states its purpose right at the beginning of the file:

This App Store Information can be used with iTMSTransporter and App Store Connect Developer API.

In other words, when you hand a package to Apple through iTMSTransporter or a similar route instead of clicking "Distribute App" in Xcode, you usually need to attach this description along with the package.

The problem is that this file is normally generated by a tool in the Xcode toolchain — one that only runs on macOS. This is where many people get stuck: the package is already built and signed on Windows, yet this one manifest is missing, and buying a Mac or renting a cloud Mac just for it isn't worth it.

appuploader-cli info solves exactly this step: it generates the file on Windows, Linux, and macOS alike, and the output format is identical.

Install the Tool and Locate the Command

Install AppUploader first; the command-line tool is installed along with it, with no separate download needed:

System	Location
Windows	`appuploader-cli.exe` in the same directory as the main program `AppUploader.exe`
macOS	`AppUploader.app/Contents/Resources/appuploader-cli`
Linux	`appuploader-cli` in the same directory as the main program `AppUploader`

Open a terminal in that directory and you can use it directly. If you want to run it from any directory, add it to PATH:

Windows: Settings → System → About → Advanced system settings → Environment Variables → select Path → Edit → New, paste this directory, then reopen a terminal for it to take effect.
macOS / Linux: add export PATH="$PATH:/your/install/directory" to ~/.zshrc or ~/.bashrc.

Verify it:

appuploader-cli info --help

Generating AppStoreInfo.plist

The most common invocation:

appuploader-cli info -u dev@example.com Payload.ipa -o AppStoreInfo.plist

-u takes your Apple ID email;
The package path can go directly at the end of the command (you can also write it as -f Payload.ipa);
-o specifies the output file. Without -o, the result is printed straight to the terminal, which is convenient for piping.

When it finishes, it prints one line of output containing the generated file name, size, and the package's Bundle ID:

asset description written to AppStoreInfo.plist (93613 bytes, xml plist, bundle id com.example.app)

A quick look at that Bundle ID immediately confirms whether you're shipping the package you intended — in CI, mixing up build artifacts is more common than you'd think.

The supported inputs go beyond IPA: .pkg (macOS apps) and .zip can also be analyzed.

If You Need the Binary Format

The default output is an XML plist — readable and easy to diff. Some downstream tools require a binary plist:

appuploader-cli info -u dev@example.com Payload.ipa --format binary -o AppStoreInfo.plist

--format accepts only xml (the default) and binary.

Using It in CI

Two typical use cases.

First, a self-check before uploading. The generation step actually unpacks the package and reads through it layer by layer, so structural problems in the package itself surface here — much faster than being rejected by Apple halfway through an upload:

appuploader-cli info -u "$APPLE_ID" -f build/App.ipa -o build/AppStoreInfo.plist || exit 1

Second, pairing it with another upload tool. If your pipeline already uses iTMSTransporter or a custom delivery script and only this description file is missing, info fills exactly that gap — just pass the generated plist to the downstream tool.

There is also a --deterministic switch, which pins down fields that differ on every run, such as UUIDs, process IDs, and timestamps:

appuploader-cli info -u "$APPLE_ID" --deterministic -f build/App.ipa -o out.plist

Its purpose is quite specific: if you want to verify "whether two builds produce exactly the same package," turning this on lets the two plists be compared byte by byte; otherwise the timestamps alone will never match. You don't need it for everyday submissions.

One last note: this plist describes one specific package, so a different build requires regenerating it. Don't cache it in your pipeline — just generate a fresh one right after building. If your goal is simply to upload the package, the same tool's upload command does it in one go, with no need to generate this file first.

I once almost rented a cloud Mac for this one file that's only a few dozen KB, and later found this command was all I needed. It's the command-line tool bundled with AppUploader, and the same toolkit can also sign certificates, create Bundle IDs, generate provisioning profiles, and upload IPAs on Windows.

Apple App Development Build Process: Complete iOS Build and Debugging with KxApp (kxapp)

CoreDataHero — Sun, 20 Sep 2026 11:04:31 +0000

When working on iOS projects, the compilation step comes up almost every day. After writing code, you need to build the app, connect a device to run it, confirm the logic is correct, and then continue modifying the code. This cycle repeats many times during development.

A while ago, while organizing an experimental project, I tried a different way to handle the build process. Instead of using the traditional Xcode project environment, I completed the entire development and build process in an iOS development IDE called KxApp. The project was small, so it was a good opportunity to walk through code writing, app compilation, and on-device debugging end to end.

Create a Project and Prepare the Code

The goal of this test project was simple: write a small app that displays the current time on the UI and provides a button to refresh the time.

After opening the KxApp IDE, you can see three project types in the new project screen:

Swift
Objective-C
Flutter

I chose a Swift project for testing. After entering the project name, the IDE automatically generates the project directory. The project already includes an entry file and basic configuration.

After opening the code file, you can write the UI logic directly. The editor layout is similar to common code tools: the project file list is on the left, and the code area is in the middle.

When writing the UI, I used a simple layout: a text label to display the time and a button to trigger the refresh event. When the button is clicked, it reads the system time and updates the UI content.

After saving the code, the IDE performs syntax checking. If there are errors in the code, the editor marks them on the corresponding lines.

Perform Apple App Compilation in the IDE

Once the code compiles normally, you can start building the app.

After connecting an iPhone to the computer with a data cable, the current phone appears in the KxApp IDE device list. After selecting the device, click the Run button, and the IDE starts the compilation task.

During this process, you can see several steps executing in sequence:

Source code compilation
App build
App installation on the phone

When the build is complete, the icon of the app just compiled appears on the phone's home screen. Click the icon to launch the app.

To verify the code logic, I clicked the refresh button, and the time on the UI updated to the current system time. This shows that the code compilation and running process are working correctly.

Modify Code and Recompile

During development, compilation does not happen only once.

I added a log output to the code to record the number of button clicks. After saving the code, I clicked the Run button again, and the IDE recompiled the app and installed the new version.

The old version on the phone is replaced, and after opening the app, you can see the updated behavior.

This cycle is fairly intuitive:

Modify code → Click Run → IDE compiles → Phone runs the new version

The whole process does not require opening other tools, and there are no extra packaging steps.

How the Compilation Tool Works

During use, you can see that the KxApp IDE integrates a set of compilation tools internally. After installing the IDE, these tools are already configured.

When you click Run or Build, the IDE calls the internal tools to execute the compilation process.

This means that when developers write iOS apps, they do not need to install Xcode separately. Code compilation, app building, and device installation are all completed in the same environment.

For projects that need to quickly verify functionality, this approach can reduce the time spent preparing the development environment.

Manage Different Project Types in the Same Environment

To test the IDE's multi-project capability, I created an Objective-C project as well.

The project creation process is basically the same as for a Swift project. After entering the project name, the IDE generates the project structure.

After writing a simple UI, I connected an iPhone and clicked Run, and the app installed on the device normally.

Then I created a Flutter project for testing. The Flutter page could also be installed on the phone after compilation.

In the same IDE, you can handle three types of projects:

Swift native apps
Objective-C apps
Flutter projects

For developers who need to maintain multiple projects at the same time, this unified environment is quite convenient.

Build the Installation Package

When app development is complete, you need to generate an installation package for testing or submission for review.

In the KxApp IDE, you can generate the app installation file through the build feature. The IDE performs code compilation and generates the installation package.

The generated installation package can be used for:

Tester installation
Internal distribution
App Store submission

Build logs are displayed in the IDE's output panel. If errors occur during compilation, you can also view detailed information here.

In this test project, the entire Apple app compilation process remained fairly simple:

Create project → Write code → Compile app → Run on phone → Modify code → Recompile → Generate installation package, all completed in the KxApp IDE.

This development approach is well suited for quickly building app prototypes or verifying functional logic, because developers do not need to spend time preparing a complex development environment.

Use TraceEagle to Compare Captured Requests Side by Side with Diff, Pinpointing Every Difference Line by Line

CoreDataHero — Wed, 16 Sep 2026 10:14:10 +0000

Request Diff

This guide shows you how to compare two requests / responses side by side, line by line: select one and mark it as A, then choose "Compare with A" on another, and the tool immediately opens a side-by-side window marking every difference line by line. "Why did it succeed this time but fail last time?" "For the same API, which line exactly differs between success and failure?" — one comparison tells you. The two records don't have to come from the same session; you can compare across sessions and sources.

1. When to use it

It fits if any of the following applies:

You want to figure out why two requests behave differently: success vs. failure, working vs. erroring — which header, which parameter, which part of the body differs.
You manually crafted / replayed a request and want to check it against the one actually captured — is the signature right, are the fields all there.
After changing the server / client, you want to confirm what exactly changed in this request or response before and after the change, and whether there are side effects.
The same API returns inconsistent results between test and production, and you want to quickly determine whether it's a config difference or a data difference.

If you've only captured one flow and have no second one to compare against, capture another one first, or use Request Crafting & Replay to create one, then come back to compare.

2. Prerequisites

TraceEagle is installed and running, and you've captured (or crafted) at least two flows.
Both flows just need to be visible in the UI — they don't have to come from the same capture session, nor to have been captured at the same time.
To compare response bodies, make sure that flow's response is decrypted / readable (the details show "Decrypted" for TLS); if one side isn't decrypted, the tool will say so during comparison.

3. Step-by-step: two steps to a diff

Right-click any flow and click "Mark as Comparison A" in the context menu. That flow is recorded as side A.
Find the other flow to compare it with (one in the same session, one in another session, or one captured after replaying from the crafter — any will do), right-click it, and click "Compare with A".
A side-by-side comparison window opens immediately: A on the left, B on the right, each with its own label (method · host · status), so you know at a glance which two you're comparing.
At the top of the window, switch with one click between comparing the request and the response. Both sides switch in sync.
Read the differences line by line: added (+), removed (−), and changed (~) are highlighted separately, with red on side A and green on side B; changed lines are shown side by side for comparison. The top also gives a line-count summary of "added / removed / changed".

The comparison covers everything in a message: the start line (request line / status line), all request / response headers, and the request / response body. The body is auto-prettified first and then compared line by line, so JSON, XML, and forms are all easy to read — the fields that actually changed stand out immediately, without interference from formatting noise such as line breaks or indentation.

4. Verification: make sure the comparison is trustworthy

After opening the comparison window, check the following points to confirm the result is unambiguous:

The labels on both sides match: A on the left, B on the right, and their method · host · status match the two you intended to compare — no mis-selection.
Request / response switching works: switch to "Request" at the top to view request headers and body, switch to "Response" to view the status code and response body; both sides change in sync.
Differences are colored and counted: changed lines are colored, and the line-count summary at the top matches the differences you see with your own eyes.
Identical content is explicitly reported: when the two are the same, the tool tells you "identical" directly, so you don't have to check line by line; if one side has no content or is not yet decrypted, it also says so, instead of leaving you waiting.

5. Tips and troubleshooting

Symptom / Thought	Most likely cause	What to do
Clicking "Compare with A" in the menu does nothing	A hasn't been marked yet	First right-click one flow and choose "Mark as Comparison A", then choose "Compare with A" on the other
The two flows you want to compare are in different sessions	You assume comparison only works within one session	Not necessary — as long as both are visible in the UI you can compare them; A and B can be cross-session and cross-source
The response side is blank / says not decrypted	That flow's response isn't decrypted yet, or simply has no body	Decrypt that flow first (the details show "Decrypted" for TLS), then compare; see Viewing & Decoding Data
You want to verify "did I craft it correctly"	The hand-crafted request and the real request aren't viewed side by side	Replay / send it in Request Crafting & Replay, capture the resulting flow, then "Compare with A" against the real historical request to check the signature and fields line by line
The body diff looks large but is actually just different formatting	Formatting noise such as line breaks / indentation	Don't worry — the body is auto-prettified before comparison, so what's marked are the fields that actually changed, not formatting jitter
You compared the wrong two / want to swap one out	A still points to the old flow	Right-click the new target and choose "Mark as Comparison A" again to overwrite the old A, then pick B

Next steps

To read and decode a flow before comparing it: see Viewing & Decoding Data.
To craft a request / replay it and capture it for checking against a real request: see Request Crafting & Replay.
To see who this request is sent to and what the other side is: see Host Details.
Private / proprietary protocols need to be understood before comparison: see Custom Protocol Decoding.

How to Generate iOS Signing Certificates and Provisioning Profiles on Windows Without Xcode

CoreDataHero — Tue, 15 Sep 2026 10:09:27 +0000

How to Generate iOS Signing Certificates and Provisioning Profiles on Windows Without Xcode

Before compiling and signing an iOS app, you usually need to complete three steps in order: register a Bundle ID → issue a signing certificate → generate a provisioning profile. The official route is to log in to developer.apple.com and do it manually, or let Xcode handle it automatically—both assume you have a Mac. With AppUploader, these three steps can be done directly on a Windows PC.

Step 1: Register a Bundle ID

A Bundle ID is an App ID. Each app needs a unique identifier and cannot duplicate another developer's.

Open the 'Bundle ID' page and click 'New Bundle ID'.
Enter the Identifier: use reverse-domain-name format (e.g., com.yourcompany.appname). It can contain only letters, numbers, hyphens, and periods, and must end with a letter or number. It cannot be changed after creation.
Enter a name (the app name) and submit to complete registration.
If the app needs specific capabilities (Push Notifications, App Groups, iCloud, etc.), go to the 'Capabilities' page for that Bundle ID, search for and check them, and save. This will be submitted to the Apple portal and take effect.

Step 2: Issue a Signing Certificate

Open the 'Certificates' page, click 'New Certificate', and choose the certificate type (development signing certificate or distribution signing certificate, depending on whether you want to generate a development or App Store provisioning profile).
Select the identifier to bind (the Bundle ID / App ID registered in the previous step).
Enter the certificate name and email, and set a .p12 protection password—the server does not store this password, so keep it safe. If you forget it, the private key will no longer be usable.
Optionally enable 'Sync certificate with AppUploader service' (cloud backup). You can then re-download this certificate on any computer, without having to use the same machine every time.
After submission, the certificate is issued by Apple.

For free accounts not enrolled in the Apple Developer Program, the certificate is valid for only 7 days and must be reissued after expiration.

Step 3: Generate a Provisioning Profile

Open the 'Provisioning Profiles' page, click 'New Provisioning Profile', and enter a name.
Choose the type: Development is used to install development builds on test devices; App Store distribution is used for submitting for review; Ad Hoc is used to distribute test builds to a limited number of registered devices.
Select the associated Bundle ID (the one registered in Step 1).
Select the associated certificate(s) (you can select multiple or choose 'All Certificates'). If it is a distribution type that requires devices (such as Ad Hoc), you also need to select the associated test devices. If you have no devices, you can click 'Register Device' and scan a QR code with your phone to register.
After submission, the provisioning profile is created. You can download the .mobileprovision file from the list and give it to your build tool (Flutter/Unity/custom signing scripts, etc.) for signing.

Ongoing Maintenance

If the capability configuration of a Bundle ID changes, provisioning profiles that depend on it will become invalid. You can click 'Rebuild' to automatically regenerate them with the currently valid certificate and devices, without repeating the three steps above.
Certificates and provisioning profiles can both be searched by name/type, making it easy to manage multiple certificate sets for multiple apps.

Once all three steps are complete, you can submit the signed IPA to the App Store directly in the same tool. The entire process does not require a Mac. Visit https://appuploader.net for details.

iOS Development Environment Setup: Xcode Configuration and KXApp Lightweight Tool Selection

CoreDataHero — Mon, 14 Sep 2026 10:48:01 +0000

I’ve noticed something: more than half of the friends around me who want to learn iOS development get stuck at the environment setup stage. Xcode is over ten GB to download, and after installation you still need to configure certificates and handle code signing. Sometimes just getting your first Hello World to run on a real device takes a day or two. This detailed guide to iOS development environment setup sorts out two paths to help you compare different approaches: the standard Xcode approach and the lightweight toolchain approach. Just choose according to your needs.

Standard Approach: Full Xcode Installation

Xcode is downloaded from the Mac App Store. The installer is over ten GB and includes the compiler, debugger, iOS SDK, Interface Builder, and Instruments. Add your Apple ID via Preferences → Accounts, and Xcode will automatically manage certificates and signing. Create a SwiftUI or UIKit project, choose a template, and you can run it in the simulator.

Real-device debugging requires a few more steps: register an Apple Developer account (free or paid), configure certificates and provisioning profiles in Xcode, enable Developer Mode on the phone, and trust the computer. Once you get through it, subsequent runs go smoothly, but not many people make it through the first time. Xcode is feature-complete, but for people who only write Flutter or just want to try Swift first, most of its features are unnecessary—yet it still takes up over ten GB of disk space.

Choosing the Xcode path means accepting a higher barrier to entry and more disk usage. But if your goal is in-depth native development, Xcode is unavoidable. When setting up an iOS development environment, you need to first confirm your project type before choosing an approach.

Lightweight Approach: KXApp

KXApp does not require installing Xcode and Command Line Tools; it has a complete build toolchain built in. The installer is much smaller than Xcode’s. After downloading, you can open it and create Swift, OC, or Flutter projects. The coding interface is based on VS Code, with intelligent completion and an AI code assistant available by default, making coding convenient.

Real-device debugging saves many steps: connect the iPhone to the computer, click Build and Install, and the tool directly compiles, signs, and installs the app on the phone. You do not need to configure certificates and provisioning profiles yourself. For beginners new to iOS development, or developers working on cross-platform projects, KXApp’s approach can save a lot of configuration time during iOS development environment setup, letting you focus on writing code instead of fighting with tools.

After the project is complete, you can also build an IPA with one click for test distribution or App Store submission. From project creation to coding to packaging and release, everything is done in the same tool, with no need to switch between multiple applications. For scenarios where you just want to see your code running on a phone as soon as possible, this approach has a much lower environment setup cost.

How to Choose Between the Two Approaches

Xcode is suitable for in-depth native development, scenarios where Instruments is needed to diagnose performance issues, or team collaboration using Apple ecosystem services such as Xcode Cloud. KXApp is suitable for developers who want to get started quickly, work on cross-platform projects, or avoid spending too much time on toolchain configuration. When setting up an iOS development environment, think clearly about what type of project you mainly write, and you can decide which path to take.

The two paths do not conflict. Open Xcode when writing native code and doing performance analysis; use KXApp for quickly validating ideas in daily work or writing Flutter projects. Leveraging each tool’s strengths is more flexible than sticking to just one approach. Whichever path you choose, the two approaches covered in this detailed guide to iOS development environment setup will get you up and running.

Android HTTPS Capture: Bypass Certificate Pinning, 4 Methods for Devices & Emulators

CoreDataHero — Mon, 14 Sep 2026 10:20:35 +0000

Android Traffic Capture

This guide walks you through capturing the traffic inside a phone / emulator on Android, step by step. Android capture most often gets stuck on certificates — you install the certificate in the app and it still isn't trusted, and apps with certificate pinning can't be captured at all. Here's a different approach: whole-device capture + automatic decryption, with no certificate installed on the phone at any point; it works on both real devices and emulators, and even apps with pinning and custom encryption can have their plaintext extracted from the inside. Follow the steps below to capture your first request.

1. When to Use It, and How to Choose Among the Methods

Match your device and goal first, then jump to the corresponding steps below:

Your situation	Which one to use	Need root?	Install a certificate?
Old device / emulator / unsure about age, want the most reliable	NIC key (recommended default)	Yes	No
Newer rooted real device, want the least hassle	NIC capture	Yes	No
Only care about one app, or it only emits ciphertext in whole-device mode	App-layer capture	Yes	No
Device isn't rooted, or you want to view and modify on the fly (rewrite / replay)	Proxy capture	No	Yes (see Section 2)

The first three are all whole-device / targeted capture + automatic decryption, with no certificate installed on the phone — that's exactly what makes them easier on Android than traditional proxy capture.
If unsure, start with "NIC key": it has the best compatibility and works on almost any rooted device.
Only proxy capture requires installing a certificate; Section 2 below explains how to get around the certificate problem on newer Android versions.

2. Prerequisites

General setup (real device)

Connect the phone to the computer with a data cable, and enable USB debugging on the phone (in "Developer options").
On first connection, the phone prompts "Allow USB debugging?" — tap Allow.
Launch TraceEagle; the device appears in the list of selectable devices. Emulators need no cable and are usually detected automatically.

About root

The first three capture methods (NIC key / NIC capture / app-layer capture) all require a rooted device. Emulators usually come with root or can enable it with one click, so they qualify.
None of these three require installing a certificate on the phone: they aren't man-in-the-middle proxies and don't rely on the phone trusting a certificate to decrypt. The helper components needed for capture are downloaded and cached automatically according to the device architecture, so you don't have to set up the environment manually.

About certificates (only proxy capture needs them)

Only proxy capture requires installing a root certificate on the phone. And newer Android versions don't trust user-installed certificates by default — which is the root cause of "I installed the certificate but still can't capture."
Two ways to handle it: ① if the device is rooted, you can let the tool install the trusted certificate at the system level automatically, skipping the manual steps; ② or skip certificates entirely and switch to the certificate-free whole-device methods above (NIC key / NIC capture). For the full certificate installation steps, see Certificate Installation.

3. NIC Key: Whole-Device Capture (Recommended Default)

Captures all traffic on the device's NIC (Wi-Fi by default) and decrypts it automatically, with no need to pick an app or install a certificate. Best compatibility — works on old devices and all kinds of emulators.

Select the target device in the device list (real device or emulator).
Choose "NIC key" as the capture method.
Choose the NIC to capture; normally just keep the default Wi-Fi.
Click Start.
Use the app normally on the phone to generate network requests; traffic appears in the request list in real time.

An emulator's system kernel is often old and may not support "NIC capture" — in that case just use "NIC key," which has the best emulator compatibility.

4. NIC Capture: Whole-Device Capture (Newer Real Devices, Least Hassle)

Also captures all traffic on the device's NIC and decrypts it automatically; it's characterized by being self-contained and the least hassle (the data and the information needed for decryption are packaged together).

Select the target device.
Choose "NIC capture" as the capture method.
Choose the NIC (default Wi-Fi).
Click Start and generate requests on the phone to see live traffic.

The prerequisite is a relatively new device (newer kernel). If the device is too old to qualify, starting capture will clearly report "NIC capture not supported" — just follow the prompt and switch to NIC key.

5. App-Layer Capture: Focus on One App, Pull Plaintext from Inside

Targets a single app and pulls plaintext directly from inside it — certificate pinning and custom encryption can't stop it. For apps whose traffic can't be decrypted in whole-device mode, use this targeted approach.

Select the target device.
Choose "App-layer capture" as the capture method.
Specify the app to capture: pick it from the installed app list, or enter its package name / process name; leave it blank to capture the current foreground app.
To capture traffic from the app's early startup, check "Restart target program" (it will close the app and relaunch it).
Click Start and use that app to see its requests.

When the regular approach can't get plaintext (stubborn apps with static linking / custom libraries), turn on the "socket traffic" switch as a fallback and take a lower-level path to the data.

6. Proxy Capture: No Root, or View-and-Modify on the Fly

When the device isn't rooted, or you need to do rule rewriting / replay on requests, take the proxy route: point the phone's Wi-Fi proxy at your computer and install the root certificate, and you can capture HTTPS plaintext just like on a PC, with full rewrite and replay capabilities.

In the phone's Wi-Fi settings, point the proxy at your computer (the tool provides the address and port).
Install the root certificate on the phone: usually by scanning a QR code for one-click installation; see Certificate Installation for details.
On newer Android versions where apps don't trust user certificates: if the device is rooted, let the tool install the certificate at the system level; if the app uses certificate pinning, see Bypassing Certificate Pinning.
Go back to the tool and start capturing, then use the app on the phone.

7. Verification: Confirming You Captured and Decrypted

Click any entry in the request list and check the details:

You can see the request: the request line, request headers, and body are all there.
TLS shows "Decrypted": the response is readable plaintext (e.g., JSON), not garbled ciphertext.

With whole-device methods (NIC key / NIC capture), HTTPS for most apps shows up as plaintext directly; a few apps that use built-in / non-standard crypto components may only emit ciphertext — use app-layer capture to target them.

8. Can't Capture or Decrypt? Check Item by Item

Symptom	Most likely cause	What to do
Device doesn't appear in the list at all	USB debugging not enabled, or "Allow" not tapped	Enable USB debugging on the phone and allow this computer; restarting the emulator once usually gets it detected
"NIC capture not supported"	Device kernel is too old to meet the NIC capture prerequisites	Switch to NIC key, which doesn't care about the kernel
Traffic captured, but one app only shows ciphertext	That app uses built-in / non-standard crypto components	Switch to app-layer capture for that app to get plaintext from inside
App-layer capture also can't get plaintext	The target is a stubborn app with static linking / custom libraries	Turn on the "socket traffic" switch as a fallback
You only want the few requests from when the app starts, but always miss them	The app is already running when you start capturing	In app-layer capture, check "Restart target program" to capture its early-startup traffic
Certificate installed, but HTTPS still can't be captured through the proxy	Newer Android doesn't trust user certificates by default, or the app uses certificate pinning	If rooted, install the certificate at the system level; or just switch to the certificate-free NIC key / NIC capture; for pinning see Bypassing Certificate Pinning

Next Steps

How to read, switch views, and decode after capturing: see Data Viewing and Decoding.
To modify a request before sending it, or intercept and edit it mid-flight: see Request Construction and Replay, Rule Rewriting and Breakpoint Interception.
For an app's certificate pinning: see Bypassing Certificate Pinning.
To capture iPhone / iPad: see iOS Capture.

Learn Swift iOS Development from Scratch: Getting Started with iOS Apps

CoreDataHero — Thu, 10 Sep 2026 10:22:22 +0000

A friend of mine who works in backend development wanted to move into iOS development, so he bought a Mac mini to get started. On the first weekend he messaged me: Xcode had pulled down an installer over ten gigabytes, he created a project and got the simulator running, but the real-device debugging step stalled him for two days — certificates, provisioning profiles, developer accounts, not one of them was painless. After a lot of back and forth, he finally got it running by manually configuring the signing on the command line. That got me thinking: when you start learning Swift and Xcode development, setting up the environment is itself the first hurdle. A lot of people burn a fair amount of enthusiasm at this step.

The traditional path: Xcode + macOS

The standard approach is to install Xcode on a Mac — download it from the App Store, install over ten gigabytes of components and the iOS SDK, and wait a good while. Open Xcode, create a project, pick a SwiftUI or UIKit template, then configure signing. Before debugging on a real device you need to register an Apple Developer account (free or paid), add your Apple ID in Xcode Preferences, and generate certificates and provisioning profiles. Once you get through it, everything afterwards goes smoothly, but for a first-timer with nobody guiding them, not many people make it through all these steps on their own. Quite a few people in my group chat got stuck right here.

Xcode is feature-complete, but you won't use every feature. For beginners just getting into Swift, Interface Builder, Storyboard, the Core Data template, and the various debugger panels are all extra baggage at the start. All you want to learn is Swift syntax and basic UI construction, yet you get distracted by the complexity of the tooling itself. Just figuring out provisioning profiles and signing configuration can keep a newcomer busy for a day or two.

Another path: KXApp

KXApp takes a streamlined approach — its installer is far smaller than Xcode's, requires no separate installation of Command Line Tools or the iOS SDK, and ships with a complete compiler toolchain built in. When you create a Swift project, it generates a standardized structure with one click, so you don't have to build a template by hand. The coding interface is based on VS Code, with intelligent completion and an AI code assistant working out of the box, which makes writing code feel natural.

Real-device debugging saves a lot of steps: once the iPhone is connected to the computer, click Build and Install, and KXApp compiles, signs, and installs straight to the phone. You don't need to configure certificates or provisioning profiles yourself, and you don't need to open Xcode Organizer. For someone who has never touched iOS development, following the documentation from installing the software to running their first Swift app on a real device takes considerably less time than going the Xcode route.

After a project is complete, KXApp also supports one-click builds that produce an IPA package for test distribution or submission to the App Store. From creating a project to coding to packaging, the whole flow happens in the same tool, so you don't have to go back and install Xcode just to package.

How to choose between the two paths

If your goal is to study iOS internals in depth and do native development down the road, Xcode is unavoidable — mainstream projects all use it. But if you're self-teaching to get started, building your own independent project, or coming from another language to test the waters, KXApp has a much lower learning cost and lets you focus on Swift syntax and logic itself rather than toolchain configuration.

My approach is to suggest that friends just starting out use KXApp to quickly get their first Hello World running and see their own Swift code running on a real device, which builds a fast feedback loop. Once they have a feel for and confidence in the basic iOS development flow, they can decide whether to go deeper into the Xcode ecosystem. The two paths don't conflict; at the starting stage, picking the easier one and getting something running first is far better than being scared off by the toolchain right away.

TraceEagle System-Level Capture Tutorial: Capture macOS Built-in Apps and Stubborn Apps as Plaintext

CoreDataHero — Thu, 10 Sep 2026 10:10:26 +0000

System-Level Capture

This guide shows you how to use "System-Level Capture" to capture macOS built-in apps and those stubborn, deeply hidden apps: without entering the process and without touching certificates, observing purely in bypass from beneath the system, so that even targets other capture methods can't reach are read as plaintext. This is the last resort among local capture methods — use it when the previous ones all fail.

1. When to Use This Capture Method

It fits if any one of the following applies to you:

You want to see what macOS built-in apps / system services (App Store, system components, background services, etc.) are saying to their servers.
The target is a stubborn, deeply hidden third-party app: it rejects all external intervention, proxies can't get in, and pulling plaintext from inside the process is blocked as well.
You've tried the previous capture methods — proxy rejected, application-layer capture refuses to intervene, only ciphertext left on the NIC — and you still need plaintext.

If it's just an ordinary program (browser / script / CLI), Specified Program Capture or Application-Layer Capture is easier; system-level capture is overkill.

2. Prerequisites

Running on macOS (this guide covers the macOS system-level method).
TraceEagle is installed and started; simply agree to the system permissions on first launch.
You know the capture target: a running program, or its program path / name.
No certificates to install and no system proxy to change — this capture method performs no man-in-the-middle and never touches certificates.

3. Start Capturing: Three Steps to Your First Capture

Create a session and choose "Local System-Level Capture".
Pick a target: select a running program from the dropdown, or enter the program path / name directly.
Optionally enable capture "the moment it starts": once checked, the tool first shuts down the target and then launches it itself, so that traffic from the early startup phase is captured as well — a great deal of authentication and handshaking happens at that very instant, and leaving it unchecked makes it easy to miss.
Click Start. The tool observes this program in bypass from beneath the system and reads out the plaintext it sends and receives.

Have the target program generate network requests (in a system app, click an operation that goes online) and the traffic will show up in the request list in real time.

4. Verification: Confirm the Capture and Decryption

Click any entry in the request list and look at the details:

The request is visible: request line, request headers, and body are all there.
TLS shows "Decrypted": the request and response are readable plaintext (such as JSON), not garbled ciphertext.

System-level capture does not inject, does not modify the program, and does not touch certificates, so even if the target performs strict certificate validation, it cannot affect the plaintext read out here.

5. Nothing Captured / Can't Decrypt? Troubleshoot Item by Item

Symptom	Most likely cause	What to do
Can't select a target / it's not in the dropdown	The program isn't running yet	Start the target program first, then come back and select it from the dropdown; or enter the program path / name directly
Captured, but the very first handshake / authentication is missing	The key traffic happened in the early startup phase, already over by the time you started capturing	Check capture "the moment it starts" so the tool first shuts down the target and then launches it, covering the early startup phase as well
Not a single request	The wrong target was selected, or that program isn't online right now	Confirm you selected the program that is actually doing the networking; trigger an operation that goes online and look again
You want to use it for ordinary programs too	System-level capture is overkill for ordinary programs	For ordinary programs, switch to Specified Program Capture (which can launch it by command) or Application-Layer Capture (already running)

6. How to Choose Among the Four Local Capture Methods

Your situation	Which to use
macOS built-in apps and stubborn apps (other methods can't capture them)	System-level capture (this guide)
The program is already running / certificate pinning / doesn't honor proxies / proprietary encryption	Application-layer capture
An ordinary program that can be launched by command (browser / script / CLI)	Specified program capture
You want to see all traffic on the machine, including non-HTTP traffic	NIC capture

Next Steps

How to read what you captured, switch views, and decode it: see Data Viewing and Decoding.
For private / proprietary protocols you want to teach it to read yourself: see Custom Protocol Decoding.
To modify a request and resend it, or intercept it mid-flight and edit it by hand: see Request Construction and Replay and Rule Rewriting and Breakpoint Interception.

Apple Account Management Guide: Practical Operations for Team, Membership Status, and License Activation

CoreDataHero — Wed, 09 Sep 2026 09:47:11 +0000

Account Overview

The first stop after logging in, it centrally displays the current account's teams and developer membership status, and provides two derived features: activation of the Happy Launch license itself, and App Store Connect API key management.

Team

An Apple ID may belong to multiple developer teams simultaneously. In the “Team” section, you can see all teams under this account. Click “Activate” to switch the currently active team (free accounts display “Free Account”). After switching, features such as certificates, Bundle IDs, provisioning profiles, devices, and apps will be reloaded based on the newly activated team.

Account Information

Displays the current login method (Web Login / App Login / API Key), name, account email, last used time, and developer status-related information:

Developer Membership: Apple Developer Program membership information for the team, including team name, team ID, Agent email, and Roles.
Certificates & Provisioning Profiles Permission: Whether the current account is allowed to manage certificates and provisioning profiles.
Can View All Apps: Whether you have permission to view all apps under the team.

If this Apple ID does not have a developer program membership, the page will show “Not enrolled in the Apple Developer Program”, indicating that you cannot access developer portal features such as certificates and provisioning profiles. Two directions are provided: go to developer.apple.com to purchase a membership, or log in with Web Login first, then generate an API key to use App Store Connect features independently (without relying on developer portal membership).

Happy Launch License

“Happy Launch License” is the usage license for this product itself (separate from Apple’s developer membership). It is bound to the current Apple ID:

If not yet activated, click “Activate Happy Launch License” and enter the activation code you purchased.
The activation code will be bound to the current Apple ID; after submission, the activation is complete.
After activation, you can view the license email and expiration time here. Before expiration, you can click “Refresh” to check the latest status.
If you don’t have an activation code, click “Go to Official Website to Purchase” (appuploader.net).

App Store Connect API Key

Used to generate passwordless, second-factor-free, long-lived login credentials. You can combine it with the “API Key” method under “Account & Login” to sign into the same App Store Connect account on any device:

Click “Generate Key” and enter a key name.
After submission, an App Store Connect API key (ADMIN permission, access to all apps) is generated, using JWT for authenticated access to App Store Connect.
The private key (.p8) can only be retrieved this once. Copy or download it immediately and save it as a .json key file. This .json file can be directly imported on the login page via “Add Account → API Key → Key File”.
The key list supports exporting the key file (.json) at any time (provided the private key for this key has been saved on this machine), or revoking a key — after revocation, all ASC accounts derived from it will immediately fail authentication and cannot be recovered.

Understanding the iOS Compiler: The Full Pipeline from Source Code to Machine Code

CoreDataHero — Wed, 09 Sep 2026 09:43:45 +0000

Every time you hit Run or Archive in the IDE, a full compilation pipeline operates behind the scenes. Understanding how compilers work helps you understand why builds vary in speed, which stage an error message comes from, and how tools like KXApp with an embedded compiler accomplish compilation.

Three Stages of the Compiler

The compilation process for an iOS app can be summarized into three stages. Front-end processing — lexical analysis and syntax analysis — transforms source code into an abstract syntax tree (AST). Swift uses swiftc, while Objective-C uses clang. Middle-layer optimization converts the AST into an intermediate representation. Swift goes through SIL (Swift Intermediate Language) for type checking and optimization before being lowered to LLVM IR. Clang directly generates LLVM IR.

Back-end processing — the LLVM back-end takes the IR and generates machine code for the target CPU architecture. iOS devices today are primarily arm64; simulators run x86_64 on Intel Macs and arm64 on Apple Silicon Macs.

The compiler also has several optimization levels: -Onone performs no optimization (used for debugging); -O performs standard optimization; -Osize optimizes package size; -Ofast performs fast optimization. Different optimization levels affect compilation speed and the execution efficiency of the generated code.

Swift Compilation Specifics

The Swift compiler adds an extra SIL pass compared to Objective-C. SIL is Swift's high-level intermediate representation. During the SIL phase, the compiler performs type checking, generic specialization, and method dispatch decisions. This is one of the main reasons Swift compilation is slower than Objective-C — SIL analysis and optimization take extra time.

Swift's modular compilation also affects build speed. Each file is compiled independently and communicated with through modules. Changing one file only requires recompiling that file and its dependencies, but it also introduces overhead in parsing module interfaces.

How KXApp's Built-in Compiler Works

KXApp includes a complete iOS compilation toolchain, including swiftc, clang, and the ld linker. It can convert source code into executable files without requiring Xcode to be installed on the system.

When you create a new Swift project in KXApp and tap Build, the toolchain completes the entire compilation flow. The front end uses the built-in swiftc to parse source code and generate SIL and LLVM IR; the LLVM back-end produces arm64 machine code. The linker merges the generated object files with system libraries into a Mach-O executable, which is then signed and packaged as an IPA.

KXApp handles Flutter projects differently. Flutter's Dart code is AOT-compiled into native ARM library files that are embedded into the IPA. KXApp has built-in Dart compilation support, so it doesn't need an external Flutter SDK environment when processing Flutter projects — the complete compilation chain is completed inside the tool.

Locating Compilation Errors

Understanding the compilation stages helps you quickly locate errors. Syntax errors are thrown during front-end parsing and point to specific line and character positions. Type errors are detected during SIL analysis; error messages from Swift's type checker are usually precise.

Linker errors occur at the linker stage, and error messages typically don't include line numbers. "Undefined symbols" means a symbol has only a declaration but no implementation; "duplicate symbol" means the same symbol was defined multiple times. Signing and packaging issues appear at the final packaging stage, with the most common error being a mismatch between certificates and provisioning profiles.

TraceEagle Proxy Capture Tutorial: HTTPS Capture Methods for Local Machine and Mobile Phones

CoreDataHero — Tue, 08 Sep 2026 10:17:21 +0000

Proxy Packet Capture

This guide teaches you how to use proxy packet capture to route network requests from your local machine, mobile phone, or other devices on the LAN into TraceEagle for inspection. Once you select an access mode and install the certificate, you can see every request in real time, and HTTPS traffic can be decrypted into readable plaintext (JSON, form data, and more). This is the most universal capture method—configure it once, and you can capture traffic from browsers, command-line tools, apps, and mobile phones.

1. When to Use This Method

This method is suitable if you meet any of the following criteria:

You want to capture HTTPS traffic from multiple programs on your local machine or from the entire machine, view plaintext, and decrypt it.
You want to capture requests from mobile phones / tablets / other computers on the LAN (just point their proxy to this machine).
You need to rewrite requests, intercept at breakpoints, replay, and compare while capturing—proxy capture works hand-in-hand with these capabilities.

If you only want to capture a single program that can be launched from the command line and do not want to install a certificate, use Designated Program Capture—it is simpler. If the program is already running, uses certificate pinning, or does not honor proxy settings, see Application-Layer Capture.

2. Prerequisites

TraceEagle is installed and running. (On first launch, accept the system permission when prompted.)
To capture HTTPS plaintext, you must first install a certificate: without a certificate, you can only see encrypted ciphertext. Follow Certificate Installation to install and trust the capture certificate. To capture phones/tablets, install the certificate on that device.
Decide which access mode to use (two modes are listed in the next section; you can switch at any time if you cannot capture).

3. Choose an Access Mode: Two Local Access Options

How traffic enters the capture depends on your scenario. In the session toolbar, choose Proxy Local Machine → gear icon Access Settings to select one of two access modes:

Traditional Proxy (uses system proxy, classic capture): One-click access. Browsers, command-line tools, and most applications automatically route through the proxy. When stopped, it restores automatically to ensure normal Internet access. This is the fastest way to get started, so use it first. Limitation: apps that do not respect the system proxy will not be captured.
Transparent Proxy (full traffic): No application configuration required. It can capture all traffic on the local machine (including direct connections and traffic forwarded by this machine acting as a hotspot/gateway). Apps that ignore the system proxy are still captured. You can also precisely scope by application/process to capture only specific programs. Choose this mode if you want to capture non-proxy-aware programs or only specific apps.

If you are unsure, start with Traditional Proxy; if you encounter no traffic at all, switch to Transparent Proxy.

4. Start Capturing: Step by Step

Create a new session and select Proxy Local Machine.
Click the gear icon Access Settings in the session toolbar, then choose Traditional Proxy or Transparent Proxy in Access Mode (see the previous section).
HTTP/3 (QUIC) handling: In the same Access Settings area, choose the level you need:

Disable (downgrade for capture): Downgrades HTTP/3 to ordinary connections for capture (a few apps do not support this). Selecting this is the most stable option.
Ignore (faithful pass-through): Forwards as-is without decryption, without interfering with the program's data requests.
Decrypt (true H3 MITM): Actually captures and decrypts HTTP/3, enabling plaintext viewing just like ordinary HTTPS. This option must be used in Transparent Proxy mode (Traditional Proxy only supports Disable / Ignore).

(Optional) Define the decryption scope: In the decryption scope settings, you can switch between blacklist / whitelist, and configure allowlist / blocklist:

Whitelist: Decrypts only the domains you specify; everything else is passed through directly, keeping the capture list cleaner.
Allowlist: Causes certain sites with strict verification to be passed through unchanged without decryption, avoiding connection errors.
Blocklist: Directly blocks the domains you do not want to pass through.

Click Start, and let the program generate requests (open a website in your browser, or send a request from the command line). Traffic appears in the request list in real time; each entry shows the method, status, host/path, size, and source process.

Capturing LAN Devices (Phone / Tablet / Other Computers)

First set up a proxy capture session on this machine following steps 1–4 above (it is recommended to use Transparent Proxy).
Follow Certificate Installation to install and trust the capture certificate on that device.
Point that device's Wi-Fi proxy to this machine's IP address plus the session listening port (the phone and computer must be on the same LAN).
Open an app / webpage on the device to generate requests; the traffic will show up in this machine's request list.

5. Verification: Confirm Capture and Decryption

Click any request in the list and inspect its details:

The request is visible: the request line, headers, and body are all present.
TLS shows Decrypted: the response is readable plaintext (e.g., JSON), not garbled ciphertext.
Source process / application is labeled: in a mixed environment, you can tell at a glance which entry belongs to which sender.

6. Can't Capture / Can't Decrypt? Troubleshoot Item by Item

Symptom	Likely cause	What to do
No traffic at all	The program does not use the system proxy	Switch the access mode from Traditional Proxy to Transparent Proxy (full traffic) so non-proxy-aware programs are captured too
Captured, but everything is ciphertext / garbled	Certificate not installed, or not trusted by this device	Install and trust it via Certificate Installation; to capture a phone/tablet, install the certificate on that device
Certificate installed but a certain program still cannot be decrypted	The target uses certificate pinning (Pinning)	See Bypass Certificate Pinning to remove its certificate validation with one click and continue decrypting
A site fails to connect / reports errors when the proxy is on	The site has strict validation and does not accept man-in-the-middle decryption	Add it to the allowlist for unmodified pass-through, or use the whitelist to decrypt only the domains you need
HTTP/3 traffic is incomplete	The target uses HTTP/3 (QUIC)	In `Access Settings`, set HTTP/3 to `Disable` (downgrade for capture); to decrypt H3 directly, switch to Transparent Proxy and choose `Decrypt`
Phone is set to proxy but still no traffic	Proxy address / port is wrong, or not on the same LAN	Check this machine's IP and session listening port; confirm the phone and computer are on the same network; the certificate must also be installed on the phone
Phone / computer already running, don't want to change its proxy	Both traditional and transparent proxy require the target to go through this machine	Use iOS Packet Capture / Android Packet Capture for direct connection, or Application-Layer Capture

7. How to Choose Among the Four Local Capture Methods

Your situation	Use this method
Capture multiple programs / the whole machine, capture phones and LAN devices, and need companion rewrite/replay	Proxy Packet Capture (this article, the most universal)
Only capture a single program that can be launched via command line, and skip certificate installation	Designated Program Capture
Watch all machine traffic, including non-HTTP traffic	Network Interface (NIC) Capture
Program already running / certificate pinning / doesn't honor proxy / custom encryption	Application-Layer Capture
macOS system built-in apps / stubborn applications	System-Level Capture

If you haven't installed the certificate or want to capture a phone: see Certificate Installation first; for certificate pinning, see Bypass Certificate Pinning.
For a more convenient, direct-connection way to capture mobile apps without setting a proxy: see iOS Packet Capture and Android Packet Capture.
To learn how to interpret captured data, switch views, and decode payloads: see Data Viewing and Decoding; for private / custom protocols, see Custom Protocol Decoding.
To modify a request and resend it, or intercept and edit it manually mid-flight: see Request Construction and Replay, and Rule Rewriting & Breakpoint Interception.
To identify the remote host, its attribution, and certificate: see Host Details.

Project URL: https://github.com/traceeagle/traceeagle

Cross-Platform Packet Capture Tool Choices: Packet Capture Solutions for Windows, Mac, and Linux

CoreDataHero — Tue, 08 Sep 2026 10:09:10 +0000

Most packet capture tools have platform limitations. Charles and Proxyman deliver the best experience on macOS, but on Windows the certificate configuration process is more complex. Fiddler is primarily for Windows, and the Mac version is only a feature-limited Beta. Wireshark runs on all platforms, but for mobile iOS traffic capture it requires the rvictl command (macOS only), and is not directly usable on Windows and Linux. If you need to switch between multiple operating systems, or your team has some members on Mac and others on Windows, platform compatibility becomes an important criterion when choosing a tool.

Tool Distribution by Platform

macOS offers the most choices: Charles, Proxyman, Wireshark, Surge, Paw, plus the debugging tools built into Xcode. On Windows, Fiddler dominates, and Charles also works but with a less polished experience than on Mac. Linux has the fewest options; Wireshark + tcpdump is the most common combination, with proxy-based capture tools largely absent.

A real problem for cross-platform teams is that Windows developers and Linux servers cannot use the same set of capture tools. A Charles SSL configuration set up on Mac must be redone from scratch on Windows, and in Linux CI environments there is no suitable proxy tool to integrate capture steps, so teams often have to rely on tcpdump for raw captures followed by manual analysis.

TraceEagle's Cross-Platform Approach

TraceEagle provides the same functionality and interface on Windows, macOS, and Linux. All three capture modes—proxy capture, direct NIC capture, and in-app stream retrieval—are available on every platform, so you don't need to switch tools when you switch systems. The same configuration can be migrated between different systems; rules configured on Windows take effect directly when brought to Mac.

On Windows, proxy capture does not require installing an extra iTunes driver, and NIC capture works directly. Linux supports both command-line and GUI modes, and the command-line version can be used for automated capture in CI environments. On macOS, the functionality is consistent with the other two platforms.

For mobile capture, TraceEagle does not require rvictl or additional commands. iOS devices can be captured directly when connected via USB, and the steps on Mac and Windows are identical.

Multi-Device Collaboration

TraceEagle supports remote capture. You can start a capture task on another machine from one machine, for example initiating a remote capture task on a Linux server from Windows. This is practical for troubleshooting network issues on servers or automating capture in CI environments.

Captured data can be viewed and analyzed across platforms. Traffic can be exported to pcap format and further analyzed with Wireshark. The OpenAPI documentation and generated code are independent of the platform where the traffic was captured, so they can be directly used for documentation management or code reuse.

Selection Recommendations

If your team's development environment is unified (all Mac or all Windows), just choose the tool that matches your operating system. For teams that need to develop across multiple platforms, scenarios where Linux servers require packet capture debugging, or teams with both Windows and Mac developers needing a unified capture toolchain, TraceEagle can serve as a common solution.

Platform compatibility is only one dimension of the selection process. Actual capture capability, HTTPS decryption support, and edge-case coverage should also be considered together.