DEV Community: iPhoneTechie

Creating iOS Certificates on Windows: Cross-Platform Tools and Workflow Comparison

iPhoneTechie — Mon, 10 Aug 2026 09:26:24 +0000

Recently I helped a new colleague set up an iOS development environment. He was using a Windows laptop and needed to create a development certificate to run tests on a physical device. According to Apple's standard process, you'd normally open Keychain Access on a Mac, generate a CSR, upload it to the Apple Developer Center, download the certificate, and export it as a P12 file. But since he didn't have a Mac, that route was a dead end. After some research, I found that there are actually several different paths to create iOS certificates on Windows.

Traditional Approach: OpenSSL + Apple Developer Center

If you don't want to rely on a Mac, you can use OpenSSL on Windows to generate a private key and CSR. Run openssl genrsa -out key.pem 2048 to generate the private key, then openssl req -new -key key.pem -out CertificateSigningRequest.csr to create the CSR file. Next, log in to the Apple Developer Center, upload the CSR, download the generated .cer certificate, and finally use OpenSSL to combine the .cer and private key into a P12 file: openssl pkcs12 -export -in certificate.cer -inkey key.pem -out cert.p12.

The process works, but it involves four separate steps—generating the private key, creating the CSR, uploading/downloading through the web portal, and converting via command line. If any parameter or path is entered incorrectly, you have to start over. Moreover, the .cer and private key files are paired one-to-one; if the private key is lost or mixed up, the certificate becomes useless. When managing certificates across multiple computers, you have to repeat the export/import process on each machine. In a team collaboration scenario, every new member requires going through the certificate transfer process again, which adds significant communication and time costs.

Using Appuploader on Windows for the Complete Certificate Workflow

Appuploader integrates the entire certificate application process into a visual interface. Open the tool, click "Certificate Management" → "Add," and in the dialog box choose the certificate type: Development Certificate (iOS App Development) for debugging and installation, or Distribution Certificate (iOS Distribution) for uploading to the App Store. Enter a certificate name to distinguish different purposes, and set a P12 password to protect the certificate file. Click Generate, and the tool automatically handles the entire flow—CSR generation, upload to Apple servers, download, and packaging into a .p12 file. No manual command-line operations are required.

The most useful feature is the "Use AppUploader service to sync certificates" option. When enabled, the certificate is uploaded to the cloud and can be downloaded and used on other computers under the same account. Both Windows and Mac machines in the team can access the same certificate, eliminating the need to repeat Keychain import/export on each machine. Certificates generated with a free account are valid for 7 days; paid accounts get one year.

After generating the certificate, you can manage provisioning profiles in the same interface, viewing permission configurations and validity periods. When a device is connected to the computer, the tool automatically reads its UDID and adds it to the test device list, so you don't have to manually enter the 40-character device code on Apple's website.

Points to Keep in Mind

Certificates generated with a free developer account are only valid for 7 days and cannot be uploaded to the App Store. For publishing, you need to enroll in the paid Apple Developer Program. It's recommended to use alphanumeric combinations for certificate names and avoid overly complex P12 passwords to prevent forgetting them—if you forget the password, there's no way to recover it, and you can only regenerate the certificate. One certificate can be used for multiple apps, so there's no need to generate a separate one for each app. It's advisable to use a consistent naming convention to avoid duplicate creation.

If you only occasionally configure certificates, the OpenSSL command-line approach requires no additional tools, though the process is somewhat lengthy. For frequent management of certificates and provisioning profiles across multiple projects, Appuploader's visual interface and certificate synchronization can save a lot of repetitive work, especially in a pure Windows environment.

Jenkins Automatically Upload IPA to App Store: Integrate Release Steps into CI/CD

iPhoneTechie — Fri, 31 Jul 2026 09:09:30 +0000

When Jenkins is used for iOS release, the process can be split into two parts:

The macOS node is responsible for building the IPA.
Jenkins calls a command-line tool to upload the IPA.

If the IPA has already been generated by Xcode, Fastlane, Flutter, or uni-app cloud packaging, Jenkins only needs to handle the upload stage.

Variables to Prepare in Jenkins

Save the following in Jenkins credentials or environment variables:

APPLE_ID=your@email.com
APP_PASSWORD=xxxx-xxxx-xxxx-xxxx
IPA_PATH=build/app.ipa

Here, APP_PASSWORD is an Apple app-specific password, not the Apple ID login password.

Uploading with AppUploader CLI

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

On Linux/macOS, first add execute permission: chmod +x appuploader_cli.

Jenkins Pipeline example:

pipeline {
    agent any

    environment {
        APPLE_ID = credentials('apple-id')
        APP_PASSWORD = credentials('apple-app-password')
        IPA_PATH = 'build/app.ipa'
    }

    stages {
        stage('Check IPA') {
            steps {
                sh '''
                if [ ! -f "$IPA_PATH" ]; then
                  echo "IPA not found: $IPA_PATH"
                  exit 1
                fi
                '''
            }
        }

        stage('Upload to App Store') {
            steps {
                sh '''
                ./appuploader_cli upload \
                  -f "$IPA_PATH" \
                  -u "$APPLE_ID" \
                  -p "$APP_PASSWORD" \
                  --type ios
                '''
            }
        }
    }
}

Coordination with the Build Stage

If Jenkins is also responsible for building, the division of labor can be as follows:

