DEV Community: DataStack

How iOS Projects Compile: A Full Breakdown of the Build Pipeline and Common Build Approaches

DataStack — Wed, 23 Sep 2026 10:31:32 +0000

A while back I was mentoring a newcomer who asked a pretty basic question: after you hit Run in Xcode, what actually happens? How does an iOS project go from a folder to that app on your phone? The question looks simple, but unpacked it's a multi-stage pipeline, and each stage has its own job. Once you understand how iOS projects are compiled, you can troubleshoot many build errors yourself. This article breaks down the whole process and then looks at which build entry points exist besides Xcode.

The Complete Build Pipeline

An iOS project isn't compiled in one step. The source code is first processed file by file: Swift code goes through swiftc, Objective-C and C/C++ go through clang, and each source file is compiled into a machine-code object file. Syntax errors and type errors surface at this stage. Next comes linking: the linker merges the scattered object files into an executable and resolves references to system frameworks (UIKit, Foundation, and so on). The most common error at this stage is Undefined symbols. Then comes resource processing: images, xibs, and storyboards are compiled into the corresponding resource formats and packaged into the bundle. Finally, signing: the executable is signed with a certificate and provisioning profile, and an unsigned app can't be installed on a real device.

What Gets Produced

Once these steps finish, you get a .app directory containing the executable, the resources, and Info.plist. Installing on a real device or shipping to the store requires an .ipa: an installation package that arranges the .app according to signing requirements. For development and debugging, a .app is enough; .ipa is only needed for distribution and app review submission.

Building in Xcode

Hitting Run in Xcode is the one-click version of this pipeline: compile, link, sign, install to the simulator or a real device, and launch, all at once. Hitting Build only compiles and links—no installation, no launch—which is handy when you just want to verify that the code compiles. Xcode wraps these steps in its build system and hides the details from developers, which is good enough for day-to-day work.

Command-Line Builds

The command line is another entry point. xcodebuild is the standard tool: specify the workspace, scheme, and configuration, and it compiles in the terminal. Most iOS builds on CI rely on it; combined with fastlane, it can handle automatic signing, packaging, and uploading. This route is well suited to automation, but the drawback is that the environment requirements don't change—xcodebuild depends on the toolchain installed by Xcode, so it's unusable on a machine without Xcode.

Building Without Xcode

If your scenario is that you don't want to install Xcode—doing cross-platform development on Windows, say, or a Mac whose disk can't spare those ten-plus GB—there are also solutions with a built-in toolchain. KXApp (快蝎) ships with a complete build toolset, so you can compile iOS projects without installing or updating Xcode. It supports Swift, Objective-C, and Flutter project types; connect an iPhone and build-and-install to the real device in one click; when development is done, generate an installation package in one click, covering both test distribution and store submission scenarios. In KXApp, everything from creating a project to compiling and installing is a closed loop, so teams that don't want to maintain a full Xcode environment can skip the time spent fighting with it.

How to Diagnose Common Build Errors

The most common categories of build errors: signing errors, where the certificate and provisioning profile don't match—check whether the certificate type and the provisioning profile in your developer account correspond to the same App ID; deployment target issues, where the project's OS version requirement is higher than the current toolchain supports—lower the target or switch to a newer toolchain; linking errors, where Undefined symbols indicates a missing framework—add the corresponding library under Build Phases > Link Binary With Libraries.

Under the hood, compiling is the toolchain doing the work; Xcode, xcodebuild, and KXApp's built-in toolchain are just different entry points. Understand each stage of the pipeline and you won't panic no matter which entry point you use.

TraceEagle Code Generation and API Doc Export, One-Click Request Code: cURL to Python Export and OpenAPI API Doc Generation

DataStack — Tue, 22 Sep 2026 10:01:24 +0000

Generate Code and Export API Documentation

This article shows how to turn captured requests into artifacts: convert a single request into runnable code with one click (cURL / Python / JavaScript / Go / OkHttp), automatically merge an entire session into standard API documentation (OpenAPI), or export it to the universal HAR format; session files captured elsewhere can also be imported for further analysis. No manual copying or writing—everything comes directly from real packet captures.

1. When to Use It

Use it if any of the following applies:

You want to reproduce a real captured request in a script / project, or send it to a colleague (anyone can run a cURL command).
You have a working request in the request builder and want to export it as code to continue development.
You have captured a segment of API traffic and need a deliverable, importable OpenAPI API document—for third-party integration, supplementing backend docs, or generating test cases.
You want to export this packet capture in a universal format (HAR) for delivery, archiving, or handing off to another tool.
You have session files captured by someone else / in production / by another tool and want to bring them in to continue analysis using decoding, host profiles, and request diff here.

2. Prerequisites

