DEV Community: ObjC_Coder

iOS Development Without Xcode: Toolchain Alternatives and Compiling, Signing, and Installing

ObjC_Coder — Thu, 24 Sep 2026 10:12:54 +0000

I used to think there was no way around Xcode for iOS development: install a dozen-plus GB of Xcode on a Mac, chase it along with every OS version update, and delete things first when disk space runs out. It wasn't until I got an iOS project running on a Windows machine that I realized what iOS development actually requires is the compilation toolchain, signing and packaging, and on-device installation — Xcode is just the shell wrapped around those things. The shell can be swapped; the toolchain can be built in. This article breaks down the two paths to Xcode-free iOS development, then covers which steps you still can't get around.

What Exactly Does Xcode Lock Down

Let's start with what Xcode locks down. For an iOS project to become an installable app, three steps are indispensable: compilation (clang for C/OC, swiftc for Swift, the linker combining objects into an executable), signing (certificates and provisioning profiles signing the executable), and installation (installing to a real device or exporting an IPA). Xcode bundles this toolchain together with the IDE, weighs over a dozen GB, and requires macOS. For Windows users, or for people whose Mac disk is tight, what's blocking you isn't iOS development itself — it's the Xcode entry point.

Path One: Cloud Builds

The first path is cloud builds: write code locally, and put compilation and packaging on CI or a cloud machine, where Xcode is installed and xcodebuild runs; download the artifacts for distribution. It suits automated release pipelines, but during development and debugging, on-device verification still can't be avoided — changing a line of code means pushing to the remote and waiting for a build, and a round trip takes several minutes, which isn't a great experience.

Path Two: An IDE with a Built-in Toolchain

The second path is switching to an IDE that ships with its own toolchain. KXApp (KuaiXie) comes with a built-in compilation tool suite, so you can compile iOS projects without installing or updating Xcode, and it runs on both Windows and Mac. When creating a project in KXApp, choose Swift, Objective-C, or Flutter, and a standardized project structure is generated in one click — no manual template setup; the editor is built on the VS Code core, so the coding experience matches VS Code, and AI coding assistant plugins plug right in.

Hands-On Workflow

The hands-on workflow is smoother than you'd expect: once the project is created, connect an iPhone and click one-click build; KXApp's compilation toolchain handles compilation and signing and installs directly to the device to run; code changes sync quickly to the phone, making debugging intuitive. When development is done, click to generate an installation package in one click, covering test distribution and App Store submission — no need for the whole Xcode IPA export routine. The entire pipeline closes the loop inside the IDE.

Who is this path for? Independent developers doing cross-platform work on Windows with only an ordinary-spec machine; veterans whose Mac disk is perpetually in the red and who are tired of being jerked around by Xcode updates; and teams where newcomers have to wait for Xcode to finish downloading before they can start — an IDE with a built-in toolchain is ready to write the moment it's installed, no waiting for a dozen-plus GB environment. Conversely, for scenarios that depend heavily on Xcode-specific features (drawing UI in Interface Builder, performance analysis with Instruments), the two paths can coexist: use the lightweight toolchain for day-to-day development and open Xcode for specialized tasks when needed.

The Boundaries You Can't Get Around

A few things can't be avoided, and it's worth being clear about them: you still need to register an Apple Developer account, and App Store review must go through Apple; certificates and provisioning profiles still need to be configured, with signing handled by the corresponding tool — a distribution certificate plus an App Store provisioning profile to package and upload; the iOS system and device ecosystem belong to Apple, and the app ultimately runs on an iPhone. Xcode-free means freeing yourself from the development tool itself, not from the rules of iOS development.

The essence of Xcode-free iOS development is giving compilation, signing, and installation a lighter entry point. Once the toolchain is complete and the workflow closes the loop, whether you use Xcode is just a matter of habit.

TraceEagle Packet Capture Rule Rewriting and Breakpoint Interception: Several Ways to Modify Requests and Mock Data

ObjC_Coder — Wed, 23 Sep 2026 09:59:06 +0000

Liquid syntax error: 'raw' tag was never closed

appuploader-cli CI/CD Integration: Auto-Uploading IPA Guide

ObjC_Coder — Mon, 21 Sep 2026 10:24:45 +0000

appuploader-cli CI/CD Integration: Auto-Uploading IPA

When your build pipeline runs on a machine without a Mac (a Windows/Linux CI runner, say), having to manually click a button for the final upload step is rather awkward. appuploader-cli turns that step into a single command: it is the command-line tool bundled with AppUploader, and uploading depends on neither Xcode nor macOS.

Step 1: Locate the Executable

Once the main app is installed, the command-line tool is already in the installation directory:

macOS: AppUploader.app/Contents/Resources/appuploader-cli
Windows: appuploader-cli.exe in the same directory as the main AppUploader.exe

cd into that directory to run it directly, or add the directory to your CI runner's PATH environment variable so scripts can call it directly.

Step 2: Upload the IPA/PKG

appuploader-cli upload -f <IPA/PKG path> -u <Apple ID> -p <app-specific password> [--type ios]

Parameter	Description
`-f, --file`	Path to the IPA / PKG file to upload (required)
`-u, --username`	Apple ID email (required)
`-p, --password`	App-specific password, in the format `xxxx-xxxx-xxxx-xxxx` (required; this is not your login password)
`--type`	Package type: `ios` / `osx` / `appletvos` / `xros`; defaults to `ios`

Example:

appuploader-cli upload -f Payload.ipa -u dev@example.com -p abcd-efgh-ijkl-mnop

The upload prints progress and result logs in real time. On failure, the log includes the specific reason (duplicate package, version number conflict, signature mismatch, etc.), so you can pinpoint the problem directly in the CI log.

Step 3 (Optional): Generate the App Store Resource Description File Locally

If you only want to validate the package contents locally before uploading, or you need an AppStoreInfo.plist for another upload tool, use the info command. It performs local analysis only and never actually uploads:

appuploader-cli info -u <Apple ID> <file path> [-o output file] [--format xml|binary]

The --deterministic flag pins fields that would otherwise change, such as the UUID, process ID, and timestamp, making it easy to compare output byte-for-byte in CI — handy for writing automated tests.

How to Wire It Into a CI/CD Pipeline

Whether you use Jenkins, GitHub Actions, or any other CI system, the integration is the same: after the build produces the IPA, add a step that runs the appuploader-cli upload command, and inject the credentials through the pipeline's secret / environment-variable mechanism instead of hardcoding them in the script. Because appuploader-cli itself does not depend on macOS, your CI runner does not need to be a Mac either.

When an upload fails, the command's exit code is non-zero, so the pipeline can simply use the exit code to decide whether this step succeeded — no log parsing required:

set -e
appuploader-cli upload -f "$WORKSPACE/build/App.ipa" -u "$APPLE_ID" -p "$APP_SPECIFIC_PASSWORD"

Using an API Key Instead of a Personal Account

Hardcoding someone's Apple ID and password into the pipeline means the automation breaks as soon as that person leaves or the password changes. For teams, an App Store Connect API key is the better fit — it belongs to the team and can be revoked independently:

appuploader-cli upload -f build/App.ipa \
  --api-key "$ASC_KEY_ID" \
  --api-issuer "$ASC_ISSUER_ID" \
  --private-key AuthKey.p8

Generate the key at https://appstoreconnect.apple.com/access/api; the .p8 private key can only be downloaded once. In CI, store the contents of the .p8 as a secret, write it to a temporary file when needed, and delete it afterward. These three parameters and -u/-p are two different methods — you can only use one set.

Note that the API key method supports only .ipa, and the bundle ID must already have an app created in App Store Connect; for .pkg on macOS, still use -u/-p.

Lightweight iOS IDE kxapp: Complete Project Development and Debugging Without Xcode for iOS Development

ObjC_Coder — Sun, 20 Sep 2026 12:53:05 +0000

After doing iOS development for a while, the choice of IDE actually directly affects your daily coding rhythm. Whether the editor is smooth, whether project creation is concise, and whether device debugging is convenient—these details come up repeatedly in day-to-day development.

A while ago, while working on an experimental utility app, I tried switching to a different development environment. Instead of continuing with my usual project configuration, I ran the project end to end in an iOS IDE called kxapp. The project wasn't large, but it was just enough to verify how the IDE performs in project creation, code writing, device debugging, and app building.

Creating a New iOS Project

After opening the kxapp IDE, you see a fairly clean startup screen. Click Create Project, and the IDE offers several different project types:

Swift
Objective-C
Flutter

For this test, I chose a Swift project. After entering the project name and save path, the IDE generates the project structure.

The project directory already contains basic code files and a resources directory. You can open the entry file and start writing code, with no additional configuration steps.

During project creation, you can clearly feel that the IDE has already prepared the development environment. There are no issues with missing SDKs or build tools, and no prompts to download additional components.

For scenarios that require quickly starting a project, this approach is quite straightforward.

Writing Code in the IDE

The kxapp IDE's editor is built on the VSCode architecture. For developers accustomed to VSCode, this interface structure will feel familiar.

The left side is the project file list, the middle is the code editing area, and the bottom is the output panel.

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

The page contains a text label
A button used to update the content

When the button is clicked, it calls a method that reads a local configuration file and then displays the content on the interface.

While writing code, the editor provides code completion and syntax hints. For example, when you type a class name or method name, the IDE automatically offers a suggestion list.

If there are syntax errors in the code, the editor displays hint information on the corresponding line.

The VSCode extension system can also continue to be used, so AI code assistants or formatting tools can be installed directly.

Connecting an iPhone for Debugging

After the project code is written, it needs to be run on a phone for verification.

Connect the iPhone to the computer via a data cable, then build.

The build process automatically performs the following steps:

Compile the project source code
Generate the application
Install the app on the phone

After a few seconds, the app icon appears on the phone's home screen. Tap the icon to launch the app.

To confirm the logic was correct, I tapped the page button, and the text label successfully displayed the contents of the configuration file.

Then I changed the button color in the code and clicked the run button again. The IDE recompiled the app and installed the new version, and the app interface on the phone updated accordingly.

This debugging process was fairly smooth, because after modifying the code you can quickly see the running result.

Built-in Compilation Tools in the IDE

Throughout the entire development workflow, the IDE did not invoke an external development environment.

The kxapp IDE has a built-in compilation tool suite. When the IDE is installed, these tools are already configured.

When you click the run or build button, the IDE invokes the internal compilation tools to complete code compilation and app building.

This approach means developers do not need to install Xcode separately. Compilation, running, and build operations can all be completed in the same IDE.

For projects that need to frequently compile test builds, this environment configuration approach reduces a lot of preparation time.

Managing Different Types of Projects

To test the IDE's project support capabilities, I created another Flutter project.

After the Flutter project was created, I wrote a simple page, connected an iPhone, and clicked run; the IDE compiled and installed the app on the phone.

Afterward, I created an Objective-C project for testing, and it also ran normally.

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

Native Swift projects
Objective-C projects
Flutter projects

This approach is quite convenient when maintaining projects across multiple technology stacks.

Building an App Installer Package

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

In the kxapp IDE, you can generate an installation file through the build menu. The IDE compiles and generates the app installer package.

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

The generated installation file can be used for test installation or submission to the app store.

How to Check Host Details While Capturing? Traceeagle ASN, TLS Ratings & Web Stack

ObjC_Coder — Wed, 16 Sep 2026 10:08:53 +0000

Host Details