Stage	Tool
Build IPA	Xcode / Fastlane / Flutter
Certificates & Profiles	AppUploader
Upload IPA	AppUploader CLI
Review Submission	App Store Connect

When uploading, AppUploader CLI automatically handles upload metadata, including AppStoreInfo.plist, without manual generation.

Post-Upload Verification

Go to "App Store Connect → TestFlight" to confirm whether the new build appears.

If it does not appear, check the following:

Whether the Build number has been incremented
Whether the Bundle ID is consistent
Whether the IPA is signed with an App Store provisioning profile
Whether the Apple app-specific password is valid

10 iOS Development Tools Worth Following

iPhoneTechie — Fri, 10 Jul 2026 09:16:57 +0000

Once, while troubleshooting a startup crash, I switched between five windows in succession.

Xcode for crash logs, Charles for packet capture, VSCode for configuration files after inspecting request data, and finally repackaging and uploading to TestFlight.

The issue itself wasn't complicated, but the development process had clearly become a workflow.

Today, iOS development can hardly rely on a single tool for everything. Code editing, dependency management, automated builds, device debugging, and release publishing—each phase is gradually being split up.

This article compiles 10 common iOS development tools currently used in practice. They may not all belong to the same category, but each plays a distinct role in real projects.

1. Xcode

No matter how the tool ecosystem changes, Xcode remains the core environment for iOS development.

Many tasks rely on it:

Project management
Interface Builder
Simulator
Certificate management
Device debugging

Even if some developers have started writing Swift with VSCode, the final project build still goes back to the Xcode toolchain.

Especially when handling:

Provisioning Profile
Archive
TestFlight

Xcode still plays a critical role in these processes.

2. VSCode

VSCode is no longer just a web development tool.

Many mobile teams now use it for:

Swift files
Flutter projects
Configuration scripts
Git management

The reason is straightforward:

Unified development context.

If a single project includes frontend, Node services, and Flutter modules, a unified editor reduces frequent switching.

AI plugins, Git plugins, and terminal capabilities also make it increasingly suitable for daily development.

3. Fastlane

Fastlane is more like a tool for automating development actions.

For example:

fastlane beta

It can automatically:

Build the project
Generate IPA
Upload to TestFlight

For teams that need to repackage and test daily, such automation tools reduce repetitive operations.

4. CocoaPods

Although many Swift projects have migrated to SPM, CocoaPods still exists in numerous legacy projects.

Executing:

pod install

generates a workspace, which is then opened with Xcode.

Some older SDKs still depend on CocoaPods, so it won't disappear anytime soon.

5. Swift Package Manager (SPM)

SPM is Apple's official dependency management solution.

Its biggest advantage is being directly integrated into the Swift toolchain.

Many new projects now prefer:

Using SPM to manage libraries
Reducing workspace complexity
Lowering third-party dependency management costs

For pure Swift projects, SPM is becoming increasingly common.

6. Charles

Many API issues don't originate in code, but occur during the request process.

Charles' role in iOS development mainly involves:

Packet capture
Inspecting API responses
Analyzing network requests
Simulating abnormal responses

For example:

A missing field
Incorrect headers
HTTPS request failures

These issues become easier to locate through packet capture.

7. App Store Connect

Strictly speaking, it's not a development tool, but it's indispensable during the release phase.

This includes:

TestFlight management
Review submission
Version information maintenance
Crash log viewing

Many development actions ultimately converge here.

8. AppUploader

Some teams separate the "upload IPA" action.

AppUploader's focus is more on:

Uploading installation packages
Managing the release process

For scenarios where opening a full IDE frequently is inconvenient, it offers a more direct approach.

9. GitHub Actions

CI/CD tools have become increasingly common.

GitHub Actions can automatically execute after code commits:

Compilation
Testing
Building
Uploading

For collaborative projects, automated pipelines have gradually become part of the infrastructure.

10. Kuai Xie (kxapp)

Recently, I came across an interesting iOS development tool: Kuai Xie (kxapp).

It's quite different from the tools mentioned above.

Many tools solve problems in a specific phase, such as:

Fastlane for automation
Charles for packet capture
VSCode for editing

Kuai Xie seems to attempt re-integrating several development phases.

Currently, it supports:

Swift projects
Objective-C projects
Flutter projects

The editor is built on VSCode architecture, with its own integrated iOS compilation toolset.

After modifying a project, you can directly:

Build
Run on a device
Generate an installation package

For those who frequently switch projects or want to reduce tool hopping, such integrated tools are worth paying attention to.

More tools, changing development approaches

Today's iOS development rarely involves "one IDE for everything."

More often, developers combine different tools:

VSCode for coding
Xcode for project management
Fastlane for automated builds
Charles for debugging APIs
GitHub Actions for release workflows

There is no universal answer for tool selection.

Different teams form different workflows.

How to Upload IPA Without Xcode: Automatically Upload IPA to App Store on Windows

iPhoneTechie — Wed, 08 Jul 2026 09:55:16 +0000

Generally, when iOS developers upload an IPA for the first time, they default to opening Xcode and using Archive → Distribute App → Upload. However, once a project enters a continuous iteration phase, this approach gradually exposes several issues:

Uploading must rely on a Mac.
CI environments are not easily integrated.
The upload process is difficult to unify in multi-person collaboration.
Transporter behavior changes significantly after Xcode upgrades.

