DEV Community: DataStack

iOS Compilation Process Explained: From Source Code to IPA Build Process

DataStack — Fri, 04 Sep 2026 10:40:21 +0000

Every time you click Run or Archive in Xcode, a full compilation pipeline runs in the background. Understanding this process helps you understand why builds are sometimes slow, where a reported error actually occurs, and how development tools that don't rely on Xcode can complete the build.

The Four Stages of Compilation

The build process for an iOS app can be broken into several steps. First is preprocessing—processing macro definitions and header imports, expanding #import and #define into actual code content.

Next is compilation. The Swift compiler (swiftc) or clang (for Objective-C/C++) converts source code into machine code. The Swift compiler first performs syntax analysis, type checking, and SIL (Swift Intermediate Language) generation, and then the LLVM backend generates binaries for the target CPU architecture. Objective-C follows a similar path: clang compiles it into IR (Intermediate Representation), then generates machine code.

After compilation comes the linking phase. The linker (ld) merges the multiple compiled .o object files and system libraries (UIKit, Foundation, etc.) into a single Mach-O executable. If there are static libraries (.a) or dynamic libraries (.dylib), the linker also resolves symbol references at this stage. Link errors typically show up as "Undefined symbols" or "duplicate symbol"—the former means a class or method has only a declaration but no implementation; the latter means the same symbol is defined more than once.

Finally, packaging and signing. The generated Mach-O executable is bundled with resources such as images, XIB/Storyboard files, JSON configuration, fonts, etc., signed with a development or distribution certificate, and accompanied by a provisioning profile (embedded.mobileprovision). The final output is a .app or .ipa.

How Xcode Manages This Process

Xcode manages the compilation process through Build Settings and Build Phases. Build Settings contains hundreds of compilation parameters—architecture (ARCHS), optimization level, Swift language version, and more. Build Phases defines the execution order: compile source code first, link binaries, then copy resource files.

Once a project grows large, several common bottlenecks cause slow builds: Swift generic type checking, overly long Objective-C header import chains, and the linker's symbol resolution. Xcode's incremental compilation reduces redundant work, but a Clean Build still runs the entire pipeline.

KXApp's Compilation Implementation

KXApp includes a built-in iOS compilation toolchain, so it can handle the process without Xcode installed on the system. The editor layer is based on VS Code; compilation calls the built-in swiftc, clang, and ld tools to complete preprocessing, compilation, and linking, and finally signs and packages the IPA output.

From the developer's perspective, the whole process is reduced to a few buttons: creating a project (automatically generating the project structure and build configuration), writing code (VS Code editor with intelligent autocompletion), and connecting a device and tapping Build (which runs the full compile → sign → install-to-device flow).

The built-in toolchain also avoids environment configuration headaches. For example, building an iOS app in a Flutter project normally requires Xcode's toolchain support. KXApp has built-in support for compiling Dart to iOS, so no separate Flutter–Xcode integration environment is needed.

Understanding the Build Process

When compilation fails, knowing whether the issue lies in the compilation stage or the linking stage can save a lot of effort. Compiler errors usually include source line numbers and specific syntax problems, so they're easy to locate. Linker errors have no line numbers; you need to inspect symbol references. The most common cause of signing/packaging errors is a mismatch between the certificate and provisioning profile.

How to Get iOS Device UDID: A Complete Guide to Query Methods and Adding Test Devices

DataStack — Thu, 03 Sep 2026 09:44:08 +0000

Previously, when adding a new iPhone as a test device, my workflow was to open iTunes, connect the device, click the serial number field on the device summary page to switch it to display the UDID, right-click to copy, and paste that long string of letters and numbers into the developer portal. Every time I switched devices, I had to go through the same tedious process—until I started using a tool that can read it automatically, which made me realize this step didn't have to be so bothersome. This article walks through the several ways to obtain an iOS device UDID, and also explains what to do after you get it.

What is a UDID

First, let's clarify what a UDID is. UDID (Unique Device Identifier) is a unique identifier for each iOS device—a 40-character hexadecimal string. It is different from a serial number: the serial number is visible in Settings, while Apple does not directly show the UDID to ordinary users. In development scenarios, its role is very specific: to add a device to the test device list or to allow a device to install your development IPA, you must first obtain the device's UDID. If the provisioning profile does not contain the target device's UDID, the compiled package cannot be installed on the phone, and the error prompt will indicate something like "device not authorized" or "device not registered."

Methods via iTunes and Finder

The most traditional method is using iTunes. Connect your iPhone to the computer, select the device in iTunes, and go to the summary page. By default, it shows the serial number. Click on the serial number text to switch it to the UDID. Right-click to copy the long string. After macOS Catalina, Finder replaced iTunes as the device management location, and the operating logic is the same: select the device in the sidebar, then click the serial number area to toggle the UDID display. Both methods share the same drawback: they rely on Apple's own tools. On Windows machines without iTunes, you must install it first, and after installation, connection issues are often related to drivers.

Web Page Method

