DEV Community: CoreDataHero

iOS App Submission Guide, Apple Developer Account Registration, IPA Packaging, etc.

CoreDataHero — Mon, 31 Aug 2026 10:00:52 +0000

Developers have probably all encountered this situation: the app is developed and ready to launch, but when you start the submission process, you realize there are quite a few things to prepare—certificates, provisioning profiles, screenshots, and privacy policies. Skip any step and you can't submit for review. This iOS app submission guide starts from registering a developer account and walks through the entire process from beginning to end, also mentioning operational differences across different computer environments.

Registering a Developer Account

Before submitting, you need to register an Apple Developer account. Individual developers choose the Individual type, which costs $99 per year and displays your personal name on the App Store. Company accounts also cost $99 per year but require a D-U-N-S number and display the company name. During registration, you fill in credit card information and tax information. Once your registration is approved by Apple, the developer account becomes active. A free Apple ID can only be used for development and on-device debugging; it doesn't have submission permissions and cannot generate Distribution certificates. If you choose the wrong account type, it's troublesome to change later, so decide in advance whether the display name will be personal or company.

Creating an App ID and Generating Certificates

Log in to developer.apple.com to create an App ID (Bundle ID), fill in the unique app identifier, and enable required services such as Push Notifications or Sign in with Apple.

There are two types of certificates: Development certificates are used for on-device debugging, while Distribution certificates are used for release submission. On a Mac, you generate a CSR using Keychain Access, submit it to the developer console, download the .cer file, and import it back into Keychain to export as a .p12. The entire process relies on the macOS environment. If you don't have a Mac, you can use tools like Appuploader to create certificates directly on Windows—open the certificate manager, select the Distribution type, enter a name and P12 password, and they can be generated within minutes. The resulting .p12 file can be exported for team use, so not everyone has to apply for one individually.

A provisioning profile associates certificates, the App ID, and test devices. For App Store submission, select the App Store type; for internal testing, select Ad Hoc. After filling in the Bundle ID, checking the certificates and devices, download and import the profile. Multiple apps can share a single Distribution certificate, but provisioning profiles must be created independently for each app. When adding new test devices, UDIDs can be read automatically, saving the hassle of manual input.

Packaging and Uploading

For native projects, use Xcode's Product → Archive to export an .ipa. This step needs to be done on macOS. Cross-platform projects (Flutter, uni-app, React Native) each have their own packaging commands that compile and output an .ipa, and they can also be compiled on Windows. When packaging, ensure the version number isn't duplicated and the Bundle ID matches the provisioning profile.

There are several ways to upload to App Store Connect: Xcode Organizer and Transporter are limited to macOS, and fastlane relies on xcrun, which also requires a Mac environment. Appuploader can upload IPA directly on Windows and Linux. Select the upload channel, fill in the app-specific password, click upload, and wait for the progress bar to complete and an email confirmation. If the build version doesn't appear, check whether the version number is duplicated or the account permissions are correct.

Preparation Before Submitting for Review

After uploading, fill in the app information in App Store Connect: name, subtitle, description, keywords, and privacy policy URL. Upload screenshots in both 6.5-inch and 5.5-inch sizes; add another set if you support iPad. Screenshots must comply with Apple's guidelines and must not contain unreleased features or sensitive content. If the app involves user login, provide test accounts for reviewers. When using permissions such as location, camera, and contacts, explain the usage in the remarks. These preparation tasks are also an easily overlooked part of the iOS app submission guide—incomplete assets can slow down the review process. After filling in everything, click Submit for Review and wait for Apple's feedback.

Apple Developer Account Registration Tutorial: Differences Between Individual and Company Accounts and Application Process

CoreDataHero — Fri, 28 Aug 2026 10:16:40 +0000

The first step to publishing an app on the App Store is to register for an Apple Developer account. Both individual and company accounts cost 688 CNY per year, but they differ in the application process, required materials, and permissions. Which account type you choose depends on your developer identity and team structure.

Individual Account

Individual accounts have the fastest registration. After submitting materials, you usually receive an approval notification within about 1 day. Registering with personal identity information, the app page on the App Store will show the individual's name. It is suitable for independent developers or personal studios.

The limitation of an individual account is that it can only be used by one person; you cannot add team members. An account can register up to 100 test devices.

Company Account

Company accounts also cost 688 CNY per year and, like individual accounts, display the company name on the App Store after publishing. They are suitable for teams with a formal entity. Company accounts allow you to create a development team, add members, and set different permissions: Admin Legal (super administrator), Admin (administrator), Member (regular developer), and No Access.

Applying for a company account requires a D-U-N-S Number. If you don't have one, you need to apply, which takes approximately 7-14 business days. The overall registration cycle is longer than that for individual accounts, generally ranging from 3-4 business days to two weeks.

Enterprise Account

Enterprise accounts cost $299 per year and are used for internal app distribution within an enterprise. They don't require App Store review, but the apps cannot be published on the App Store. Currently, new applications are essentially not accepted.