Especially for cross-platform projects like Flutter, React Native, uni-app, and HBuilderX, the IPA is already generated by other tools. What developers truly need is just a stable way to upload the IPA.

This article specifically discusses practical methods for uploading IPA without Xcode, including:

Uploading on Windows
Uploading on Linux
Command-line upload
Automatic metadata generation
Submitting to App Store Connect

Clarify: IPA Upload ≠ Xcode Build

Many people confuse "build" and "upload," but they are two separate phases.
The build phase handles compilation, signing, and exporting the IPA.
The upload phase handles generating metadata, calling App Store Connect APIs, and submitting the IPA.

In other words, once the IPA is generated, Xcode is not necessarily required for uploading.

Which Projects Are Suitable for Uploading Without Xcode?

The following types of projects are very suitable:

Type	Scenario
Flutter	Codemagic / CI build
React Native	Automated release
uni-app	Cloud build
HBuilderX	Already generated IPA
Unity	Export iOS package
Jenkins	Automated upload
Linux server	No GUI environment

Many Teams Are Moving Away from Xcode Upload

Because Xcode's upload logic depends on:

The current macOS environment
The current Xcode version
The current Transporter version

After upgrades, issues such as "Deprecated Transporter usage" or "Metadata validation failed" can occur. Moreover, handling GUI in CI environments is inconvenient. Therefore, more and more teams are splitting:

Phase	Tool
Build	Xcode / Flutter / Cloud build
Upload	CLI tool

A More Stable Solution: CLI IPA Upload

If the IPA already exists, it can be uploaded directly via the command line.

Here we take the AppUploader CLI as an example.

First, ensure the IPA is signed: verify that an App Store distribution profile and a valid Distribution certificate are used.

Obtain an Apple App-Specific Password (note: this is not the Apple ID login password; it must be created in the Apple ID account management page).

Locate the command-line tool. After downloading AppUploader:

Windows: runtime/appuploader_cli.exe
macOS: AppUploader.app/runtime/
Linux: runtime/appuploader_cli

Uploading the IPA

Directly execute:

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

Alternatively:

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

What does the CLI do during upload? During the upload process, it automatically analyzes the IPA, reads the Bundle ID, Version, Build Number, and automatically generates metadata including AppStoreInfo.plist — no manual creation needed. It then automatically submits to App Store Connect. The entire process requires no Xcode, Transporter GUI, or manual metadata.

CI Scenario

Typical structure: Jenkins builds Flutter with flutter build ipa, then uploads on a Linux node:

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

The version automatically appears in TestFlight. After upload, you can see the build in App Store Connect → TestFlight.

iOS Upload Structure

Now more and more teams split the workflow like this:

Stage	Tool
Development	Flutter / RN / uni-app
Build	Xcode / Cloud build
Certificate Mgmt	AppUploader
IPA Upload	AppUploader CLI
Review Mgmt	App Store Connect

In this way, a Mac is no longer the only entry point, the upload process is easier to automate, and Windows/Linux can participate in releases.

Uploading IPA without Xcode is not about bypassing Apple; it's about separating "build" and "upload" into two independent steps. Once the IPA is generated, uploading can be done entirely via command line.

iOS Development Tools: Beyond IDE Code Writing and App Installation

iPhoneTechie — Mon, 06 Jul 2026 08:00:26 +0000

If you only look at the surface, iOS development tools seem to have just one core. But if you break down the development process, you'll find that each step actually requires different capabilities: how code is edited, how the project is parsed, how the app is compiled, and how the device receives the installation package. These capabilities are usually hidden within a single tool, but once separated, you can more clearly see what each step does.

When you create a new project, what is the tool doing

Many people's understanding of creating a new project stops at clicking a button.

But in reality, this step accomplishes several things:

Generate the project structure
Initialize configuration files
Specify the compilation entry
Create resource directories

These determine whether subsequent code can be compiled correctly.

In some IDEs, these steps are hidden; in tools that support multiple project types, you can see the differences in project structures for different languages.

Kuaixie provides three project types here: Swift, Objective-C, and Flutter. When creating, it directly generates the corresponding structure, ensuring the project is ready to run from the start.

When writing code, how does the tool participate

Entering the editing phase, the tool's role becomes more granular.

For example:

Prompting methods when entering a class name
Auto-completing parameters
Marking syntax errors

These capabilities appear to be editing experience, but they actually affect code correctness.

An editor based on the VSCode architecture breaks these capabilities into plugins and language services. Kuaixie's approach here is to retain this lightweight editing experience while keeping the project structure compilable.

Device connection is not just plugging in a cable

Running an app on an iPhone is not as simple as copying a file.

It involves:

Device identification
Installation protocol
Permission handling
App signing

If any step fails, the app cannot run properly.

Some tools integrate these steps into one action: connect the device and directly execute the run. Kuaixie's approach here is to combine "compilation + installation" so that code changes can be directly synchronized to the device.

A subtle change during debugging

In actual development, one detail affects efficiency: the feedback time after modification.

For example:

Modifying UI
Adjusting logic
Fixing a bug

Each modification requires a rebuild. If the build path is too long, the development rhythm is interrupted. When compilation and running are completed within the same tool, this path is shorter. After code changes, you can directly trigger build and installation, reducing intermediate steps.

Building the installation package: shifting from development to distribution

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

This stage differs from the development stage: the goal is no longer running, but distribution.

The build process outputs an installable file for testing or submission review.