The web page method is suitable when you have the phone at hand and want to skip desktop operations. Using Safari on your phone, open a web page that provides UDID lookup. The page prompts you to install a provisioning profile. Once installed, the web page directly reads and displays the device's UDID, which you can copy and use. The mechanism is that the web page reads the UDID from device information carried by the provisioning profile. The obtained value is identical to the one from iTunes and can be used to add test devices.

Automatically Reading with Appuploader

If you have Appuploader installed on your computer, obtaining the UDID is even more convenient: just connect your device to the computer via a USB cable, and the tool automatically reads the UDID of the connected device. You don't need to click around or memorize where the serial number toggle is. Its device management module directly maintains a list of test devices under your account. The read device can be added to the list and synced to your developer account, so you don't have to switch back and forth between Apple's website and the tool. For cross-platform teams doing iOS development on Windows, Appuploader can directly read USB devices, eliminating the dependency on iTunes—a particularly handy step.

What to Do After Obtaining the UDID

After obtaining the UDID, the next steps are: log in to the developer portal, register the device under Devices (requires a paid developer account), and then regenerate the provisioning profile—when creating a Development type profile, you must select the test devices. If you don't select the new device, previously compiled packages still won't install. In Appuploader, when regenerating the provisioning profile, remember to check this device, then update the signing configuration in your build tool, recompile, and proceed with installation testing.

Troubleshooting Installation Failures

When installation fails, follow this order to check: whether the certificate is a development certificate, whether the provisioning profile includes the target device's UDID, and whether the device has Developer Mode enabled and trusts the computer. The premise for QR code installation is that the provisioning profile already contains the device's UDID and the account supports it, while USB installation requires iTunes to be installed, the device unlocked, and the computer trusted.

The several methods for obtaining a UDID differ only in whether you need Apple's own tools and whether you copy manually. Choose one based on your current environment, and standardize the workflow of "obtain UDID, add test device, regenerate provisioning profile." From then on, every new device is just a repetition of the same steps.

App Publishing: Summary of Domestic App Stores and Android Channel Distribution Essentials

DataStack — Wed, 02 Sep 2026 09:50:10 +0000

I noticed that many cross-platform app teams focus on iOS publishing, while on Android they either release to only one or two channels or have no idea about the differences between domestic app stores. Unlike iOS which has only the App Store as a single entry, each Android vendor in China has its own developer platform and review rules. The same app can have quite different listing requirements on different channels. Here is an overview of mainstream domestic app stores, along with their features and key publishing points, to help teams plan their launch schedule per channel.

Huawei AppGallery

Huawei AppGallery is one of the largest Android traffic channels in China, with broad device coverage. Developers need to register an enterprise or individual account on the Huawei Developer Union. When uploading an app, a software copyright certificate is required. The review focuses on app quality, privacy compliance, and permission rationality, with strict checks on in-app advertising and push behavior. Huawei requires app signing, and the signing certificate must be properly configured.

Xiaomi App Store

The registration threshold for Xiaomi Developer Platform is relatively low, and individual developers can also join. The listing review is fast, but apps must comply with Xiaomi's UI specifications and permission management requirements. Xiaomi restricts in-app self-update behavior, and apps are required to use the official update channel. After listing, developers can apply for Xiaomi's exclusive promotion slots, which is beneficial for traffic acquisition.

OPPO and vivo

The OPPO Software Store and vivo App Store are both vendor-built-in channels with large user bases. Both require software copyright, privacy policies, and permission explanations. OPPO pays attention to package size and startup speed during review, while vivo strictly reviews in-app induced behavior. The two platforms support joint publishing; after submitting on one platform, developers can synchronize distribution to the other.

Tencent MyApp

Tencent MyApp relies on the Tencent ecosystem and is a representative third-party distribution channel. Enterprise qualification is required for listing, and the review is relatively strict, requiring complete test accounts and functional descriptions. MyApp supports in-app payment integration (WeChat Pay, QQ Wallet) and is suitable for apps with in-app purchase needs. It has high search weight but also fierce competition.

Other channels

360 Mobile Assistant, Baidu Mobile Assistant, and Alibaba app distribution (such as Wandoujia) are also common channels with relatively fragmented traffic, suitable for long-tail coverage. Small channels have lower listing thresholds and faster reviews, but user quality varies. Review standards among third-party app stores are inconsistent; some channels are more lenient on software copyright requirements, but privacy compliance is the bottom line for all channels. Apps that abuse permissions or lack a privacy policy will not pass on any channel.

Unified preparation before listing

Before multi-channel distribution, several preparations are common: apply for a software copyright (required by most major channels), prepare a privacy policy and permission explanation, and complete app signing. The Android signing keystore can be generated online through the Appuploader official website, and app icons can also be generated via the website's online tool to meet size requirements for various channels. Completing these preparations once can save a lot of repetitive work when distributing to various channels.

How Long Does It Take to Apply for an Apple Developer Account as a Company? Materials and Time Needed for App Launch

DataStack — Wed, 02 Sep 2026 09:23:27 +0000

A friend from a startup team recently asked me about registering an Apple Developer account under the company's name — how long it would take, what materials they needed, and how much time the entire app release process would require. Many teams have asked these questions, so here is a summary of the timeline and checklist for both company account registration and app release.

