DEV Community: ObjC_Coder

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

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

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

Two types of credentials for CI

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

The official route on Mac: altool and fastlane

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

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

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

Generating the .p8: the Appuploader approach

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

Putting the upload step on the command line

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

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

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

Wiring it into GitHub Actions

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

Choosing a route by environment

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

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

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

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

What Can VS Code + Swift Plugins Do?

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

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

What VS Code Can't Do

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

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

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

How KXApp Differs

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

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

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

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

When to Use Which

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

TraceEagle NIC Packet Capture: Without Proxy or Certificate

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

NIC Packet Capture

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

1. When to Use This Approach

This suits you if any of the following applies:

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

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

2. Prerequisites

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

3. Start Capturing: Capture Your First Packet

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

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

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

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

4. View Plaintext: Turn Ciphertext into Plaintext

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

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

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

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

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

5. Verification: Confirm Capture and Decryption

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

6. Nothing Captured / Can't Decrypt? Troubleshoot

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

7. Choosing a Local Capture Method

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

Next Steps

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

Quick Start with TraceEagle Network Tracker

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

Quick Start

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

1. Install and Launch

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

2. Fastest Success: Capture Your Own Browser

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

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

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

3. Choose a Capture Approach That Fits Your Goal

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

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

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

4. Understand the Interface

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

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

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

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

For more detailed troubleshooting, run Network Diagnostics first.

6. What's Next

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

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

App Store App Management Features

ObjC_Coder — Fri, 04 Sep 2026 10:51:45 +0000

App

Requires a paid Apple Developer Program membership.

Manage your apps on App Store Connect: maintain app information, localized text, version details, screenshots and preview videos. Create and manage in-app purchases (name, price, review screenshot). You can import/export metadata, add review information, and track submission and review status.

The app list supports searching by name / Bundle ID / SKU. Click an app to enter the detail page, where you can open it in App Store Connect or App Store to jump to Apple's official pages.

App Information

The App Information tab maintains app-level, version-independent information:

Primary Language: The default display language on the App Store.
Categories: Primary and secondary categories, plus optional subcategories (up to two levels).
Age Rating: Check the frequency of each content descriptor (e.g., violence, profanity) as None / Infrequent, Mild / Frequent, Strong. The age rating is generated after saving.

Managing categories and age ratings requires an App Store Connect API Key account; other sign-in methods are not supported.

Version Management

Each app can have multiple versions, divided into two tabs: Versions and Builds.

Create and Submit a Version

Click New Version, enter the version number. Existing versions can be edited to modify copyright information.
On Release Settings choose a release method:
- Manual release after approval: You must click release manually after approval.
- Automatic release after approval: The app goes live immediately after approval.
- Scheduled release: Specify a release date; the app becomes available automatically once the date arrives after approval.
- Optionally enable Phased Release: After the version is released, updates are gradually pushed to users over 7 days instead of all at once.
In Review Information, enter contact name, email, phone, and notes. If the app requires login for testing, check Need demo account and provide a demo account and password for Apple reviewers.
After completing metadata and screenshots, click Select a build to submit. You must first upload and process a build via Xcode or Transporter before it can be selected.
Click Submit for Review. The status will show “Waiting for Review”. If you need to withdraw, you can Cancel this submission.

Metadata Editing (Multilingual)

App Store display text must be maintained per language: name, subtitle, description, keywords, what's new, promotional text, support URL, marketing URL, privacy policy URL, etc.

Add Language: Choose from the languages supported by App Store (multi-select) to create blank localization.
AI Translation: Select a language with existing content as the source, click Translate to Other Languages, and automatically translate description, keywords, what's new, and promotional text to target languages. (Name and subtitle are not translated because they are app-level shared fields.)
Name and subtitle are app-level shared fields; changes take effect only after they pass review with the next version. Promotional text can be effective immediately without review. “What's New” is required only on version updates.
Each field is labeled whether it is required by App Store.

Screenshots & Preview Videos

Screenshot Management: Check the languages to upload to, drag in or select screenshot images. The system automatically identifies pixel dimensions and categorizes each image to the corresponding device size, batch-uploading to all checked languages. Images whose dimensions do not match any App Store device are skipped. You can also Copy screenshots to other languages, copying all screenshots of one language to others (optionally clearing the same screenshots in the destination language first to avoid duplicates).
Preview Video Management: Upload app preview videos for a specific device and language. You can set a cover frame timestamp (if left blank, Apple automatically chooses the middle frame). After upload, Apple transcodes asynchronously; the status later changes to Completed.