In some tools, this step requires switching to a release workflow; in an integrated IDE, you can directly execute the build operation.

Kuaixie provides build capabilities within the development environment, without the need for additional tools.

ITMS-90704 Icon Error Troubleshooting: Starting from Inside the IPA

iPhoneTechie — Wed, 17 Jun 2026 09:49:44 +0000

During a normal submission process, after uploading the IPA, a prompt was quickly received:

ERROR ITMS-90704: Missing Marketing Icon

There were no crash logs or compilation errors; it was just rejected during upload. If you directly modify configurations for such issues, it's easy to repeatedly trial and error. A safer approach is to first confirm whether the icon is actually present in the IPA.

1. Don't Modify the Project First; Check the IPA Content

Many people's first step is to open Xcode and modify Assets, but a more direct way is to first confirm if the IPA package truly contains the 1024 icon.

You can directly unpack the IPA:

unzip app.ipa -d ipa_tmp

Enter the directory:

ipa_tmp/Payload/YourApp.app/

Then check:

Whether Assets.car exists
Whether AppIcon resources exist

If Assets.car exists but the error persists, further judgment is needed:

Does Assets.car contain the 1024x1024 marketing icon?

2. Common Misconception: Having Icons ≠ Having the Marketing Icon

In Assets.xcassets:

AppIcon contains multiple-sized icons
But the 1024x1024 is a "separate requirement"

Errors typically occur when:

Only sizes like 180 / 120 / 60 are configured
Or the 1024 icon is not correctly packaged

3. Verify Assets.car Content (Key Step)

On macOS, you can use:

assetutil --info Assets.car

Look for in the output whether it contains:

"SizeOnDisk": 1024x1024

If not, it indicates:

The marketing icon was not included during packaging
Or the icon set configuration is incomplete

4. Several Specific Scenarios Where the Issue Occurs

Based on practical troubleshooting, several triggering scenarios can be summarized:

Scenario 1: Icon File Exists but Is Not Referenced

There is a 1024 image in Assets, but:

It was not dragged into AppIcon
Or the corresponding position was not checked

Scenario 2: Using Third-Party Packaging Tools

For example:

HBuilder
Some cross-platform tools

If these tools do not correctly generate Assets.car, it can lead to:

Icons existing
But not being included in the final package

Scenario 3: Icon Format Does Not Meet Requirements

Even with the correct size, it may fail if:

It's not PNG
It uses an alpha channel (in certain scenarios)
The color space is not RGB

5. Repair Process

Step 1: Prepare the Correct Icon

Requirements:

1024x1024
PNG
RGB

Step 2: Regenerate Complete Icon Resources

Manual handling can easily miss sizes; you can directly use tools to generate complete resources.

For example, using the icon generation tool from AppUploader (Happy Upload):

Open the icon generation page
Upload the 1024 original image
Automatically generate all required sizes for iOS
Export Assets.car or icon resources

This helps avoid:

Missing sizes
Naming errors
Format issues

Step 3: Replace Project Icons

In Xcode:

Open Assets.xcassets
Delete the old AppIcon
Import the newly generated icon set
Confirm the 1024 icon is filled

Step 4: Repackage

Execute Archive → Export IPA.

Step 5: Verify the IPA Again

Repeat the first step:

Unpack the IPA
Check Assets.car

Confirm it contains the marketing icon.

6. Checks During the Upload Phase

Before uploading, you can add a check action:

Confirm icon configuration in Info.plist
Confirm Assets.car exists
Confirm Bundle ID is correct

If using a Windows upload tool, such as AppUploader:

Select the IPA
Check files before uploading
Switch upload channels
Submit the upload

This can reduce repeated failures.

ITMS-90704 indicates that the final package lacks a compliant marketing icon, not that the icon is missing.

What are iOS Development Tools? A Tool List Organized by Development Process

iPhoneTechie — Sat, 13 Jun 2026 09:46:09 +0000

If you only look at the surface, the answer to the question of iOS development tools is simple. But once you start writing a project, you'll find that tools are actually scattered across different stages: writing code, managing the project, compiling and running, debugging on devices, and packaging for distribution—each step involves different tools.

Choosing Editors and IDEs for Writing Code

The most basic step is writing code.

Many people directly use a full-fledged IDE, while others opt for lightweight editors:

Xcode: Comes with an editor, project management, and debugging capabilities, offering the highest level of integration.
VSCode: Supports Swift syntax highlighting and code suggestions through plugins, suitable for those accustomed to lightweight editors.
AppCode (JetBrains): Provides stronger code analysis capabilities but relies on the Xcode toolchain.

The differences at this level are more about the "experience of writing code," such as autocompletion, navigation, and plugin ecosystems.

Project Structure and Project Management

Beyond writing code, you need a tool to manage the project structure.

Xcode does this quite comprehensively, handling project configuration, dependency management, and target settings all in one interface.

But the issue lies here: the project structure is tightly bound to the tool itself. Once you switch environments, you need to adapt again.

Some developers try to separate "writing code" and "project management," using an editor for coding and other tools for building.

Compilation and Building: The Key Step from Code to App

After writing the code, the next step is compilation.

This involves:

Swift / Objective-C compilers
Build toolchains
App packaging

Traditional workflows largely rely on Xcode to handle this part.

However, some tools are starting to isolate compilation capabilities, such as embedding the compilation toolchain into the IDE to reduce dependency on external environments.