This article shows you how to click open any host during packet capture and see its full profile on a single screen: who it belongs to (ASN / organization / registration), where it is (geo map), how healthy its certificate is (TLS checkup + rating), and what technology it runs (web tech stack). It works whether you have an IP or a domain name — just click and look it up. Useful for troubleshooting, security auditing, and asset inventory.

1. When to Use It

It fits you if any of the following applies:

You captured a flow and want to know who the peer actually is — which data center / ISP it goes through, which organization it belongs to.
You are doing a security audit: you want to verify whether the certificate is trusted, whether it is about to expire, and whether the cipher suites are strong enough.
You are doing asset inventory / traceback: you want to follow a certificate and dig out every hostname and related subdomain it covers in one pass.
You want to get the abuse contact for a given IP so you can file a complaint.

In short: in an ordinary capture tool, a flow stops at "one IP + one domain name." When you want to see more, open the host profile.

2. Prerequisites

TraceEagle is installed and running.
You have a captured flow, or a known IP / domain / SNI.
Lookup requires network access (ownership, geolocation, DNS, certificate checkup, and similar data are fetched in real time).

3. Step-by-Step

1. Find a clickable host

Anywhere the UI shows a captured hostname / IP / SNI, you can click to open the profile. Common entry points:

The destination IP and hostname in HTTP flow details.
The destination IP and SNI in TCP / TLS flow details.
Right-click in the traffic list or packet view and choose "View Host Details" from the menu.
The peer host in the live connections panel.

2. Click to open the profile

After you click a host, the profile panel auto-fills and starts querying; the full results appear shortly. Below we walk through each section from top to bottom.

3. Look at ownership (whose IP is this)

The resolved IP and reverse DNS (PTR).
ASN: number + name + announced route prefix (CIDR).
The organization, registry, and country.
The netblock (CIDR + allocation type).
The abuse contact — use it directly to file a complaint.

4. Look at geolocation (where it is)

City / region / country (including ISO code).
The host's exact location is marked directly on a world map, visible at a glance.

5. Look at DNS records

A / AAAA / MX records, showing type / value / TTL.

6. Look at the TLS certificate checkup (is it secure)

This is the section security audits consult most often:

The A / B / C / F security rating (highlighted color code), so you can judge health at a glance.
Whether the hostname matches, whether the certificate chain is trusted, and expiry status (expired / days remaining).
TLS version, certificate issuer and subject (organization).
Together with TLS auditing you can go further and see:
- The full certificate chain (subject / issuer / validity period / days remaining / DNS names / is CA / key type / signature algorithm / self-signed).
- The list of supported protocols, the cipher suites and their strength (weak-suite / forward-secrecy flags), and the suite actually negotiated in this handshake.
- Certificate Transparency (CT) logs — list every hostname covered by a certificate in one pass along with the total count, digging out related subdomains that never appeared in the traffic. This is where you dig deeper during traceback.

7. Look at the web tech stack (what it runs)

Page title, Server header.
Recognized servers / frameworks / CMSs / libraries, displayed as tags.

4. Verification: Confirm the Lookup Succeeded

After opening a profile, check the following points to confirm the information is in place:

The ownership section shows ASN, organization, and country — not blank.
A marker appears on the map.
The certificate checkup gives an A / B / C / F rating color code.
If the target is a website, the tech stack section shows recognized tags.

If a section does not appear, it is most likely that the target itself has no such information (for example, a bare IP has no domain name, and a non-HTTPS target has no certificate section) — it is not a failed lookup.

5. Tips / Troubleshooting

Symptom	Likely cause	What to do
Clicking does nothing / profile is blank	You did not click a recognizable host, or there is no network access	Confirm you clicked an IP / hostname / SNI; confirm the network is available and reopen
The certificate checkup section is empty	This flow is not HTTPS, so there is no certificate to inspect	This is normal; try a TLS flow instead
Only an IP, no domain / tech stack	The peer really is a bare IP with no domain bound, or is not a web service	Just check ownership, geolocation, and the certificate; the tech stack depends on there being a web page
You want to look up a related subdomain that never appeared in the traffic	It is hidden in the certificate	Expand the CT logs; every hostname covered by the certificate is listed at once
The rating is low (C / F)	Something is wrong with the certificate or the encryption configuration	Expand it to see whether it is expired, the hostname does not match, the chain is untrusted, or weak suites are in use

6. Next Steps

How to read details, switch views, and decode after capturing: see Data Viewing and Decoding.
To see which connections are currently active and open a host directly from a connection: see Connection Table.
To mine subdomains from a certificate and go further with port and subdomain discovery: see Port Scanning and Subdomain Discovery.
To verify connectivity, path, and latency for a host: see Network Diagnostics.

Incomplete Xcode Installation in iOS Development: Repair Steps and Alternative Toolchain Setup

ObjC_Coder — Tue, 15 Sep 2026 10:05:59 +0000

Two weeks ago, a colleague reinstalled Xcode, downloaded over a dozen GB, opened it and found the simulator list empty; during compilation it reported a missing iOS SDK, and Command Line Tools also showed as not installed. After struggling for a day, he found out that the network had dropped during the download, causing incomplete components. Running into incomplete Xcode installation is actually quite common. Here are several repair methods, and I'll also mention an alternative for doing iOS development without Xcode. This solution for incomplete Xcode installation in iOS development covers two directions: one is repairing the existing Xcode, and the other is switching to a toolchain that does not require Xcode.

Common Fixes for Xcode

The most common signs of an incomplete Xcode installation are that the simulator won't open after installation, or compilation reports missing header files or SDKs. The cause is usually an unstable network during download, resulting in some components not being fully downloaded. When this happens, don't rush to reinstall; try the following commands and they may fix it. If you understand the solution for incomplete Xcode installation in iOS development, these troubleshooting steps can save a lot of reinstall time.

Missing Command Line Tools: Run xcode-select --install in Terminal, and an installation window will pop up to install the command-line tools separately. After installing Xcode, this is sometimes not configured automatically, so you need to manually run the install command.