Account Registration Process

On the Apple Developer website, register an Apple ID using your email address, fill in personal information as prompted, and verify your email and phone number to complete registration. Then download the Apple Developer App on your iPhone or iPad, log in, and select an account type. For an individual account, submit your name, ID number, address, and other information, complete facial recognition, and pay 688 CNY.

Company accounts also require the D-U-N-S Number and company qualification documents. Since 2020, registration must be completed through the Apple Developer App; the web portal no longer supports new registrations.

What to Do After Registration

After successful registration, you can create certificates and provisioning profiles in Appuploader. Certificates are divided into development certificates (for debugging on real devices) and distribution certificates (for publishing to the App Store). On the certificate management page, click Add, select the type, enter a name and password, and the tool will automatically generate a P12 file from Apple's servers. It is recommended to enable certificate synchronization for easy sharing within the team.

Provisioning profiles are created on the provisioning profile management page, and you need to bind the Bundle ID, certificate, and test devices. The development provisioning profile requires the UDID of test devices, which Appuploader automatically reads when connected. Distribution provisioning profiles do not require binding to devices. Free accounts can also create certificates, but they are only valid for 7 days and cannot be used to publish apps on the App Store.

Jenkins Integration for iOS IPA Auto-Upload: Using Appuploader CLI for CI/CD Releases

CoreDataHero — Wed, 26 Aug 2026 10:25:58 +0000

In iOS CI/CD pipelines, uploading the packaged IPA to App Store Connect typically relies on Xcode or Transporter in a Mac environment. If Jenkins runs on Linux or Windows, this upload step becomes a bottleneck. The command-line version of Appuploader can be embedded into Jenkins pipelines to complete the upload in non-Mac environments.

Common Practices for iOS Builds in Jenkins

Jenkins pipelines for iOS projects usually consist of several steps: pull code → install dependencies → compile and package → sign → upload. The earlier steps can be performed on Linux or Windows (pulling code, installing Pods, running scripts), but compilation and upload typically depend on Mac.

One approach is to run the Jenkins Master on Linux and register a Mac as a Jenkins Slave dedicated to iOS builds. After compilation, the same Slave uploads the IPA. The drawback is that Mac Slave resources are heavily occupied, and if only uploading is needed, a Mac environment is not actually required.

Another approach is to decouple compilation and upload—compilation is done on the Mac Slave, and after producing the IPA, it is transferred to the Linux build machine, where Linux performs the upload. The upload step does not depend on Xcode or Transporter.

Integrating Appuploader CLI

Appuploader provides a command-line version that can directly invoke the upload functionality on Linux and Windows. The command format is: appuploader_cli --upload-app -f Payload.ipa -u user@example.com -p xxxx-xxxx-xxxx-xxxx --type ios.

Parameter description: --upload-app specifies the upload operation, -f specifies the IPA file path, -u specifies the Apple developer account, -p specifies the App-specific password (not the login password), and --type ios specifies the upload platform type.

In Jenkins Configuration, add an Execute Shell or Execute Windows Batch Command step and fill in this command. Alternatively, you can invoke it via the sh or bat step in the Pipeline script.

Jenkins Pipeline Configuration Example

Add a stage in the Jenkinsfile:

stage('Upload IPA to App Store') {
    agent { label 'linux' }
    steps {
        sh 'appuploader_cli --upload-app -f build/App.ipa -u $APPLE_ID -p $APP_PASSWORD --type ios'
    }
}

It is recommended to inject the Apple developer account and app-specific password through the Jenkins Credentials Binding plugin as environment variables, rather than hardcoding them in the script. Add a withCredentials step to reference the credentials.

Preparation Before Upload

Before executing the upload operation in Jenkins, several things need to be prepared. The IPA file must be signed with a distribution certificate. The Apple developer account needs two-factor authentication enabled, and an App-specific password must be generated on the Apple ID page. This app-specific password differs from the login password, and the upload tool uses it for authentication.

If the build version does not appear on App Store Connect immediately after uploading in the Pipeline, you can add a wait-and-poll step in the script to check whether the specified version number has appeared. If an error is returned, check whether the Bundle ID matches and whether the version number is duplicated.

Multi-Channel and Retry

Appuploader provides multiple upload channels. If the default channel fails, you can specify another channel in the command. In CI environments with unstable networks, it is recommended to configure a retry mechanism in the Jenkins job—wait a few seconds after an upload failure and retry with a different channel.

The command-line version is more stable than the GUI version and is suitable for unattended automation scenarios. The logs output by the command-line version can be displayed directly in the Jenkins console, making it convenient to troubleshoot the cause of upload failures.

Recommendations

After decoupling IPA upload from the Mac environment, Jenkins iOS pipelines can allocate resources more flexibly. Compilation still relies on the Mac Slave, but upload can be delegated to Linux or Windows nodes, saving Mac node occupancy time.