Company Account Application Duration

Registering an Apple Developer account in a company's name involves several steps: obtaining a D-U-N-S number, applying for an Apple Developer account, and submitting company information for review.

The D-U-N-S number is a mandatory requirement for a company account. If you don't have one, apply to Dun & Bradstreet first. You'll receive an email with the number after approval, which typically takes 3–7 business days, though it may occasionally take up to two weeks. Once you have the number, go to developer.apple.com to register a company account, filling in details such as the company name, address, and D-U-N-S number. Apple will conduct a manual review, and you can expect results in 1 business day at the earliest or 3 business days at the latest.

Therefore, from the start of preparation to the account becoming active, it takes about one week in the best case, or two to three weeks in a slower scenario. It's wise to leave buffer time.

Required Documents

To apply in the company's name, you need to prepare the following:

Basic company information: The company name as shown on the business license (must match the registration information), registered address, and contact phone number. Apple is strict about name consistency, and incorrect entries can extend the review period.

D-U-N-S number: The core credential for company account application. If your company already has one, fill it in directly; otherwise, apply for it ahead of time.

Apple ID: Register an Apple ID with your company email, which will then be used to apply for the developer account.

Payment information: A payment method for the $99 annual fee, which supports credit cards. The fee is the same for company and individual accounts, but a company account allows you to add multiple team members in the backend to manage the account together.

Tax information: During registration, you'll need to provide tax details such as the beneficial owner. If the company information is inconsistent, Apple may ask for supporting documents like the business license.

What to Do After the Account Becomes Active

After the account is approved, log in to the developer dashboard, create an App ID (Bundle ID), and generate certificates and provisioning profiles. To create certificates, generate a CSR using Keychain Access on a Mac. If you don't have a Mac, you can use Appuploader on Windows to directly create a Distribution certificate and provisioning profile. Once the certificate and profile are ready, package the .ipa and upload it to App Store Connect via Xcode, Transporter, or Appuploader for review. Uploading from a company account does not carry personal Mac device information, which offers better privacy.

Estimated Overall Time for App Release

For an app from upload to launch, the time is mainly spent on the review phase. After uploading the build, processing takes 5–15 minutes. Once submitted, App Review generally delivers results within 24–48 hours, which may extend to 3–5 business days during peak periods. If the app is rejected, you need to fix the issues according to the feedback and resubmit; each review round involves another waiting period, so thoroughly checking your materials before submission can save considerable time. Therefore, from upload to official release, it takes about 2–3 days in the best case, or more than a week in a worse scenario. Overall, a reasonable estimate from company account registration to app launch is about one month.

iOS Development Tools Selection Guide: From Editors, Compilers to Automated Builds

DataStack — Tue, 01 Sep 2026 09:10:16 +0000

Last year, while maintaining a hybrid project, I found that the project simultaneously contained Swift pages, Objective-C legacy modules, new Flutter features, and a set of automated build scripts. During development, the editor, build tools, upload tools, and debugging tools were scattered across different places.

Sometimes, even just modifying an API field required going through the process: changing code → compiling → installing → packet capture → repackaging → uploading for testing.

Throughout this entire process, the actual time spent writing code wasn't that long. After that period, I began to realize that the choice of iOS development tools directly affects how a project is developed.

Don't Rush to Choose an IDE

When many people look for iOS development tools, their first reaction is: which IDE is better? But in a project, the IDE is only part of the toolchain. What really needs to be considered is:

What type is the project?
What language does the team use?
Is automation required?
Is frequent on-device debugging needed?
Does it maintain multiple technology stacks?

Different conditions lead to different tool combinations.

If the Project is Primarily Native Swift

For pure Swift projects, Xcode remains the core, because it directly handles project management, Interface Builder, simulators, Archive, certificates, and signing.

Especially when dealing with Provisioning Profiles, App Store Connect, and Release builds, Xcode still offers the highest level of integration. However, many developers choose to separate the "code editing" action, for example:

Using VSCode to edit Swift files
Using Git plugins
Using AI-assisted plugins
Using terminal scripts to manage the project

The reason for this is not to replace Xcode, but to reduce context switching during development.

If the Project Includes Flutter or Multiple Technology Stacks

This type of project presents a problem: different modules correspond to different tools. For example, Flutter pages are in VSCode, the iOS project is in Xcode, and automation scripts are in the terminal. As switching becomes more frequent, the development rhythm becomes fragmented. Therefore, some teams start to pay attention to "unified development environments," which is why in recent years, some integrated iOS development tools have emerged.

When Are Automation Tools Worth Adding?

Many personal projects don't integrate CI/CD at the beginning, but once a project enters stages such as multi-person collaboration, high-frequency testing, or continuous release, automation tools become important. For example:
Fastlane handles automatic building, packaging, uploading to TestFlight, and releasing versions. For instance, after running fastlane beta, the entire release process can be completed directly.

GitHub Actions / Jenkins are more suitable for team collaboration. After code is committed, they can automatically compile, test, build, and upload. These tools solve the problem of "reducing repetitive work" rather than "development."