Initialize and Complete Components: Run xcodebuild -runFirstLaunch, and Xcode will check for and complete missing components. If you encounter compilation errors, run this command first.

Missing Simulators: Open Xcode → Settings → Platforms, and click to download the required iOS version. If disk space is limited, just install the version needed for current development; you don't need to download them all.

Clean Reinstall: If none of the above works, delete /Applications/Xcode.app and download it again. Be sure to back up DerivedData and custom configurations in your projects first. Ensure a stable network during download, and avoid downloading during peak hours. After installation, run xcodebuild -runFirstLaunch again to ensure components are complete.

Alternative: KXApp Xcode-Free Development

If you repeatedly encounter incomplete Xcode installation, or your disk space is too tight to fit a dozen-plus GB Xcode, consider KXApp, an iOS development IDE that does not require installing Xcode. For developers often troubled by incomplete Xcode installation in iOS development, this is a once-and-for-all solution.

KXApp has a complete built-in compilation toolchain and does not require installing the huge Xcode and Command Line Tools. Its installer is much smaller than Xcode, and there is no problem of missing components. When creating a project, choose Swift, Objective-C, or Flutter, and generate the project structure with one click. The coding interface is based on VS Code, with intelligent completion and AI code assistant available by default.

Real-device debugging saves many steps—after connecting the iPhone to the computer, click Build and Install, and the tool automatically compiles, signs, and installs to the phone. You don't need to configure certificates and provisioning profiles yourself. After the project is complete, it also supports one-click building of an IPA package for test distribution or submission to the App Store. From project creation to packaging and release, you don't need to open Xcode.

How to Choose

If your team mainly uses Macs for native development, Xcode is still a necessary development tool; when the installation is incomplete, just troubleshoot using the repair steps above. If your development machine is Windows, your disk is insufficient, or you are repeatedly troubled by incomplete Xcode installation, KXApp is a more worry-free path. Both paths have their strengths; choose according to your actual development environment and project type.

Certificate Configuration, Management, and Installation for HTTPS Proxy Capture with TraceEagle

ObjC_Coder — Mon, 14 Sep 2026 10:35:49 +0000

Certificate Management and Installation

To capture HTTPS with a proxy, the first step is to make devices and software trust this tool's root certificate—if not trusted, TLS errors occur, and you can only see garbled ciphertext. This article walks you through installing the certificate step by step: one-click installation on the local machine, QR code installation on mobile, and how to use Full Coverage to supplement programs that 'still don't trust it even after the system certificate is installed' (Java / Python / curl, etc.). Install once, and all subsequent sessions can be decrypted.

I. When to Use

Whenever you use proxy capture for HTTPS and want to see plaintext, you need to install the certificate first. Typical scenarios:

Before using proxy capture for HTTPS for the first time: The local machine has not yet trusted the root certificate; install it once first. See Proxy Capture.
Mobile capture: The phone must separately trust the root certificate once; QR code installation is the fastest. See iOS Capture, Android Capture.
Java / Python / curl / wget, etc. cannot decrypt: These programs only recognize their own certificate list. Even after the system certificate is installed, they still cannot decrypt—use Certificate Full Coverage to install the certificate directly into them.

If you use proxy-free capture methods such as Specified Program Capture or Application-Layer Capture, you usually do not need to install certificates, and can skip this article.

II. Prerequisites

TraceEagle has been installed and started (for the first startup, just agree to the system permissions).
Open the Certificate Management page (all certificate-related operations are here: local trust status, download, mobile QR code, full coverage, client certificates).
When installing the certificate by scanning the QR code on your phone, the phone and computer must be on the same LAN.

III. Step-by-Step Operations

The scenarios below are numbered; just follow the one you need. A is the first step everyone must do.

A. Local One-Click: Install and Trust on the Local Machine

To capture local traffic, first make the local machine trust the root certificate.

Open Certificate Management and check Local Trust Status—if it shows 'Not Trusted,' continue to the next step; if it already shows 'Trusted,' you can skip.
Click 'Install to Local Machine and Trust', and confirm according to system prompts (you may need to enter your login password once).
When the status changes to 'Trusted', it is complete. Installing once is enough; all subsequent sessions can decrypt HTTPS.

If you need to distribute it manually or use it with other tools, you can use 'Download Root Certificate' on the same page; multiple formats are provided, use as needed.

B. Mobile QR Code Installation

The phone must separately trust the root certificate once. The root certificate is globally universal; install it only once per device.

On the Certificate Management page, find Mobile QR Code Installation. The tool generates a QR code for each available address on the LAN.
Use your phone camera to scan the code, open the installation page, and install it according to the corresponding system below:
- iOS: First follow the page prompt to download the profile, then go to Settings → General → VPN & Device Management to install the profile; after installation, also go to Settings → General → About → Certificate Trust Settings to enable full trust for this root certificate (if you skip this step, iOS still cannot decrypt). See iOS Capture for details.
- Android (regular device): Open the installation page and install the root certificate as a user certificate / CA certificate. Note that some apps only recognize system certificates and do not recognize user certificates; if you encounter decryption failures, see Android Capture].
- Android (rooted device): You can directly install the root certificate into the system certificate store, eliminating manual import and providing the best compatibility.
After installation, return to the App and generate an HTTPS request to confirm decryption works.

C. Certificate Full Coverage: Decrypt Even Programs That 'Do Not Recognize System Certificates'

Some programs still cannot decrypt even after the system certificate is installed—they only recognize their own certificate list. Full Coverage can install the root certificate directly into these programs:

On the Certificate Management page, open Certificate Full Coverage. The tool will automatically discover such software on the local machine (including running software), list them one by one, and mark them as Installed / Not Installed. Common ones include:
- Java programs
- Python programs
- Command-line and scripting tools such as curl / wget / Ruby / PHP / git
- Software such as Firefox / Thunderbird
For items not installed, click Install to install the root certificate; to revoke, click the corresponding Remove.
For missed ones that automatic discovery did not find (installed in non-standard paths, or not recognized by the tool), use manual path entry to add them, then install.