App Store Screenshot Batch Upload Methods: Several Ways to Avoid Manual Upload One by One

CoreDataHero — Wed, 12 Aug 2026 09:38:10 +0000

Anyone who has gone through App Store submission has likely experienced rejection due to mismatched screenshot sizes, having to prepare dozens of images for multiple language versions, and repeating the upload process for every version update. A typical app requires screenshots in both 5.5-inch and 6.5-inch sizes, plus additional ones for iPad if supported. Multiplied by the number of languages, uploading them one by one is indeed time-consuming.

Screenshot Management in Xcode

Xcode provides built-in screenshot upload functionality. In the Organizer or Archives window, choose "Distribute App," and the workflow will lead to the screenshot management page. You can drag screenshots into the placeholder boxes for the corresponding devices to upload. The advantage is that it's integrated into Xcode without requiring extra tools; the disadvantages are that you can only handle one language version at a time, screenshots need to be sorted by size before dragging, and it can only be done on a Mac. If your project supports multiple languages, you'll need to repeat the drag-and-drop for each language.

Application Loader and Transporter

Apple's Transporter app can upload IPA files and metadata, but it only provides basic support for screenshot management—you need to prepare screenshot files and place them in a specified directory structure, then import them with Transporter. This is somewhat faster than dragging directly in Xcode, but the directory structure is strict, and files placed incorrectly will cause errors.

Batch Upload with AppUploader

AppUploader's batch screenshot upload feature is accessed by selecting "Batch Upload Screenshot Management" on the home page. The process is straightforward: click "Download Template" to generate the directory structure, place screenshot files into the corresponding folders by size, then click upload, and the tool automatically completes classification and matching. The tool automatically categorizes and matches screenshots to corresponding devices based on size, so you don't need to manually specify the position of each screenshot.

If your app does not support iPad, you only need to upload screenshots in 5.5-inch and 6.5-inch sizes to meet the submission requirements. If you don't have actual iPad screenshots, you can generate iPad versions by adjusting the resolution of iPhone screenshots or use screenshots from the simulator. Before uploading, note that screenshots must comply with App Store size specifications. Insufficient resolution or content containing non-public APIs may lead to rejection during review.

Managing Multilingual Screenshots

Managing multilingual screenshots involves a significant amount of work. Each language version requires a corresponding set of screenshots. AppUploader supports storing them in separate categories within the directory structure by language, and processes them together during upload, so you don't need to handle each language separately. It is recommended to use standardized naming and directory management for screenshot files to avoid the pitfall of uploading Chinese screenshots to the English version.

If you have only a few screenshots or are submitting a single-language version, using Xcode to upload directly is sufficient. For projects with multiple languages, multiple sizes, and frequent updates, using a batch upload tool can save a lot of time.

Why Upload Fails After Changing Bundle ID? Old Configuration Residue

CoreDataHero — Wed, 05 Aug 2026 09:29:30 +0000

After changing the Bundle ID, uploads fail. The most easily overlooked aspect is that you changed the Bundle ID in the project, but the certificate, provisioning profile, and App Store Connect records may still be old. Submitting an app to the iOS App Store is not just about the project configuration; it also validates that the Bundle ID in the IPA, the App ID bound to the provisioning profile, the app record created in App Store Connect, and the certificate and provisioning profile all match.
If any one of them still holds the old value, the upload will fail, or the build will not appear in the backend even after a successful upload.

For example, if the project's original Bundle ID was "com.demo.oldapp" and later changed to "com.demo.newapp" in HBuilderX, Xcode, Flutter, or React Native, then repackaged and uploaded, you might see No suitable application records were found or:

Provisioning profile has app ID 'com.demo.oldapp',
which does not match the bundle ID 'com.demo.newapp'

This indicates a mismatch between the IPA and the Apple backend configuration.

First, Check the Real Bundle ID in the IPA

Don't just look at the project configuration files; check the final IPA first.

After unzipping the IPA, check the "CFBundleIdentifier" in Info.plist to see whether it is "com.demo.oldapp" or "com.demo.newapp". If the IPA still contains the old value, the build configuration did not take effect.

Then, Check the App ID Bound to the Provisioning Profile

The provisioning profile .mobileprovision also contains an App ID. If the profile is bound to the old Bundle ID, the signing verification will fail even if the project has been changed to the new value.

You can use AppUploader (Happy Listing) to view the provisioning profile contents:

Open AppUploader
Go to File Viewer or Provisioning Profile Management
Select .mobileprovision
View the bound Bundle ID / App ID

If it still shows the old ID, you need to regenerate the provisioning profile.

Fix Process

1. Create a New Bundle ID in Apple Developer

For example, "com.demo.newapp". You can also add it in Bundle ID Management in AppUploader.

2. Regenerate the Provisioning Profile

In AppUploader:

Open "Provisioning Profile Management"
Create a new provisioning profile
Select App Store as the type
Select the new ID for Bundle ID
Bind the distribution certificate
Download the new .mobileprovision