Debugging Tools Are More Important Than You Think

In many iOS projects, the real time sink is debugging, such as abnormal API responses, inconsistent permission behavior, and differences between real devices and simulators. At such times, you start to rely on:
Charles handles: packet capture, viewing requests, and analyzing APIs.
On-device debugging tools handle: installing apps, viewing logs, and verifying device behavior. Especially when Bluetooth, push notifications, camera, and similar features are involved, on-device verification is inevitable.

A New Direction: Putting the Whole Process Back into One Environment

The problem with many development processes today is not that a particular tool is bad, but that the tools are too scattered. For example:

Write code in VSCode
Compile in Xcode
Package with Fastlane
Upload with AppUploader

Each step is fine, but the switching itself constantly interrupts the development process. Recently, I came across an interesting tool: Kuaixie (kxapp). Its direction is not to introduce a new programming language, but to try to reintegrate several high-frequency actions.

Currently, it supports Swift projects, Objective-C projects, and Flutter projects. Its editor is based on the VSCode architecture, and it also includes its own set of iOS compilation tools. After modifying a project, you can directly build, run on a real device, and generate installation packages. This kind of tool is suitable for development scenarios that require frequently switching projects, maintaining multiple technology stacks, and wanting to reduce tool hopping.

Choosing Tools Is Essentially Choosing a Development Workflow

If we revisit the question of iOS development tool selection, we find that it's no longer about which IDE to choose, but about how to organize the entire development workflow. Some teams choose to split each phase and handle each tool independently, while others prefer to minimize switching and put the development workflow back into one environment. Both approaches are valid; the key lies in project scale, team habits, and development rhythm.

How to Choose Apple Upload Tools: Several Ways to Submit to App Store Without a Mac

DataStack — Fri, 28 Aug 2026 10:27:52 +0000

Our team used to rely on a dedicated Mac mini for uploading releases; anyone who needed to ship had to queue up and connect to it. When that machine went in for repair one time, a build packaged with uni-app got stuck and couldn't be released. That's when I seriously looked for App Store upload tools that don't depend on a Mac. It turned out there are quite a few options, each suited to different scenarios. Here's a rundown of the ones I've tried.

Xcode Organizer: Official but Mac-Bound

The most standard route is Xcode Organizer: after archiving, you directly select Distribute App to upload. It integrates most smoothly with certificates and provisioning profiles, so you rarely need to worry about signing issues. The catch is that you must have a Mac—Xcode only runs on macOS, so Windows and Linux users are blocked from the start. If your project is pure native Swift/Objective-C and your team already has a Mac for everyone, there's little to complain about. The problem arises with cross-platform stacks: builds from Flutter, uni-app, or React Native often come from Windows machines, and maintaining a separate Mac just for uploads is costly.

Transporter: Still Requires a Mac

Transporter is Apple's replacement for the retired Application Loader. You download it from the Mac App Store, drag in the .ipa, and it uploads. It's lighter than Xcode and suits the step where the build is already ready and you just need to upload. But it's also macOS-only; it won't install on Windows at all. So it solves the problem of simplifying the upload interface, not the requirement of having a Mac.

fastlane: Good for CI, with a Learning Curve

fastlane's deliver and pilot can automate uploading, screenshots, and metadata. Once integrated into CI, each release is a single command. For larger teams with frequent releases, this automation saves a lot of repetitive work. The barrier is that its upload path still depends on macOS under the hood (altool/xcrun), so your CI needs a Mac node. Configuring Fastfile, Appfile, and match certificate management also has a learning curve. It's suitable for teams that already have Mac CI and are willing to invest in automation, but not for individual developers who just want to upload a build from their Windows machine.

Appuploader: Direct Upload from Windows / Linux

Appuploader takes a different route—no Mac required. It can upload IPA files to the App Store from Windows, Linux, or Mac. The actual process takes a few steps: choose the compiled IPA in the submission/upload screen, pick an upload channel in the upper-right corner (the tool offers channels 1, 2, 3, and a legacy channel; if the network is bad, switching to the legacy channel or a hotspot and retrying helps), then enter the Apple app-specific password for uploads, click upload, and wait for Apple's confirmation email. The upload-specific password is an app-specific password generated in your Apple ID account; it's used for authentication so you don't have to hand over your main password to the tool.

It also handles the other pre-submission tasks: without Keychain Access, you can enter a certificate name, email, and password to create iOS development and distribution certificates on Windows. Those certificates can be shared across computers, so team members don't each need to request their own. Provisioning profiles, Bundle IDs, and test-device UDIDs are also managed in the same interface; UDIDs can be auto-detected from the currently connected device. App Store screenshots and multi-language metadata support batch upload, saving you from uploading one by one. One caveat: the upload/distribution feature only works with a paid developer account ($99/year, ¥688 in China). Free Apple IDs can only create development certificates for internal testing, not for App Store distribution.

If you want to integrate with CI, it also has a command-line version. One command does it all:

appuploader_cli -u abc@icloud.com -p xxx-xxx-xxx-xxx -c 1 -f a.ipa