Export / Import Store Information via Folder

Store information for a given version can be exported to a local folder for offline editing, then imported back to App Store. This is convenient for batch modifications or version control.

Export to Folder

Click Export to Folder on the version detail page.
Enter the export path (leave blank to use the default directory). Optionally include screenshots and preview videos in the export (this downloads uploaded media from Apple, may be large and time-consuming).
Directory structure after export: the root config.yaml contains category/copyright/age rating; review_information.yaml separately stores review information (for Apple reviewers); under metadata/<language>/, each field is a .txt file; screenshots and videos are under screenshots/ and previews/ directories respectively.

Import from Folder

Click Import from Folder, enter the import path (leave blank to import from the default directory).
Import is a partial update: only the content actually present in the folder is applied. For example, if the folder contains only review_information.yaml, only the review information is updated; if only metadata/zh-Hans/, only the Chinese (Simplified) text is updated. Empty files are skipped and will not clear existing content on Apple. If a screenshots/ or previews/ directory exists, the corresponding language/device screenshots or videos are replaced entirely.
After import, a summary is shown: counts of updated, skipped, and failed items, along with detailed results for each item.

In-App Purchases (IAP)

In-app purchases belong to the current app. Each purchase must have a localized display name, price, and review screenshot before Apple will approve it. Auto-renewable subscriptions should be managed on the App Store Connect official pages. This tool manages three types: consumable, non-consumable, and non-renewing subscriptions.

Type	Description
Consumable	Consumed upon use and can be purchased again, e.g., gold coins, stamina, hint counts
Non-Consumable	Owned forever after purchase, e.g., removing ads, paid level packs
Non-Renewing Subscription	A fixed-duration entitlement that does not auto-renew, e.g., season pass

Creation steps:

Click New In-App Purchase, enter the product ID (reverse-DNS format, cannot be modified after creation, nor can it be reused after deletion), reference name (internal only, used in App Store Connect and sales reports; not shown to users), and type.
In the Localization tab, enter display name and description for each language (what users see on the purchase screen). You must add the app's primary language at minimum.
In the Price tab, select a base region, then choose a price point. This price determines the price in the base region, and Apple converts to other regional prices.
In the Review Screenshot tab, upload a screenshot showing where the in-app purchase appears in your app (for review only, not displayed on App Store; one per purchase).
In the Settings tab, you can enable Family Sharing, allowing purchases to be shared with the buyer's family sharing group.
Once localization, price, and review screenshot are complete, click Submit for Review. Submissions cannot be withdrawn after submission, so make sure everything is correct before submitting.

Using the in-app purchase management feature requires signing in with an App Store Connect API Key or Developer Portal account; other sign-in methods are not supported.

Several Ways to Develop iOS Applications on Windows

ObjC_Coder — Thu, 03 Sep 2026 09:44:15 +0000

Previously, a colleague of mine encountered a situation where the company-issued computer was Windows, but the project required participation in iOS development. A troublesome aspect of iOS development is the environment lock-in: macOS + Xcode is a hard requirement, and Windows cannot directly compile and sign iOS apps. Later, after trying several different approaches, we found that although each has limitations, each also has its own applicable scenarios.

Install macOS in a Virtual Machine

The most straightforward approach is to run macOS on Windows through a virtual machine. Install a macOS image in VMware Workstation or VirtualBox, then install Xcode and the iOS SDK inside the virtual machine. This effectively gives you a complete Mac development environment running on Windows. The advantage is that you can run the full Xcode, including Instruments and the debugger. The disadvantages include high hardware requirements—at least 16 GB of RAM, CPU with virtualization support—and significant disk space taken up. Running macOS on non-Apple hardware also has licensing restrictions. In terms of compilation speed, Xcode in a virtual machine is considerably slower than on a real Mac, and for large projects, every clean build takes a long time.

Compiling on a Remote Mac

Another approach is to write code on a local Windows machine and remotely connect to a Mac for compilation. On Windows, you use VS Code or any editor for development, then SSH into the remote Mac and use the xcodebuild command to package. This approach gives you freedom in your coding environment—you can use your preferred editor, plugins, and fonts. The remote Mac can be a shared Mac mini or a Mac server.