3. Re-package the IPA

Replace the new Bundle ID and corresponding certificate in the packaging tool, then regenerate the IPA.

4. Create or Select the Corresponding App in App Store Connect

If there is no app record using the new Bundle ID in App Store Connect, the upload will not match correctly. Go to App Store Connect → My Apps → New App, and select the new Bundle ID.

5. Upload the IPA Again

You can use:

Xcode Organizer
Transporter
Fastlane
AppUploader Upload Tool

If uploading from Windows or Linux, you can use the AppUploader CLI.

Judgment Criteria

As long as the "Bundle ID in IPA", "App ID in provisioning profile", and "App record in App Store Connect" all use the latest Bundle ID and are consistent, the upload process will work normally.

Automated IPA Upload to App Store Connect from Linux: Integrating Upload into CI Workflow

CoreDataHero — Thu, 09 Jul 2026 09:47:59 +0000

Many teams encounter a problem when automating iOS releases: the IPA is built on a macOS node, but they don't want to rely on Xcode for the upload process.
Reasons include:

GUI is not suitable in CI environments
Manual operations are too heavy for multi-project uploads
Upload behavior can change after Xcode updates
Linux servers are better suited for running release scripts

Thus, a typical architecture emerges: macOS handles building, Linux handles uploading.
This article focuses on how to automatically upload IPA to App Store Connect from a Linux environment and truly integrate the upload action into the automation workflow.

Decouple Build and Upload

When first setting up CI, many people put IPA generation and App Store upload in the same stage. In reality, these two tasks can be completely decoupled.

The build stage handles archiving, signing, and exporting the IPA, usually on macOS.
The upload stage handles metadata generation, App Store Connect upload, and build submission. This stage can be entirely placed on Linux.

Linux is Better Suited as an Upload Node

If a project has moved to daily builds, multi-environment releases, automated testing, and multi-person collaboration,
Linux advantages become clear.

For example:

Scenario	Linux Advantage
Jenkins	Easy deployment
Docker	Easy isolation
GitLab CI	Mature Runner
GitHub Actions	Easy scripting

GUI upload is hard to maintain in these environments. In real projects, it's common that:

macOS node runs flutter build ipa or xcodebuild archive to generate app.ipa
Linux node receives the IPA, uploads to App Store Connect, and outputs logs

What is Needed for Linux Upload

The upload stage requires:

Item	Purpose
IPA file	Upload payload
Apple ID	Developer account
App-Specific Password	Upload authentication
Upload tool	Submit the IPA

Obtain App-Specific Password

Do not use your Apple login password. You need to create an App-Specific Password in your Apple ID security settings. The upload tool will use this password for authentication.

Upload Tool in Linux Environment

Here we take AppUploader (Happy Upload) CLI as an example.

The Linux version is located at runtime/appuploader_cli. First, grant permissions: chmod +x appuploader_cli

Execute Upload Command

Direct upload:

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

Alternatively:

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

What happens during the upload? The CLI tool will:

Automatically parse IPA information: read Bundle ID, Version, Build Number
Generate metadata: including AppStoreInfo.plist, no manual creation needed
Submit to App Store Connect: after successful upload, Apple begins processing the build

Complete CI Example

Below is a GitLab CI scenario.
Build stage (macOS Runner):

build_ios:
  script:
    - flutter build ipa

Generates:

build/ios/ipa/app.ipa

Upload Stage (Linux Runner)

upload_ios:
  script:
    - chmod +x appuploader_cli
    - ./appuploader_cli upload \
      -f build/ios/ipa/app.ipa \
      -u $APPLE_ID \
      -p $APP_PASSWORD \
      --type ios

Where to Check Results After Upload

Go to App Store Connect → TestFlight. If the upload was successful, the build should appear within a few minutes. If not, check the following:

Check Item	Content
Build Number	Is it incremented?
Bundle ID	Does it match?
IPA Signing	Is it App Store type?
App-Specific Password	Is it valid?

Project Types Suitable for Linux Automated Upload

The following project types are well-suited:

Type	Scenario
Flutter	Automated build
React Native	CI release
Unity	Cloud build
uni-app	Upload after cloud packaging
HBuilderX	Automatic IPA submission

Now many teams adopt:

Task	Tool
Development	Flutter / RN
Packaging	macOS
Upload	Linux CLI
Review Mgmt	App Store Connect

This way:

Linux handles automation
macOS only handles compilation
Release process is easier to maintain

Automated IPA upload to App Store Connect from Linux essentially shifts the iOS release process from GUI to scripting. Once the IPA is generated, the upload can be completed independently via CLI.

What are iOS Development Tools? Practical Tools for Each Stage of iOS Development

CoreDataHero — Tue, 07 Jul 2026 09:58:47 +0000

When organizing an old project some time ago, I counted how many tools I opened in a day.