For example, Kuai Xie has a built-in compilation tool suite that can directly build iOS apps within the IDE without requiring additional installation of Xcode.

Real-Device Debugging: The Most Frequent Operation During Development

After writing code, almost every step requires verification on a device.

The tool capabilities involved here include:

Recognizing iPhone devices
Installing apps
Viewing runtime logs
Quick rebuilds

In traditional workflows, these operations are all performed through Xcode.

Tools like Kuai Xie streamline "connecting devices + running apps" into a more direct operation, allowing code changes to be quickly synchronized to the phone.

This change is particularly noticeable when frequently debugging UI or interactions.

Issues with Tool Switching in Multi-Tech Stack Projects

Nowadays, many projects are not limited to a single tech stack:

Native Swift
Legacy Objective-C modules
Newly integrated Flutter pages

These projects often require support from different tools.

For example, Flutter requires the Flutter SDK, while native projects depend on Xcode. Switching back and forth between environments increases context-switching costs.

Some new development tools are starting to support unified management of multiple project types, such as handling Swift, Objective-C, and Flutter projects within the same IDE.

Kuai Xie directly supports these three types, allowing switching between different projects in one environment.

Building and Distribution: The Final Step Before App Launch

After development is complete, you need to generate an installation package.

This involves:

Building release versions
Generating installation files
For testing or submission for review

Xcode provides a complete workflow, but the steps are relatively fixed.

Some tools simplify this process into a "one-click build," integrating the development and release stages within the same tool.

Kuai Xie also offers app-building capabilities, allowing direct generation of installation packages for distribution.

Different developers combine tools based on their habits, while others choose an integrated tool to handle the entire process.

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

App Bundle ID Management: How to View and Set Bundle ID

iPhoneTechie — Fri, 12 Jun 2026 09:30:02 +0000

In the iOS development workflow, a Bundle ID may seem like just a string such as com.company.app, but when a project enters multi-environment, multi-version, or multi-person collaboration stages, this field frequently becomes a source of problems.

For example:

Test package installation fails
Builds cannot be found after upload
Push certificates do not take effect

These issues are not code problems but rather inconsistencies in Bundle IDs across different tools.

The Role of Bundle ID in the Workflow

Think of the Bundle ID as a main thread running through the process:

Apple Developer: Register App ID
Certificates and provisioning profiles: Bind Bundle ID
Xcode / Build tools: Write to Info.plist
App Store Connect: Identify the app

If any link is inconsistent, problems will arise.

Starting with a Problem

Consider a scenario:

IPA upload succeeds
No build appears in App Store Connect

Investigation reveals:

The Bundle ID used for packaging is com.demo.app.test
The one created in the backend is com.demo.app

This situation does not produce an error, but the build will not appear. Therefore, the key to managing Bundle IDs is unifying the source.

Creating a Bundle ID in Apple Developer

Go to the Apple Developer backend:

Open Identifiers
Click Add
Enter the Bundle ID
Select capabilities (Push, Sign In with Apple, etc.)

Recommendations:

Use reverse domain naming
Do not arbitrarily modify existing IDs

Once an app is live, the Bundle ID cannot be changed.
Or create a Bundle ID in Appuploader

Configuring Bundle ID in the Project

In Xcode:

Open the project
Select the Target
Modify Bundle Identifier

This value will be written to:

CFBundleIdentifier

It will be included when building the IPA.

Binding in Certificates and Provisioning Profiles

The Bundle ID must be bound in the signing system.

In AppUploader (Happy Upload), you can manage it uniformly:

Create Bundle ID

Open the tool
Go to Bundle management
Click Add
Enter the Bundle ID

Select During Provisioning Profile Creation

During provisioning profile creation:

Select the corresponding Bundle ID
Bind the certificate

If the wrong one is selected here:

Packaging will not produce an error
But installation or upload will fail

Bundle ID Management in Multi-Environment Scenarios

In actual projects, multiple environments may exist:

Development environment
Testing environment
Production environment

Different Bundle IDs can be used:

Environment	Example
Development	com.demo.app.dev
Testing	com.demo.app.test
Production	com.demo.app

This allows:

Multiple versions to be installed simultaneously
Testing without affecting the official version

Handling in CI and Automation

In CI, scripts can modify the Bundle ID.

For example, before building:

plutil -replace CFBundleIdentifier -string "com.demo.app.test" Info.plist

This enables generating multiple environment versions from the same codebase.

How to Avoid "Misusing Bundle ID"

A simple check process can be established:

Before Packaging: Confirm Bundle ID in Xcode

During Provisioning Profile Creation: Confirm the Correct Bundle ID is Selected

Before Upload: Unpack IPA and Check Info.plist

App Store Connect: Confirm the Bundle ID Corresponding to the App Record

A Simple Workflow

A project can follow this process for release:

Create Bundle ID in Apple Developer
Synchronize and manage in AppUploader
Create provisioning profile and bind it
Configure Bundle ID in Xcode
Package to generate IPA
Upload to App Store Connect

If the Bundle ID remains consistent throughout, issues like successful upload but no build will not occur.

A Bundle ID may seem simple, but it connects the development, signing, and release workflows.

Reference link: https://www.appuploader.net/blog/233

iOS Certificates Not Working Across Computers? A Complete Guide to Signing Migration

iPhoneTechie — Wed, 10 Jun 2026 09:51:33 +0000