This is exactly the long-standing pain point of ordinary capture tools: the certificate is installed, but the program still cannot decrypt. Full Coverage specifically solves this.

D. Client Certificate Import

If the target site requires a client certificate (mutual authentication), and you happen to have one:

Open the Client / Domain Certificate page.
Import your client certificate (enter the password as well, if any).
After that, when capturing these sites, the handshake and decryption will work normally.

IV. Verification: Confirm Installation and Decryption

Local machine: Return to the Certificate Management page; the local trust status shows 'Trusted'.
Decryption works: Generate an HTTPS request through the proxy, open the details in the request list, and TLS shows 'Decrypted', with the response being readable plaintext (such as JSON) rather than garbled text.
Full Coverage / Mobile: HTTPS requests from the corresponding program or mobile App can also be seen in plaintext.

For how to read details, switch views, and decode, see Data Viewing and Decoding.

V. Installed but Still Cannot Decrypt? Check Item by Item

Symptom	Likely Cause	What to Do
The local machine has a system certificate installed, but a program still shows only ciphertext	This program only recognizes its own certificate list (typically Java / Python / curl / Firefox)	Use C. Certificate Full Coverage to install the certificate into it; for ones not listed by automatic discovery, use manual path entry
The phone has a certificate installed, but the App still cannot capture plaintext	The App only recognizes system certificates, does not recognize user certificates, or has certificate pinning	On Android, use a rooted device to install it into the system store; if it still fails, it is likely pinning—see Bypassing Certificate Pinning
iOS still reports an error after the profile is installed	You missed the Full Trust switch in 'Certificate Trust Settings'	Go to `Settings → General → About → Certificate Trust Settings` and enable trust for this root certificate—see iOS Capture
A program cannot be found in Full Coverage	It is installed in a non-standard path, so automatic discovery did not cover it	On the Full Coverage page, use manual path entry to point to it, then install
It is installed but still cannot decrypt, and what is captured is its proprietary encryption	The target does not use standard TLS, so certificates cannot solve it	Switch to Application-Layer Capture to obtain plaintext from inside the program

Next Steps

Once the certificate is installed, you can start capturing: return to Proxy Capture.
Full mobile workflow: see iOS Capture, Android Capture.
The certificate is installed, but the App uses certificate pinning and cannot be captured: see Bypassing Certificate Pinning.
How to read and decode after capturing: see Data Viewing and Decoding.

iOS Development IDEs: Xcode and KXApp Lightweight Alternatives

ObjC_Coder — Fri, 11 Sep 2026 10:07:51 +0000

I used to think Xcode was the only path for iOS development — until a colleague on the Flutter team complained about how heavy Xcode is: a single install eats up tens of gigabytes, and most of its features go unused when you're just writing Flutter code day to day. That's when I realized how much IDE needs vary across project types and development scenarios. Here's a comparison of the two approaches.

Xcode: Full-Featured, but a High Barrier to Entry

Xcode is Apple's official iOS IDE, covering the entire workflow: coding, debugging, performance analysis, packaging and App Store submission, and certificate management. It's undeniably powerful, but it comes with several clear pain points:

The installer is over ten gigabytes, and every major version update means re-downloading the full package from the App Store — painful when you're short on disk space. Sometimes you just want to change a few lines of code and still have to wait for it to finish loading. Configuring certificates and provisioning profiles before real-device debugging is not beginner-friendly: just understanding Provisioning Profiles and code signing takes a lot of time, and going from registering an account to running your first app on a real device can take a day or two. In cross-platform projects (Flutter, uni-app), most Xcode features go unused while writing Dart, yet the disk footprint and IDE load time are no smaller.

For teams doing pure native Swift or ObjC development on Macs, Xcode is the natural choice — its integration of performance and debugging tools genuinely has no replacement today. But for cross-platform work, or for beginners still learning Swift, Xcode's learning curve is a bit steep.

KXApp: A Lightweight Path Focused on Coding and Debugging

KXApp positions itself as a lightweight iOS IDE: no need to install Xcode or the Command Line Tools, since it ships with a complete compilation toolchain. When creating a project, pick Swift, Objective-C, or Flutter, and it generates a standardized project structure in one click — no manual template setup. The VS Code–based coding interface feels familiar and smooth, with intelligent completion and an AI coding assistant available out of the box.

Real-device debugging is where KXApp shines: connect your iPhone to the computer, click Build and Install, and the tool compiles, signs, and installs the app on the phone directly. No need to configure certificates and provisioning profiles yourself, and no need to open Xcode's Organizer to set up signing. For newcomers to iOS development, or for people who mainly write code on Windows, this workflow saves a lot of detours.

It also supports Flutter projects, so cross-platform developers can manage both the native layer and the Flutter layer in a single iOS IDE without opening Xcode separately just to debug the iOS side. Build and packaging are built in too, so no extra tools are needed. When the project is done, build an IPA in one click for test distribution or App Store submission.

Which One Should You Choose?

No single iOS IDE does everything. Xcode suits deep native development, scenarios requiring Instruments tuning, or team workflows that rely on Apple ecosystem services such as Xcode Cloud. KXApp suits getting started quickly, lightweight development, cross-platform projects, or situations where you don't want to burn energy on toolchain configuration.

Keeping both around is no conflict — just switch based on project type. Open Xcode when writing native Swift code or doing in-depth performance analysis, using Instruments to pinpoint problems. Use KXApp when maintaining Flutter projects, quickly validating an idea, or writing small day-to-day tools, since startup and compilation are faster. Playing to each one's strengths is far more flexible — and far more practical — than fixating on a single iOS IDE.

