DEV Community: UIKit_Ninja

10 Noteworthy iOS Development Tools: From Coding and Debugging to Release and Operations

UIKit_Ninja — Thu, 03 Sep 2026 10:07:34 +0000

An iOS developer's toolchain goes far beyond Xcode and CocoaPods. From coding, debugging, and performance monitoring to security protection, every stage has some tools worth paying attention to. The following 10 are categorized by usage scenario, covering several key stages in the development workflow.

Coding and Project Development

Xcode goes without saying—it is the cornerstone of iOS development, integrating the editor, compiler, and debugger. Its drawbacks are the large installation package (tens of gigabytes), slow startup and indexing—with large projects, even a few lines of code change require a full reload. However, it is irreplaceable for Storyboard editing and Instruments performance analysis.

KXApp is an iOS development IDE based on VS Code. It integrates a compilation toolchain, enabling compilation and signing without installing Xcode on the system. It supports Swift, Objective-C, and Flutter project types, and generates a standardized project structure with one click. When an iPhone is connected via USB, clicking Build installs the app directly on the device, with signing and deployment handled automatically. It is ideal for rapid prototyping, Flutter project validation, and cases where Mac disk space is limited.

VS Code + Swift extension allows writing Swift and Objective-C code with good syntax highlighting and code completion. It works even better with SourceKit-LSP, but compilation and on-device debugging still cannot bypass Xcode's toolchain—ultimately, you still need the xcodebuild command line.

Network Debugging

Charles is the most popular HTTP/HTTPS packet capture tool. After installing its CA certificate, it can decrypt HTTPS traffic. It supports request replay, breakpoint modification, and throttling to simulate weak network conditions. It is sufficient for everyday API debugging, but when facing SSL pinning, you may need to use it with Frida or switch to other tools.

Proxyman has a more modern UI than Charles, making visual configuration of request filtering and rules more intuitive. The macOS and iOS clients work well together, and it supports grouping by domain and advanced search.

SniffMaster supports both proxy capture and direct capture modes. Direct capture connects to an iOS device via USB, requiring no proxy configuration or trusted certificate installation, and it can bypass SSL pinning and mutual TLS authentication. It also supports stream capture to capture TCP/UDP traffic. It is suitable for scenarios where Charles encounters restrictions.

Performance and Debugging

KeyMob integrates performance monitoring panels for CPU, GPU, memory, FPS, etc., as well as real-time log viewing, file management, and crash log symbolication. It works on Windows, Mac, and Linux.

Wireshark is most useful when examining TCP/UDP transport-layer data. With Mac's Remote Virtual Interface, you can capture network traffic from iOS devices, or import pcap files exported by SniffMaster's stream capture for protocol analysis.

Security and Release

IpaGuard performs code obfuscation and resource file renaming directly on the compiled IPA, without requiring the project's source code. It supports multiple platforms including Objective-C, Swift, Flutter, and Unity3D. Running the obfuscation process before release effectively increases the difficulty of reverse engineering and re-packaging.

Appuploader manages iOS certificates and provisioning profiles and uploads IPA files to the App Store on Windows, Mac, and Linux. It supports batch uploading of App Store screenshots and a command-line mode, making it suitable for cross-platform development teams and CI/CD automated release processes.

Choose According to Needs

No single tool can cover all scenarios. Xcode is the main tool, while others are added according to project needs. A more complete toolchain means more ways to solve problems when they arise.

iOS Development IDE Alternatives besides Xcode: Lightweight Development Environment Comparison

UIKit_Ninja — Thu, 03 Sep 2026 09:41:42 +0000

The first reaction to iOS development is to install Xcode, which is no problem. But if you ask developers who have used other IDEs, you may hear different answers—some use VS Code with Swift plugins to write code, some use AppCode (though it has been discontinued), and others use Vim plus command-line compilation in the terminal. The IDE options for iOS development are actually more numerous than you might think, but most solutions have shortcomings in some aspect.

Comparison of Existing Solutions

Xcode is Apple's official IDE, integrating an editor, compiler, debugger, and Instruments performance analysis tools. Its strength lies in the best compatibility within a closed ecosystem, with first-time support for features in new systems and SDKs. The shortcomings are also obvious: the installer is over a dozen gigabytes, startup and indexing take a long time, and when a project becomes large, even changing one line of code requires waiting for the entire workspace to load. Coupled with DerivedData and various caches, a 256G Mac will soon need to free up space.

VS Code with the Swift plugin can write Swift code, providing good syntax highlighting and code completion. However, compilation and real-device debugging of iOS projects cannot bypass Xcode's toolchain—you ultimately need to go back to Xcode or use the xcodebuild command line to compile. This means writing code in the editor, starting compilation in the terminal, and returning to Xcode for debugging, with the toolchain switching between multiple windows.