In iOS projects, certificate-related issues often manifest as follows:

Packaging works normally on Computer A
Signing fails after switching to Computer B
Xcode prompts that the private key is missing or the certificate is invalid

Many people initially think the certificate is incorrect, but the problem usually lies in the composition structure of the certificate.

Without understanding this, the same issue will recur when switching devices, collaborating with colleagues, or integrating with CI.

Why Certificates Don't Work

iOS certificates are not a single file; they consist of two parts:

Public key certificate (the .cer file downloaded from Apple's backend)
Private key (generated locally)

These two parts must exist as a pair.

If only the .cer file is imported to a new computer, the following occurs:

The certificate is visible
But signing is not possible
Xcode prompts that the private key is missing

This is one reason why certificates cannot be used across computers.

The Correct Way for Cross-Computer Usage: P12 Files

To make certificates usable across different computers, export a .p12 file.

A .p12 file contains:

The certificate
The private key

Export method (macOS):

Open Keychain Access
Find the certificate
Right-click and export
Select .p12 format
Set an export password

Then import this file on another computer.

Common Failure Scenarios

In actual projects, this situation is often encountered:

Developer A creates a certificate
Sends the .cer file to Developer B
B fails to package after importing

The reason is that .cer does not contain the private key.

Therefore, .p12 must be used.

Another Way to Avoid Keychain Dependency

If someone in the team uses Windows or Linux, they cannot use Keychain Access for export.

In this case, complete certificate files can be generated directly in a tool.

For example, using AppUploader (Happy Upload):

Log in to the Apple Developer account
Open "Certificate Management"
Click to add a certificate
Select the type (development or distribution)
Set the certificate name
Set the P12 password

After generation, directly obtain the .p12 file.

This file can be:

Imported on any computer
Used in CI
Avoid private key loss issues

A Method for Cross-Computer Certificate Synchronization

If there are many team members, certificates can be managed uniformly.

An executable process is as follows:

Step 1: Uniformly Generate Certificates

Have one person create certificates (or use a tool to generate them).

Step 2: Export P12 Files

Ensure they include the private key.

Step 3: Store in a Shared Location

For example:

Private Git repository (encrypted)
Internal file server
CI Secret management

Step 4: Import in Each Environment

On each machine, execute:

macOS: Import to Keychain
CI: Load certificates via scripts

Provisioning Profiles Also Need Synchronization

After certificates are usable across computers, provisioning profiles also need to be synchronized.

Because packaging depends on:

Certificates
Provisioning profiles

Provisioning profiles bind:

Bundle ID
Certificates

If certificates are updated but provisioning profiles are not, signing will fail.

Provisioning profiles can be created and downloaded via AppUploader:

Go to "Provisioning Profile Management"
Create a new provisioning profile
Bind certificates and Bundle ID
Download .mobileprovision

Distribute it together with .p12.

Usage in CI Environments

In CI (e.g., Jenkins / GitLab CI), P12 files can be used directly.

Example process:

Upload .p12 to CI Secret
Import certificates in build scripts
Configure provisioning profiles
Execute packaging

For example, in Fastlane:

import_certificate(
  certificate_path: "cert.p12",
  certificate_password: "password"
)

How to Determine if a Certificate is Complete

After importing on a new computer, a quick verification can be done:

Select the certificate in Xcode
Signing works normally
No prompt for missing private key

If it prompts that the private key is missing, it means a non-P12 file was imported.

The issue of certificates not working across computers is essentially due to the private key not being correctly transferred. When certificates are uniformly managed in .p12 format, such problems can be resolved.

Reference link: https://www.appuploader.net/blog/230

Are There Xcode Alternatives? The Process of iOS Development in KuaiXie IDE

iPhoneTechie — Tue, 09 Jun 2026 10:03:45 +0000

In the iOS development environment, Xcode has always been the core tool. Project management, compilation, and device debugging are largely dependent on it. However, in specific scenarios, such as temporarily verifying an idea or quickly running a project on a new device, the step of setting up the environment in the development workflow can become quite complex.

Recently, while working on a small utility app, I tried a different approach: instead of using Xcode, I completed the entire development process in an IDE called KuaiXie. The goal was simple: to see if project creation, coding, compilation, running, and installation package generation could be smoothly accomplished in an independent environment.

Creating an iOS Project in Another Way

After opening KuaiXie IDE, you can directly access the project creation interface. It offers three project types:

Swift
Objective-C
Flutter

For this test, I selected Swift. After entering the project name and confirming the path, the IDE generates the project structure.

The generated project directory already includes entry files and basic configurations. Opening the code files allows you to start writing logic directly, with no additional initialization steps.

At this stage, there were no issues with missing SDKs or compilation components. The IDE installation includes the necessary development environment, so after project creation, you can proceed directly to the coding phase.

Writing Application Logic in the IDE

KuaiXie's editor is based on the VSCode architecture, with a relatively intuitive interface layout. The left side shows the project file list, the middle is the code area, and the bottom is the output panel.

To validate the development workflow, I wrote a simple page:

A text label to display status
A button to trigger updates

When the button is clicked, it calls a method that reads some local data and updates the interface.

While typing code, the editor provides auto-completion hints. For example, when entering class or method names, a suggestion list pops up. After saving the file, the IDE performs syntax checking; if errors exist, they are marked at the corresponding locations.

Since the editor is based on VSCode, you can directly use its plugin ecosystem, such as code formatting tools or AI-assisted plugins.

Connecting a Device and Running the Application

After writing the code, it needs to be run on a real device.

After connecting an iPhone to the computer, the IDE starts the build process.

This process sequentially completes:

Compiling the source code
Building the application
Installing it on the phone

After the build is complete, the app icon appears on the phone's home screen. Opening the app shows the interface displaying normally.

Clicking the button successfully updates the text label, indicating that the code logic has been executed correctly.

Modifying Code and Re-running

During development, after modifying code, recompilation is needed to verify the effects.

I added a simple processing step to the button-click logic, then saved the code and clicked the run button again. The IDE re-executes the compilation process and installs the new app version.

The app on the phone is updated, and opening it shows the modified effects.

This process is relatively straightforward:

Write code → Click run → IDE compiles → Phone runs the new version

There are no steps for exporting installation packages or manual installation.

Implementation of Compilation Capabilities

Throughout this process, the IDE does not call Xcode.

KuaiXie IDE has a built-in compilation tool suite. After installation, these tools are already configured. When clicking run or build, the IDE calls its internal compilation tools to complete the application build.

This means developers can complete iOS app development without installing Xcode.

For scenarios requiring quick code testing or feature validation, this approach can reduce environment setup time.

Handling Different Projects in the Same Environment

For further testing, I created two more projects of different types:

An Objective-C project
A Flutter project

The project creation method is the same as for the Swift project. After writing a simple page, connecting the device and clicking run, the IDE can complete compilation and install the app for both.

Handling multiple project types in the same IDE can be more convenient when maintaining projects with different technology stacks.

Building Application Installation Packages

After development is complete, installation packages need to be generated.

In KuaiXie IDE, you can generate application installation files through the build function. The IDE executes compilation and outputs the installation package.

Build logs are displayed in the output panel; if compilation issues arise, you can view detailed information here.

The generated installation files can be used for test distribution or app store submission.

In this test project, the development workflow remained relatively simple:

Create project → Write code → Compile and run → Modify code → Recompile → Build installation package

The entire process did not use Xcode.

For developers, this approach can serve as an Xcode alternative, useful for rapid development or feature validation.

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

How to Encrypt React Native iOS Code, Bundle JS, and Obfuscate IPA

iPhoneTechie — Tue, 14 Apr 2026 08:37:35 +0000

When deploying a React Native project to iOS, one detail is often overlooked: although JS code is bundled, it is not unreadable. If you directly unpack the IPA, you can find the .jsbundle file in the resource directory, and after formatting, business logic can still be discerned.

In a React Native project containing payment and membership modules, we specifically performed code encryption and structure hiding. The goal is not absolute protection but to significantly increase the cost of code reading while not affecting application operation.

Handling JS Bundle During React Native Build Phase

When releasing React Native for iOS, a JS bundle file is generated, for example:

main.jsbundle

This file is located at:

Payload/App.app/main.jsbundle

If opened directly, you can see compressed JS, but after formatting, it remains readable.

Generating Compressed Bundle with Metro

During the build phase, you can execute:

npx react-native bundle \
--platform ios \
--dev false \
--entry-file index.js \
--bundle-output main.jsbundle \
--assets-dest ./assets

--dev false disables development mode, reducing debug information.

Further Compression with Terser

After generating the bundle, you can compress it again with terser:

terser main.jsbundle -o main.min.jsbundle

After compression:

Variable names are shortened
Code structure becomes single-line
Readability significantly decreases

Then replace the original bundle with the compressed file.

Handling Critical Strings in JS

In React Native projects, some logic is triggered by strings, for example:

"login_success"
"vip_purchase"
"payment_callback"

If these strings are directly exposed in the bundle, they can still aid in logic analysis.

You can perform a simple replacement before bundling, for example:

"login_success" → "a1b2c3"

This step can be automated with a script, such as a Node.js script for batch replacement.

Note that such replacements must be consistent with business logic; otherwise, they may affect operation.

Viewing React Native Resource Structure in IPA

After building the IPA, you can unpack it to view:

Payload/App.app/

React Native-related content includes:

main.jsbundle
Image resources
Font files
JSON configurations

If the resource directory retains the development structure, for example:

assets/images/vip_banner.png
assets/config/payment.json

These paths themselves are information.

Handling Resources and JS Files at the IPA Level

React Native's bundle and resources are already packaged into the IPA, so they can be processed directly at the IPA level.

Ipa Guard supports unified processing of resource files, including:

JS
JSON
Images
HTML
Audio

After loading the IPA in the tool, go to the resource module and select JS and image types.

After execution:

main.jsbundle → x92kd.bundle
vip_banner.png → a83kd.png

The tool synchronously updates resource reference paths, so it does not affect operation.

Obfuscating Symbols for Native Modules

React Native projects still contain iOS native code, for example:

Native bridge modules
Third-party SDKs
Objective-C / Swift files

These parts remain as Mach-O binaries in the IPA.

Using Ipa Guard, you can obfuscate these symbols:

Class names
Method names
Parameter names
Variable names

For example:

RNPaymentModule → k39sd2
handleLogin → a8d2k1

After obfuscation, viewing the binary with strings shows the original names have disappeared.

Modifying Resource MD5 and Image Features

If multiple applications share the same resources, such as UI icons or background images, you can process the resource MD5.

After enabling image processing options in Ipa Guard:

Image content remains consistent
MD5 values change

This prevents resources from being easily identified by comparison.

Cleaning Up Debug Information

React Native build processes may include log strings.

You can run:

strings AppBinary | grep React

If the output contains debug information, it can be cleaned up during IPA processing.

Ipa Guard supports removing some debug information to make the binary cleaner.

Re-signing and Installation Testing

All IPA modifications cause the signature to become invalid, so re-signing is required.

You can use the command:

kxsign sign app.ipa \
-c cert.p12 \
-p password \
-m dev.mobileprovision \
-z test.ipa \
-i

Alternatively, you can configure certificates directly in Ipa Guard and complete the signing.

After connecting the device, the application will install automatically.

Verifying React Native Operation Status

After installation, key tests include:

Whether JS pages load normally
Whether Bridge calls work correctly
Critical processes like login and payment
Whether dynamically loaded resources succeed

If certain modules are abnormal, you can return to resource or symbol configurations to adjust.

React Native code encryption should not rely solely on JS compression. Bundle processing is only the first step; resource structure, native module symbols, and IPA-level information also affect code exposure.

In practical projects, by handling JS with Metro + terser and combining Ipa Guard for IPA resource obfuscation and binary symbol processing, overall security can be enhanced without modifying the source code structure.

Reference link: https://ipaguard.com/tutorial/zh/1/1.html

iOS mobileprovision Profile Management: Creation, Download, and Content Viewing

iPhoneTechie — Tue, 14 Apr 2026 08:36:26 +0000

In iOS development, provisioning profiles are rarely explained in detail, yet they are involved in almost every packaging, installation, and submission.

Many issues that appear as installation failures or signing errors are actually due to misconfigured provisioning profiles. If profile management isn't clarified, problems will persist later.

Role of Provisioning Profiles in the Submission Workflow

In the iOS workflow, provisioning profiles occupy a middle position:

Upstream: Certificate + Bundle ID
Downstream: IPA packaging + installation + submission

Their role can be understood as binding the certificate, Bundle ID, and environment together.

Therefore, if the wrong provisioning profile is selected, everything downstream will fail.

Hypothetical Scenario

An app has been successfully packaged, but an error occurs when installing it on a device, with no obvious error in Xcode.

This situation is likely not a code issue but a provisioning profile problem:

Using a Development provisioning profile for App Store packaging
Or the device is not included in the provisioning profile
Or the provisioning profile is bound to the wrong certificate

Thus, the first step in managing provisioning profiles is not creation but clarifying their purpose.

How to Choose Provisioning Profile Types

In practice, only two types need to be distinguished:

Type	Usage Scenario
Development	Local debugging / test installation
App Store	Submission for review / distribution

If the current goal is "distribution," there's no need to consider device UDIDs or select the Development type.

Creating Provisioning Profiles in Tools

In AppUploader (Happy Upload), provisioning profiles can be created directly without relying on Xcode or web backends.

Specific steps are as follows:

1. Access Profile Management

Open AppUploader and click "Profile Management."

2. Create a New Provisioning Profile

Click "Create New Profile" and fill in:

Profile name (custom, for distinguishing environments)
Profile type (select App Store or Development)
Bundle ID (must match the project)

If the Bundle ID doesn't exist, it can be added directly in the tool.

3. Bind Certificate

Select the previously generated certificate:

Development provisioning profile → bind development certificate
App Store provisioning profile → bind distribution certificate

If "certificate is empty" appears, it means:

The account lacks a certificate of the corresponding type
Or the certificate hasn't been created yet

Return to certificate management to add it.

4. Handle Test Devices (Development Only)

If creating a Development provisioning profile:

Need to check test devices
If a device doesn't exist, add its UDID first

Skipping this step will cause installation to fail directly.

5. Download Provisioning Profile

Click download to get the .mobileprovision file.

This file will be used during the packaging phase.

How to Verify if a Provisioning Profile is Correct

After generating a provisioning profile, a simple verification can be done:

Method 1: View Content

Parse the .mobileprovision file to confirm:

If the Bundle ID is correct
If the certificate matches
If the type is App Store

Method 2: Actual Packaging Test

Import the provisioning profile into packaging tools:

Xcode
HBuilderX
CI environment

If packaging succeeds and installation works normally, the provisioning profile is correctly configured.

Provisioning Profiles and Multi-Tool Collaboration

In real projects, provisioning profiles don't exist in isolation but work with multiple tools.

For example:

Xcode → uses provisioning profiles for signing
Fastlane → loads provisioning profiles during automated builds
AppUploader → creates and manages provisioning profiles
CI → uses provisioning profiles for automated packaging

If provisioning profiles are managed uniformly, it can reduce issues like:

Multiple people using different provisioning profiles
Certificate mismatches
Inconsistent packaging environments

Several Easily Overlooked Details

1. Provisioning Profile and App Have a One-to-One Relationship

One app corresponds to one provisioning profile; reuse is not recommended.

2. Certificates Can Be Reused, but Provisioning Profiles Should Not Be Misused

The same certificate can be used for multiple apps, but provisioning profiles must be bound to specific Bundle IDs.

3. Distribution Only Requires App Store Provisioning Profiles

No devices or UDIDs are needed.

Provisioning profiles themselves aren't complex, but they connect certificates, apps, and distribution environments. Therefore, proper management is essential.

Reference link: https://www.appuploader.net/tutorial/zh/5/5.html