DEV Community: UIKit_Ninja

2026 iTMSTransporter Windows IPA Upload and Release Tutorial

UIKit_Ninja — Wed, 23 Sep 2026 10:30:06 +0000

2026 iTMSTransporter Windows IPA Upload and Release Tutorial

To upload an IPA on Windows with Apple's official iTMSTransporter, the correct command in 2026 looks like this:

iTMSTransporter -m upload -assetFile App.ipa -assetDescription AppStoreInfo.plist -u dev@example.com -p abcd-efgh-ijkl-mnop

Note the -assetDescription AppStoreInfo.plist in there — it is mandatory on Windows and Linux, and officially this file can only be exported from Xcode. This is exactly where I got stuck, so below I'll explain how to generate it directly on Windows.

First, understand what changed in 2026

If you follow tutorials from a few years ago, you will most likely fail. Three things have changed:

-f can no longer be used to upload apps. Apple has made it clear: uploading or verifying an app must use -assetFile; -f is retained only for other content types. The old -m upload -f App.ipa style now fails outright.
.itmsp package delivery is deprecated. In the past you had to manually create a <vendor_id>.itmsp directory and drop metadata.xml and the IPA into it; now you just point -assetFile at the IPA. Much simpler.
-assetDescription is required on Windows / Linux. Apple's official user guide states it plainly: this parameter is "required for Linux and Windows App uploads, but not for macOS App uploads." On macOS you don't need it, because Transporter invokes the tools inside Xcode to generate one on the fly; on Windows there is no Xcode, so you have to prepare it yourself and hand it over.

Point 3 is the killer, so we'll handle it in a dedicated step below.

Step 1: Install iTMSTransporter

Transporter is currently at version 4.2, and the Windows build is a self-extracting installer.

Download URL (official Apple direct link):

https://itunesconnect.apple.com/WebObjects/iTunesConnect.woa/ra/resources/download/public/Transporter__Windows/bin

The download is iTMSTransporterToolInstaller_4.2.0.<build>.exe. Double-click it, accept the license agreement, and the default install directory is:

C:\Program Files\itms

After installation, an iTMSTransporter.woa subdirectory is created inside. The command-line entry point lives in the install directory, written in the official docs as .\iTMSTransporter (on Windows it is actually a batch script of the same name). If you're not sure where it is, search for iTMSTransporter in the install directory.

First verify that it runs:

cd "C:\Program Files\itms\bin"
iTMSTransporter -version

If it prints a version number, the installation is fine. To make later commands easier to type, it is recommended to add this bin directory to the system PATH: Settings → System → About → Advanced system settings → Environment Variables → select Path → Edit → New, paste the directory path, then open a new command-line window for it to take effect.

Step 2: Prepare AppStoreInfo.plist (the critical step)

This is where Windows users really get stuck, so let's first be clear about what it is.

AppStoreInfo.plist is not a configuration file in your project; it is a descriptive manifest of your package: the package type, platform, the structure of each bundle inside, icons, signing information, and so on. Apple relies on it to check the package when it is received. Apple itself wrote a line in the file:

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

The problem is that this manifest is normally generated by a tool in the Xcode toolchain, and that tool only runs on macOS. So Windows users hit a dead end: Transporter has a Windows version, yet on Windows it insists that you provide a file that can only be generated on a Mac.

The common workaround online is to find a Mac to generate it and copy it over, or rent a cloud Mac — spinning up an entire machine for a file of a few dozen KB is clearly not worth it.

With the AppUploader command-line tool, you can generate this file directly on Windows, with a single command:

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

appuploader-cli.exe is in the AppUploader install directory; it comes with the main program, so there's no separate download;
-u takes your Apple ID email;
the trailing -o specifies the output file name.

When it finishes, it prints a line with the file size and the package's Bundle ID, so you can check that you're uploading the package you intended:

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

Put the IPA and the plist in the same directory. This is one of the more commonly hit pitfalls in practice: when the two files are scattered across different paths, the upload tends to fail. Keeping them together is the least hassle.

Step 3: Prepare account credentials

iTMSTransporter supports two login methods.

Option 1: Apple ID + app-specific password. Go to https://account.apple.com/account/manage and generate an app-specific password in the form abcd-efgh-ijkl-mnop. It is shown only once, so save it on the spot. Pass it with -u and -p on the command line.

Option 2: App Store Connect API key (recommended). Generate one at https://appstoreconnect.apple.com/access/api, and you get a key ID, an Issuer ID, and a .p8 file. iTMSTransporter is particular about where the .p8 lives: it does not accept a path you pass in; instead it looks for a fixed file name in several fixed directories:

./private_keys/AuthKey_<key ID>.p8

That is, create a private_keys folder in the current directory where you run the command, and put the file in it named AuthKey_<key ID>.p8. Besides the current directory, it also looks in ~/private_keys, ~/.private_keys, and ~/.appstoreconnect/private_keys, in that order, and you can also specify a directory with the API_PRIVATE_KEYS_DIR environment variable.

A side note: Transporter also has a -jwt parameter that takes a token directly, but since late September 2025, -jwt combined with -assetDescription has had server-side rejection issues, reporting No value present. The -apiKey / -apiIssuer pair does not have this problem, so avoid -jwt if you can.

Step 4: Verify first, then upload

Before the real upload, it is advisable to run a verification pass first; it catches problems with the package itself early and saves you from waiting through an upload only to be rejected:

iTMSTransporter -m verify -assetFile App.ipa -assetDescription AppStoreInfo.plist -u dev@example.com -p abcd-efgh-ijkl-mnop

Once verification passes, upload by changing -m verify to -m upload:

iTMSTransporter -m upload -assetFile App.ipa -assetDescription AppStoreInfo.plist -u dev@example.com -p abcd-efgh-ijkl-mnop

If you're using an API key (remember to create the private_keys directory first):

iTMSTransporter -m upload -assetFile App.ipa -assetDescription AppStoreInfo.plist -apiKey UK29KBAX9X -apiIssuer 69a6de78-4459-47e3-e053-5b8c7c11a4d1

Parameter reference:

Parameter	Meaning
`-m upload` / `-m verify`	Upload / verify only without uploading
`-assetFile`	Path to the IPA or PKG (stop using `-f`)
`-assetDescription`	The AppStoreInfo.plist generated in the previous step; required on Windows
`-u` / `-p`	Apple ID and app-specific password
`-apiKey` / `-apiIssuer`	API key ID and Issuer ID; mutually exclusive with `-u -p`
`-v`	Log verbosity: `off`, `critical`, `informational`, `detailed`, `eXtreme`

When troubleshooting, add -v eXtreme for much more detailed output:

iTMSTransporter -m upload -v eXtreme -assetFile App.ipa -assetDescription AppStoreInfo.plist -apiKey UK29KBAX9X -apiIssuer 69a6de78-4459-47e3-e053-5b8c7c11a4d1

After the upload, Apple still needs a few minutes to a few tens of minutes to process it, and only then does the build appear in the "Builds" list in App Store Connect; only after that can you select it for review submission. Not seeing it right after uploading is normal.

Common errors

Says -f cannot be used to upload apps

Old syntax. Switch to -assetFile.

Says the asset description is missing, or fails with no message at all

On Windows, -assetDescription is required; check whether you left it out and whether the path is correct. Also make sure the IPA and the plist are in the same directory.

Reports No value present

A known issue when passing a token via -jwt; switch to the -apiKey / -apiIssuer pair.

API key authentication fails, saying the key can't be found

The .p8 location or file name is wrong. It must be private_keys/AuthKey_<key ID>.p8, placed in the current directory where you run the command, and the key ID in the file name must match the -apiKey parameter exactly.

Duplicate version number or build number

That version number + build number combination has already been uploaded; Apple does not allow overwriting, so change the build number and repackage.

Java-related errors

Transporter bundles its own runtime, so you generally do not need to install Java separately. If you get a Java-related error, it is usually an incomplete installation — uninstall and reinstall.

By the way: you don't actually have to go through all this

The whole process above — installing Transporter, generating the plist, setting up the private_keys directory, assembling a long string of parameters — if your only goal is "get the IPA uploaded," there is a shorter path: the same appuploader-cli you used to generate the plist can upload directly:

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

One command does the upload; no AppStoreInfo.plist needed, no Transporter install needed, and on failure the exit code is non-zero, so you can wire it straight into your build script.

When is it still worth using iTMSTransporter: when company process explicitly requires Apple's official tools, or when your pipeline already has other stages built around Transporter. In those two cases, just use appuploader-cli info to fill in the AppStoreInfo.plist piece and keep the rest as is.

References

Apple's official Transporter User Guide: https://help.apple.com/itc/transporteruserguide/

The most troublesome part of the whole setup is really the AppStoreInfo.plist step; the rest is just filling in parameters. The plist is generated with the command-line tool bundled with AppUploader, which on Windows can also sign certificates, create Bundle IDs, and generate provisioning profiles.

Must-Have Programming Tools for iOS Developers: Five Categories, Compared and How to Choose

UIKit_Ninja — Mon, 21 Sep 2026 10:57:56 +0000

I've noticed a pattern: every time a new person joins an iOS team, their first question is almost never about syntax — it's "what else do I need to install besides Xcode?" The answer is a long one, because the programming tools involved in iOS development go far beyond a single IDE. By purpose, they fall into five categories, and each category offers different choices. This article catalogs the must-have programming tools for iOS developers by category, presents representative tools and selection thinking for each, and helps you set up your development environment in one go.

IDEs and Editors

The first category is IDEs and editors — the main battleground for writing code. Xcode is the official all-in-one bundle: compilation, debugging, simulator, and App Store submission all in one. Its downsides are its large size and frequent updates; when disk space is tight or the network is poor, a single install is quite a chore. If you don't want to be tied to Xcode, KXApp (Kuai Xie) is another route: it ships with a built-in compilation toolchain, so you can do iOS development without installing or updating Xcode. It supports Swift, Objective-C, and Flutter projects, and once you connect an iPhone it builds and installs to a real device in one click, eliminating the export-IPA-then-drag-into-Xcode workflow. VS Code, meanwhile, represents the lightweight camp, with a rich plugin ecosystem, suiting developers who like to customize their editor. Each of the three has its own use cases — just pick according to your team's habits.

AI Coding Assistants

The second category is AI coding assistants. GitHub Copilot is mature in code completion and generation, while Cursor integrates AI capabilities into the editor experience. KXApp is built on the VS Code kernel, so it can directly use various AI code assistant plugins; combined with a standardized project structure and intelligent suggestions, it gives you a familiar editing experience from the very first line of code. If your editor itself supports a plugin ecosystem, adding an AI assistant is a natural extension with no extra learning curve.

Build and Release

The third category is build and release tools. xcodebuild is the standard way to build from the command line, and paired with fastlane it can form a pipeline for automatic signing and automatic uploads — ideal for teams that release frequently. If your project is small and your process is simple, KXApp's one-click build can generate an installation package directly, covering test distribution and App Store submission scenarios, and skipping the step of configuring scripts. The trade-off between the two approaches depends on team size: the more complex the process, the more scripts are worth it; otherwise, the tool's built-in one-click capability is faster.

Debugging and Performance Analysis

The fourth category is debugging and performance tools. LLDB breakpoint debugging is the foundation of iOS debugging, while Instruments handles performance analysis, with templates for CPU, memory, and leaks. Real-device verification is a key step for functional correctness; KXApp has a built-in live real-device debugging engine — connect an iPhone and it runs, with code changes synced quickly to the phone for WYSIWYG results, without going through a full build first. Do functional verification and performance analysis separately, each with the tool that suits it.

Code Management

The fifth category is code management tools. Git is the foundation; whether you use the command line or a GUI client is a matter of personal habit. SourceTree and GitHub Desktop are friendly for visual operations and suit developers who don't want to memorize commands. Choices in this category barely affect the other four — convenience matters most.

With the categories covered, when it comes down to individuals, the configuration for newcomers and veterans differs quite a bit. Newcomers should start with a complete IDE — pick either Xcode or KXApp — and get the project running first. It's worth hooking up an AI assistant early, since it saves a lot of time digging through documentation. Veterans, by contrast, tend to slim down their toolchain: for example, running xcodebuild and fastlane only on CI machines, keeping just an editor and a handy branch management tool locally. There's no standard answer for environment setup — satisfying your current stage's needs is enough. Tools change with the project, and that judgment itself matters more than which one you pick.

Packet Eagle: Port Scan & Subdomain Discovery for Asset Inventory

UIKit_Ninja — Sun, 20 Sep 2026 11:49:03 +0000

Port Scanning and Subdomain Discovery

You have a host or a domain name and want to know what it exposes to the outside? Each approach has its own use: port scanning actively probes which ports a host has open and what services run on them; subdomain discovery reads only public data, never interacts with the target, and still digs out the subdomains under a domain.

1. Port Scanning: Which Ports a Host Has Open and What Services Run on Them

Enter a hostname or IP and it quickly scans out its open TCP ports, showing progress and "N open found" in real time. Each open port has three columns:

Port number.
Service name: first guessed from the port, then corrected against the captured Banner — so even if SSH, redis, mysql and the like run on non-standard ports, they are still recognized.
Banner: the captured service greeting; for HTTP ports, the status line and Server header.

Scan range has three choices: common ports (the default, a curated set of high-frequency ports), all ports (1–65535), or custom (e.g. 80,443,8000-8100). Banner grabbing can be toggled — with it off, the service name is still derived from the port, but no greeting is captured and no correction is made from it. The open-port list can be sorted by port number. Works out of the box, no extra drivers or privileges required.

Non-standard ports are still recognized: run SSH, redis, mysql and the like on an obscure port and an ordinary scanner that only "guesses the service from the port number" gets it wrong — here the captured Banner is used for correction, so the real service is identified no matter which port it runs on.

2. Subdomain Discovery: Passively Map Out a Domain's Subdomains

Enter a domain name and it aggregates several public intelligence sources queried in parallel, listing the subdomains under it. Sources are shown in two categories (each with a hit count): certificate transparency logs and passive DNS. Results are automatically deduplicated and sorted, with real-time filtering and one-click copy all. If a source is temporarily unavailable or rate-limited, it won't drag down the whole run — the remaining sources still return results, each annotated with its hit count.

Reads only public data, never interacts with the target: throughout, it only queries public datasets and sends no requests to the target domain or its servers. This is the fundamental difference from "active scanning".

3. Active vs. Passive: How They Work Together

	Port scanning	Subdomain discovery
Target	A host / IP	A domain name
Method	Actively probe the target's ports	Passively query public intelligence
Interacts with target	Yes (connects directly to its ports)	No (reads only public data)
What you get	Open ports + services + Banners	A list of externally exposed subdomains

First use subdomain discovery to read public data and spread out a domain's asset surface, then use port scanning on the hosts you pick out to verify which services are open — passive mapping of the surface, active verification of the points; run the pair and your external exposure becomes clear.

4. When to Use It

To map out the service surface a device / server exposes: which ports are open, roughly what runs on them, and what the Banner says.
To have a domain name and want to inventory the subdomains it exposes using public data alone.
For asset inventory and sorting out external exposure: passively mine subdomains + actively verify ports, the two complementing each other.

appuploader-cli Tutorial: Uploading an IPA to the App Store from the Command Line on Windows

UIKit_Ninja — Wed, 16 Sep 2026 10:15:52 +0000

appuploader-cli Tutorial: Uploading an IPA to the App Store from the Command Line on Windows

One command pushes your built IPA to App Store Connect — no Mac, no Xcode:

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

appuploader-cli is the command-line tool bundled with AppUploader (开心上架); once the app is installed, it's right there in the install directory. Below is a walkthrough from scratch: how to find it, what you need before your first upload, which login method to use for teams and pipelines, and how to diagnose failed uploads.

When you need the command line

If a couple of clicks in the GUI can submit your build, most people don't need the CLI. It's really for these three situations:

The build is produced automatically. CI packages a build every time you commit, and then someone still has to click upload manually — that step should be wired in.
The upload has to be run by someone else. Outsourcing, agency work, releasing multiple apps in rotation — a script beats verbally explaining which button to click.
On a machine with no GUI. Such as a company build server with only a remote terminal.

If you only publish manually once in a while, clicking twice in the GUI is actually faster; the value of the CLI is in repeated execution.

Before you start

1. You need a signed package first. appuploader-cli handles the "hand the package to Apple" step; it does not compile or sign. You must already have a built .ipa (iOS) or .pkg (macOS).

2. Find the command. Once AppUploader is installed, it's already in the install directory:

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

Open a terminal in that directory and you can use it directly. If you don't want to cd there every time, add the directory to your system PATH (on Windows: Settings → System → About → Advanced system settings → Environment Variables → select Path → Edit → New, paste the directory path, then reopen a terminal for it to take effect).

Run one command to confirm it works:

appuploader-cli --help

If it lists upload and info, you've found the right one.

First upload: using an app-specific password

The most convenient credential for logging in to Apple from the command line is an app-specific password — Apple created these specifically for third-party tools, they do not trigger two-factor authentication, and you don't have to confirm on your phone for every upload.

Generate one first: sign in at https://account.apple.com/account/manage, find "App-Specific Passwords," and create a new one. You'll get a password shaped like abcd-efgh-ijkl-mnop, shown only once, so copy and save it right away.

Then:

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

Three arguments: -f is the path to the package (you can also omit -f and put the path at the end of the command), -u is the Apple ID email, and -p is the app-specific password you just created.

Make sure -p is the app-specific password, not the password you normally use to sign in to your Apple ID. An app-specific password is always 16 letters with three hyphens in the middle, looks nothing like your login password, and you can tell at a glance whether you got it wrong.

After you press Enter, progress prints line by line, and a few minutes later you'll see this line, meaning success:

> upload finished successfully

On failure it's > upload finished with error:, followed directly by the reason Apple gave — a duplicate version number, a signature mismatch, a missing Info.plist field, and so on; just fix accordingly.

In scripts you don't need to read the logs: on failure the command's exit code is non-zero, so checking the exit code is enough.

Don't rush to App Store Connect to look for the build right after uploading — Apple takes anywhere from a few minutes to a few tens of minutes to process the package, and only after that does it appear in the "Builds" list, at which point you can select it for review.

Uploading macOS / tvOS / visionOS packages

It's treated as iOS by default; add --type for other platforms:

appuploader-cli upload -u dev@example.com -p abcd-efgh-ijkl-mnop --type osx App.pkg

There are only four possible values: ios (default), osx, appletvos, xros (visionOS).

Teams and CI: switch to API key login

The approach in the previous section has a problem: the command carries an individual's Apple ID and password. If that person leaves, changes their password, or simply doesn't want to hand their account to the pipeline, the whole automation breaks.

For team scenarios, an App Store Connect API key is more appropriate: it belongs to the team rather than an individual, can be revoked independently, and doesn't involve two-factor authentication.

Generate one at https://appstoreconnect.apple.com/access/api (requires Account Holder or Admin permission) and you'll get three things:

Key ID (a string of uppercase letters and digits)
Issuer ID (at the top of the page, shaped like 69a6de78-4459-47e3-e053-5b8c7c11a4d1)
The .p8 private key file — downloadable only once, Apple gives no second chance, so save it immediately

Then replace -u -p with these three arguments:

appuploader-cli upload -f Payload.ipa \
  --api-key UK29KBAX9X \
  --api-issuer 69a6de78-4459-47e3-e053-5b8c7c11a4d1 \
  --private-key AuthKey_UK29KBAX9X.p8