As a result, I use VSCode for writing code; switch back to Xcode when debugging certain modules; run build scripts when creating test packages; and open another tool when uploading installation packages.

These actions have become habitual, so I rarely think about: what exactly are iOS development tools?

What Developers Face Every Day is a Process

Many articles discussing iOS development tools simply list a bunch of software names. However, from the perspective of the actual development process, tools have different purposes. For example, a typical feature development cycle goes through these steps:

Creating a project
Writing code
Version management
Compiling the application
Running on a device
Debugging issues
Generating an installation package
Uploading for testing

Each step involves different tools.

Writing Code: The Editor Determines Work Habits

For many developers, the most frequently used tool is the editor. Xcode comes with built-in editing capabilities, and Swift projects are almost inseparable from it.

On the other hand, VSCode is becoming increasingly common, especially when maintaining front-end, back-end, and mobile projects simultaneously. Many developers want to minimize editor switching. Syntax highlighting, auto-completion, and plugin support do not change business logic but affect the rhythm of daily coding.

Therefore, choosing an editor is more about choosing a way of working.

Project Management: Project Structure Matters More Than Expected

As the project scale grows, tools take on other responsibilities, such as:

Managing targets
Managing schemes
Managing dependencies
Managing resource files

These tasks are rarely discussed in technical sharing but happen every day. If a project contains both Swift and Objective-C modules, the importance of project structure management becomes even more apparent. Problems encountered during development sometimes stem not from the code itself but from project configuration.

Compilation: The Most Overlooked Step

Many people do not think about what happens behind the scenes when they click the Run button. In reality, a simple compilation action may include:

Parsing the project
Reading configuration
Selecting architecture
Calling SDKs
Linking system libraries
Generating the application

Only after all these steps are complete can the application run. For developers, the compiler is usually unobtrusive, but it determines whether a project can become an executable program.

Device Debugging: The Most Frequent Action in Development

Many features can only be verified on a real device, such as:

Push notifications
Camera permissions
Bluetooth functionality
Location services

Therefore, device debugging happens almost every day. If a page requires repeated modifications and verifications, the cycle of "modify code → run on phone → view results" repeats many times. Whether a tool can shorten this path directly affects the continuity of the development process.

Build and Distribution: Another Process After Development Ends

Many people equate development with writing code. However, after the code is complete, there is a completely different process:

Building the Release version
Generating the installation package
Testing distribution
Submitting for review

The tools involved here are different from those in the development phase. For example, Fastlane is more oriented toward automated builds.

AppUploader is more focused on uploading and distribution. They solve problems that arise after development is complete.

More Developers Are Starting to Focus on Tool Processes

As projects become more complex, a phenomenon gradually appears: the number of tools increases. For example:

VSCode for writing code
Xcode for managing projects
Fastlane for automated builds
AppUploader for uploading installation packages
Git for version management

Each tool is specialized, but the switching cost is real. During development, frequent switching between multiple windows is often necessary. Some teams continue this approach because each tool can maximize its utility. However, some tools are beginning to explore a different path.

A More Integrated Approach

Recently, I came across an iOS development tool called Kxapp.

What caught my attention is not that it supports some new language, but that it attempts to reassemble several parts of the toolchain into a single environment.

Currently, Kxapp supports:

Swift projects
Objective-C projects
Flutter projects

The editor uses the VSCode architecture, so many developers will find it familiar. In addition to code editing, it also includes its own set of compilation tools that can directly handle project building. The ability to run on a real device and build installation packages is also integrated into the same environment.

For developers who need to frequently switch between projects, quickly verify requirements, or maintain multiple technology stacks, this design approach is quite interesting.

It does not change iOS development itself but attempts to reduce the back-and-forth between tools.

If iOS development is understood as "writing code," then the role of tools seems limited. But if development is seen as a process, you will find that:

Editors, compilers, debugging tools, build tools, and distribution tools all participate in the same process.

Different developers make different choices. Some prefer to handle each step separately, while others lean towards using integrated tools. The recently seen Kxapp is one such attempt.

How to handle the error "Metadata validation failed Deprecated Transporter usage." when submitting to iOS App Store

CoreDataHero — Wed, 01 Jul 2026 09:48:46 +0000

Recently, a type of upload error has been occurring frequently, manifesting as:

Metadata validation failed: Deprecated Transporter usage. You are required to use the -assetFile command instead of the -f command with your .ipa or .pkg files. Additionally, to continue uploading apps using the Aspera and Signiant delivery methods, you are required to use Transporter 4.2 or later. (1046)

Some developers encounter this error when:

Xcode upload
altool upload
old version upload scripts
third-party upload tools (e.g., AppUploader old channel; test shows switching to new channel works)

The error is "Metadata validation failed". In fact, the problem is that Apple adjusted the Transporter upload interface and restricted the old upload method.

This article addresses the issues: why it occurs, how to locate the problem, and how to replace the upload method.

What does this error actually mean