App Store IPA Upload Automation: .p8 Key Auth and CI/CD Integration in Practice

ObjC_Coder — Thu, 10 Sep 2026 10:11:34 +0000

On release day, the most annoying step is the manual upload: the build machine produces the package, but a human still has to open the upload tool, pick the file, enter credentials, and watch the progress bar—then do it all over again if the network hiccups. Worse, these operations live on individual laptops, so handing off to someone else means walking them through the process again. To wire "upload the IPA" into CI/CD, the first thing to solve is actually authentication—letting a machine in the pipeline submit the build to App Store Connect as you, without scattering your Apple ID password everywhere.

Two types of credentials for CI

Credentials for automation fall into two categories. One is an app-specific password, generated in the Apple account backend in the xxxx-xxxx-xxxx-xxxx format, tied to an Apple ID, and suited to being typed manually into interactive tools. The other is an App Store Connect API key, which yields a .p8 private key plus two identifiers, a Key ID and an Issuer ID; requests are signed with JWT. It doesn't consume password quota, can be revoked independently, and its permissions can be scoped. In CI scenarios the .p8 route is handier: it doesn't trigger two-factor authentication, needs no human at a terminal, and if the key leaks only it is affected—rotating it doesn't disrupt other automation.

The official route on Mac: altool and fastlane

Apple's official route is feeding the .p8 to altool. The altool bundled with Xcode supports the --apiKey and --apiIssuer parameters, so one command uploads the build:

xcrun altool --upload-app -f Payload.ipa --apiKey XXXXXXXXXX --apiIssuer YYYYYYYYYY --type ios

fastlane's pilot lane consumes the same credentials, injected via the three environment variables APP_STORE_CONNECT_API_KEY_KEY_ID, APP_STORE_CONNECT_API_KEY_ISSUER_ID, and APP_STORE_CONNECT_API_KEY, so CI never has to commit the key to the repository. The cost of this approach is the environment: altool depends on the Xcode toolchain, fastlane needs Ruby dependencies installed, and it basically won't run on Windows or bare Linux build machines—the key itself, ironically, has no platform restrictions.

Generating the .p8: the Appuploader approach

If your build machine isn't a Mac, or you don't want to maintain another Xcode environment in the pipeline, take a look at the Appuploader combination. Its account overview page lets you generate an App Store Connect API key directly: enter a key name and submit, and it creates a key with ADMIN privileges that can access every app under the account. The private key (.p8) is shown only this once, and the page prompts you to copy it immediately or download it as a .json key file and store it safely—import that .json under "Add Account → API Key → Key File" on the login page, and you can sign in to the same App Store Connect account without a password or a second verification step. The key works across devices, anything derived from it dies the moment it's revoked, and revoking it leaves things clean.

Putting the upload step on the command line

The IPA upload step runs on the command line. The runtime folder in the Appuploader install directory ships appuploader_cli, invoked as a subcommand:

appuploader_cli upload -f Payload.ipa -u dev@example.com -p abcd-efgh-ijkl-mnop --type ios

-f specifies the IPA path, -u is the Apple ID, -p is the app-specific password, and --type defaults to ios. It does exactly what the "Submit to App Store" button in the GUI does, but it's fully scriptable and runs on Windows, Linux, and Mac; the whole chain involves no Xcode and carries no Mac device information.

Wiring it into GitHub Actions

Hooking it into CI is just a few ordinary pipeline steps: once the build artifact is out, download the Linux build of Appuploader in Actions, add the runtime directory to PATH after extraction, put the account and app-specific password in secrets, and one run step completes the upload. You can also run appuploader_cli's info command before uploading to analyze the IPA locally and generate AppStoreInfo.plist, validating things like signing and version up front so problems surface early instead of waiting for Apple to reject the build and digging through logs afterward—when an upload fails, the CLI's logs likewise spell out the reason, making version conflicts and signing mismatches obvious at a glance.

Choosing a route by environment

Pick between the two routes based on the build environment: on a Mac-based CI, altool with a .p8 is convenient, the ecosystem is mature, and there are plenty of community write-ups on pitfalls; on a Linux or Windows build machine, the Appuploader command line is the most direct way to get IPA uploads into the pipeline. The .p8 key solves the identity problem on the account side—login, certificate management, and package upload all share one identity. Once uploads are pulled out of manual operations, the only thing left to watch on release day is the review status, saving you that half hour per release and the back-and-forth of a handoff.

Can VS Code be used for iOS development? Does it support code completion and real-device debugging?

ObjC_Coder — Wed, 09 Sep 2026 09:58:34 +0000

Many iOS developers have had this thought: Xcode is too heavy—slow to start, slow to index—so can we use VS Code to write iOS code? VS Code does offer better startup speed, a richer plugin ecosystem, and a more polished editor experience than Xcode, but iOS development isn't just about writing code; the compilation and debugging stages inevitably depend on underlying toolchains.

What Can VS Code + Swift Plugins Do?

After installing the Swift plugin and SourceKit-LSP server in VS Code, you can handle basic code editing: syntax highlighting, code completion, jump to definition, and error hints are all supported. Combined with Git plugins for version control, Prettier for formatting, and GitHub Copilot for AI-assisted completion, the editor experience can actually surpass Xcode.

VS Code provides solid support for Swift Package Manager projects with high native integration. After opening Package.swift, you can browse and edit code normally. For traditional xcodeproj projects, support relies on the extension capabilities of apple/sourcekit-lsp and isn't as smooth as working directly with SPM projects.

What VS Code Can't Do

Real-device debugging is VS Code's weak point. Xcode bundles compilation, signing, installation to a physical device, and breakpoint debugging into a single workflow. VS Code has no built-in iOS debugger support; to debug you must return to Xcode or compile the app via the command line with xcodebuild, then attach LLDB to the process.