Remote Mac compilation is another approach: write code with VS Code on Windows or Linux, then SSH into a remote Mac to execute xcodebuild. The coding environment can be freely chosen, but it relies on network stability, and every compilation verification after code changes requires the upload→remote compile→download chain, which affects the iteration pace. Moreover, configuring certificates and signing in a remote environment can also be a sticking point.

KXApp's IDE Approach

KXApp is developed based on VS Code, retaining VS Code's shortcuts, plugin ecosystem, and interface layout at the editor level. Developers accustomed to VS Code can get started without an adaptation period. The difference is that it has a built-in iOS compilation toolchain—it can compile and sign iOS applications without installing Xcode on the system, and there is no need to configure the xcodebuild environment separately.

Project creation supports three templates: Swift, Objective-C, and Flutter. After selecting the type, a standardized project structure can be generated with one click. iOS-side compilation of Flutter projects typically relies on Xcode's underlying toolchain. KXApp directly embeds the relevant support, so opening a Flutter project allows you to run it on a real iOS device. The real-device debugging process is also simplified: connect an iPhone via USB, click one-click build and install, and the tool automatically handles signing and deployment—there is no need to open Xcode's Devices window to configure certificates and provisioning profiles. After debugging, you can package and build directly in the same interface for test distribution or uploading to the App Store.

Which to Choose Depends on the Scenario

Xcode remains a must-have for complex project configuration, Storyboard/XIB editing, and Instruments performance analysis. KXApp is more suitable for rapid prototyping, Flutter project validation, Windows developers participating in iOS coding, and scenarios with limited disk space. Having one more option in the toolchain is not a bad thing; just choose the one that feels convenient for your current scenario.

Common Reasons for App Store Review Rejection: Screenshot Specs and Permission Description Pitfalls

UIKit_Ninja — Wed, 02 Sep 2026 09:27:12 +0000

Anyone who does iOS development has likely encountered this situation: after submitting your app with great effort, you receive an App Store review rejection email the next day with a variety of reasons—incorrect screenshot sizes, missing privacy policy links, unclear permission usage descriptions, and so on. Most rejection reasons can be avoided in advance, without waiting to be rejected before making changes. Here are the common reasons for rejection, categorized and explained with how to fix each.

Screenshots and Metadata Issues

Screenshots are a frequent cause of rejection. Rejections can result from sizes not conforming to App Store specifications, screenshots containing unreleased features, screenshots marked with test environment indicators (such as "beta" watermarks), screenshots inconsistent with the actual interface, or screenshots with incorrect device model labels. These issues can be caught by checking for yourself before submission.

How to fix: Regenerate screenshots at the sizes required by App Store, with one set for 6.5 inches and another for 5.5 inches. If your app supports iPhone only, these two sets are sufficient; if it supports iPad, add an additional set. App Store screenshots do not support transparent backgrounds (alpha channel), so convert transparent backgrounds to opaque before uploading. When batch-uploading screenshots, tools like Appuploader allow you to select multiple images at once and upload them automatically sorted by device size, rather than dragging them one by one on the web page.

Privacy Issues

Missing privacy policy links or incomplete content is a common reason for rejection. If your app collects user data (including via third-party SDKs), you must provide a privacy policy, and the link must be accessible.

How to fix: Prepare a privacy policy page and host it at an accessible URL, then fill in the link in the privacy policy section in App Store Connect. If your app involves third-party SDKs for advertising, analytics, payment, etc., make sure the privacy policy covers these data collection behaviors. If your app has user-generated content (UGC), you also need to provide reporting and blocking mechanisms, as this is also a review concern.

Unclear Permission Purpose Descriptions

When your app uses permissions such as location, camera, contacts, or photo album, you must explain the purpose of each permission in the review notes in App Store Connect. If you simply state "requires permission" without giving reasons, reviewers may reject it for unclear purpose.

How to fix: In the review notes, explain the purpose of each permission one by one, e.g., "Location permission is used to recommend nearby merchants," "Camera permission is used for scanning QR codes to log in." If you use in-app purchases, describe the items and prices being purchased.

Missing Test Account

If your app requires login to access core features, you must provide a working test account and test instructions. If reviewers cannot log in, they will reject the app directly for inability to evaluate functionality.

How to fix: In App Store Connect review notes, provide the test account, password, and a path to demonstrate features. If you use Sign in with Apple, explain its configuration.

Using Deprecated APIs

Using APIs that Apple has deprecated (such as UIWebView) will result in rejection. UIWebView has been removed on newer OS versions.

How to fix: Replace UIWebView with WKWebView. Search your project globally for references to UIWebView and replace each one with the WKWebView API, then rebuild and upload. If your project uses a third-party library that internally contains UIWebView, check whether you need to upgrade the library version. Such issues can be detected early using build warnings before submitting for review.

Essential Knowledge and Process for App Publishing: Certificate Types, Provisioning Profiles, and Submission