Several key terms in the error:

Deprecated Transporter usage: The current upload method has been marked as an old interface by Apple.

use the -assetFile command instead of the -f command: Apple requires a new upload parameter format.

xxxxxxxxxx Transporter 4.2 or later: The old upload component can no longer work.

Which situations are prone to occur

This problem mainly occurs in:

Scenario	Trigger Reason
Old version altool	Using old parameters
Old iTMSTransporter	Version too low
Old upload scripts	Calling deprecated interfaces
Some old upload tools	Bundled old Transporter

IPA is fine, but upload fails

Many people mistakenly think there is a problem with the IPA build or certificate expiration. In fact, checking reveals the IPA is fine and App Store Connect is also normal.

The issue only occurs during upload, meaning the upload protocol is outdated, not the package itself.

The real solution is to change the upload channel. Since the problem lies in the upload protocol and Transporter interface, the core fix is not modifying the IPA but replacing the upload method.

Use AppUploader new channel for upload

This problem appears in the old upload interface.

You can directly use the new channel upload method of AppUploader (Happy App Store Submission).

Steps:

Open the submit upload page, go to Submit Upload
Select IPA, load the already built .ipa
Set Apple App-Specific Password. Note: It is not your Apple ID login password, but an App-Specific Password.
Switch to the new channel: In the upload channel settings, select the new channel and do not use the old channel.
Re-upload. After executing, it will use the new Transporter upload method, and the build can enter App Store Connect normally.

Why does changing the channel solve the problem

The key here is that different channels use different underlying upload components.

Old channel: uses old Transporter parameters

New channel: adapts to Apple's new interface

Therefore, the upload method needs to be updated.

Inventory of iOS App Development Tools: Tools in Real Development Tasks

CoreDataHero — Tue, 30 Jun 2026 01:03:42 +0000

If you treat "what iOS app development tools are" as a list, it's easy to write: Xcode, VSCode, Git, Firebase... But in real development, these tools are used step by step as development progresses.

Suppose you want to make a simple app from scratch. At which stages will you use which tools?

First choose a place to write code when taking on a requirement

After receiving the requirement, the first step is to write code.

Here you encounter the first choice:

Use a full IDE (e.g., Xcode)
Use a lightweight editor (e.g., VSCode)

If you only write Swift code, VSCode can handle basic tasks like syntax highlighting and simple autocompletion. But once project structure and execution are involved, more complete tool support is needed.

Some developers choose an environment that "can write and run" at this step, considering the subsequent steps together.

For example, an iOS development tool like Kuaixie itself includes code editing capabilities (based on the VSCode architecture) and also has subsequent compilation and execution capabilities.

Project structure becomes important as code takes shape

After writing to a certain extent, you will find that code cannot just be scattered files; it needs to be placed in a complete project.

At this point, the tool needs to provide:

Project directory structure
Entry files
Basic configuration

Xcode automatically generates these.

Some new development tools also provide similar capabilities, such as directly generating a standard structure when creating a project, so that the code can be recognized by the build system.

The key here is whether the code already has the conditions to be built.

Compilation tools must be involved when you first want to run the app

When the code reaches a level where it can display a UI, you will want to run it.

This involves compilation:

Swift / Objective-C compilation
Application building
Executable generation

In the traditional workflow, this part completely relies on Xcode.

But there are tools that choose to embed compilation capabilities. For example, Kuaixie provides its own compilation tool suite, completing the build process within the IDE.

The developer's operation becomes click run → IDE executes compilation → app is generated.

Device debugging becomes a core part when you need to verify functionality

After code compilation, you need to run it on a device.

This involves a set of specific actions:

Identify the iPhone
Install the app
Launch the app
View the running effect

If this step is not smooth, it will directly affect development efficiency.

For example, when adjusting UI, every layout change requires re-running the app. If this process takes a long time, it can interrupt your flow.

Some tools make running on a device more direct. For instance, Kuaixie can build and install the app directly after connecting the device, without additional exporting or tool switching.

Multiple technology stacks appear as projects become complex

As the project grows, different types of code appear:

New Swift modules
Old Objective-C code
Introduced Flutter pages

At this point, the requirements for development tools change: they must not only support one language but also handle different project types.

Switching between multiple tools increases context-switching costs.

Some IDEs begin to support unified management of multiple project types, for example, handling Swift, Objective-C, and Flutter projects in one environment.

Build tools reappear when preparing for testing

When the feature is complete, the app needs to be handed over to testers.

This step involves:

Building the app
Generating installation files
Providing distribution methods

In Xcode, this step is done through the Archive and export process.

In some integrated tools, the installation package can be generated directly through the build function.

Kuaixie provides a one-click build capability, generating installation files for testing or distribution.

When breaking down development tasks, it's essentially that different tools solve different problems, and some tools try to solve these problems together.

React Native on the App Store: Project Running and Review Build Process

CoreDataHero — Thu, 18 Jun 2026 10:10:20 +0000