The main drawback is that compilation and debugging are split between two separate environments. You write code on Windows, push it to the remote for compilation, and when errors occur, you switch back to local to fix them—each iteration cycle is much longer than local development. Certificates and provisioning profiles must also be managed on the remote Mac, and compilation can easily time out when the network is unstable. If you only occasionally participate in iOS development, it’s acceptable; but when it becomes frequent, efficiency suffers.

Using KXApp on Windows

KXApp takes a different approach than the two previous options. It is built on VS Code, and the editor itself runs natively on Windows. The difference is that it includes an iOS compilation toolchain, allowing you to compile and sign apps without installing Xcode on the system. From creating Swift, Objective-C, or Flutter projects to building IPA files, everything can be done on Windows.

For real-device debugging, iOS devices connect to the Windows PC via USB, and KXApp can directly recognize the device. Click the one-click build and install button, and the tool automatically handles signing and deployment—no need to operate a remote Mac or configure virtual machine network bridging. If your project uses Flutter, KXApp directly supports Dart compilation to iOS, saving the step of configuring the Xcode toolchain in the Flutter environment.

There is still no perfect solution for iOS development on Windows; each approach has its own trade-offs and focuses. The virtual machine approach is feature-complete but resource-intensive and consumes disk space. Remote compilation is flexible but switching between multiple environments hampers efficiency. KXApp covers the main phases of iOS development—coding, real-device debugging, and packaging—making it suitable for fast development, real-device testing, and daily verification in a Windows environment, reducing dependence on Mac hardware.

What other handy tools are there for iOS development? An IDE that doesn't require Xcode

ObjC_Coder — Wed, 02 Sep 2026 09:52:21 +0000

I've noticed that iOS devs around me are often running low on storage space. Xcode takes up over a dozen gigabytes, the Simulator eats tens of gigabytes across a few versions, and on top of that there's DerivedData and various caches—a 256GB Mac will show red within half a year. Before every major version update, you have to delete a bunch of things to make room. Once I was complaining in a group about not having enough disk space, and someone replied, "You actually don't need to install Xcode." I didn't believe it at first.

Later, in another developer group, I saw someone discuss a tool called KXApp that lets you do iOS development without installing Xcode. My first reaction was: isn't it common knowledge that iOS development is tied to Xcode? But looking at the description, it has a built-in compilation toolchain, so you can compile and sign apps without Xcode installed on the system. It's built on VS Code, with the same shortcuts, plugin ecosystem, and interface layout as VS Code, so your editor habits basically carry over. Everything from creating a project to running on a real device happens in one interface—no switching between different tools.

When might you reach for it

After some thought, I came up with a few scenarios where it genuinely helps.

First, scenarios where the team includes Windows developers. A hard requirement for iOS development is having a Mac, but occasionally front-end or server-side engineers need to collaborate on iOS modules, or new members temporarily use Windows because Mac resources are scarce. In a pure Windows environment, the traditional approach to writing iOS code is either setting up a remote Mac as a build machine or running macOS in a virtual machine. The former lengthens the process and hurts efficiency; the latter demands high hardware specs and degrades the experience.

Second, scenarios for quickly validating prototypes. Sometimes you just want to run a small demo to see how it looks, but changing one line of code means launching Xcode, waiting for indexing to complete, then clicking Run and waiting for the build—in a large project, that's several minutes each time. Simple UI tweaks or small logic changes could be done in a lighter editor, making the iteration pace much smoother.

Third, Flutter projects. Flutter developers who write Dart on a Mac traditionally rely on Xcode's toolchain for iOS compilation validation. But if your main job is Flutter business logic and iOS is only for packaging and real-device verification, installing a full Xcode just for that isn't cost-effective.

There's also a very practical issue—disk space. Xcode updates add over a dozen gigabytes every major release, the iOS SDK keeps growing, and the storage on older Macs gets tighter. If you can remove Xcode from the daily workflow, you free up a lot of room.

Who is it suitable for

In these scenarios, KXApp positions itself as a supplementary tool. Creating a project doesn't require ticking off tons of template options in Xcode; connect an iPhone and build with one click, and it includes built-in support for Flutter iOS compilation. Development, debugging, and packaging all happen in the same interface.

Can it completely replace Xcode? For complex project configuration, visual Storyboard editing, and Instruments performance analysis, you still need to go back to Xcode. But if you mainly write business code, or develop Flutter with tight Mac resources, KXApp is worth installing as an alternative. Having more options never hurts.