UIKit_Ninja — Tue, 01 Sep 2026 09:35:02 +0000

Two weeks ago, I helped a colleague who just started iOS development review his first app submission project. I found that he was completely confused about certificates and provisioning profiles—he couldn't tell the difference between Development and Distribution, nor did he know how to choose between App Store and Ad Hoc profiles. This isn't just his problem; people new to iOS publishing often get confused by these concepts the first few times. This guide breaks down the core knowledge and concepts of each step in the app publishing process.

Developer Account

Before publishing, you need to register an Apple Developer account. A personal account costs $99 per year and displays your personal name on the App Store. A company account also costs $99 per year, requires a D-U-N-S number, and displays the company name. An enterprise account costs $299 per year and is only for internal distribution, not for App Store publishing. A free Apple ID can only be used for real-device debugging and development certificates; it doesn't have publishing permissions. It's troublesome to change the account type after registration, so decide on the display name before submitting. The tax information provided during registration must be genuine; the account becomes active only after approval.

Certificate Types

In the iOS signing system, there are two types of certificates: Development certificates are used for real-device debugging, and Distribution certificates are used for publishing to the App Store. One certificate can be shared among multiple apps, and its validity period follows the annual fee of the developer account. On a Mac, you generate a CSR using Keychain and submit it to the developer portal to download the .cer, then export the .p12 for backup. If you don't have a Mac, tools like Appuploader can create Distribution certificates directly on Windows. The P12 password for the certificate must be recorded separately; if you forget it, you can only regenerate it.

In this guide, the matching relationship between certificates and provisioning profiles is the most common pitfall. Simply put: for App Store publishing, use a Distribution certificate with an App Store profile; for internal testing, use Development or Distribution with an Ad Hoc profile.

Provisioning Profiles

A provisioning profile associates certificates, App IDs, and test devices. There are three types: Development for development and debugging, Ad Hoc for internal testing distribution (up to 100 devices), and App Store for publishing to the App Store. Multiple apps can share the same Distribution certificate, but each app needs its own provisioning profile. When adding new test devices, UDIDs can be automatically read and imported. Selecting the wrong type during archiving will directly cause upload failure, so confirm which type you need before configuring.

Archiving and Uploading

For native projects, in Xcode, go to Product → Archive to export the .ipa. Cross-platform projects (Flutter, uni-app, React Native) each have their own build commands to compile and output the .ipa. When archiving, make sure the Bundle ID matches the provisioning profile and that the version number (CFBundleVersion) is not the same as any previously submitted.

There are several ways to upload: Xcode Organizer and Transporter can only be used on a Mac. fastlane is suitable for teams with a Mac CI for automated releases, but it requires configuring Fastfile and Appfile. Appuploader allows direct IPA upload on Windows and Linux; you can switch channels, enter your password, and upload. It also provides a command-line version for CI integration. After uploading to App Store Connect, wait 5-15 minutes for processing. If the build version doesn't appear, first check whether the version number is duplicated.

Preparing for Submission

After uploading, fill in the app information in App Store Connect: name, subtitle, description, keywords, and privacy policy URL. Upload screenshots in two sizes: 6.5-inch and 5.5-inch. If the app supports iPad, add another set. Screenshots must comply with Apple's guidelines and must not contain unreleased features. Explain the purpose of user permissions in the notes. Provide a test account if login is required. After confirming everything, click Submit for Review and wait for feedback from the Apple Review team.

Detailed Explanation of iOS App Signing Methods: From Certificate Types to Cross-Platform Management Solutions

UIKit_Ninja — Mon, 31 Aug 2026 09:57:56 +0000

I noticed that colleagues who are new to iOS development often have many signing issues—they can't distinguish certificate types, select the wrong provisioning profile, fail to export P12, or lose certificates when switching computers. The iOS signing system indeed has many steps, but once you understand it, it's just a few fixed procedures. Here I'll go through the common signing methods by scenario, and also mention how to handle it in non-Mac environments.

Certificate Types and Provisioning Profiles

In the iOS signing system, there are two types of certificates: Development certificates are used for debugging on real devices, and Distribution certificates are used for releasing to the App Store or Ad Hoc internal testing. Both certificates follow the annual fee cycle of the developer account. When they expire, you just renew and extend; there's no need to regenerate them. If the account expires, the certificates become invalid, but they automatically recover after re-subscription. One certificate can be shared across multiple apps; you don't need to apply for a separate one for each app.

A Provisioning Profile associates certificates, App IDs, and test devices. There are three types: Development for development and debugging, Ad Hoc for internal testing distribution (up to 100 devices), and App Store for release. For App Store submission, you select the App Store type, and the package will be signed with a Distribution certificate.

Signing Process on Mac