Many React Native projects work fine during development but get stuck when it's time to publish. For example, Xcode can run the project, but Archive fails; an IPA can be generated, but after uploading, there's no build, and TestFlight never shows a version.

These issues are not actually React Native problems, but rather a misunderstanding of the iOS release process.

First, Confirm the Project Has iOS Build Capabilities

First, run locally:

npx react-native run-ios

If it runs successfully, proceed to the next step.

Check the ios Directory

In a React Native project:

The /ios directory is the complete iOS project
The actual packaging is done by Xcode

Enter the directory:

cd ios
pod install

Complete Necessary Configuration in Xcode

Open:

open ios/YourProject.xcworkspace

Configure Bundle ID

Path:

Targets → General → Bundle Identifier

Ensure:

It matches the one in App Store Connect

Configure Version Numbers

Version (CFBundleShortVersionString)
Build (CFBundleVersion)

Each upload:

Build must be incremented

Signing Preparation: React Native Doesn't Do This Automatically

Most RN project build failures are caused by signing issues.

You need to prepare:

Distribution certificate
App Store provisioning profile

Use AppUploader to Generate Signing Files

Using AppUploader (Happy Publishing) can directly generate:

Create a Certificate

Open the certificate management
Click Add New
Select Distribution
Set a name
Set a P12 password
Download the .p12

Create a Provisioning Profile

Enter Profile management
Create a new App Store type
Select Bundle ID
Bind the certificate
Download the .mobileprovision

Import into Xcode

Double-click .p12 to import into Keychain
Double-click .mobileprovision to install

Archive to Build IPA

In Xcode:

Select the device as Any iOS Device
Click Product → Archive

After building:

Open Organizer
Select the newly generated Archive

Export IPA

Choose:

Distribute App → App Store Connect → Export

Export the .ipa file.

Upload IPA (Can be done without Xcode)

Once IPA is generated, uploading can be done without macOS.

You Can Use AppUploader to Upload

Steps:

Open the Submit Upload page
Enter Apple ID
Set an app-specific password
Select the IPA file
Select the upload channel (1 or 2)
Click Upload

Verify After Upload

Go to:

App Store Connect → TestFlight

Wait for Processing to complete.

A Common Issue: Upload Success but No Build

This is relatively common in RN projects.

Check the Build number – is it incremented?

Check the Bundle ID – does it match the one in App Store Connect?

Check the signing type – is an App Store provisioning profile used?

Check the provisioning profile – is it bound to the correct certificate?

React Native Specific Pitfall

If you use third-party libraries (e.g., push notifications, login), note:

Are Capabilities Enabled?

In Xcode:

Signing & Capabilities
Enable the corresponding capabilities (Push, Associated Domains, etc.)

Ensure They Match the App ID

In Apple Developer:

Enable the same capabilities

Otherwise:

Build may pass
Review or runtime may fail

Publishing a React Native project to the App Store is essentially following the iOS native release process.

Getting Started with iOS System Software Development: Don't Just Learn the Language

CoreDataHero — Wed, 17 Jun 2026 09:49:08 +0000

Many iOS beginner tutorials start with Swift syntax, covering variables, functions, UI components, and progressing step by step. But when you're actually ready to write an app that runs on a phone, you quickly encounter another issue: code is only part of the story; the rest involves an entire development workflow.

If you define getting started as being able to run an app on an iPhone, what you need to master is a series of sequential actions, not just isolated knowledge points.

Step 1: Give Code a Place to Exist

The first step in writing an iOS app isn't writing code, but giving the code a recognizable structure.

This involves the concept of a project:

Where is the entry file located?
In which directory are resources stored?
How is the basic configuration of the app organized?

In traditional environments, this step is automatically generated by the IDE. Open the tool, select a template, and you get a complete project.

In Kuai Xie, this process is similar: after choosing a Swift or Objective-C project type, the IDE generates a project structure that can be run directly. Open the file and you can start writing code.

The key point in this stage is whether the written code is in a compilable context.

Step 2: How Code Becomes an Executable Program

After writing the code, the next thing is to make it run.

This step involves the compilation process:

Source code is converted into machine-executable files.
The app is packaged into a system-recognizable format.

For beginners, this process is a "black box," but it always exists.

In some tools, this step requires a full development environment; while in IDEs like Kuai Xie, the compilation tools are built directly into the software. When you click run, the IDE automatically completes compilation and building.

Developers only see a button, but behind it is a complete build workflow.

Step 3: Why It Must Run on a Real Device

Many people complete testing in a simulator, but when it comes to system behavior, performance, or real interactions, running on a real device is necessary.

The key here isn't just running, but connection:

How is the device recognized?
How is the app installed onto the device?
How are modified code changes quickly synchronized?

In Kuai Xie, this capability is integrated within the IDE. After connecting an iPhone, you can directly execute the run operation, and the app will be installed on the device.

For the beginner stage, the more direct this process is, the lower the learning cost.