-u is your Apple account, -p is the app-specific password, -c selects the channel, and -f points to the IPA file. This command runs on Windows and Linux with no Mac node needed.

How to Choose

If you have a Mac and a pure native project, Xcode Organizer is enough. If the build is ready and you just need to upload and you have a Mac, Transporter is easiest. For large teams with Mac CI that want full automation, fastlane is worth the investment. If your dev machines are Windows/Linux, you're building with cross-platform frameworks, or you don't want to maintain a separate Mac just for releases, a tool like Appuploader ties together certificates, provisioning profiles, and uploads in a non-Mac environment. Most teams mix and match—use Xcode for local development, then pick an upload method based on the machine available at release time.

App Store build version not showing after upload? Common causes and solutions

DataStack — Wed, 26 Aug 2026 10:37:39 +0000

After uploading the IPA to App Store Connect, you may see a success message, but when you return to your app's page, the build list is empty—this is a problem many developers have encountered. A successful upload does not guarantee that the build will appear; Apple's backend performs a series of validations on the IPA, and builds that fail validation will not be displayed.

Check Your Email After a Successful Upload

Once the upload tool shows a success message, Apple sends a notification email to the email address associated with your developer account. It is recommended to check your inbox, including the spam folder. The email will clearly state whether the upload succeeded or failed, and failure emails include specific error reasons and codes. This is the most direct way to troubleshoot why a build hasn't appeared.

Common error emails include: incorrect certificate type, app icon containing an alpha channel or transparency, missing permission declarations, and redundant binary uploads.

Wait for Processing Time

After a successful upload, the build will not appear immediately. Apple's backend needs to scan and process the newly uploaded IPA, which typically takes 10-30 minutes, sometimes longer. In App Store Connect, on the "My App → Activity → Builds" page, if it shows "Processing," the upload was successful—just wait for it to complete.

If it still hasn't appeared after a few hours, it means the IPA was deemed problematic during processing, and you should have received a failure email in your inbox.

Duplicate Version Number

An IPA with the same version number can only be uploaded once. If you previously uploaded version 1.0 (build 1), uploading the same version again will result in error ITMS-90189 "Redundant Binary Upload." The solution is to increment the Build Number in Xcode or your packaging tool and repackage. Apple requires that the combination of version number and build number must be unique for each upload.

Certificate Type Mismatch

An IPA signed with a development certificate cannot be submitted for release. It will be rejected by the system after upload, and the build will not appear. Confirm that you are using a Distribution (release certificate) and an App Store provisioning profile when packaging. Development certificates are only for testing on physical devices and cannot be used for release.

Bundle ID Must Match

The Bundle ID in the IPA must exactly match the Bundle ID of the app created in App Store Connect. If they do not match, the upload will fail, or the build will not appear. You can verify the Bundle ID setting in the configuration file of your packaging tool.

Troubleshoot and Re-upload with Appuploader

If the build does not appear after uploading with Appuploader, first check the upload logs to see if there are any errors. The upload interface supports switching channels; if one channel fails, you can try another. When using the command-line version, the log output is more detailed, making it easier to troubleshoot.

After identifying and fixing the issue, repackage, remembering to increment the version number or build number, and then upload again with Appuploader. Wait 10-30 minutes after uploading and refresh the build list page. If failures persist, carefully read the error codes in the email—most issues can be identified through the email information.

Upload IPA to App Store Without Xcode: Transporter and Cross-Platform Tools

DataStack — Thu, 13 Aug 2026 09:32:18 +0000

If you've published iOS apps, you know the Xcode IPA submission flow: Archive → Organizer → Distribute App → Upload. Each step involves various validations, and when the network is unstable, it often gets stuck during upload—and when it fails, you have to start over. But by the packaging stage, the IPA is already signed with a distribution certificate. Uploading is essentially just file transfer, so Xcode isn't strictly necessary. If you don't want to install Xcode, or if you need to submit from Windows or Linux, there are several alternatives.

Application Loader and Transporter

Apple provides a standalone macOS app called Transporter (formerly Application Loader) specifically for uploading IPA files to App Store. You don't need to open Xcode—just drag the IPA file into the app and upload. The interface is minimal, without the Archive and validation workflow. The downside is that it only runs on macOS; Windows and Linux are not supported.

Some usage notes for Transporter: after a successful upload, the build may take anywhere from a few minutes to over ten minutes to appear in App Store Connect. Sometimes the upload succeeds but the build doesn't show up for a while; usually waiting or re-uploading resolves it. You must enable two-factor authentication for your Apple developer account, and you'll need to generate an app-specific password on the Apple ID page before uploading—your regular account password won't work.

AppUploader Desktop

AppUploader works on Windows, Mac, and Linux. The upload process is straightforward: in the submission screen, select the IPA file, choose an upload channel from the four options in the upper-right corner (switch if the network environment is poor), enter your Apple ID and app-specific password, and click upload. If upload fails due to carrier restrictions or network issues, you can switch to a legacy channel or try a mobile hotspot.