The standard process is Xcode Preferences → Accounts, add your Apple ID, and Xcode will automatically manage certificates and provisioning profiles. In most cases, you don't need to handle it manually. When you need to manage it manually, generate a CSR on the Mac using Keychain Access, submit it at developer.apple.com, download the .cer, and import it back into Keychain to convert to .p12. This process is stable for Mac users, but once you leave the macOS environment, it's impossible—Keychain and Xcode don't support Windows or Linux, so it's problematic if someone on the team doesn't have a Mac.

Signing Solution on Windows/Linux

If you don't have a Mac, Appuploader brings certificate management fully to Windows and Linux. Open the certificate management interface in the tool, click Add, select the iOS Distribution type, fill in the name and P12 password, and click OK to generate. The entire process doesn't require touching Keychain or understanding what CSR is. The generated .p12 file can be directly exported to other team members, allowing them to share the same certificate on different computers without each person applying at the Apple Developer portal.

Provisioning profiles are also managed in the same tool: select the corresponding App ID, check the test devices, and click Create. When adding a new device, the UDID can be automatically read from a phone connected to the computer, so you don't have to manually enter that long identifier.

Certificate Sharing and Team Collaboration

The core of a signing file is a .p12 (certificate) plus a .mobileprovision (provisioning profile). After exporting these two files, send them to colleagues, and they can import them into their tool for use. Appuploader supports syncing certificates to the cloud, allowing team members to log in and download them, saving everyone from the hassle of repeated applications. Note that the P12 protection password should be communicated separately and not mixed with your Apple ID password.

Troubleshooting Signing Errors

The most common cause of signing verification failure is a mismatch between the certificate and provisioning profile types. For example, using a Distribution certificate with a Development provisioning profile will cause an error during upload. An inconsistent Bundle ID will also make the signature invalid. When switching computers, if you haven't exported the original certificate and directly use a newly generated certificate to sign an old app, it won't pass verification either. Checking your signing configuration before packaging can save you a lot of backtracking.

iOS App Publishing Tools: Xcode, Transporter, Appuploader

UIKit_Ninja — Thu, 27 Aug 2026 08:57:32 +0000

After app development is complete, publishing to the App Store is the most critical step. The publishing process involves multiple stages such as certificate creation, provisioning profile configuration, IPA packaging, and uploading. Different stages can be completed with different tools, and it is not necessary to rely entirely on Xcode.

Xcode: Full-Process Publishing

Xcode is Apple's official IDE, integrating the complete workflow from coding to publishing. After archiving with Archive, you submit through Organizer → Distribute App → Upload, select the signing method, and upload directly to App Store Connect.

The advantage of publishing with Xcode is the strongest control—compilation parameters, signing configuration, Bitcode processing, and symbol file export are all managed in the same interface. The downside is that it must run on a Mac, the installation package takes up a lot of space, and startup and indexing times are long. If you only open the entire Xcode just to upload an IPA, the cost-benefit ratio is low.

Transporter: Standalone Upload Tool

Transporter is an independent upload application provided by Apple, specifically designed to upload IPAs to App Store Connect. You do not need to open Xcode; you can simply drag the IPA file into it and upload. The interface is simple, with no complex validation steps.

Transporter requires macOS and cannot be used on Windows or Linux. After a successful upload, the build will take 10–30 minutes to appear in App Store Connect. You must enable two-factor authentication on your Apple ID and generate an App-Specific Password in advance.

Appuploader: Cross-Platform Publishing Assistant

Appuploader runs on Windows, Mac, and Linux, covering several key stages of the publishing process.

For certificate management, you can create development and distribution certificates within the tool and generate P12 files. There is no need to open Keychain Access or Xcode. For provisioning profile management, you can create Development and App Store type profiles, binding the Bundle ID and test device UDIDs. Once a device is connected, the UDID is read automatically without manual input.

For IPA upload, simply select the file, channel, and App-Specific Password on the submission interface. If a channel fails to upload, you can switch to another one. If the upload fails due to network issues, you can retry using a mobile hotspot. The command-line version is suitable for integration into CI/CD workflows.

Appuploader also offers batch screenshot upload, allowing screenshots for multiple language versions to be uploaded at once. For projects that require frequent updates, you do not need to upload screenshots one by one on the App Store Connect web interface every time.

Choose Based on Scenario

If your team has a Mac environment, the officially recommended workflow is Xcode Archive packaging plus Transporter upload. If you do not have a Mac environment or need cross-platform operation, Appuploader covers certificate creation, provisioning profile management, IPA upload, and screenshot upload. For CI/CD pipelines, the Appuploader command-line version is recommended for automated uploads.

The preparatory work before publishing is the same regardless of the tool used: ensure the IPA is signed with a distribution certificate rather than a development certificate, the Bundle ID exactly matches the app created in App Store Connect, the version number is unique (increment the build number), and the privacy policy link is configured in App Store Connect. After submission, pay attention to the review feedback sent by Apple to the developer's email, as well as the processing status of the build in App Store Connect. If the build does not appear for a long time, check the error email in your inbox or the ITMS-90189 error caused by uploading with the same version number.