The two login methods are mutually exclusive; mixing them is rejected outright.

Confirm two things before using an API key:

You can only upload .ipa. This method relies on the Bundle ID in the package to find the corresponding app on App Store Connect, which can't be obtained from a .pkg. For macOS packages, stick with the app-specific password from the previous section.
An app must already exist in App Store Connect for this Bundle ID. If not, you'll get no App Store Connect app found for bundle ID — create the app first, then upload.

Wiring it into a pipeline

The idea is one sentence: after the build produces the IPA, add an upload step, and pass credentials via the CI's built-in secrets rather than writing them in plaintext in the script.

GitHub Actions (store the three items as repository secrets):

- name: Upload to App Store Connect
  env:
    ASC_KEY_ID:    ${{ secrets.ASC_KEY_ID }}
    ASC_ISSUER_ID: ${{ secrets.ASC_ISSUER_ID }}
    ASC_P8:        ${{ secrets.ASC_P8 }}
  run: |
    printf '%s' "$ASC_P8" > AuthKey.p8
    appuploader-cli upload -f build/App.ipa \
      --api-key "$ASC_KEY_ID" \
      --api-issuer "$ASC_ISSUER_ID" \
      --private-key AuthKey.p8
    rm -f AuthKey.p8

Don't skip that last rm line — the private key shouldn't be left in the Runner's working directory.

Jenkins / generic shell:

set -e   # abort the whole pipeline if the upload fails
appuploader-cli upload -f "$WORKSPACE/build/App.ipa" \
  -u "$APPLE_ID" -p "$APP_SPECIFIC_PASSWORD"

Windows batch / PowerShell:

& "C:\Program Files\AppUploader\appuploader-cli.exe" upload `
  -f .\build\App.ipa -u $env:APPLE_ID -p $env:APP_PASSWORD
if ($LASTEXITCODE -ne 0) { throw "Upload failed" }

The whole process needs no Mac; even if the build machine is Windows, this step still runs fine.

By the way: inspecting a package without uploading

There's also the info command, which doesn't upload over the network — it only reads the package locally and generates the resource description file App Store needs, AppStoreInfo.plist:

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

Two uses: confirm the package itself is fine before uploading (on success it prints the package's Bundle ID and size, so you can double-check you're uploading the right one); or your process uses a different upload tool and you're only missing this plist.

Without -o it prints to the terminal, which is handy for piping. info only supports the -u account form, with no API key mode.

Understanding the iOS Development Toolchain: A Comprehensive Comparison and Selection Guide for Cursor, Xcode, and KXApp

UIKit_Ninja — Tue, 15 Sep 2026 10:11:12 +0000

I've noticed a trend: there are more and more tools to choose from for iOS development today. Besides Apple's official Xcode, there's the AI-driven Cursor and the lightweight KXApp. Many teams and indie developers hesitate among the three when picking an IDE. This iOS development toolchain comparison puts all three side by side, comparing them across the core dimensions of compilation, debugging, AI capabilities, and learning cost, so you can choose based on your own situation. Once you understand where each tool fits in the iOS development toolchain, the decision won't feel so agonizing.

Xcode: The Most Feature-Complete Official IDE

Xcode is Apple's official iOS development IDE, covering the entire workflow of coding, debugging, performance profiling, and packaging for release. Its strength is tight integration: performance analysis with Instruments, crash logs with Organizer, and UI building with Interface Builder all live in the same toolset. It suits teams doing pure native Swift or OC development that need deep debugging. The downside is an installer of over ten gigabytes, and every major version update means another full download, which places high demands on disk and memory. In cross-platform projects (Flutter, uni-app), many features go unused, yet the disk footprint doesn't shrink at all.

Cursor: An AI-Assisted Editor

Cursor is an AI-driven editor built on VS Code. Its core advantage is built-in code completion and conversational programming: when writing Swift code, you can describe your requirements in natural language and let the AI generate or complete the code. It's good for rapid prototyping and learning Swift syntax. But Cursor is not a complete iOS IDE by itself — it doesn't support compilation, signing, running on a real device, or packaging. To write an iOS app, you still need Xcode or command-line tools to handle building and debugging. If Xcode is already your primary tool, you can use Cursor to help write code and then compile and run in Xcode. If you don't want to install Xcode, consider a tool like KXApp that ships with its own compilation chain.

KXApp: A Lightweight iOS IDE

KXApp positions itself as a lightweight iOS development IDE. It requires no installation of Xcode or Command Line Tools and has a complete compilation toolchain built in. When creating a project, choose Swift, OC, or Flutter, and a standardized structure is generated in one click. The coding interface is based on VS Code, with intelligent completion and an AI assistant available by default. Real-device debugging saves a lot of steps — connect your iPhone to the computer, click Build and Install, and it compiles, signs, and installs onto the phone directly, with no need to configure certificates yourself. Flutter projects are supported too: cross-platform developers can manage both the native layer and the Flutter layer code in the same IDE, without opening Xcode separately just to work on the iOS part. When the project is done, build an IPA in one click for test distribution or release.

Key Comparisons

Compilation capability: Only Xcode and KXApp have an integrated compilation toolchain; Cursor needs external tooling. Real-device debugging: Xcode and KXApp support one-click runs on a real device; Cursor can't do it directly. AI capability: Cursor's AI is relatively the strongest; KXApp also has basic AI completion; Xcode's AI features are limited. Learning cost: KXApp is the lowest, Xcode the highest, and Cursor sits in between. Cross-platform support: Both KXApp and Cursor can handle Flutter projects; Xcode leans native.

How to Choose

Choose Xcode if your main work is native development and you need Instruments for performance profiling. Choose Cursor if you're after AI-assisted coding but can accept using other tools to complete the build. Choose KXApp if you want a lightweight environment, a quick start, cross-platform development, or simply don't want to burn too much energy on toolchain configuration. There's no absolute right or wrong among the three iOS development toolchain options — tools serve the project, so pick according to your actual needs.

HTTPS Capture Meets Certificate Pinning: Bypass App Certificate Validation with TraceEagle

UIKit_Ninja — Tue, 15 Sep 2026 09:52:18 +0000

Removing Certificate Pinning (Unpinning)

Some apps use certificate pinning: the certificate is installed and the proxy is running, yet the app stubbornly trusts only the certificate bundled inside it, and the moment it sees the proxy certificate it throws an error and refuses to connect. This article shows you how to select such an app and remove its certificate validation with one click, so that it trusts the proxy certificate again and HTTPS traffic can be decrypted normally.

1. When to Use This Capture Approach

Come to this step when any of the following happens:

The certificate has been installed as described in Certificate Installation and the proxy is configured correctly, but a particular app simply can't get online / keeps reporting network errors.
Every other app works fine, and only this one loses connectivity once the proxy is enabled — most likely because it uses certificate pinning.
You want to capture this app, but it doesn't trust the proxy certificate, the handshake is cut short, and you can't even see the ciphertext in the request list.

The key distinction in one sentence: removing certificate pinning only makes the app willing to trust the proxy certificate; it doesn't perform decryption itself — the proxy still does that. If what you want is to pull plaintext directly out of the program's internals, that's a different matter — see Application-Layer Capture.

2. Prerequisites

The proxy certificate is already installed and trusted — if not, see Certificate Installation first.
A proxy session is already running: unpinning builds on proxy capture, so get other apps captured first, then deal with this stubborn one. See Proxy Capture.
Prepare the corresponding environment for your target:
- Desktop programs: they can be listed and selected directly.
- iOS apps: the device is ready and the app is of a re-signable type; if you're unsure how to connect a device, see iOS Capture.
- Android apps: the device is rooted; for connecting the device and capturing, see Android Capture.

3. Step-by-Step

Open the "Remove Certificate Pinning (Unpin)" panel and switch to the tab matching your target: Desktop Programs / iOS Apps / Android Apps.
Select the target to process:
- Desktop programs: check them in the process list; you can filter by process name or PID, and multi-select is supported.
- iOS apps: pick the device first, then choose from the app list; you can also enter the bundle ID manually.
- Android apps: pick the device first, then choose from the app list; you can also enter the package name / process name / PID manually.
Toggle the two switches as needed:
- Automatically handle child processes (desktop): in some applications, child processes are the ones sending and receiving network requests; enable this to handle them too and avoid missing traffic. It's recommended to keep it on for multi-process desktop apps.
- Restart target: restart the app once before processing, so that requests sent during its early startup are covered as well. Check this if you want to capture the few requests fired "the moment it opens".
Click Start. The panel gives real-time feedback on the result: on success it tells you how many targets / processes were handled; if the app uses an uncommon networking component and isn't supported yet, it explicitly tells you instead of leaving you waiting.

4. Verification: Confirming It Now Yields Plaintext

Once processing is done, go back to the proxy session and have the app send a request again (refresh the page, re-enter a feature):

The app that used to error out / lose connectivity now works normally: it no longer fails to connect as soon as the proxy is on.
Its traffic now appears in the request list: request line, request headers, and body are all there.
TLS shows "Decrypted": the response is readable plaintext (such as JSON), instead of the state where the handshake was cut short and nothing could be seen.

If the traffic shows up but the content is still ciphertext (not a rejected handshake, but something that can't be decrypted), that's usually not a certificate pinning problem; get the plaintext from inside the program instead — see Application-Layer Capture.

5. Can't Process It / Still Can't Connect? Check Item by Item

Symptom	Most likely cause	What to do
The panel says this app isn't supported yet	It uses an uncommon networking component	Try a different approach and get plaintext from inside the program: switch to Application-Layer Capture
Processing succeeds, but only requests made after startup are captured; the first few are missed	The app had already been running for a while when you processed it	Check Restart target and process again to cover requests from early startup
A desktop app has been processed, but some traffic is still missing	Its network requests are sent by child processes	Turn on Automatically handle child processes and process again
Unpinning doesn't work for Go / Rust programs or desktop Java programs	Such programs usually don't need unpinning	They mostly read the system certificate store — just install the certificate into the system trust store; see Certificate Installation
iOS apps won't list / can't be selected	The device isn't connected properly, or the app isn't of a re-signable type	Prepare the device and environment as described in iOS Capture, or enter the bundle ID manually
Android apps won't list	The device isn't rooted	Prepare a rooted device as described in Android Capture

Next Steps

Now that decryption works, how to read these requests, switch views, and decode them: see Viewing and Decoding Data.
The full workflow for capturing a specific app on iOS / Android: see iOS Capture and Android Capture.
To get plaintext directly from inside the program (bypassing the certificate route): see Application-Layer Capture.
For private / in-house protocols that you want the tool to recognize: see Custom Protocol Decoding.

Guide to Applying for an iOS Push Certificate and Configuring APNs Bulk Push

UIKit_Ninja — Mon, 14 Sep 2026 10:31:47 +0000

Guide to Applying for an iOS Push Certificate and Configuring APNs Bulk Push

To add push messaging to an iOS app, you first need an APNs push certificate, and then a push channel that can manage device tokens and support bulk sending — in AppUploader, this entire set is an operations push platform independent of App Store Connect, with four tabs: Push Channels, Device Library, Send, and History.

Step 1: Issue an APNs Push Certificate

Open the "Certificates" page:

Click "New Certificate" and select the push certificate type.
Select the Bundle ID to bind (if you don't have one yet, register it on the "Bundle ID" page first).
Fill in the certificate name and email, and set a .p12 protection password (the server does not store it, so keep it safe).
We recommend enabling "Cloud Backup", so that you can use it directly on the push page later without transferring files back and forth.
After submission, the push certificate is issued.

A push certificate is deployed on the push server and used exclusively for the APNs channel; it is not used to sign and compile the app itself, which is where it differs from a signing certificate.

Step 2: Create a Push Channel and Get the App Key

Open the "Push Channels" tab on the "Push" page:

Click "New Channel".
Select the APNs push certificate issued in the previous step.
Enter the export password of the certificate's .p12 (if the certificate has already been backed up to the cloud, entering the password is enough to retrieve the private key).
Fill in the channel name (for example, "Marketing Push") and select the environment (Production / Sandbox — Sandbox is usually used during development and debugging).
After submission the channel is created and you get an App Key; in "Integration Code" you can find the integration instructions for developers.

Step 3: Have the App Report the Device Token

Following the guidance in the "Device Integration Instructions", ask the app developer to add Push Notifications under Signing & Capabilities in Xcode and put the sample method into the AppDelegate, so that the app calls the reporting API after obtaining the APNs token. Devices that report successfully automatically appear in the "Device Library" tab, where you can search by note/token/tag, and also manually add device tokens or edit tags. During testing, choose the LAN address where the phone is located, and make sure the phone and your computer are on the same Wi-Fi.

Step 4: Compose and Send a Notification

On the "Send" tab:

Select the push channel to use.
Fill in the title, content, sound (default alert/silent) and badge number; when you need finer control, switch to "Advanced Mode" to edit the raw JSON Payload directly.
Choose the send target: all devices / by tag / specific devices.
After confirming the number of valid devices the notification will be sent to, click "Send Now"; when it finishes, the number of successful/failed devices is displayed.

Step 5: View Delivery Results

The "History" tab records the time, content, target and result of each send. Click "Details" to see the per-device delivery report (success/failed/delivered and the failure reason); you can also "Resend" a history entry directly.

One Thing to Note

Deleting a push channel also deletes the device library and send history under that channel, and the App Key becomes invalid immediately. This operation cannot be undone, so if you only want to pause pushing, do not delete the channel.

TraceEagle iOS Packet Capture Tutorial: How to Choose the Three iPhone No-Jailbreak Capture Methods

UIKit_Ninja — Fri, 11 Sep 2026 10:04:33 +0000

iOS Packet Capture

This guide teaches you how to capture packets on iPhone / iPad: connect a data cable to a computer, choose a mode, and start capturing—no jailbreak throughout. From 'zero-config visibility into system requests' to 'full device traffic' to 'complete plaintext for a single app', each of the three modes has its own steps. This guide walks you through them step by step.

1. When to Use It and How to Choose Among the Three Modes

After you select iOS in New Session for iOS packet capture, you will be asked to choose one of three. First pick the one you want from the table below, then follow the corresponding section:

Your Goal	Which Mode	What You Can See	Certificate / Re-signing Needed?
Quickly see which HTTPS requests this device sends (URL / status / headers)	System-level Capture	Even for regular apps, you can see request URLs and headers (Body not visible)	Only install a device diagnostics profile
All traffic from the entire device (including non-HTTP, handshake / SNI)	NIC Capture	Full data, ciphertext by default; can do targeted decryption for a specified app	Not needed to view ciphertext; re-sign only to decrypt plaintext for a specific app
Complete plaintext send/receive (including Body) for an app	App-level Capture	Complete plaintext for a single app	Target app must be re-signed with a development certificate

System-level capture is the easiest: for regular apps and App Store apps, you can also see which HTTPS addresses they request—no CA certificate, no proxy, and no fear of certificate pinning. To quickly investigate 'which endpoints does this app actually connect to', start with it.

In addition to the above three, iPhone / iPad can also use proxy capture: point the device's Wi-Fi proxy to this computer, install a root certificate, and you can capture HTTPS plaintext just like on a computer, with full capabilities such as rewrite and replay. Suitable for debugging apps that use the system proxy.

2. Prerequisites (Common to All Three Modes)

TraceEagle is installed and started (on first launch, just accept the system permissions).
Connect iPhone / iPad to the computer with a data cable, and tap Trust when prompted on the device.
No jailbreak required: all three modes are for non-jailbroken devices.
Newer systems are also supported: iOS 17 and later can still connect and capture normally.
Prepare certificates / re-signing according to the mode (no rush if you do not have them; the tool will guide you when needed):
- System-level capture: install a device diagnostics profile (once is enough).
- NIC capture: to view only ciphertext and addresses, no certificate is needed; to decrypt plaintext for an app, you must re-sign that app with a development certificate.
- App-level capture: the target app must be re-signed with a development certificate (App Store and system apps must be re-signed first before they can be targets).
- For detailed steps to install certificates / profiles, see Certificate Installation.

3. Select a Device: The First Common Step for All Three Modes

Create a new session, and select iOS for Target.
Select your phone in the Device dropdown; if it does not appear right after plugging in, click Refresh. If the same device also appears over the network, identifying the USB entry by USB / Network is the most reliable.
Under Mode, select one of NIC Capture / System-level Capture / App-level Capture, then read the corresponding section below.

4. System-level Capture — Easiest, Works with Regular Apps

If you want to quickly see 'which HTTPS requests this iPhone sends' without installing a CA certificate, setting a proxy, or dealing with certificate pinning, choose this mode.

Select System-level Capture for Mode.
If you have not installed the device diagnostics profile, install it once as prompted (see Certificate Installation); skip if already installed.
Click Create to start, then operate the app you want to observe normally on the phone.

How much you can see depends on the target app:

Regular apps, App Store apps: usually you can see the request method, full URL (HTTPS addresses are also plaintext), status code, request headers, and response headers.
Apps signed with a development certificate: even the complete request / response Body is visible.

5. NIC Capture — See Everything on This Device

To view all network traffic of the entire device—unrestricted by app or protocol, including non-HTTP QUIC and custom protocols—choose this mode.

Select NIC Capture for Mode.
Click Create to start. By default, what is captured is ciphertext packets + metadata (target address, port, and the SNI hostname in the TLS handshake)—enough to see 'where this device connects and with what protocol'.
To see plaintext for a specific app: check Decrypt this Program for that app to decrypt its plaintext; the prerequisite is that the app has been re-signed with a development certificate (see Certificate Installation).

6. App-level Capture — Complete Plaintext for a Single App

To obtain the complete plaintext (including Body) sent and received by one specific app—it takes data from inside the app, and certificate pinning cannot block it—choose this mode.

Select App-level Capture for Mode.
Select the target app from the app list. Only apps that have been re-signed with a development certificate are selectable; the rest are grayed out—if the app you want to capture is gray, re-sign it first (see Certificate Installation).
If you also want to capture early startup traffic, you can first close the target app, then click Create and reopen it.
Click Create to start, then operate the app on the phone.
If plaintext cannot be decrypted: turn on the socket traffic switch as a fallback—for apps whose plaintext cannot be obtained through the regular method, use a lower-level path to get data.

7. Verify: Confirm You Have Captured Traffic

After creation, a session tab opens. Operate the corresponding app on the phone, and requests will appear in the left list in real time. Click any entry to view details:

System-level Capture: you can see the request method, full URL, status code, and request / response headers (for apps signed with a development certificate, you can also see the Body).
NIC Capture: you can see the target address, port, and SNI hostname; for an app with Decrypt this Program checked, the response is readable plaintext.
App-level Capture: the request line, request headers, and Body are all present, and the response is plaintext rather than garbled ciphertext.

8. Cannot Connect / Cannot Capture? Troubleshoot Item by Item

Symptom	Likely Cause	What to Do
Phone not visible in the Device dropdown	Not plugged in properly, not trusted, or just plugged in and not enumerated yet	Try another data cable / USB port, tap Trust on the phone, then click Refresh
Two entries for the device; which one to choose	The same device is on both USB and network	Prefer the USB entry; it is the most reliable
System-level capture creates no entries	Device diagnostics profile is not installed or not effective	Install the profile as described in Certificate Installation, then create the session again
System-level capture shows only addresses and headers, no Body	Target is a regular app / App Store app	This is a limitation of system diagnostic logs; for a complete Body, switch to App-level Capture (the app must be re-signed first)
NIC capture is all ciphertext; plaintext is not visible	Targeted decryption was not enabled for the target app	Check Decrypt this Program for the app; if it cannot be checked, the app has not been re-signed with a development certificate—re-sign it first (Certificate Installation)
Target app is gray and unselectable in App-level Capture	The app has not been re-signed with a development certificate	Re-sign it first (both App Store / system apps must be re-signed first), see Certificate Installation
App-level Capture captures traffic but cannot decrypt plaintext	The app uses a proprietary / statically linked library	Turn on the socket traffic switch as a fallback and use a lower-level path to get data
Want to capture requests from the first few seconds after app launch	The session was opened after the app was already running	Close the app first, create the session, then reopen it
Certificate / profile is installed but capture still fails	The profile has not been trusted in the phone's Settings	Go to the phone's Settings and trust the corresponding profile / certificate, then retry; see Certificate Installation for details

Next Steps

How to read captured data, switch views, and decode: see Data Viewing and Decoding.
To modify while viewing, edit and resend requests, or intercept and manually modify them: see Rule Rewriting and Breakpoint Interception, Request Construction and Replay.
For private / proprietary protocols and teaching it how to read them yourself: see Custom Protocol Decoding.
To capture HTTPS plaintext on a phone like on a computer and use full rewrite/replay capabilities: see Proxy Capture with Certificate Installation.
To capture Android devices: see Android Capture.

iOS Provisioning Profile Management: Create, Regenerate, and Clean Invalid Profiles

UIKit_Ninja — Thu, 10 Sep 2026 10:05:41 +0000

Provisioning Profile

Requires a paid Apple Developer Program membership.

A provisioning profile (Provisioning Profile, i.e. .mobileprovision) is used to build an App. You need one for development and one for distribution. After modifying the permission configuration of a Bundle ID, you must regenerate and download the provisioning profile; push notifications do not require a provisioning profile.

A provisioning profile is bound to one Bundle ID and linked to several certificates and devices (only distribution profiles require devices).

Provisioning Profile Types

Type	Purpose
iOS / tvOS / macOS / DriverKit App Development	Install development builds on test devices (the iOS type also covers iPadOS, watchOS, and visionOS)
iOS / tvOS Ad Hoc Distribution	Install the app on a limited number of registered devices
iOS / tvOS / macOS App Store Distribution	Submit the app to the App Store / Mac App Store
macOS Direct Distribution (Developer ID)	Distribute Mac apps directly outside the Mac App Store
iOS / tvOS Enterprise In-House Distribution	Distribute apps within an organization; requires the Apple Developer Enterprise Program

Create a Provisioning Profile

Open Appuploader.

Click "New Provisioning Profile" and enter a name.
Select the type (this determines the available certificates and devices).
Select the associated Bundle ID; if you don't have the required Bundle ID yet, click "New Bundle ID" directly.
Select the associated certificates (multiple selections allowed, or choose "All Certificates").
If it is a distribution type that requires devices, select the associated devices (multiple selections allowed, or choose "All Devices"; you can also click "Register Device" directly).
Once submitted, the provisioning profile is created and can be downloaded from the list.

Regenerate and Clean Up

Regenerate: After a profile's certificates or devices change, click "Regenerate" — the profile is deleted and recreated with the currently valid certificates and all enabled devices. If the profile has no associated Bundle ID, it cannot be regenerated automatically.
Clean Up Invalid: Delete all invalid (INVALID / EXPIRED) provisioning profiles with one click; they can be recreated at any time afterward.

Search

The list supports searching by name / type / UUID.

No-Login File Viewing & App Store Submission: A Practical Guide

UIKit_Ninja — Wed, 09 Sep 2026 09:31:19 +0000

Appuploader: Files & Submission

No Apple ID login required. Supports viewing information in .plist, .mobileprovision, .p12, and .ipa files; submitting to App Store; installing to connected iOS devices; and exporting public/private keys from a .p12 file. Maximum single file size: 2.9GB.

Uploading Files

Click Add File to select a file, or drag and drop files directly into the list area (multiple files can be dropped at once). Uploaded files appear in the list with their types labeled (Plist File / Provisioning Profile / P12 Certificate / IPA Package / Other).

Viewing File Content

Open Appuploader, click a file to enter the viewer. Different file types show different information:

Plist: Displays XML content.
Provisioning Profile (.mobileprovision): Bundle name, display name, version, minimum OS, embedded provisioning profile details, signing certificate, CA certificate chain.
P12 Certificate: If encrypted, enter the export password to parse (leave blank if no password). After parsing, you can export the public key PEM or export the private key PEM.
IPA Package: Displays signing information, including whether it is signed, embedded provisioning profile, and signing certificate. It also indicates whether the information source is “binary code signature (actual signing result)” or “embedded provisioning profile (allowed scopes only)” — these may differ. Note that IPA packages downloaded from the App Store have their provisioning profile removed by Apple; only development, Ad Hoc, and enterprise distribution packages include provisioning profiles.

Submitting IPA to App Store

On first use, you need to set an Upload-Specific Password: use your Apple ID and an App-Specific Password (not your login password). Go to Account Management & Security → App-Specific Passwords, generate one (format: xxxx-xxxx-xxxx-xxxx). Note that what you manually name is only the password label; the auto-generated string is the password you need to fill in.
Select an IPA file and click Submit to App Store.
The submission process does not require fully logging into that Apple account and will not trigger two-factor authentication.

Installing to a Phone

Select an IPA file and click Install to Phone. Two methods are provided:

Connected Device Installation: Connect and unlock the device with a USB cable, and make sure you trust this computer. The IPA must include the device's UDID to install successfully.
QR-Code Installation (LAN): Connect the iPhone/iPad and computer to the same Wi-Fi, use the system camera to scan the QR code, and tap the installation prompt that appears at the top.

Before installation, the system automatically detects the provisioning profile type (Development / Ad Hoc / Enterprise Distribution / App Store). If an issue could cause installation to fail (e.g., the device UDID is not included in the provisioning profile), it prompts with the specific problem, and you can choose Install Anyway or Cancel Installation.

Other

You can delete uploaded files at any time.

Packet Capture Tool Comparison: Charles, Fiddler, TraceEagle, Wireshark, and Proxyman

UIKit_Ninja — Tue, 08 Sep 2026 09:33:54 +0000

Packet capture is one of the most common techniques developers use in daily debugging. There are many tools on the market, but each has a distinct positioning and applicable scenario, so choosing the right one can save a lot of time.

Charles: The Most Widely Used Proxy Packet Capture Tool

Charles has the largest user base for HTTP/HTTPS packet capture. Its advantage lies in its low learning curve—after installing it on a Mac, configuring the proxy on your phone, and installing the certificate, you can see the request list within minutes. It supports Breakpoint interception to modify requests, Repeat for replaying requests, and Map Local/Remote for request mapping. Once SSL Proxying is configured with the target domains, HTTPS traffic can also be decrypted.

Charles's limitations appear mainly in several scenarios: with SSL Pinning, proxy certificates are rejected by the client, leaving only handshake failure records; traffic from apps that ignore the system proxy is not captured; HTTP/3 and QUIC support is insufficient; and the certificate configuration flow on Windows is more complex than on Mac.

Fiddler: The Main Packet Capture Tool in the Windows Ecosystem

Fiddler is widely used on Windows. Its core strength is FiddlerScript—writing scripts in C# to customize request and response handling, which suits automated testing scenarios. It supports breakpoint debugging and request construction. A built-in performance analysis panel shows request latency and bandwidth usage.

Fiddler's shortcomings are also obvious: on macOS only a limited-feature Beta version exists, and Windows remains the primary platform; HTTPS decryption requires manually configuring certificates, with more steps than Charles; the interface feels dated, and filtering is less convenient when handling large volumes of data.

TraceEagle: Covers More Edge Cases

TraceEagle takes a different approach from the tools mentioned above. It builds on proxy-based capture and fills the blind spots of other tools: apps that ignore the system proxy can be captured directly from the network interface or via in-app stream extraction; in SSL Pinning scenarios, there is no need to swap certificates in the middle—plaintext can be obtained directly from inside the app; HTTP/3 and QUIC are handled via three modes: downgrade capture, fidelity transparent passthrough, and actual decryption.

The workflow after packets are captured is also more complete—you can set breakpoints and modify requests in the same interface, right-click to run load tests and view p99 tail latency, compare differences line by line, and reverse-engineer OpenAPI documents. It supports packet capture on iOS without jailbreak and on Android without installing certificates, and runs on Windows, macOS, and Linux.

Wireshark: The Most Comprehensive Protocol Analyzer

Wireshark is unrivaled in the depth of protocol analysis, supporting parsing of thousands of protocols. Its filter expressions are powerful, allowing you to combine source IP, port, protocol, and other conditions to locate specific traffic. It is the standard tool for troubleshooting TCP retransmissions and TLS handshake details.

To capture iOS mobile traffic with Wireshark, you need to use the rvictl command on a Mac to create a virtual interface; it cannot be used directly on Windows. Moreover, Wireshark does not handle HTTPS decryption—you must export keys separately. For everyday API debugging, Wireshark's operational workflow is longer than that of proxy-based tools.

Proxyman: A Modern Choice on macOS

Proxyman is a packet capture tool that has become popular on macOS in recent years. Its interface is more modern than Charles and Fiddler, and the visual configuration for request filtering rules is more intuitive. It supports grouping by domain, advanced search, and script extensions. In SSL Pinning scenarios, it can be solved by installing a root certificate together with iOS's SSL Kill Switch.

Proxyman's limitation is that it supports macOS only, so Windows users cannot use it. HTTP/3 support is also limited. Its deep analysis capability and script flexibility are not as strong as Fiddler's.

Selection Recommendations

For simple HTTP API debugging in daily work, Charles or Proxyman is sufficient. In Windows environments where scripting capability is required, choose Fiddler. For deep dives into the TCP protocol layer, Wireshark is a must. When encountering edge cases such as certificate pinning, HTTP/3, or proprietary protocols in a project, adding TraceEagle to your toolchain fills in the blind spots.

Developing iOS Without a Mac: Several Feasible Solutions Using Cloud Services and Built-in Compilers

UIKit_Ninja — Tue, 08 Sep 2026 08:58:45 +0000

The most rigid limitation of iOS development is that you must use a Mac. But in practical work, there are always scenarios that cannot avoid this problem—your company assigns you a Windows laptop, your budget is too limited to afford a Mac, or you are only temporarily participating in an iOS project. Are there feasible ways to do iOS development without a Mac? Sorted by cost and experience, a few options are available.

Cloud Mac Services

Services like MacStadium and MacinCloud offer remote Mac servers billed by the hour or month. Accessing them remotely gives you a full Xcode environment; compiling, packaging, and uploading all work fine. The advantage is that the experience is almost identical to a real Mac; the downside is that latency depends on network quality, and long-term costs are not cheap.

Another route is building your own Hackintosh, installing macOS on compatible PC hardware. This lets you use Xcode, and performance can be better than a low-end Mac. However, installation and maintenance can be troublesome, system updates may break it, and hardware compatibility is limited.

Remote Mac + Local Coding

The most flexible solution: write code locally in Windows or Linux using VS Code, then connect to a remote Mac for compilation. Use SSH to connect to the remote Mac and use xcodebuild to package, or use VS Code's Remote-SSH extension to edit code directly in the remote environment.

The coding experience is free, but switching between compilation and debugging across two environments can be tedious. Every time you change code, you have to push it to the remote; when errors occur, you switch back to the local editor. Certificate and provisioning profile management also depends on the remote Mac. This works if you are only occasionally changing a few lines, but efficiency drops under frequent iterations.

Hackintosh

Hackintosh is the practice of installing macOS on an ordinary PC. A mid-range desktop running Xcode may outperform a Mac mini at a similar price. During installation, you need to pick compatible hardware, configure the bootloader, and work through driver issues. After major macOS releases, you may need to redo the bootloader configuration.

Hackintosh exists in a legal gray area—macOS's license agreement does not permit running it on non-Apple hardware. It is not recommended for official team use, though it is a good option for personal learning and experiments.

KXApp Built-in Compiler

KXApp goes about things differently from the above options—it does not need a system-level installation of macOS; it runs directly on Windows or Linux. It bundles an iOS compilation toolchain, covering everything from creating Swift/Objective-C/Flutter projects, compiling and building, to running and debugging on a real device, all inside the same tool.

With KXApp, iOS development does not require a remote Mac, a virtual machine, or a Hackintosh. Connect your phone via USB, and you can directly build and install onto the physical device; the tool handles code signing and deployment automatically. iOS compilation for Flutter projects is also supported out of the box, saving you the trouble of configuring Flutter and Xcode integration.

That said, an objective review is warranted: KXApp is suitable for rapid prototyping, Flutter project validation, and lightweight iOS development. For complex project configuration and Instruments performance analysis, Xcode remains essential.

Choosing a Solution

If budget is not a concern, a cloud Mac offers the closest experience. If cost-effectiveness is what you care about, you can consider building a Hackintosh. If you mainly work with Flutter or do lightweight iOS development, KXApp runs directly on Windows, saving the overhead of a Mac environment.