AppUploader also offers a command-line version suitable for CI/CD integration. The command format is: appuploader_cli --upload-app -f Payload.ipa -u user@example.com -p xxxx-xxxx-xxxx-xxxx --type ios, specifying the IPA file, Apple ID, and app-specific password. The command-line version is more stable than the GUI version and can be embedded in automation pipelines like Jenkins or GitHub Actions. The GUI requires manual file selection and clicking upload each time, while the CLI can execute with a single command after scripting.

However, AppUploader's upload feature only supports paid developer accounts (¥688/year); free accounts cannot submit apps. If you see the message "Your account has not paid ¥688 to Apple," it means the current account is free and can only be used for development and testing.

Points to Note

Before uploading, ensure the IPA is signed with a distribution certificate—packages signed with a development certificate cannot be submitted. The IPA's Bundle ID must match the app created in App Store Connect. If the build doesn't appear in App Store Connect after a successful upload, it may be due to network latency or an issue with the app's Info.plist configuration; wait ten minutes and refresh. If it still doesn't appear, check whether the IPA includes bitcode and whether the architecture support is complete (at least arm64).

Which to Choose

If you have a Mac, Transporter is the easiest. For cross-platform IPA uploads or automation integration, AppUploader's desktop and command-line versions offer more flexibility. Neither approach requires installing Xcode.

How to Automatically Upload IPA in Flutter and Separate Build from Upload

DataStack — Thu, 06 Aug 2026 07:24:44 +0000

When uploading for iOS in a Flutter project, a better approach is to treat it as two steps: Flutter generates the IPA package, and an upload tool submits it to App Store Connect, rather than thinking of it as 'one-click publishing with Flutter'.

By doing this, whether you're on Windows, Linux, or using Jenkins, GitLab CI, you can easily integrate the upload process.

Generate IPA

Run on a macOS build node:

flutter clean
flutter pub get
flutter build ipa

The generated path is typically build/ios/ipa/, verify that a .ipa file exists in the directory.

Prepare Upload Account

Uploading to the App Store requires:

Apple Developer account
App-specific password
A signed IPA

The app-specific password is not your Apple ID login password; it needs to be created in your Apple ID security settings.

Upload Using AppUploader CLI

After downloading AppUploader, find the command-line tool in the runtime directory.

On Linux/macOS, first run chmod +x appuploader_cli, then use the upload command:

./appuploader_cli upload \
-f build/ios/ipa/Runner.ipa \
-u user@example.com \
-p xxxx-xxxx-xxxx-xxxx \
--type ios

During upload, the tool automatically handles metadata, including AppStoreInfo.plist, so no manual generation is needed.

Integrate with Jenkins or GitLab CI

Example script:

flutter clean
flutter pub get
flutter build ipa

./appuploader_cli upload \
-f build/ios/ipa/Runner.ipa \
-u "$APPLE_ID" \
-p "$APP_PASSWORD" \
--type ios

In CI, it's recommended to put:

APPLE_ID
APP_PASSWORD

into environment variables or credential management, and avoid hardcoding them in scripts.

Post-Upload Checks

Go to App Store Connect → TestFlight. If the build doesn't appear, check:

Whether the build number has been incremented
Whether the Bundle ID matches
Whether the IPA is signed with an App Store provisioning profile
Whether the app-specific password is correct

Manage iOS Provisioning Profiles on Windows Without a Mac: A Complete Non-Xcode Guide

DataStack — Fri, 10 Jul 2026 09:16:38 +0000

Many developers first encounter iOS provisioning profiles through tutorials that revolve around Xcode and Keychain.

But in real development, there are projects not completed on a Mac—uni-app, Flutter, React Native, HBuilderX cloud packaging, Windows development environments. Then the question becomes: how do you actually manage .mobileprovision files?

Especially as projects multiply, developers start encountering issues like: profile and certificate mismatch, Bundle ID confusion, missing test devices, expired files preventing installation, and inability to sync across different computers.

What a provisioning profile binds

An iOS provisioning profile core binding includes:

Content	Purpose
Bundle ID	Identifies the App
Certificate	Used for signing
Device UDID	Development testing install
Type	Development / App Store

That is, a provisioning profile does not exist independently; it depends on the App ID, certificate, and Apple Developer portal.

Most common issues in a Windows environment

Mac users often rely on Xcode's automatic signing and Automatically Manage Signing, but in a Windows environment, management is more manual, making it easier to bind a profile to the wrong Bundle ID, e.g., Profile: com.demo.app but packaging config: com.demo.test, resulting in build failure, installation failure, or upload failure.

Profile uses wrong certificate

For example, a Development profile paired with a Distribution certificate, or vice versa.

Test devices not added to the profile

IPA can be generated, but installation on the phone fails.

Better structured management under Windows

Don't dump all .mobileprovision files on the desktop. Once projects increase, maintenance becomes difficult. It is recommended to separate by project/environment/type.

Sample directory structure:

profiles/
├── appstore/
├── development/
├── adhoc/
└── expired/

Then name each file including BundleID + type + date, e.g., com.demo.shop_appstore_2026.mobileprovision. This will make troubleshooting much easier later.