iPhone Real-Device Debugging Methods: Solutions from a Push Notification Permission Issue

ObjC_Coder — Wed, 02 Sep 2026 09:26:26 +0000

The QA colleague reported that the push notification authorization dialog did not appear after the app was installed for the first time. I initially thought it was an API timing issue, but later discovered that the problem only occurs on real devices. In the simulator, everything works fine. During that troubleshooting, I re-compiled the common methods for debugging on a real iPhone, because many iOS features can only be verified on a device, such as push notifications, Bluetooth, camera, Face ID, background location, and Apple Sign-In. These behaviors involve system permissions and real hardware, which the simulator cannot fully cover.

Xcode Direct Connection Debugging: The Most Common Approach

The first real-device debugging method most iOS developers encounter is Xcode. Connect the iPhone, select the device, click Run, and the IDE automatically builds and installs the app. During debugging, you can directly view console logs, crash information, memory usage, and network requests. The advantage of this method is completeness. Project management, compilation, and debugging are all done in the same environment. However, as projects become more complex, some teams begin to split the development workflow.

Using TestFlight for Real-Environment Verification

Some issues are not suitable for debugging via a development build, such as differences in review environment, Release configuration behavior, or real user permission flows. In such cases, many teams distribute test versions via TestFlight. The typical process is: Build IPA → Upload to App Store Connect → Install via TestFlight. This approach is closer to the production environment, but the downside is obvious: every modification requires a rebuild and upload. If you're only debugging UI or APIs, the entire feedback loop can be quite long.

Wireless Debugging: Reducing Device Connection Efforts

Later, Apple added wireless debugging. After the first connection, you can continue debugging over the local network. For those who frequently test page layouts or animations, this reduces many cable plug/unplug actions. However, it still relies on a full IDE, and the build and installation process remains unchanged.

Using Log Tools to Aid Real-Device Troubleshooting

Some problems do not directly cause crashes, such as an empty API field, abnormal background state transitions, or inconsistent permission states. In these cases, many developers also use the following tools:

Charles

Used for packet capture, viewing requests, and analyzing API responses.

Console.app

Used for viewing device system logs and analyzing runtime status.

These tools do not run the app directly, but they help diagnose real-device behavior.

Debugging Methods in Flutter and Hybrid Projects

After cross-platform projects appeared, the real-device debugging workflow has also changed. For example, a Flutter project uses "flutter run" to directly install and run on a device, and hot reload shortens page verification time. However, when a project includes Flutter, Swift, and Objective-C together, the development process becomes more complex, and some changes still require going back through the iOS build process.

Tools That Begin to Re-integrate the Real-Device Debugging Workflow

In recent years, some new iOS development tools have emerged that no longer completely separate "editing," "compiling," and "running on a real device." Recently, I came across Kuaixie (kxapp). Its special feature is that real-device debugging capabilities are directly embedded in the IDE. It currently supports Swift projects, Objective-C projects, and Flutter projects. After modifying code, you can directly build, install to iPhone, and run on the real device. The editor is based on the VSCode architecture and also includes its own iOS compilation tool suite. For those who frequently modify UI, debug interactions, or verify permission behaviors, this approach reduces tool switching in the development process.

The Issue of Real-Device Debugging Is Feedback Speed

Different tools are addressing this issue. Some choose Xcode direct connection debugging, TestFlight for verifying the real environment, or Flutter hot reload, while others are beginning to try integrated workflows.

iOS App Submission Pitfalls: Common Issues and Solutions for Certificates, Packaging, and Submission Review

ObjC_Coder — Tue, 01 Sep 2026 09:22:31 +0000

I used to think that as long as the code was fine, submitting an iOS app was easy. But after uploading one myself, I realized that most of the process is spent dealing with certificates, provisioning profiles, and various ITMS errors. Knowing these pitfalls in advance can save a lot of time. This iOS submission guide lists several typical issues we encountered, explaining the cause and solution for each.

Certificate-Related Issues

Wrong certificate type. Development certificates are only for debugging on a real device; you must use a Distribution certificate for submission. If you select the wrong one during packaging, the upload will fail with an invalid signature. Check which type is currently used in Keychain. If you don't have a Mac, Appuploader lets you directly regenerate a Distribution certificate on Windows.