Complete Solution for Uploading IPA to App Store on Linux with React Native

UIKit_Ninja — Wed, 26 Aug 2026 10:03:52 +0000

Teams that develop with React Native mostly use Mac for iOS compilation and release. But there is a scenario that is becoming increasingly common: CI/CD pipelines run on Linux servers, or frontend developers in the team use Linux as their primary system. React Native projects can write code, run Metro dev server, and even build Android APKs on Linux, but the iOS step gets stuck—the IPA file is already compiled on a remote Mac. How can you upload it to the App Store from Linux without tying the upload step to a Mac environment?

iOS Build Workflow for React Native

The iOS build of a React Native project depends on the Xcode environment. The usual approach is to run npx react-native run-ios on a Mac or use Fastlane to archive. If a team has only one Mac as the build machine, RN developers can write React code locally, and after submission, CI pulls the code and builds/uploads it on the Mac.

For Linux developers, if you don't want to tie the upload step to Mac as well, you can decouple the IPA upload process—let compilation be handled by a Mac or a cloud build service, and use a cross-platform tool on Linux to perform the upload.

Upload Solution using Appuploader on Linux

Appuploader provides desktop and command-line versions, both of which support Linux. The desktop version can run on Linux via Wine or directly if a native Linux version is provided, while the command-line version can be directly integrated into Bash scripts.

In the Appuploader desktop version, you select the IPA file, upload channel, and Apple account-specific password on the submission screen, then click upload. It provides multiple upload channels; you can switch when the network is poor. After a successful upload, the build appears in App Store Connect; you can select the build and submit it for review.

The command-line version is more suitable for integrating into the CI/CD pipeline of a React Native project. The command format is: appuploader_cli --upload-app -f Payload.ipa -u user@example.com -p xxxx-xxxx-xxxx-xxxx --type ios. You only need to specify the IPA file path, Apple account, and app-specific password; no GUI is required.

A recommended complete workflow on Linux CI is: compile the IPA on a Mac runner via GitHub Actions or GitLab CI → transfer the IPA artifact to a Linux runner → invoke Appuploader CLI on the Linux runner to upload the IPA. This decouples the build and upload steps in the CI pipeline—building depends on a Mac as a hard constraint, but uploading does not need to be tied to a Mac environment. Linux runners are typically much cheaper than Mac runners, so moving the upload step to Linux can also save some CI costs.

Preparation Before Upload

Regardless of the method, several things must be confirmed before uploading the IPA. The IPA must be signed with a distribution certificate; an IPA signed with a development certificate cannot be submitted for release. The Apple developer account needs two-factor authentication enabled, and an app-specific password must be generated (create it under "Security" → "App-Specific Passwords" in your Apple ID page). The upload-specific password is different from your login password; make sure to record it at least once. The Bundle ID must exactly match the app created in App Store Connect; if not, you will get a "No suitable application records were found" error.

Post-Upload Operations

After the upload is complete, go back to App Store Connect, select the build, and fill in the review information. If the build does not appear immediately, wait a few minutes and refresh. If it still does not appear, check whether the version number is duplicated or whether the network upload channel is functioning properly.

iOS Provisioning Profile Creation and Management: From Type Selection to Device Binding

UIKit_Ninja — Tue, 11 Aug 2026 09:34:47 +0000

Recently, I helped a colleague troubleshoot an issue: the IPA they built kept showing "Unable to Install" on the phone, and Xcode logs didn't reveal any clear error. After investigating, we found that the provisioning profile didn't include the UDID of that test device. This kind of problem is common in iOS development — certificates are fine, code is fine, but if the provisioning profile is misconfigured, the app simply won't run.

What Does a Provisioning Profile Do?

A provisioning profile connects three things: your developer account, your app, and your test devices. It tells the system who signed this app, which services it can use, and which devices it can run on. Every time you build, Xcode or a packaging tool embeds the provisioning profile and certificate into the IPA, and the device verifies this information during installation.

There are two types of provisioning profiles: Development profiles are used for debugging during development, and App Store profiles are used for release and distribution. Development profiles must be bound to specific test device UDIDs, while distribution profiles are not tied to devices — users downloading from the App Store don't require UDID verification.

Creating a Provisioning Profile with AppUploader

In AppUploader's main interface, there's an entry for "Provisioning Profile Management." After clicking "New Provisioning Profile," you need to fill in three core pieces of information: profile name, type, and the corresponding Bundle ID.

For the name, it's recommended to use the project name plus a type suffix for easy identification, such as MyApp_Dev. For the type, choose Development or App Store based on your purpose. Development profiles require you to select test devices — the tool can automatically read the UDIDs of iOS devices currently connected to your computer and add them to the list. If a device isn't in the list, you can also manually enter the UDID to add it.