Creating a provisioning profile on Windows

Here we take AppUploader (Happy Release) as an example.

Because in a Windows environment, no Xcode or Keychain is needed; you can directly manage provisioning profiles.

Prepare the Bundle ID first

Go to [Bundle ID Management] and create com.company.app. Ensure consistency later when packaging.

Prepare the certificate

A provisioning profile must bind a certificate.

Go to [Certificate Management] and create: Development for real device testing and debugging installations; Distribution for App Store uploads.

Create a provisioning profile

Go to [Provisioning Profile Management] and click: New Provisioning Profile.

Select the profile type

Don't select the wrong type. Development is for real device installation testing and will bind device UDIDs. Distribution is for submitting to the App Store and does not bind test devices.

Bind the Bundle ID

Select the corresponding App's Bundle ID. This must match the package name in:

Flutter
uni-app
Xcode
React Native

If it's a Development profile, check the test devices; otherwise, the IPA cannot be installed.

Download the provisioning profile

After generation, download the .mobileprovision file. It is recommended not to rename it to gibberish. Keep the Bundle ID and type for easier troubleshooting.

How to view provisioning profile content on Windows

Sometimes you need to confirm if it's expired, which Bundle ID it's bound to, or which devices are included. You can directly parse it.

View key information

Focus on:

Field	Meaning
Name	Profile name
UUID	Unique identifier
TeamIdentifier	Developer team
Entitlements	Permissions
ProvisionedDevices	Test devices
ExpirationDate	Expiration date

Recommended combination on Windows

A stable setup:

Function	Tool
Bundle ID management	AppUploader
Certificate management	AppUploader
Profile management	AppUploader
IPA upload	AppUploader CLI
Packaging	Flutter / uni-app / RN

Managing iOS provisioning profiles on Windows essentially breaks down the signing process that originally depended on Xcode.
Once the relationships among Bundle ID, certificate, and provisioning profile are clarified, many installation failures and signing errors become easier to locate.

What are the iOS development tools? A comprehensive list for 2026 developers

DataStack — Thu, 09 Jul 2026 09:47:36 +0000

A while ago, when taking over an old project, I had four tools open on my desktop at the same time.

One for writing code, one for handling Git, one for packaging, and another dedicated to uploading test builds.

The project itself wasn't particularly large, but the development process had clearly been fragmented into many segments. Later, when I sorted things out, I realized that iOS development today is no longer an era where you just install an IDE and you're done.

Different tools are now responsible for different stages: some handle code editing, some handle project building, and some are specifically designed for automated releases. What developers actually use is a complete workflow.

This article will not simply list software; instead, it organizes common iOS development tools according to the actual development process and discusses what problems each solves.

Code Editing: The Longest Part of Development

The tools you spend the most time with each day are usually the code editors.

Xcode

Xcode remains the core tool in iOS development.

Project creation, target configuration, Interface Builder, certificate management, and real device debugging are all bundled together. For pure native projects, it is still the most complete development environment. However, as projects grow larger, many developers start to separate "writing code" from "project management."

VSCode

VSCode has become increasingly prominent in mobile development in recent years, largely because many teams maintain multiple platforms simultaneously:

iOS
Android
Flutter
Web
Node services

If all code can be worked on within a single editor, the development process becomes more continuous. Swift plugins, Git plugins, terminal support, and AI-assisted tools have also made VSCode appear more frequently in iOS projects.

AppCode

JetBrains' AppCode is still used by some developers. Its code analysis capabilities are strong, especially in large Objective-C projects, where refactoring and navigation are more noticeable. However, it still relies on the Xcode toolchain.

Project and Dependency Management

Beyond code, the project structure itself also requires tools for maintenance.

CocoaPods

Many older projects still rely on CocoaPods to manage third-party libraries. After running pod install, a workspace is generated and then opened with Xcode. Although many projects have migrated to SPM, CocoaPods hasn't completely disappeared.

Swift Package Manager (SPM)

SPM has become the default choice for an increasing number of Swift projects. It is directly integrated into Apple's official toolchain, so no additional dependency management tools need to be installed. Many new projects have begun to reduce their reliance on CocoaPods.

Compilation and Building: The Most Overlooked Part

Many developers click Run every day, but what actually happens is more complex than imagined:

Parse the project
Call SDKs
Select architectures
Compile code
Link libraries
Generate the App

These steps together form the build process.

Fastlane

Fastlane is common in team projects. It automates the execution of:

Building
Packaging
Uploading to TestFlight
Releasing versions

For example:

fastlane beta

This automatically completes the upload of a test build. When projects require frequent releases, such tools significantly reduce repetitive operations.

Jenkins / GitHub Actions

CI/CD tools are more commonly seen in team collaboration scenarios. After code is submitted, they can automatically:

Compile the project
Execute tests
Generate installation packages
Release versions

These processes become increasingly important in the later stages of a project.

Real Device Debugging and Device Management

Many issues only appear on real devices, such as:

Push notifications
Bluetooth permissions
Camera functionality
Performance issues