Forgotten P12 password. The password you set for the P12 file when generating the certificate cannot be retrieved if forgotten; you have to regenerate it. It's recommended to record this password separately and not mix it with your Apple ID password.

Certificate not available on another computer. If the certificate is generated on one Mac, it won't be available on another. You need to export the .p12 and provisioning profile, then import them on the new computer. Alternatively, tools like Appuploader can sync certificates to the cloud, allowing other computers to download them directly after login, avoiding manual copying and transfer.

Provisioning Profile Issues

Provisioning profile type mismatch. You must use an App Store type profile for submission; selecting Ad Hoc or Development will cause upload errors. Check the type carefully when creating it.

Bundle ID mismatch. If the Bundle ID used for packaging doesn't match the provisioning profile, signature verification fails. Make sure both are consistent when creating a new project.

Test device UDID not in the provisioning profile. For Ad Hoc distribution, if the tester's UDID is not included in the profile, the app cannot be installed on that device. The App Store type for submission does not have device limits.

Upload and Build Version Issues

Build version not showing. After a successful upload, the build may not appear in App Store Connect. Possible reasons: the build version number (CFBundleVersion) duplicates a previous submission—change it in Info.plist and rebuild; the upload is still processing—wait 5-15 minutes and refresh; using a free Apple ID—it has no distribution rights and can only create development certificates. Uploading to a different App Store Connect account can also cause it not to show. If you resubmit with a different developer account, confirm the app record exists under the new account.

ITMS errors. ITMS-90189 means duplicate build version, fix it and re-upload. ITMS-90101 is a certificate issue—check if the Distribution certificate is expired or whether the provisioning profile type is correct. ITMS-90704 indicates incorrect icon size—adjust to the required size and rebuild. ITMS-90076 means the image has an Alpha channel (transparent background)—use a tool to remove the channel and save as an opaque format. UnknownError usually occurs when the app record hasn't been created in App Store Connect—create the app first, then upload. ITMS-90161 is a configuration issue during packaging—check the signing settings.

Submission Review Notes

Screenshot sizes not meeting App Store specifications, missing privacy policy links, user permission descriptions not included in the review notes, and not providing a test account for login-required apps are common rejection reasons. Going through the checkpoints in this iOS submission guide before submitting can reduce the chance of rejection. If rejected, modify the corresponding issues based on Apple's feedback and resubmit; you don't need to go through the entire submission process again.

Complete Step-by-Step Guide to Publishing an iOS App to the App Store with Appuploader: From Certificates to Submission

ObjC_Coder — Fri, 28 Aug 2026 10:29:40 +0000

Complete Step-by-Step Guide to Publishing an iOS App to the App Store with Appuploader: From Certificates to Submission

Recently, I helped a team release a version. Their development machines were all Windows, and the project used Flutter. The package was built as an .ipa, but how to get it to the App Store? We tried Xcode Organizer — it can't be installed. Transporter — only has a macOS version. fastlane — it depends on xcrun at the core, and the CI also needs a Mac node. After researching, we found that Appuploader can complete the entire process on Windows: certificate creation, provisioning profile generation, IPA upload, and batch screenshot management. Here's a record of our operations in order that day.

Certificates and Provisioning Profiles: Creating from Scratch on Windows

Before publishing, you need to configure certificates. The normal process involves generating a CSR using Keychain on a Mac, submitting it to developer.apple.com, downloading the .cer, and importing it back into Keychain to convert it to a .p12 — the entire process depends on macOS, and none of it can be done on Windows. Appuploader compresses these steps into a single interface: go to certificate management, click add, select iOS Distribution as the type, enter a name and P12 password, and click OK to generate. It's done in minutes, without touching Keychain or understanding what CSR is. The generated .p12 can be exported and shared with other team members, so everyone can use the same certificate across different computers without each person having to apply separately.

Provisioning profiles are also handled in the same tool. Select the corresponding App ID, check the test devices, click create, and it's done. If you need to add new test devices during development, the UDID can be automatically read from the phone connected to the computer, saving manual input. You need to distinguish the purpose here: for publishing, you must use a Distribution certificate paired with an App Store type provisioning profile. Development is only suitable for debugging on real devices; using it to upload a release build will cause errors.

IPA Upload and Channel Selection