Step 4: The Feedback Loop After Modifying Code

Writing code isn't a one-time act, but a continuous process of correction.

For example:

Modifying interface layouts
Adjusting button logic
Updating data display methods

Each modification requires recompilation and running to observe changes.

If this loop is interrupted, such as needing to switch tools or reconfigure the environment, it can disrupt the learning pace.

In a highly integrated IDE, this loop is shorter: save code → rerun → view results.

The role of Kuai Xie here is to compress "modify → compile → run" into the same environment.

Step 5: The Significance of Different Tech Stacks in the Beginner Stage

iOS development isn't just one approach.

Besides Swift, there are:

Objective-C (encountered when maintaining legacy projects)
Flutter (a cross-platform solution)

Exposure to multiple project types in the beginner stage isn't for in-depth mastery, but to understand the existence of different solutions.

In a tool that supports multiple project types, you can quickly switch between different projects and observe their structures and running methods.

Kuai Xie supports Swift, Objective-C, and Flutter projects, which can serve as an observation window in the beginner stage.

Step 6: The Step of Building an Installation Package

When app functionality is complete, you need to generate an installation file.

The uses of this file include:

Installing for testers
For internal validation
Submitting to the App Store

This step differs from the development phase; it's closer to the release process.

In some tools, this step requires additional operations; while in an integrated IDE, you can directly generate an installation package through the build function.

Understanding the significance of this step in the beginner stage helps distinguish between the development workflow and the release workflow.

Reference link: https://kxapp.com/blog/21

2026 iOS Release New Trends: Modularization of iOS Publishing Process

CoreDataHero — Sat, 13 Jun 2026 08:47:32 +0000

If we look at the iOS release process from a few years ago, most teams had a relatively fixed approach:

Package on Mac + Xcode
Upload via Xcode or Transporter
Submit on App Store Connect

However, in the past two years, tools have started to change significantly—it's not that a particular tool has become better, but rather that the entire process can be split apart. This article explains a more common modular release approach for 2026.

Breaking the Release Process into Four Modules

When a project enters the release phase, the process can be divided into four stages:

Module	Output
Signing Preparation	p12 + mobileprovision
Building Phase	ipa
Uploading Phase	Build Record
Review Phase	Release Version

Each stage can be completed independently and can use different tools. This modular approach is what many teams are currently implementing.

Signing No Longer Depends on Local Environment

A significant change is that certificates and provisioning profiles are no longer tied to a specific Mac.

In earlier workflows:

Certificates were in Keychain
Provisioning profiles were local
Switching computers required reconfiguration

Now, a more common practice is:

Generate .p12 uniformly
Generate .mobileprovision uniformly
Store them in a team-shared environment

For example, using AppUploader (Happy Release):

Log in to the Apple Developer account
Go to certificate management
Create a distribution certificate
Download .p12

Then:

Go to provisioning profile management
Create an App Store type provisioning profile
Bind Bundle ID and certificate
Download .mobileprovision

These two files become standard inputs, and subsequent processes no longer depend on the device.

Building Shifts from Local Operations to Replaceable Execution

The method of building IPA is becoming more flexible.

Options include:

Local Archive in Xcode
Automated building with Fastlane
Cloud packaging services

For example, with Fastlane:

lane :release do
  build_app(
    scheme: "AppScheme",
    export_method: "app-store"
  )
end

The essence of building is:

Input: Code + Certificate + Provisioning Profile
Output: IPA

Where the build is executed is no longer a critical issue.

Upload Tools Begin to "De-platform"

The change in the IPA upload phase is even more pronounced.

Previously relied on:

Xcode Organizer
macOS Transporter

Now, options include:

Command-line tools
Cross-platform upload tools
CI automated uploads

For example, on Windows or Linux, you can directly use:

appuploader_cli -f app.ipa -u appleid@example.com -p xxxx-xxxx-xxxx-xxxx -c 2

Or use a graphical interface tool to complete the upload.

In AppUploader (Happy Release):

Open the submission upload page
Enter Apple ID
Set up an app-specific password
Select IPA
Switch upload channel
Execute upload

After uploading, the build will enter App Store Connect.

Review Phase Has Little Change, but Inputs Are More Standardized

The review process itself hasn't changed much, but the input information has become stricter:

Privacy policy
Permission descriptions
Test accounts

This information needs to be filled in on App Store Connect.

The process remains:

My Apps → Select App → Select Build → Submit for Review

An Example from Actual Development

A team's actual workflow:

Frontend developed using uni-app
CI runs on Linux
Build on Mac Runner
Upload on Windows

The process is as follows:

AppUploader generates certificates and provisioning profiles
CI downloads certificates
Mac Runner builds IPA
Upload to Linux
Use command-line upload
Submit for review on App Store Connect

In this workflow, no step is forced to be device-bound.

The change in iOS releases for 2026 is not about tool upgrades, but rather process decoupling.