TraceEagle is installed and running.
To generate code / export OpenAPI / export HAR: first capture requests (any capture method works; see Quick Start. As long as there is data in the request list, you can proceed.
For 'Import External Session' only: no need to capture packets first; just have the corresponding session file.

3. Step-by-Step Operations

A. Generate Code for a Single Request and Copy It

In the request list, select a request you want to reproduce or share.
Right-click → 'Generate Code…'. (You can also configure a request in Request Construction and Replay, then click 'Generate Code'; the export method is the same.)
At the top, switch language to regenerate instantly; there are 5 formats in total:
- cURL (paste into a terminal and run)
- Python
- JavaScript
- Go
- OkHttp (Java / Kotlin)
Click Copy, then paste it into a terminal / project / send it to a colleague.

The generated code is complete: request method, URL, all request headers, and request body are included; request headers also keep their original order and duplicates are allowed, preserved exactly as-is, so the result matches the real request when run.

Common tools often reorder and deduplicate request headers when generating code, which makes reproduction inaccurate; here they are preserved as-is for more faithful reproduction.

B. Export an Entire Session to OpenAPI / HAR

Export OpenAPI (API Documentation)

After capturing a segment of API traffic, open Export API Documentation (OpenAPI).
It analyzes first, then exports: it automatically identifies APIs from the current session and lists them for you to select. The list directly shows each API's method, path, occurrence count, and observed status codes, giving you a clear overview.
Select the APIs you want (only selected ones are exported, avoiding noise). The tool automatically helps you:
- Merge paths: templatize paths containing specific IDs, e.g. /users/123 → /users/{id}, merging multiple requests to the same API into one entry.
- Infer structure: merge request / response JSON structures, group responses by status code, and organize path variables into parameters.
On the right, preview in real time the generated standard OpenAPI 3.0 document. Once confirmed, click Copy or Download and import it into any OpenAPI-supported API tool to continue working.

Export HAR (Universal Exchange Format)

On the session, select Export HAR.
The entire packet capture is exported with one click as a standard HAR 1.2 file for delivery, archiving, or handing off to another tool for further analysis.

C. Import External Sessions

Select Import Session.
Select the file to import—HAR 1.2, .pcap / .pcapng, and session files exported by common packet capture tools are supported.
After import, packets captured by others appear in the request list, and you can continue viewing, comparing, and exporting as usual, as well as continue analysis with decoding and host profiles here.

4. Verification: Confirm You Have the Artifacts

Generate Code: the preview refreshes instantly when switching languages; if the cURL command runs successfully in a terminal and returns the same result as captured, it means request headers / body were fully included.
Export OpenAPI: after selecting APIs, the right-side preview shows methods, paths (already templatized as /{id}), parameters, and response structures; the copied / downloaded result is an OpenAPI 3.0 document that API tools can import.
Export HAR / Import Session: after export you get a .har file; after importing an external file, corresponding request entries appear in the request list, and clicking one shows full details.

5. Tips and Troubleshooting

Symptom	Likely Cause	What to Do
Generated code does not match the real request when run	Request header order was manually changed, or a header was missed	Regenerate code from the original request; header order and duplicates are preserved by default, so no manual fixing is needed
Desired language is not available	Currently five formats are provided: cURL / Python / JavaScript / Go / OkHttp	Export the closest one first (e.g. cURL), then convert as needed
Unrelated APIs appear in the OpenAPI list	The session contains noise traffic	In the 'analyze first, then export' list, check only the APIs you want; unselected ones are not exported
The same API is split into multiple entries	Paths contain specific IDs and were not merged	Merging templatizes paths like `/users/123` into `/users/{id}`; if they are still separate, confirm their methods / path structures are consistent
Want to analyze packets captured in production / by a colleague	Data is not in the local session	Use 'Import Session' to bring in HAR 1.2 / `.pcap` / `.pcapng` files; after import, view, compare, and export as usual
Want to hand off to another tool that does not recognize this tool's format	A universal exchange format is needed	Export HAR 1.2 (for delivery, archiving, cross-tool use) or OpenAPI 3.0 (universal API documentation)

Before generating code, inspect the request clearly, switch views, and decode it: see Data Viewing and Decoding
To fine-tune a request before exporting it as code, or modify and resend it: see Request Construction and Replay.
To compare an imported session line by line with the local one: see Request Diff.
For private / in-house protocols, if you want the tool to understand them before export: see Custom Protocol Decoding.

What Can a Free Apple ID Do Without Joining the Paid Developer Program?

DataStack — Sun, 20 Sep 2026 10:33:30 +0000

What Can a Free Apple ID Do Without Joining the Paid Developer Program?

A free Apple ID (without joining the $99/year Apple Developer Program) can use part of the development and testing features, but it has clear limitations and cannot officially publish to the App Store. AppUploader has special support for free accounts, letting you get the development and testing workflow working before you decide to pay.

What can a free account use, and what are the limitations?

Feature	Free account	Paid account (Apple Developer Program)
Login method	App login only (no Xcode required)	Web login / API key / App login all supported
Signing certificate validity	7 days only	Normal validity, renewable
Number of test devices that can be registered	Up to 3	Up to 100 per device type
Developer portal features such as provisioning profiles and certificates	Partially restricted	Fully available
App Store Connect app management, official publishing	Unavailable	Available

How do free accounts log in?

When adding an account, select "App Login" (uses the App protocol, no Xcode required). This is a login method designed specifically for unpaid free Apple IDs. The other two methods, web login and API key, usually require the account to have joined the paid Apple Developer Program.

When must you upgrade to a paid membership?

If you need:

Signing certificates valid long-term (not 7 days);
To register more than 3 test devices;
To create apps, submit for review, and officially release on App Store Connect;

you need to go to developer.apple.com to purchase an Apple Developer Program membership. After purchase, return to the "Account Overview" page in AppUploader. The account status will automatically update to show that the paid program has been joined. Your previous operations under the free account are unaffected, and you can directly switch to web login or generate an API key to use the full functionality.

CaptureEagle Packet Capture Root Certificate Management and Installation

DataStack — Sun, 20 Sep 2026 10:01:43 +0000

Certificate Management and Installation

To capture HTTPS with a proxy, the first step is to make devices and applications trust this tool's root certificate—otherwise you get TLS errors and cannot decrypt. Certificate management makes this one-click and comprehensive: local machine, mobile, and even apps that "still don't trust it despite system certificates installed" can all get the certificate installed.

1. One-click installation on the local machine

Check at any time whether the local machine already trusts this tool's root certificate.
One-click "Install to local machine and trust". Install once, and all subsequent sessions can decrypt HTTPS.
When needed, download the root certificate (multiple formats) for manual distribution.

2. Mobile QR-code installation

Generate a QR code for every available LAN address. Scan it with the mobile camera, open the installation page, and install the certificate—both iOS and Android are supported.
iOS also provides one-click configuration profile installation.
Rooted Android devices can install the root certificate directly into the system certificate store, eliminating manual import.
The root certificate is globally universal; each device only needs to trust it once.

3. Full certificate coverage: even apps that "don't trust system certificates" can be decrypted

Some apps still cannot be decrypted even after system certificates are installed—they only trust their own certificate list. Full certificate coverage can install the root certificate directly into these apps, allowing them to be decrypted:

Java applications
Python applications
curl / wget / Ruby / PHP / git and other command-line and scripting tools
Firefox / Thunderbird and other software

The tool automatically discovers these applications on the local machine (including running ones) and shows "installed / not installed" for each. If auto-discovery misses some, you can manually enter the path to add them.

This is exactly the longstanding pain point of ordinary packet capture tools: the certificate is installed, but the application still cannot be decrypted. Full certificate coverage is designed specifically for this.

4. Client certificates

If the target site requires a client certificate and you happen to have one, you can import it (including the password) on the "Client / Domain Certificate" page. Then you can decrypt these sites normally.

5. When to use

Before using the proxy to capture HTTPS for the first time, first make the local machine / mobile trust the root certificate.
Mobile packet capture: scan the QR code to install the certificate.
When the target is a Java / Python / curl / Firefox app and decryption fails: use full certificate coverage to install the certificate into them.

Xcode Programming Languages, Key Features, and Beginner Guide to Lightweight Alternatives

DataStack — Wed, 16 Sep 2026 10:11:15 +0000

Two weeks ago, a friend who had just switched to iOS development asked me what languages Xcode actually supports and what its features are — opening the app and facing a wall of panels, they had no idea where to start. This is actually a very common problem for beginners. So here I'll go through the programming languages and core features Xcode supports, then talk about the common barriers and pain points for newcomers, and a lighter path to get started.

Programming Languages Xcode Supports

Xcode's official primary languages are Swift and Objective-C; these two are also the most commonly used languages for iOS app development, and the vast majority of iOS projects run on them. Beyond that, Xcode also natively supports C and C++, so you can write low-level modules and C-language interfaces, which comes in handy for performance-sensitive code. Metal Shading Language is used for GPU graphics programming, for high-performance rendering. For cross-platform projects, Xcode can also compile the native iOS part of Flutter and the iOS build output of Unity, though the editing experience is limited, and most of the time you still write code in the respective editors. Knowing the list of programming languages Xcode supports is the first lesson in iOS development.

Key Features

Code editor: Smart completion, syntax highlighting, refactoring, code navigation, version comparison; Swift's completion and error reporting are both quite good.

Debugger (LLDB): Breakpoint debugging, variable inspection, memory view, and you can also run LLDB commands directly in the console.

Interface Builder: Visually build UIs by drag and drop; visual editing of storyboard and xib files.

Simulator: A built-in iOS simulator; switch between device models at any time, and run apps quickly to verify UI and interactions without connecting a real device.

Instruments: A suite of performance analysis tools — Time Profiler for CPU, Allocations for memory, Energy Log for energy usage.

Packaging and release: Archive to export an IPA, plus the whole workflow with Organizer for managing certificates, signing, and uploading to the App Store.

Common Barriers for Beginners

Xcode is feature-complete, but there are a few obvious hurdles for beginners: the installer is over a dozen GB, so downloading and updating both take a long time, and machines with smaller hard drives have little space left after installation; before debugging on a real device you have to configure certificates and provisioning profiles and register a developer account, which is a complicated process; and there are many panels — the editor, debug area, simulator, and inspector are all separate — so it's easy to fail to find the feature you're looking for the first time.

Developers on cross-platform projects install Xcode but don't use most of its features, while it still occupies a dozen-plus GB of disk space. These barriers put off quite a few people who are just starting out, which is why many beginner tutorials recommend starting with lighter tools.

Lightweight Alternative

If you just want to learn Swift, write Flutter projects, or don't want to be held back by Xcode's complexity, a lightweight iOS development IDE like KXApp is another path. It bundles a compilation toolchain — no need to install Xcode or the Command Line Tools — and its installer is much smaller. It supports Swift, Objective-C, and Flutter projects, and creates project structures with one click. For real-device debugging you don't have to configure certificates yourself; just connect your iPhone to the computer and click build-and-install to run it.

Based on a VS Code editing interface, smart completion and an AI assistant work out of the box, so the learning curve is much lower. When a project is finished, you can build an IPA with one click for test distribution or App Store submission. For beginners who want to get up to speed with iOS development quickly, getting the first real-device app running to build confidence, and then deciding whether to dig deeper into Xcode, is a very practical approach.

Tutorial: Register Test Devices by QR Code + Install IPA Wirelessly to iPhone

DataStack — Wed, 16 Sep 2026 10:10:35 +0000

Tutorial: Register Test Devices by QR Code + Install IPA Wirelessly to iPhone

In iOS development and testing, two tasks often come up: registering test devices' UDIDs with a developer account and installing a test build on a phone. Traditionally, both require connecting to a Mac with a data cable. With AppUploader (Kaixin Shangjia), both steps can be done by scanning a QR code with a phone and operating wirelessly over the LAN.

Step 1: Register Test Device UDIDs by QR Code

Open the Devices page, click Register Device, and choose the QR code method:

Make sure the phone and computer are on the same Wi-Fi network.
Use the phone camera to scan the QR code on the page.
Tap Continue, then tap Allow to download a temporary provisioning profile.
On the phone, go to Settings → Profile Downloaded and tap Install.
After installation is complete, the UDID is automatically reported and filled into the registration form. Enter a device name, select the platform, and click Register.

If you have a data cable on hand, you can also use USB Connection: connect the iPhone/iPad and tap Trust on the device. The system will automatically detect the connected device, and the UDID will be filled in automatically (on Windows, install the Apple device driver or iTunes first).

Each device type is limited to 100 registrations, and devices can only be added, not deleted (accounts not enrolled in a paid developer program can register at most 3). If you need to register multiple devices at once, use Batch Import. Enter one device's UDID and name per line, with a maximum of 100 devices per import.

Step 2: Install an IPA Wirelessly to the Phone

Open the Files & Submit page, upload or drag in the IPA file you want to install, select it, and click Install to Phone. The QR code method is also available:

Connect the iPhone/iPad and the computer to the same Wi-Fi.
Use the system camera to scan the QR code displayed on the page.
Tap the installation prompt that appears at the top of the phone to confirm installation.

Before installation, the system automatically detects the provisioning profile type (Development / Ad Hoc / Enterprise Distribution / App Store). If installation may fail—for example, if this device's UDID is not within the authorization scope of the provisioning profile embedded in the IPA—it will indicate the specific issue. You can choose to Install Anyway or Cancel Installation.

How the Two Steps Connect

If installation fails with "device is not within the authorized range," it means the device UDID you registered in Step 1 has not yet been included in the provisioning profile corresponding to this IPA. Go back to the Provisioning Profiles page, find the corresponding profile, and click Rebuild so that it includes the newly registered device. Then export a new IPA and install it again. You do not need to go through the certificate process again.

The entire process requires no data cable, Xcode, or TestFlight, making it suitable for frequently installing new builds on test devices.

View and Automatically Decode Captured Data with TraceEagle: JSON Pretty, Hex View, Media Preview

DataStack — Tue, 15 Sep 2026 10:07:59 +0000

Data Viewing and Decoding

Capturing is only the beginning; understanding is what counts. This article shows you how to read a request after opening it: switch the viewing mode independently on both the request and response sides (Structured / Pretty Text / Hex / Auto Detect), automatically decompress compressed data, pretty-print JSON/XML/forms/protobuf, and preview images, videos, and audio directly in the details. Most of the time you don't need to configure anything—just open it and you'll see the most readable form. If you run into garbled data, the end of this article tells you what to do next.

1. When to Use

After capturing traffic, you want to read each request clearly—what the request headers, body, and response actually sent.
The response opens as a bunch of compressed bytes or looks like garbled data, and you want to switch views to see it clearly.
You want to inspect a piece of data as JSON / hex / raw message side by side.
You captured images, videos, audio, PDFs, etc., and want to preview directly instead of saving and opening them separately.

If you're dealing with non-HTTP proprietary / binary protocols that standard views still can't parse, see Custom Protocol Decoding.

2. Prerequisites

You have already captured at least one piece of traffic (if not, see Quick Start or Capture Traffic from a Specific Program).
To see HTTPS plaintext, this connection must be decrypted (TLS in the details shows 'Decrypted'). Undecrypted connections can still be viewed, but only the raw sent/received bytes are visible.
No extra configuration is required. Viewing and decoding work right after you open them.

3. Step-by-Step

1. Open Details

Click any item in the request list to open its details. The upper half is the request and the lower half is the response. The two sides are independent and do not affect each other.

2. Choose a Viewing Mode ('View as')

Each side has a row of viewing modes at the top; switch as needed:

Structured: start line + request header table + smart body. This is the default view; look at it first.
Text · Pretty: automatically indent and format based on content type—JSON, XML, and forms (x-www-form-urlencoded) are laid out readably with one click.
Text · Raw: show the complete message as raw text, without changing a single byte.
Hex: a hex viewer that shows offsets, highlights hex and ASCII side by side with linked highlighting, and can save to a binary file with one click; even very large data can be viewed smoothly without lag.
Auto Detect: hands data to the engine for deep decoding and renders it as a layer-by-layer expandable decode tree—compression nested inside compression, frames nested inside frames, all can be drilled into layer by layer.

If you want the request side in raw view and the response side in structured view, just click each side's button; the two sides can use different views.

Tip: 'View as' only switches the presentation layer. JSON, XML, and forms are not separate buttons; they are formats automatically handled by Text · Pretty. Selecting Text · Pretty will automatically recognize and format them.

3. Let It Auto-Decompress and Auto-Pretty

In most cases you don't need to do anything:

Responses compressed with gzip / brotli(br) / deflate / zstd are automatically decompressed before display; multiple stacked encodings (such as gzip, br) are also decoded layer by layer from outer to inner.
If the body is JSON / XML / forms / protobuf / gRPC, it is automatically recognized and pretty-printed. protobuf/gRPC can be decoded into field numbers, types, and values without a .proto file.

4. Use Hex to View Raw Bytes

When you want to verify raw bytes, or the data itself is binary, switch to Hex. Click a byte, and hex and the ASCII on the right will highlight in a linked way; when you need to keep a record, click Save to export it as a binary file.

5. Preview Media

When the body is an image, video, or audio, the details view previews / plays it inline directly and marks the type and size, so you don't need to save and open it separately.

4. Verification: Confirm You're Reading Plaintext

A correctly read entry should look like this:

In the Structured view, the request line, request headers, and body are all present, with fields clearly displayed.
A compressed response opens as readable text (such as well-indented JSON), not a bunch of compressed bytes.
If it is an image / video or other media, it can be seen / played directly in the details.
Switch to Hex: offset, hex, and ASCII columns are aligned, and clicking a byte highlights linked positions.

5. Troubleshooting and Tips

Symptom	Likely Cause	What to Do
Opens as a bunch of garbled data / unreadable bytes	Not a standard HTTP body; may be a proprietary / binary protocol, or an undecrypted raw stream	First switch to Auto Detect and let the engine try to decode it; if it still can't be parsed, use custom decoding—see Custom Protocol Decoding
The response looks compressed and cannot be opened	Rare multi-layer or non-standard encoding	Switch to Auto Detect and expand the decode tree layer by layer; or switch to Hex to verify the raw bytes
JSON / XML is crammed into one line	You are currently in Text · Raw or Structured, where no pretty-printing is applied	Switch to Text · Pretty for automatic indentation and formatting
You can only see raw sent/received bytes, with no request headers	This connection is undecrypted (non-HTTP or TLS not decrypted)	Check whether TLS in the details shows 'Decrypted'; for decryption-related topics, see Application-Layer Capture
You want to verify the original text with not a single byte changed	Pretty / Structured views reformat the content	Use Text · Raw or Hex; neither modifies the original content
Large responses feel heavy to open	The data volume is very large	The hex viewer can smoothly browse even very large data; if you need to keep a record, save it as a binary file with one click

Tip: The views on the request and response sides are independent. When troubleshooting by comparison, you can keep Structured on one side and open Hex on the other and compare them on the same screen.

Next Steps

If proprietary / in-house protocols can't be parsed by standard views and you want to teach it how to read them: see Custom Protocol Decoding.
To compare where two requests differ, line by line: see Request Diff.
To modify this data and resend it, or intercept it midway and change it manually: see Request Construction and Replay, Rule Rewriting and Breakpoint Interception.
To generate code or export documentation from this API: see Generate Code and Export API Docs.

App Store Multi-Language Metadata and Screenshot Batch Management (with AI Translation) Tutorial

DataStack — Mon, 14 Sep 2026 10:37:14 +0000

App Store Multi-Language Copy and Screenshot Batch Management (with AI Translation) Tutorial

App Store listing information must be maintained per language — name, description, keywords, screenshots, and so on. Once the number of languages grows, filling each one in by hand turns into repetitive busywork. In its "Apps" feature, AppUploader provides three capabilities built specifically to solve this problem: batch screenshot upload, AI translation, and store information export/import folders.

Batch Upload Screenshots, Auto-Categorized by Device Size

Open an app's version detail page and go to the "Screenshot Management" tab:

Check the languages you want to upload screenshots for (multiple selection allowed).
Drag in or select screenshot images — there is no need to pre-sort them into folders by device size. The system automatically identifies and categorizes each image by its pixel dimensions into the corresponding device size, then uploads them in batch to all selected languages.
Images whose dimensions don't match any App Store device are skipped automatically and won't interrupt the overall upload process.
After uploading screenshots for one language, use "Copy screenshots to other languages" to copy that entire set to other languages in one go. You can optionally clear the existing screenshots of the same type under the target languages first, to avoid duplicating old and new.

Preview videos support similar per-device/per-language management. After upload, Apple transcodes them asynchronously and the status later becomes "Completed". You can set the poster frame time point; if left blank, Apple automatically picks the middle frame.

Use AI Translation to Generate Multi-Language Copy at Once

Under the "Metadata Editing" tab, first select a language you have already filled in as the source language, then click "Translate to other languages":

Description, keywords, what's new, and promotional text are translated automatically and written into the other languages you selected.
Name and subtitle do not participate in translation — they are app-level shared fields, so all languages share the same value; changes take effect only with the next version review.
Promotional text is special: it can take effect at any time without review, making it suitable for quick adjustments to marketing copy.

Each field is annotated with whether it is required by App Store, so you won't miss required content after translation and fail the review submission.

Export to a Folder for Offline Editing, Then Batch Import Back

If you prefer editing copy in bulk locally with a text editor or version control tool (such as Git), you can export a version's store information into a folder structure:

On the version detail page, click "Export to folder" and enter the export path (leave it blank to use the default directory). You can optionally export screenshots and preview videos as well (large and time-consuming — check as needed).
Exported directory structure: the root config.yaml stores categories/copyright/age rating, review_information.yaml stores review information separately, metadata/<language>/ holds one .txt file per field, and screenshots/videos go in the screenshots/ and previews/ directories respectively.
After editing, click "Import from folder". Import is a partial update: only the parts actually present in the folder are applied. For example, if the folder contains only review_information.yaml, only the review information is updated; empty files are skipped and won't wipe out existing content on Apple; when screenshots/ or previews/ directories exist, the screenshots or videos for the corresponding language/size are replaced entirely.
After the import completes, a summary is displayed: the number of updated, skipped, and failed items, plus detailed results for each item, making it easy to verify.

This export/import mechanism is particularly well suited to multi-person collaboration on reviewing copy, or to putting store information under version control history.

Swift Development Tools: From Xcode to Lightweight IDEs

DataStack — Thu, 10 Sep 2026 10:08:22 +0000

Swift has come a long way, and the choice of development tools is no longer limited to Xcode. Xcode is still the workhorse — SwiftUI previews, Instruments profiling, and Archive packaging all depend on it — but the open-sourcing of the Swift compiler and toolchain has made third-party tools like VS Code increasingly capable.

Scenarios Where Xcode Remains Irreplaceable

Xcode holds a decisive advantage in several scenarios. Since Xcode 15, SwiftUI previews have become dramatically more responsive, updating the canvas instantly as you edit code. Instruments' profiling toolset offers more comprehensive support for Swift projects than third-party tools do. Features like Interface Builder and Storyboard visual editing, along with the Core Data model editor, are also exclusive to Xcode. If your project relies heavily on SwiftUI previews and Instruments, Xcode is the only choice.

SwiftLint and Formatting Tools

SwiftLint is the most widely used code style tool in the community. It defines rules through a .swiftlint.yml configuration file, letting teams enforce a consistent style. Add a Run Script phase to Build Phases to check code automatically — non-compliant code raises a warning or error at compile time, sparing code reviews from debates over formatting.

SwiftFormat focuses on automatically formatting code and can be integrated into a Git pre-commit hook to format code before each commit. The two tools work together — SwiftLint checks the rules, SwiftFormat fixes the formatting.

SourceKit-LSP provides Swift language services for editors — code completion, go-to-definition, and error diagnostics. VS Code, KXApp, and many third-party editors rely on SourceKit-LSP for these capabilities.

VS Code + Swift Extension

After installing the Swift extension, VS Code can handle basic Swift development. Syntax highlighting, code completion, go-to-definition, and error diagnostics are all supported. It suits writing Swift Package libraries or doing code reviews, and it starts up far faster than Xcode.

The limitation is compilation and debugging — VS Code has no built-in iOS compiler and needs an external toolchain to work.

KXApp's Support for Swift Projects

KXApp is built on VS Code, so its editor layer is identical to VS Code's. The key difference is a built-in iOS compilation toolchain, including the swiftc compiler. After creating a Swift project in KXApp, you can connect an iPhone and build and run the app directly, with no need for an Xcode environment.

KXApp supports Swift Package Manager projects, so when writing a Swift library or framework you can compile and verify it inside the tool without opening Xcode. For projects using SwiftUI, KXApp's VS Code foundation provides a solid coding experience. KXApp also supports iOS development for OC and Flutter projects, covering multiple project types with a single tool. The Swift compilation pipeline matches native Xcode — the swiftc front end parses the code and generates SIL, the LLVM back end generates machine code, and the linker merges everything into an executable, which is then signed and packaged.

Other Tools

SPM's Package.swift lets you manage dependencies in Swift code, and unlike CocoaPods it requires no extra Ruby environment. DocC is Apple's official documentation generation tool, producing documentation pages from Swift comments. Periphery detects unused code in a project, helping you clean up redundant class and function declarations.

Recommended Combinations

Use Xcode for SwiftUI development and profiling. Use KXApp or VS Code for everyday coding and code review. Use SwiftLint for style checks. Use SwiftFormat for automatic formatting. Combining multiple tools by scenario improves overall development efficiency more than an Xcode-only approach.

TraceEagle Targeted Program Capture Tutorial: One Command to Capture a Single Program's Traffic

DataStack — Wed, 09 Sep 2026 09:45:45 +0000

Targeted Program Packet Capture

This tutorial shows you how to use targeted program packet capture to capture the traffic of one particular program: give it a startup command, and the tool will launch the program for you, capturing only its traffic. You'll see plaintext as soon as it starts. No proxy configuration or certificate installation is required, and there's no cleanup afterward—it's the fastest and cleanest way to capture traffic.

When to Use This Approach

Use this when any of the following applies:

You want to see what a program that can be launched from the command line (browser, script, CLI tool) is sending.
You don't want to modify the system-wide proxy, install a certificate, or affect other software on the machine.
You just want to run a quick script or verify an API, and you want to start capturing right away with one command.

If the program is already running, does certificate pinning, uses proprietary encryption, or doesn't honor proxy settings, targeted program capture may fail to capture or decrypt it. Use Application-Layer Packet Capture instead.

Prerequisites

TraceEagle is installed and running (grant system permissions on first launch).
You know the startup command of the target program (for example, python3 app.py, a curl command, or the executable path of a browser).
No certificate installation or system proxy changes are required.

Start Capturing: Three Steps to Get Your First Capture

Create a new session and choose Local Targeted Program Packet Capture.
In the Startup Command field, enter the command you want to run. If you prefer not to type it manually, click the built-in one-click examples—they will fill in the command for you and you can still edit it:
- Browser example: launches a separate and clean browser window (without affecting the browser you use daily), and has already made HTTP/3 (QUIC) fall back to ordinary connections so the traffic can be easily captured and decrypted.
- Python example: sends a request with one command, giving you the most reliable way to see plaintext.
- CLI example: captures HTTPS requests issued from the command line.
Click Start. The tool launches the program and captures only its traffic. Child processes spawned by the program are also captured, so nothing is missed.

Let the program run and generate network requests (open a website in the browser or have the script send a request), and the traffic will appear in the request list in real time.

Verify: Confirm That Traffic Is Captured and Decrypted

Click any request in the list to inspect its details:

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

For common programs—browsers, Electron desktop apps, Node, Python, desktop Java, and command-line tools that use general-purpose cryptographic libraries—plaintext is available immediately on startup, with no extra steps.

Can't Capture or Can't Decrypt? Troubleshoot Line by Line

Phenomenon	Most Likely Reason	What to Do
Packets are captured, but only ciphertext	The program uses a special cryptographic library (most typically the macOS built-in `curl`, and some pure-Go programs)	To see plaintext on the command line, the Python example is the most reliable; switch to an OpenSSL build of `curl`; if that doesn't work, use Application-Layer Packet Capture
No traffic at all	The program completely ignores proxy settings	Use Application-Layer Packet Capture (extract plaintext from inside the program) or NIC Packet Capture (the NIC layer captures everything)
Captured, but it uses HTTP/3 and is incomplete	The target uses HTTP/3 (QUIC)	Enable session-level Block HTTP/3 to force it back to ordinary connections, so it can be easily captured and decrypted
The target program is already running	This method requires the tool to start the program	Close it first and restart it with the startup command; or use Application-Layer Packet Capture to attach to the running process

How to Choose Among the Four Local Capture Methods

Your Situation	Which Method to Use
A normal command-line-startable program (browser/script/CLI)	Targeted Program Packet Capture (this article, the easiest)
You want to see all traffic on the machine, non-HTTP traffic, or all network behavior of a program	NIC Packet Capture
The program is already running / does certificate pinning / doesn't honor proxy / uses proprietary encryption / system cryptographic libraries	Application-Layer Packet Capture
System built-in apps / stubborn applications on macOS	System-Level Packet Capture

Next Steps

To learn how to read the captured data, switch views, and decode it: see Data Viewing and Decoding.
For private/proprietary protocols, or to teach the tool how to read them: see Custom Protocol Decoding.
To modify and resend requests, or intercept and edit them mid-flight: see Request Construction and Replay and Rule Rewriting & Breakpoint Interception.

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

Test Device Registration and Management: Two Ways to Obtain UDID via USB Connection or QR Code Scan

DataStack — Tue, 08 Sep 2026 10:18:39 +0000

Test devices are registered for development and Ad Hoc distribution. Use Appuploader to view UDIDs and add test devices. Each device type is limited to 100 registered devices. Devices can only be added, not deleted, and there is one reset opportunity after each annual renewal. Accounts not enrolled in the Apple Developer Program can register up to 3 devices.

Register a Device

The registration dialog provides two methods:

Method 1: USB Connection

Connect your iPhone or iPad with a data cable and tap Trust on the device. The system automatically detects the list of connected devices (on Windows, you need to install the Apple Device Driver or iTunes first). Select the device from the detected results, and the UDID and other information will be filled in automatically.

Method 2: QR Code Scanning (Over-the-Air Delivery)

When no data cable is available, you can scan the QR code with your phone to obtain the UDID:

Put the phone and the current computer on the same Wi-Fi network.
Open the camera and scan the QR code.
Tap Continue, then tap Allow to download a temporary configuration profile.
On the phone, go to Settings → Downloaded Profile and tap Install.
The UDID will be automatically reported and filled into the registration form.

Then enter a name, select the platform, and tap Register to complete the registration.

Bulk Import

Tap Bulk Import and enter one device per line: the UDID may be followed by a name separated by Tab, comma, or space. You can also Import from File. Up to 100 devices can be imported per batch. Before importing, you need to select a platform that applies uniformly to all devices. After submission, the import result (success/failure) for each device will be displayed.

Manage Devices

You can Enable / Disable a device, or Rename it.
Devices cannot be deleted, only disabled.
Reset Devices: This can only be performed once per membership year. After selecting the devices to reset and submitting, the registration slots occupied by these devices will be released and can be used for new devices. This action is irreversible, so please choose carefully.

Appuploader's device list can be searched by name / ID / UDID.

iOS Development Environment Setup Guide: From Xcode to Lightweight Toolchain Options

DataStack — Tue, 08 Sep 2026 10:15:03 +0000

When setting up an iOS development environment, the first thought is to install Xcode. Downloading the multi-gigabyte installer, waiting for it to unzip, installing the Simulator, and configuring your account—the whole process takes at least an hour. But Xcode isn't the only option for an iOS development environment; depending on your project type and development habits, you can flexibly combine different setup configurations.

Xcode Standard Environment

Xcode is the standard environment for iOS development. After downloading from the Mac App Store, open Preferences → Accounts and add your Apple ID; Xcode then automatically manages certificates and provisioning profiles. When you create a new project, you choose a template, configure the Bundle ID and Team, and you can run it on the Simulator or connect a physical device via USB for debugging.

For debugging on a physical device, you need to trust the development certificate on your phone under Settings → General → VPN & Device Management. If Xcode reports certificate issues, click Download Manual Profiles on the Accounts page to refresh.

The main issues with the standard environment are its size and startup speed. The Xcode installer is about 7–8 GB and takes up more than 15 GB after extraction; combined with cache files from various iOS SDK versions and the Simulator, a 256 GB Mac quickly runs out of storage. As your project's codebase grows, every launch requires waiting for indexing to load, during which code completion and navigation are affected.

VS Code + Plugin Environment

If your day-to-day development doesn't involve Storyboard editing or Instruments performance analysis, VS Code with the Swift plugin is a lightweight option. After installing the Swift plugin and SourceKit-LSP, you get syntax highlighting, code completion, and definition jumps.

But this environment has obvious limitations. Compiling for iOS and debugging on a real device still require Xcode's toolchain. The common approach is to write code in VS Code and, when you need to compile, switch to the terminal to run xcodebuild, or use a remote Mac for compilation. While the code editing experience improves, the build-and-verify workflow becomes fragmented.

KXApp Built-in Environment

KXApp takes this approach a step further by embedding the compilation toolchain directly into the IDE, allowing you to compile and sign without installing Xcode on the system. For everyday coding, debugging, and packaging, this reduces reliance on environment configuration.

The process of setting up a development environment in KXApp is: download, unzip, launch → register and log in with your email → connect your phone to the computer via USB → enable Developer Mode → start coding. There's no need to configure Xcode's Build Settings, manage the Simulator, or manually set up certificate chains.

If you typically use Flutter for cross-platform development, KXApp has built-in support for compiling Dart to iOS, eliminating the need to configure the Xcode toolchain within Flutter. When creating a project, simply select the Flutter template, connect an iPhone, and build to run on a physical device.

Mixing and Matching Environments

The standard environment, lightweight environments, and KXApp are not mutually exclusive; they can be used together. Use Xcode for complex project configuration and performance analysis, VS Code or KXApp for daily coding and quick verification, KXApp for validating iOS builds in Flutter projects, and KXApp for iOS development on Windows.

Recommendations for setting up your environment: keep at least one Mac as a baseline for handling certificate configuration and App Store submissions. For daily development, choose tools based on project type and scenario; you don't need a full Xcode installation on every machine. The space and startup time you save are also part of efficiency.