The Bundle ID is the unique identifier of your app. One provisioning profile can be bound to only one Bundle ID. However, if multiple apps share the same certificate, you don't need to regenerate the certificate for each app — certificates have a many-to-one relationship with apps, while provisioning profiles are one-to-one.

After creation, click Download to generate the .mobileprovision file. You can then select this profile in your packaging tool or Xcode.

Common Issues

If you see "Certificate is empty" when creating a new provisioning profile, first check whether the corresponding certificate type exists in your certificate management. Development profiles require a development certificate, while App Store profiles require a distribution certificate. A type mismatch will also produce the same error.

If a device cannot install the IPA, the most common cause is that the device's UDID is not included in the provisioning profile. Go to Provisioning Profile Management, update the device list, re-download the profile, and rebuild.

Management Recommendations

The validity period of a provisioning profile is tied to its certificate. When the certificate expires, the associated provisioning profile becomes invalid. It's recommended to regenerate the certificate and provisioning profile before the certificate expires to avoid sudden build failures in production. In multi-project environments, you can use AppUploader to manage all provisioning profiles centrally without having to manually log in to Apple Developer Center each time.

How to Solve ITMS-90035 Error: From Signature Chain Troubleshooting to IPA Regeneration

UIKit_Ninja — Mon, 03 Aug 2026 08:15:11 +0000

When uploading to the App Store, ITMS-90035 is a typical signing error. Many people first assume the IPA is corrupted, but in reality, this error is more related to certificates, provisioning profiles, signing methods, and export methods.

Especially in scenarios like Flutter, uni-app, React Native, HBuilderX, and Jenkins automated builds, this error is more likely to occur.

What is ITMS-90035

The error message typically looks like ERROR ITMS-90035: Invalid Signature or This bundle is invalid.

Apple indicates that the uploaded IPA failed signature verification.

Where Does the Error Occur

First, distinguish:

Stage	Belongs to ITMS-90035?
Xcode Archive failed	No
IPA installation failed	Not necessarily
Rejected by Apple after upload	Yes
Processing failed	Very likely

Most Common Issue: Certificate Type Mismatch

This is the most frequent situation in real projects.

For example, using a Development certificate while the upload target is App Store. In this case, the IPA can be generated and may install on a device, but the upload fails.

The correct approach is that uploading to the App Store requires:

Type	Purpose
iOS Distribution	App Store distribution
App Store Profile	App Store upload

Another frequent issue: provisioning profile and certificate mismatch, for example:

Item	Actual Type
Certificate	Distribution
Profile	Development

Or the reverse.

How to Check the Provisioning Profile

Open the .mobileprovision file and focus on:

Field	Content
Name	Profile name
TeamIdentifier	Team
Entitlements	Permissions
ProvisionedDevices	Whether it's a test version
ProvisionsAllDevices	Enterprise version

Check If Bundle ID Is Consistent

An easily overlooked issue: the App ID in the profile does not match the actual Bundle ID used for packaging. For example, profile: com.demo.app, but actual: com.demo.test. Apple will directly deem the signature invalid during upload.

Typical Issues in uni-app Scenarios

In HBuilderX cloud packaging, it's common to see the app identifier in the profile file not matching the package name. The reason is that manifest.json, Bundle ID, and mobileprovision are inconsistent.

Regenerating Certificates

The more time-saving approach to these issues is to regenerate the entire signing chain, including the Bundle ID, certificate, and provisioning profile.

To regenerate in the Windows environment, you can directly use AppUploader, which allows you to manage Bundle IDs, create Distribution certificates, generate App Store provisioning profiles, and upload IPAs in Windows, without relying on Xcode or Keychain.

Step 1: Confirm the Bundle ID

For example, com.company.app, ensure the Apple developer portal, packaging configuration, and Profile are all consistent.

Step 2: Recreate the Distribution Certificate

Do not continue using the old Development certificate.

Step 3: Recreate the App Store Profile

Be careful not to select the Development type.

Step 4: Re-export the IPA

If using Xcode Export → App Store Connect, do not choose Ad Hoc.

Issues in Jenkins / Fastlane Scenarios

In CI environments, it's common to have the certificate present but the private key missing. This manifests as successful uploads locally but failures in Jenkins, due to an incomplete P12.

So you need to verify whether the IPA is actually signed correctly.

Unzip the IPA with the command: unzip app.ipa, then check Payload/App.app to see if _CodeSignature and embedded.mobileprovision exist.

Issues Caused by Upload Tools

Recently, Apple has been stricter about legacy upload protocols. If you see Deprecated Transporter usage, it means the upload tool is outdated or the Transporter protocol has been deprecated.

In this case, upgrade the upload tool or use a new upload channel.

CLI Upload Makes Log Diagnosis Easier

Many errors are hidden in GUI uploads, while CLI makes it easier to see complete logs for metadata, transporter, signing, and upload session. For example:

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

Finally, the issues can be summarized as:

Type	Frequency
Incorrect certificate type	Very high
Incorrect Profile type	Very high
Bundle ID mismatch	Very high
Missing private key	Medium
Outdated upload protocol	Medium
Corrupted IPA	Low

ITMS-90035 essentially means Apple is verifying whether the IPA has a legitimate and complete signature. Therefore, the troubleshooting focus is not on the “upload button” but on whether the certificate, provisioning profile, Bundle ID, and export method are consistent.

Generate AppStoreInfo.plist on Linux and Submit iOS App to App Store

UIKit_Ninja — Tue, 07 Jul 2026 09:57:51 +0000

When handling iOS uploads on a Linux server, many people get stuck on a strange issue: after signing the IPA and waiting to upload, the tool reports a missing AppStoreInfo.plist.

This file is easily misunderstood. It is not a resource file inside the app, nor a configuration file placed in the Payload directory. It belongs to the upload phase data, submitted together with the IPA to App Store Connect.

Confirm that Linux is responsible for uploading

In this workflow, the role of Linux is to receive the already-signed IPA and call a command-line upload tool to submit the package to App Store Connect.
The IPA can come from: Xcode Archive, Fastlane build, Flutter/React Native macOS build node, HBuilderX, or cloud packaging services. Linux does not need to participate in iOS compilation; it only handles the upload.

Why does AppStoreInfo.plist appear during Linux upload?

If you use Xcode's graphical upload workflow, the relevant metadata is handled automatically by Xcode, and we rarely see it.

But on Linux, there is no Xcode and no Transporter GUI. If the upload tool does not automatically generate metadata, you may encounter Missing AppStoreInfo.plist, or the upload step may fail directly.

Such issues do not indicate a damaged IPA or invalid certificate. They mean that the upload lacks the description information required by the App Store.

Manually creating AppStoreInfo.plist is not recommended

Manually creating the plist seems feasible, but the maintenance cost is high. Because:

Metadata fields change as Apple's upload API evolves.
Different upload methods may require different structures.
Errors in manually written fields make debugging more difficult.

If your goal is simply to upload an IPA, manually maintaining the plist is not a stable solution.

Use AppUploader CLI to auto-generate and upload

On Linux, you can use the AppUploader (Happy Launch) command-line tool to complete the upload.

The Linux version of appuploader_cli is located in the runtime directory of the downloaded package.

Navigate to the directory, grant execute permissions first: chmod +x appuploader_cli

Then execute the upload command:

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

You can also use the subcommand syntax:

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

The meaning of the parameters:

-f specifies the IPA file path
-u specifies the Apple developer account
-p specifies the app-specific password
--type ios specifies uploading an iOS app

During upload, the CLI automatically handles the upload metadata, including AppStoreInfo.plist, without the developer needing to generate it separately.

How to integrate into CI

If the Linux node runs in Jenkins, GitLab CI, or other release systems, you can place the upload command in a script:

if [ ! -f build/app.ipa ]; then
  echo "IPA not found"
  exit 1
fi

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

This makes the upload process an automated, repeatable step:

Build system produces the IPA
Linux node checks if the file exists
AppUploader CLI uploads
App Store Connect receives the build

During this process, AppStoreInfo.plist is automatically generated by the upload tool.

Generating AppStoreInfo.plist on Linux is more accurately described as auto-generation during upload, rather than manual creation.

As long as the IPA is signed, using the AppUploader CLI allows direct upload to App Store Connect from Linux, with automatic metadata handling.

What iOS Developer Tools Are Available? Combined Use of Xcode, Fastlane, and kxapp

UIKit_Ninja — Wed, 01 Jul 2026 09:48:04 +0000

If you break down the iOS development process, few people use just one tool for everything.

Writing code, compiling the app, uploading for review, and automating builds—these steps are often spread across different tools. That's why the question "What iOS developer tools are available?" essentially asks: Who does what at each step?

This article places several common tools into the development workflow: Xcode, AppUploader, Fastlane, and Kuaixie (kxapp), examining the role of each.

Writing Code & Project Management: Xcode Remains the Starting Point

Most iOS projects begin with Xcode.

Creating a project, managing targets, configuring signing—these operations are all done within Xcode. It provides a complete environment:

Code editing
Project structure management
Compilation and running
Basic debugging capabilities

In the early stages of a project, this all-in-one tool is straightforward. Open the IDE, create a new project, write code, and run it.

However, as the project grows more complex or when more flexible workflows are needed, developers often start dividing tools.

Upload Code: What AppUploader Does

When an app is ready for testing or review, it enters the upload phase.

This step doesn't involve code—it deals with the installation package:

Select the IPA file
Log in to the developer account
Upload to App Store Connect

Tools like AppUploader solve the upload process. They separate the upload operation from the IDE, making this step more independent.

In some scenarios, such as when someone is only responsible for release and not development, these tools are more straightforward.