VS Code also cannot do visual editing for Interface Builder or Storyboards; you can only edit XML source files in text mode. If your project heavily relies on XIBs and Storyboards, VS Code can only act as a text editor for those XML files.

Instruments' deep performance analysis tools are also beyond VS Code's reach. Tools like Time Profiler, Allocations, and Energy Log require the Xcode environment—VS Code plugins cannot replace them.

How KXApp Differs

KXApp is built on VS Code and preserves all editor-level shortcuts, interface layout, and the plugin ecosystem of VS Code. The key difference from a typical VS Code + Swift plugin setup is that KXApp includes the iOS compilation toolchain internally.

This means after writing code in KXApp, you don't need to switch to the terminal to run xcodebuild or open Xcode to compile. The built-in swiftc, clang, and ld toolchain can compile source code directly into an IPA file. Real-device debugging is also natively supported: connect your iPhone via USB, click Build and Run, and the tool automatically handles signing and deployment.

KXApp also provides native Dart-to-iOS compilation support for Flutter projects, eliminating the need to configure the Xcode toolchain separately within the Flutter environment.

VS Code isn't incapable of writing iOS code—its editor experience is genuinely good, even surpassing Xcode in some respects. However, the typical VS Code + Swift plugin approach requires external tools for compilation and debugging, leaving the development workflow disjointed. KXApp fills the compilation and debugging gap on top of VS Code, closing the entire loop within the same tool.

When to Use Which

For everyday coding and code reviews, use VS Code or KXApp for fast startup, rich plugins, and a smooth editing experience. When you need visual UI editing, Instruments performance analysis, or App Store submission, switch back to Xcode. Combining both tools yields higher efficiency than relying solely on Xcode.

TraceEagle NIC Packet Capture: Without Proxy or Certificate

ObjC_Coder — Wed, 09 Sep 2026 09:30:12 +0000

NIC Packet Capture

This guide teaches you to use NIC capture to grab everything that flows through this machine's NIC: DNS, QUIC, games, IoT, various proprietary protocols — anything passing through the NIC is right before your eyes. No proxy configuration, no certificate installation — pick a NIC and start capturing. HTTPS no longer stays as ciphertext either: common apps are decrypted to plaintext as soon as captured, and for the rest, just click Decrypt this app to read them.

1. When to Use This Approach

This suits you if any of the following applies:

Want to see non-HTTP traffic: DNS, QUIC, ICMP, ARP, or any TCP/UDP — what proxies can't capture is all captured here.
Want to understand a program's full network behavior: which addresses it connects to, which protocols it uses, and whether it has any "silent" connections.
Don't want to change the system proxy or install certificates — you want zero-intrusion direct capture.
You have proprietary / self-developed protocols and want to capture raw streams first, then reverse-engineer them later.

If you just want to debug an HTTP API and rewrite or replay requests, Proxy Capture is more precise. If you only need to capture a program that can be launched from a command line, Process Capture is more convenient.

2. Prerequisites

TraceEagle is installed and started (simply agree to system permissions on first launch).
No need to change the system proxy or install certificates.
Only when you want to read a program's HTTPS plaintext do you need to click Decrypt this app on it during capture (see Section 4). For common programs, even that step is unnecessary.

3. Start Capturing: Capture Your First Packet

Create a new session and choose "Local NIC Capture".
Select a NIC: The tool automatically lists all local NICs and preselects the currently active one. Choose whichever you want to capture.
(Optional) Set a capture filter before starting: If you only care about certain traffic, enter a capture filter rule or simply apply a built-in preset (TLS / HTTP / QUIC / DNS / TCP / UDP / ICMP / ARP / SSH, etc.) with one click.

Capture filters can only be set before capture and cannot be changed afterward — they determine what is captured at the NIC layer. To filter already-captured data, use the Display Filter in the packet view (see Section 4).

Click Start. Packets flowing through the NIC appear in the list in real time.

Make the target program produce network requests (open a webpage, initiate a connection), and traffic will stream into the list in real time.

4. View Plaintext: Turn Ciphertext into Plaintext

Traffic captured on the NIC is ciphertext by default (captured as-is). To see HTTPS plaintext for a program, use these three levels, each as a fallback:

Auto-decryption: Common programs such as browsers and Electron apps usually appear as plaintext right after capture, with no extra action needed.
Manual "Decrypt this app": For programs that cannot be auto-decrypted, click Decrypt this app and select it in the list to reveal its encrypted traffic. Multiple programs can be decrypted simultaneously.
Two enhancement switches (use only if decryption is still incomplete):
- Restart the program: Restart the target from scratch so even the encrypted traffic from its early startup phase is decrypted.
- Handle child processes in one click: Some programs send/receive traffic through child processes; enabling this processes child processes as well, avoiding gaps.

During capture, two views help you make sense of the packets:

Packet view: Inspect individual packets like in professional capture tools. Selecting a frame shows its frame info, raw bytes, and the protocol hierarchy tree expanded layer by layer. The search box supports Wireshark-style display filters (e.g., tcp.port==443, tls.handshake, dns), validating syntax as you type, allowing precise navigation across the full captured data.
Connection view: Reassembles scattered packets into logical connections. Use Follow Stream to see the complete sent/received data of a connection; DNS/TLS/HTTP can also be viewed structurally.

The two views navigate back and forth (jump from a connection to its raw packets, or follow an entire connection from a single packet). Right-clicking any frame lets you show only this connection / filter this connection, flag the frame, copy source/destination address, or directly look up host details / ping / port scan a remote IP. You can also pause anytime during capture, review what's been captured, then continue.

5. Verification: Confirm Capture and Decryption

Captured successfully: The list refreshes continuously when traffic passes the NIC; in the connection view you can see connections grouped by protocol.
Readable: Open an HTTPS connection. If it displays as readable plaintext (e.g., JSON), decryption has succeeded. If still ciphertext, return to Section 4 and click Decrypt this app on it.
Verify non-HTTP: Type dns, quic, icmp, etc., into the display filter in the packet view. If corresponding traffic appears, the NIC layer has captured everything.