Once the certificates are in place, go to the submission upload interface. Select the compiled .ipa file, and switch the upload channel in the upper-right corner — the tool provides four options: 1, 2, 3, and the legacy channel. Different broadband operators respond differently to these channels. If the default doesn't work, switch to the legacy channel or retry with a mobile hotspot. This trick has resolved multiple cases of uploads getting stuck.

Enter the Apple upload-specific password (the app-specific password generated in your appleid.apple.com account, not your login password), then click upload. After the progress bar completes, Apple will send a confirmation email. Here's a detail: if the app record hasn't been created in App Store Connect yet, the upload will prompt "No suitable application records were found" — go to App Store Connect first to create a new app, fill in the Bundle ID and basic information, then come back to upload.

If you need to integrate with CI, the tool also provides a command-line version:

appuploader_cli -u your@apple.com -p xxxx-xxxx-xxxx -c 1 -f app.ipa

This command works on both Windows and Linux, so there's no need for a Mac node. It's suitable for integrating into Jenkins or GitLab CI, allowing automatic packaging and uploading after each code commit.

What to Do When the Build Doesn't Appear

After uploading, you sometimes can't see the build in App Store Connect; I've encountered this a few times. The troubleshooting path is fairly fixed: first wait 5-15 minutes for Apple to process it. If it still doesn't appear, check the version number — if CFBundleShortVersionString or CFBundleVersion duplicates a previously submitted one, you need to change it in Info.plist, rebuild, and upload again. Also, check the account: a free Apple ID can only generate development certificates for internal testing and cannot upload release builds. You must use a developer account that has paid the $99 annual fee.

Another situation is when you selected a Development or Ad Hoc provisioning profile during upload. These are only suitable for internal test distribution, and the App Store won't receive the build. Make sure you use an iOS Distribution provisioning profile, repackage, and upload again.

Batch Processing of Screenshots and Metadata

Before submission, you also need to prepare screenshots and metadata. Appuploader's batch upload feature lets you select multiple screenshots of different sizes at once, and the tool automatically assigns them to the corresponding device positions and language versions. There's no need to drag and drop each screenshot one by one on the App Store Connect web page. If the project supports both iPhone and iPad, just place the two sets of images in the corresponding directories when batch uploading. App description, keywords, and multilingual information are also managed on the same page. After filling in and saving, the data syncs to the developer backend, eliminating the need to switch pages repeatedly.

Submitting for Review

After completing all the steps above, return to App Store Connect and click Submit for Review. From a Windows machine, you can handle certificates, upload the IPA, manage screenshots and metadata, and finally submit for review — the entire chain is viable, so you don't need to prepare a dedicated Mac for releases. If your team has both Mac and Windows development machines, Windows colleagues can fully participate in release operations without having to wait to borrow a machine each time.

A Complete Guide to iOS Certificate Management: From Creation to Renewal

ObjC_Coder — Thu, 27 Aug 2026 08:34:46 +0000

iOS certificate management is one of the most overlooked yet error-prone aspects of development. Expired certificates prevent app submission, forgotten updates to the provisioning profile's device list prevent test devices from installing the IPA, and chaotic certificate file sharing among team members during collaboration — almost every team has encountered these issues.

Certificate Types and Purposes

iOS certificates come in two types: development certificates and distribution certificates. Development certificates are used to install apps on physical devices for debugging, with a maximum of 2 per developer. Distribution certificates are used for App Store submission or Ad Hoc distribution, with a maximum of 3.

Provisioning profiles correspond to either development or distribution types. Development provisioning profiles must include the UDIDs of test devices, while distribution profiles do not bind to devices. A single certificate can be referenced by multiple provisioning profiles.

Certificate Lifecycle Management

iOS certificates are valid for one year. Once expired, apps already on the App Store are unaffected — users who have installed the app with the old certificate can continue using it normally. However, to submit a version update, you must repackage with a new certificate.

It is recommended to start renewal operations one month before the certificate expires. Regenerate the certificate in the Apple Developer Center or Appuploader, then create new provisioning profiles with the new certificate. The old certificate's P12 file can be retired, but keeping a backup for reference is advisable.

Certificate Security

P12 files contain private keys, so password protection is mandatory. It is recommended to manage the passwords set during certificate generation centrally and avoid overly simple passwords. Do not mix passwords across different projects' certificates.

Do not transmit P12 files in plaintext. When uploading to shared storage, compress with a password, or use Appuploader's certificate sync feature — once enabled, certificates can be downloaded and used across computers, avoiding leakage during transfer. Free developer accounts only have a 7-day validity; after expiration, delete and regenerate.