Automated Builds: Where Fastlane Comes In

When a project requires frequent packaging, testing, or releases, manual operations become repetitive.

Fastlane's role here is to script these operations:

Automatically build the app
Automatically sign
Automatically upload
Automatically release test versions

Developers only need to execute one command to complete a series of actions.

However, the trade-off is that you need to understand configuration files and command flow. This can be a barrier for developers new to iOS.

When Tools Are Too Fragmented

Putting the tools mentioned above together, you'll notice a pattern:

Writing code in one tool
Uploading in another tool
Automation in the command line

Each step solves a problem, but the overall workflow is fragmented.

For large-scale projects, this fragmentation is reasonable; but in some scenarios, such as rapid development or requirement validation, switching between tools itself becomes a cost.

Kuaixie (kxapp) is more about continuing to fragment tools; instead, it brings some steps back into one environment.

Its capabilities include:

Supporting Swift, Objective-C, and Flutter projects
Providing a code editing environment (based on VSCode architecture)
Built-in compilation tool suite
Directly running on iPhone
App building capabilities

From another perspective, it consolidates tasks that originally required multiple tools into a single IDE.

For example:

After writing code, you can directly build and install it onto a device
After development, you can directly generate an installation package

During this process, there is no need to switch to other tools for compilation or packaging.

Choosing Tools Is Essentially Choosing a Workflow

With more and more tools available, what really needs consideration is not which one is better, but which combination makes the development process smoother.

Some developers prefer to split tools, controlling each step precisely; others prefer to centralize the workflow in one environment to reduce switching.

Both approaches are valid.

The question "What iOS developer tools are available?" has no fixed answer because it depends on how the development workflow is organized.

Xcode, AppUploader, Fastlane, and Kuaixie (kxapp) each solve problems in different stages.

What Flutter Development Tools Are Available? A Practical Guide to Cross-Platform Project Development and Publishing

UIKit_Ninja — Sat, 27 Jun 2026 09:24:24 +0000

If we only list which tools Flutter has, it's easy to list a bunch of names. But how these tools connect with each other is the most time-consuming part in actual development.

Below, from project creation → debugging → building → iOS publishing, each step corresponds to a specific tool, and we explain when and how to use them.

Project Initialization

A Flutter project is created from the command line. Run the following on your system (Windows / macOS / Linux):

flutter create my_app
cd my_app
flutter run

After this step, Android can run directly, and the iOS project will automatically generate the /ios directory.

Tools

Tool	Purpose
Flutter SDK	Core for project creation and building
Dart SDK	Language support

Development Phase

Common choices:

VS Code
Android Studio

Key features:

Hot Reload
Debug panel
Log viewer

For example, in VS Code:

flutter run --verbose

You can see:

Network requests
Rendering logs
Crash information

Dependency Management: pubspec.yaml

Flutter project dependencies are centralized in:

dependencies:
  http: ^1.0.0
  provider: ^6.0.0

Run:

flutter pub get

This step will:

Download dependencies
Update the lock file

If the build fails, check here first.

Building Flutter iOS: Underlying Xcode

Run:

flutter build ipa

Flutter will:

Compile Dart code
Invoke Xcode to build
Generate an IPA

This step depends on:

Certificates
Provisioning profiles

If signing is missing, it will fail directly.

Signing Preparation: Flutter Itself Does Not Handle Certificates

Flutter is not responsible for certificate generation; additional tools are needed.

You can use AppUploader (Happy Release) to prepare the signing environment:

Generate Certificate

Open the tool
Enter certificate management
Create a new certificate (distribution)
Set a password
Download .p12

Create Provisioning Profile

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

Use in Flutter Project

After importing the certificates, Xcode will recognize them, and flutter build ipa can execute normally.

Upload IPA: Flutter Does Not Include Upload Capability

After Flutter builds, you only get an IPA file.

Uploading requires additional tools.

Options include:

Xcode Organizer (macOS)
Command line tool
AppUploader

Upload with AppUploader

On Windows or macOS:

Open the submit upload page
Enter Apple ID
Set app-specific password
Select the IPA file
Select the upload channel
Execute upload

After upload completes:

The build appears in App Store Connect

Screenshots and Resource Preparation: An Easily Overlooked Step

Flutter does not handle App Store assets.

You need to prepare:

iPhone screenshots
iPad screenshots (if supported)
App icon

You can take screenshots using the simulator or use online generation tools, for example:

Adjust resolution to generate iPad screenshots
Use icon tools to generate Assets
Or go to the Appuploader website

Common Pitfalls

In Flutter projects, common errors:

Bundle ID modified but provisioning profile not updated

Symptoms:

Build succeeds
Upload fails or no build appears

Solutions:

Regenerate the provisioning profile
Confirm Bundle ID consistency

Flutter's advantage lies in a unified development experience, but during the iOS publishing phase, you still need to understand Apple's signing and release mechanisms.