Therefore, real device debugging remains one of the most frequent actions during development.

Apple Configurator

Primarily used for device management, for example:

Installing configuration profiles
Managing test devices
Batch deploying applications

It is common in enterprise testing environments.

Charles

Charles is not an IDE, but almost every iOS developer has it installed.

It is mainly used for:

Packet capture
Viewing API requests
Analyzing network issues

When APIs behave abnormally or data structures are inconsistent, such tools become very important.

Upload and Release

After development is complete, another workflow begins.

App Store Connect

Ultimately, submitting the final version still requires Apple's official platform.

This includes:

TestFlight testing
Review submission
Version management

AppUploader

Some teams separate the upload step into a dedicated tool. Tools like AppUploader are more focused on IPA upload management rather than development itself.

Emerging Integrated Tools

As the number of tools increases, a change is emerging: the development process has become increasingly fragmented. For example:

VSCode for writing code
Xcode for managing projects
Fastlane for packaging
AppUploader for uploading

Each tool is good on its own, but the cost of switching becomes increasingly apparent.

Recently, some new integrated tools have started to appear.

One of the more interesting ones is Kuaixie (kxapp).

It does not simply solve one single step; instead, it attempts to bring several high-frequency actions back into a single environment.

Currently, Kuaixie supports:

Swift projects
Objective-C projects
Flutter projects

Its editor is based on the VSCode architecture, and it comes with its own built-in compilation tool suite. After modifying a project, you can directly perform builds and run on real devices. Application building and installation package generation are also completed within the same development environment. For developers who need to frequently switch between projects or quickly verify features, this kind of tool is closer to a "complete workflow."

Now, when considering the question "What are the iOS development tools?", it becomes clear that it is no longer just a list of software names. Editors, dependency management tools, compilation tools, automation tools, packet capture tools, and release tools all participate in the development process.

Different teams will combine different workflows. Some prefer to use separate tools, while others are beginning to try integrated solutions.

How to generate AppStoreInfo.plist on Windows? A method independent of Xcode

DataStack — Thu, 02 Jul 2026 08:37:21 +0000

Many developers first encounter the Info.plist file when uploading an IPA.

Especially when packaging iOS on Windows, uploading IPA on Linux CI, or using non-Xcode upload workflows, they often encounter:
Missing Info.plist or Could not find Info.plist

Some articles suggest: manually create the plist, export using Xcode, or use Transporter to auto-generate.

But if your current environment is Windows, these methods are not convenient.

What is Info.plist

It is essentially a metadata file attached when uploading to the App Store.

It contains Apple upload identification information, package structure description, and upload task parameters.

It is not a file required for the application to run.

What to do in a Windows environment

In Xcode, the Archive and Export IPA steps automatically generate the relevant metadata.

But if:

Flutter Windows packaging
Unity exporting IPA
HBuilder cloud packaging
React Native CI

The IPA has already been generated, but the upload metadata has not. In this case, the upload tool may report an error.

Common misconception: writing plist manually

Some online solutions suggest:

<?xml version="1.0" encoding="UTF-8"?>

Then manually construct the plist content. The problem is that Apple's upload fields may change, Transporter versions differ, and metadata structures vary. This often leads to upload failure (metadata validation failed).

A more direct approach: let the upload tool auto-generate

If your goal is simply to upload an IPA to App Store Connect, there is no need to generate the plist yourself.

Using the AppUploader CLI approach, when uploading via command line on Windows, Linux, or Mac, the Info.plist is automatically generated. Therefore, no manual creation, no Xcode, no Transporter GUI needed.

Actual upload workflow on Windows

Prepare the IPA, ensure it is signed, can be installed normally, and the Bundle ID is correct.
Locate appuploader_cli under the runtime/ directory (included in the Windows download package).
Execute the upload command, for example:

appuploader_cli --upload-app -f Payload.ipa -u user@example.com -p xxxx-xxxx-xxxx-xxxx --type ios

Or:

appuploader_cli upload -f Payload.ipa -u user@example.com -p xxxx-xxxx-xxxx-xxxx --type ios

During CLI upload, it automatically analyzes the IPA, including Bundle ID, Version, and Build Number.

It automatically generates upload metadata, including: Info.plist

It automatically calls the upload API.

It directly uploads to App Store Connect.

Command-line approach is more suitable for CI

In a continuous integration environment, it is not convenient to open a GUI or rely on Xcode.

The CLI can be scripted, integrated with Jenkins / GitLab CI, and placed in Docker. CI example:

appuploader_cli upload \
-f build/app.ipa \
-u ci@example.com \
-p xxxx-xxxx-xxxx-xxxx \
--type ios

Easy to overlook: App-Specific Password

When uploading, -p is not the Apple login password. You need to create an App-Specific Password in the Apple ID backend, otherwise upload authentication will fail.

Command parameter explanation

Parameter	Description
`--upload-app`	Upload application
`-f`	IPA file path
`-u`	Apple ID
`-p`	App-Specific Password
`--type ios`	iOS package

In a Windows environment, if the upload tool already supports auto-generation, there is no need to manually maintain the plist file.