Incorrect Certificate Type

The most common cause of Invalid Signature is packaging with a development certificate. An IPA signed with a development certificate can only be installed on test devices with UDID added, and cannot be submitted for release. Uploading to the App Store requires an IPA signed with a distribution certificate (iOS Distribution).

Check method: In Appuploader's certificate management, view the certificate type. The Development type is a development certificate, while the Distribution type is a distribution certificate. If there is no distribution certificate in the list, create one first. When creating, select iOS Distribution, fill in the name and password, and the tool automatically generates it from the Apple server.

When packaging, you also need to select the corresponding distribution provisioning profile (App Store type), ensuring the certificate referenced by the profile is the distribution certificate.

Certificate and Provisioning Profile Mismatch

A provisioning profile is bound to a specific certificate. If the profile references certificate A, but the actual certificate used during packaging is certificate B, signature verification will fail.

Troubleshooting: Check the contents of the provisioning profile, which includes certificate information and Bundle ID. In Appuploader's provisioning profile management, you can view detailed information of the .mobileprovision file, confirming that the certificate information inside matches the certificate used for packaging. If mismatched, regenerate the profile and select the correct certificate.

Signature Corruption Caused by Re-signing

If an IPA has been unpacked and modified (e.g., code obfuscation or resource replacement) and then re-signed with another certificate, the signature chain may be broken. Especially after code obfuscation, the executable's signature becomes invalid.

After obfuscation tools like IpaGuard process the IPA, the signing process needs to be redone. If you used a development certificate for testing after obfuscation, remember to switch to a distribution certificate and re-sign before release. The certificate types for the new signing must not be mixed.

Missing Private Key

Signing requires two things: the certificate (public key) and the corresponding private key. If only the P12 certificate file is imported on the computer without the corresponding private key, signature verification will fail. When regenerating a certificate in Appuploader, the private key is automatically included, and the generated P12 file should be properly saved. When operating on a different computer, you need to import the original P12 file used to generate the certificate into the tool, rather than regenerating a certificate with the same name.

Re-upload with Appuploader

After fixing the signing issue, increment the version number and re-package. In Appuploader's submission/upload interface, select the new IPA, fill in the app-specific password, and click Upload. After successful upload, wait 10-30 minutes for the build version to appear. If the Invalid Signature error persists, check the specific error code in the email. Apple will send an email to the developer account's mailbox after an upload failure, indicating the specific signing issue.

Other Possible Causes

An app icon containing an alpha channel or a Bundle ID mismatch can also cause signature verification to fail, and such errors usually have more specific descriptions. A Bundle ID mismatch typically results in "No suitable application records found", while icon issues prompt ITMS-90717.

Individual Account

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

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

Company Account

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

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

Enterprise Account

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

Account Registration Process

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

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

What to Do After Registration

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

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

Incomplete Privacy Policy

Apple requires all apps submitted to the App Store to provide a privacy policy link in App Store Connect. If the review feedback says "Your app collects device information but no privacy policy provided," it means the app has network requests or SDKs collecting device information, but the developer has not uploaded a privacy policy.

Solution: Prepare a privacy policy document that explains what information is collected, how it is used, and how user data is stored and protected. You can quickly generate one using a third-party privacy policy generator, or refer to the privacy policies of similar apps. Host the document at a publicly accessible URL (a website page or GitHub Pages works), then fill in the privacy policy link in the app information page on App Store Connect and resubmit for review.

If the app integrates third-party SDKs (analytics, push, or advertising SDKs), these SDKs also collect device information, so you need to disclose this in the privacy policy as well.

IDFA Usage Issues

If the app calls IDFA (advertising identifier) related APIs, Apple requires you to integrate the App Tracking Transparency framework in your code and present an authorization request. When rejected, you will typically see the message "Missing usage description for NSUserTrackingUsageDescription."

Solution: Add the NSUserTrackingUsageDescription description string to Info.plist, explaining the purpose of using IDFA. Then, request authorization via ATTrackingManager at an appropriate time. After making the changes, rebuild the IPA and upload it again.

The Role of Appuploader After Rejection

After modifying the app in response to rejection, you need to resubmit for review. If you only changed information in App Store Connect (such as the privacy policy link or review notes), simply save the changes on the page. If you need to replace the IPA file, Appuploader can quickly handle the upload.

In the upload interface, select the updated IPA, use the original app version number or increment it, wait a few minutes after uploading for the build to appear in App Store Connect, then submit it for review. If you use the command-line version, you can integrate it into the fix workflow to package and upload in one click after modifying configuration and code.

If the build does not appear after uploading, check whether the version number duplicates one that was previously submitted. Apple does not allow the same version number to be submitted twice. You can withdraw the old version’s review in App Store Connect and resubmit with a new version number.

Post-Rejection Handling Process

After receiving the rejection email, first clearly identify the specific reason. Rejections related to device information usually have a fixed solution direction: if a privacy policy is missing, add the policy link; if permission descriptions are missing, add Info.plist descriptions; if SDKs collect information, update the privacy policy. After making changes, reply to the review team in Resolution Center explaining what you modified, and then resubmit. If the issue involves only metadata (description text, privacy policy, etc.), you do not need to repackage; simply update the information in App Store Connect and submit.