6. Nothing Captured / Can't Decrypt? Troubleshoot

Symptom	Likely Cause	Solution
Captured, but a program is still ciphertext	It isn't one of the common programs that are plaintext immediately	Click Decrypt this app on it and select it. If still incomplete, enable Restart program / Handle child processes.
No traffic at all	Wrong NIC selected, or the capture filter filtered out all traffic	Switch to the currently active NIC; relax or clear the capture filter and restart the session.
Want to re-filter captured data but find the capture filter can't be changed	Capture filters only take effect before the capture starts	Use the Display Filter in the packet view to filter the captured full data (e.g., `tcp.port==443`).
Target uses HTTP/3 (QUIC), cannot see all traffic	More apps are adopting QUIC; it has always been hard to capture and decrypt at the NIC layer	Induce the target to gracefully fall back from HTTP/3 to a regular connection, making it capturable and decryptable again (stopping the session auto-restores). When session keys are available, you can also decrypt QUIC/HTTP/3 directly.
Only want to debug an HTTP API, but NIC traffic is too noisy	NIC captures "everything", focusing on completeness over precision	Use Proxy Capture (more precise) or Process Capture (only one program).

7. Choosing a Local Capture Method

Your situation	Use this method
See all traffic on the whole machine, non-HTTP traffic, or a program's full network behavior	NIC Capture (this article, most complete)
Debug HTTP APIs, rewrite/replay requests	Proxy Capture (more precise)
Ordinary programs launchable from command line (browser/script/CLI)	Process Capture (simplest)
Program already running / certificate pinned / proxy unsupported / proprietary encryption	Application-Layer Capture
System apps on macOS / stubborn applications	System-Level Capture

Next Steps

How to read captured data, switch views, and decode: see Data Viewing and Decoding.
For proprietary/self-developed protocols, to teach the tool how to read them: see Custom Protocol Decoding.
To quickly look up remote IP ownership/geolocation/certificates: see Host Details.
To probe a remote further: see Network Diagnostics, Port Scanning, and Subdomain Discovery.

Quick Start with TraceEagle Network Tracker

ObjC_Coder — Tue, 08 Sep 2026 07:18:28 +0000

Quick Start

This guide gets you through a packet capture in minutes: install, launch, capture your first decrypted request in the simplest way, then pick a capture approach that fits your goal. You'll be up and running after reading.

1. Install and Launch

Download and install the desktop app for your platform (macOS / Windows / Linux).
Open the app. On first launch it may ask for system permissions (required for low-level capture) — grant them.
It works right away, with no extra configuration.

2. Fastest Success: Capture Your Own Browser

To see results immediately, use Targeted App Capture: the tool launches a browser for you, captures only that process, and auto-decrypts all the way — no proxy configuration, no certificate installation.

Create a new session and choose Local Targeted App Capture.
Click the built-in Browser Example (it auto-fills the launch command), or enter your own command under Launch Command.
Click Start. The tool opens an independent, clean browser window.
In that browser, open any website. Requests appear in the list instantly. Click one to see the decrypted plaintext: request line, request headers, body — and the same for the response.

If you want to get it working the first time, take this route — no system proxy, no certificate, least effort. It's the perfect way to get a taste of "capture and see plaintext." See Targeted App Capture for full steps.

3. Choose a Capture Approach That Fits Your Goal

Use different approaches for different goals; pick one from the table:

What you want to capture	Which approach to use
Local browser / app, or want to tamper and replay	Proxy Capture
Entire machine traffic, including non-proxy traffic, UDP / QUIC, DNS	NIC Capture
Only one app, auto-decrypt, no certificate	Targeted App Capture
Apps with certificate pinning or custom encryption that can't be broken	App-Layer Capture
System built-in apps, stubborn apps	System-Level Capture
iPhone / iPad traffic	iOS Capture
Android phone traffic	Android Capture

If in doubt, start with Proxy Capture: it's the most general, supports plaintext viewing, request tampering/replay, and can also capture phones and LAN devices.

4. Understand the Interface

Request List: Each captured traffic item appears here in order; click to expand its details.
Automatic Decryption: When the session key for an item is available, the tool automatically turns ciphertext into plaintext; the details show TLS as "Decrypted".
Raw and Plaintext Side by Side: View both the decrypted request/response and the underlying raw bytes.
Process Attribution: Each item is tagged with which program sent it, so you can tell them apart at a glance even when they're mixed together.

To understand a capture, switch views, or decode payloads, see Data Viewing & Decoding; to compare two requests, see Request Comparison.

5. Can't Capture / Can't Decrypt? Check These First

Symptom	Likely cause	What to do
No requests at all	Target doesn't go through the system proxy	Switch to NIC Capture — it sees everything at the NIC layer
Captured, but all ciphertext	No certificate installed, or app has certificate pinning	Install a certificate (see Certificate Installation), or switch to App-Layer Capture
Phone capture still fails after certificate installed	Newer OS versions don't trust user certificates	See the certificate-free methods in Android Capture / iOS Capture
HTTP/3 / QUIC not visible	It runs over UDP, which ordinary proxies can't see	Use NIC Capture with H3 decryption

For more detailed troubleshooting, run Network Diagnostics first.

6. What's Next

Once you can capture, decrypt, and understand, these are the everyday high-frequency features:

Rule Rewrite & Breakpoint Interception: Modify requests and responses without changing code, or intercept requests mid-way and edit them manually.
Request Construction & Replay: Modify any request and resend it; even signed and timestamped APIs can be truly replayed.
Session Replay & Stress Testing: Replay a whole batch of requests, or load-test a single endpoint in place.
Code Generation & API Document Export: Turn a request into multi-language code, or reverse the entire session into an OpenAPI document.