Multi-Device and Multi-Member Management

Managing certificates on a single Mac for an individual developer is straightforward — install them in the keychain and Xcode associates automatically. Team collaboration adds complexity. Each member's Mac needs to import the P12 file. If someone forgets the P12 password or loses the file, all provisioning profiles and build processes depending on that certificate will be affected.

It is recommended to have one person centrally manage certificates and provisioning profiles. After creating certificates in Appuploader, enable the certificate sync feature. Other members can log in with the same account and use them directly without needing to pass P12 files individually. Provisioning profiles are also centrally managed, with device list updates modified directly in the tool.

If using Fastlane match, you can manage certificates securely through an encrypted Git repository. match syncs all certificates and provisioning profiles via an encrypted Git repository, combined with the Appuploader command-line version for uploads. This enables versioned management of certificates.

Common Issues

Certificate installation error "Valid signing identity not found" — re-download the certificate and import it into Keychain or Appuploader. If a provisioning profile indicates a device is not included — update the device UDID in provisioning profile management. If a signing error occurs during build — check that the correct certificate is selected for Code Signing Identity in the project's Build Settings.

Complete App Store Submission Guide: Certificates, Provisioning Profiles, and Windows Publishing

ObjC_Coder — Thu, 20 Aug 2026 09:12:45 +0000

When submitting to the App Store for the first time, the most troublesome part is the process involving certificates and provisioning profiles. It's even more difficult without a Mac—the traditional approach requires finding a Mac to generate certificates, export P12 files, create provisioning profiles, and then use Xcode to upload. Later, I found that using a cross-platform tool can bypass the Mac environment dependency, and the entire process can be done on a single Windows machine.

Preparation Before Submission

First, you need to register an Apple Developer account. Register at developer.apple.com and pay an annual fee of 688 RMB. A free account can only be used for debugging on a real device and cannot be used to submit apps. After account registration, you need to generate an app-specific password: enable two-factor authentication on the Apple ID page, create an app-specific password, which will be used when uploading the IPA.

To submit an app, you need three things: a certificate (P12), a provisioning profile, and an IPA installation package. The certificate is used for signing, the provisioning profile binds the app's Bundle ID and certificate, and the IPA is the compiled application.

Completing the Entire Process with Appuploader

On the homepage of Appuploader, you can select three modules: Certificate Management, Provisioning Profile Management, and Submission Upload, which correspond to the three core steps of the submission process.

Certificate Management: Click "Add" to create a certificate, select Development or Distribution type, fill in the name and password, and the tool will automatically generate a P12 file. Distribution certificates are used for submitting to the App Store, while development certificates are used for testing installations.

Provisioning Profile Management: Click "New Provisioning Profile", fill in the name, select the type (choose App Store type for distribution), and the corresponding Bundle ID. The Bundle ID must match the one in your project; otherwise, packaging and installation will fail. If you have test devices, the development provisioning profile needs to add the device UDIDs. Once Appuploader is connected to the device, it can automatically read the UDIDs.

IPA Upload: On the submission upload screen, select the IPA file, the upload channel, and the app-specific password for the Apple account, then click Upload. Appuploader provides multiple upload channels, and you can switch if the network is not good. After successful upload, wait a few minutes, and the build version will appear on iTunes Connect.

Other Steps to Note

Before submission, make sure the app icon and screenshot sizes meet the requirements. At least two screen sizes are required: 5.5-inch and 6.5-inch. You can use Appuploader's batch upload feature to upload screenshots at once. If the app does not support iPad, uploading only these two sizes is sufficient.

Regarding filing, apps released in China also need to complete APP filing. You need to fill in the package name, signing information, and operation information on Alibaba Cloud or Tencent Cloud, and after obtaining the filing number, fill it in the App Store review information.

After uploading, if the build version does not appear on iTunes Connect, wait for ten to twenty minutes and refresh. If it still does not appear, check whether the IPA version number duplicates a previously submitted version, or try uploading again using the command-line version.

Suggestions

The first submission process is relatively lengthy. It is recommended to first go through certificate and provisioning profile creation in Appuploader, confirm that the Bundle ID matches the app configuration, and then build the IPA package. After the toolchain is well-coordinated, subsequent updates will only require rebuilding and uploading the IPA.