Forem: ObjC_Coder

Upload iOS Apps via Command Line on Linux: Fastlane + AppUploader (Happy Uploading)

ObjC_Coder — Fri, 20 Mar 2026 10:32:35 +0000

Many teams run their CI or release environments on Linux servers, such as GitLab Runner, Jenkins, or self-built build nodes. After the app has generated a .ipa file, the next question is: Can the IPA be directly uploaded to the App Store from Linux?

The answer is yes, with the key being to separate the processes—building the IPA and uploading the IPA are not the same thing.

Below explains how to complete the iOS upload process via command line on Linux.

1. Prepare Files Required for Release

Before uploading from Linux, three files need to be prepared:

File	Purpose
`.ipa`	iOS app installation package
`.p12`	iOS distribution certificate
`.mobileprovision`	App Store provisioning profile

These files can come from different sources:

Mac build environment
CI build system
Cloud packaging services

If the team does not have a Mac, certificates and provisioning profiles can also be generated in Windows or Linux environments using AppUploader (Happy Uploading).

General process for generating certificates:

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

Process for creating provisioning profiles:

Go to provisioning profile management
Create a new App Store type
Bind the Bundle ID and certificate
Download the .mobileprovision file

These files will be used during the packaging or CI build phase.

2. Build IPA in CI or on Mac

Linux environments typically only handle releases, not building iOS apps.

IPA can be generated in the following ways:

Using Xcode

Execute on Mac:

Product → Archive

Then export the App Store type IPA.

Using Fastlane

If the project uses Fastlane, it can be built via script:

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

Execute:

fastlane release

Generate the .ipa file.

After building, upload the IPA to the Linux server.

3. Install Upload Tool on Linux

Upload tools from Xcode cannot run on Linux, but command-line upload tools can be used.

One way is to use AppUploader CLI.

After downloading AppUploader, the command-line tool can be found in the compressed package.

Confirm the command is executable:

chmod +x appuploader_cli

4. Upload IPA Using Command Line

Execute on the Linux server:

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

Parameter explanation:

Parameter	Meaning
`-f`	IPA file path
`-u`	Apple Developer account
`-p`	App-specific password
`-c`	Upload channel

Channel explanation:

1 Old upload channel
2 New upload channel

After successful upload, the command line will return the upload status.

5. View Build in App Store Connect

After uploading, go to App Store Connect:

My Apps → App → TestFlight

Wait for Apple to process the build.

After processing is complete:

New build version can be seen
TestFlight distribution is possible
Submission for review is possible

6. Automate Upload in CI

One advantage of Linux command-line upload is direct integration into CI.

For example, Jenkins Pipeline:

stage('Upload IPA') {
    sh '''
    ./appuploader_cli \
    -u $APPLE_ID \
    -p $APP_PASSWORD \
    -c 2 \
    -f build/app.ipa
    '''
}

CI automatically uploads after building is complete.

7. Common Issue Troubleshooting

Build Not Appearing in App Store Connect

Check:

Whether Bundle ID is consistent
Whether build number is incremented
Whether Distribution provisioning profile is used

Upload Failure

Confirm:

App-specific password is correct
Network is not blocked
IPA file is not corrupted

8. Summary of Linux Release Process

If the process is organized into a tool combination, the structure is as follows:

Phase	Tool
Certificate Generation	AppUploader
Provisioning Profile Generation	AppUploader
IPA Building	Xcode / Fastlane
Command-line Upload	AppUploader CLI
Review Submission	App Store Connect

iOS app upload process is not necessarily tied to macOS.
If the IPA file is already generated, the upload phase can be completely done via command line in Linux environments.

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

Complete Guide to Apple App Store Submission Process: From Developer Registration to Happy

ObjC_Coder — Thu, 04 Dec 2025 04:47:30 +0000

Compared to the relatively open Android market, the Apple App Store's submission process is strict and systematic.
For developers, understanding the Apple App Store submission process not only increases the approval rate but also avoids multiple rejections due to signing, privacy policy, or screenshot issues.

With the rise of cross-platform development, more developers want to complete iOS submission in Windows or Linux environments. The new Happy Submission (Appuploader) command-line tool (CLI) is designed for this purpose.

1. Basic Process of Submitting an App to the Apple App Store

The Apple App submission process consists of 6 core stages:

Stage	Content
Stage 1	Register an Apple Developer account
Stage 2	Create App ID, apply for signing certificates and provisioning profiles
Stage 3	Package and generate an IPA file
Stage 4	Configure app information in App Store Connect
Stage 5	Upload the IPA file (can use Appuploader)
Stage 6	Submit for review and release

Below, we will break down each step in detail.

2. Register an Apple Developer Account

Register on the Official Website

Visit the Apple Developer official website, log in with your Apple ID, and click "Enroll" to join the developer program.

Pay the Annual Fee

Registering as an individual or company account requires paying an annual fee of $99 (approximately 699 RMB).

Account Type	Suitable For	Features
Individual Account	Independent developers	Simple registration, fewer permissions
Company Account	Enterprise teams	Supports multi-user collaboration and role assignment

After registration, you can log in to App Store Connect.

3. Create Signing Certificates and Provisioning Profiles

The Apple system requires all submitted apps to use valid signing certificates.

Type	Function
Development Certificate	For real device debugging
Distribution Certificate	For App Store submission
Provisioning Profile	Binds certificates and App ID

Use Happy Submission (Appuploader) to Create Certificates with One Click

No Mac or Keychain required.

Advantages:

Supports Windows / Linux / macOS;
One-click generation of certificates and provisioning profiles;
Can be shared among multiple users;
Completely eliminates Mac environment dependency.

4. Package and Generate an IPA File

IPA is the final release package for iOS apps.

Framework	Packaging Method
Native iOS (Xcode)	Use Xcode → Product → Archive → Export IPA
uni-app / HBuilderX	Cloud packaging to generate IPA, no Mac required
Flutter / React Native	Command-line build + signing export
Cordova / Ionic	CLI build followed by IPA upload

If you don't have a Mac, you can use HBuilder cloud packaging + Happy Submission CLI to complete the entire process.

5. Configure App Information in App Store Connect

Click "My Apps" → "+" to create a new app; fill in the following information:

Information Item	Description
App Name	Up to 30 characters, cannot be duplicate
Bundle ID	Must match the certificate
SKU	Internal tracking number
App Category	Select an appropriate category (e.g., Education, Utilities)
Language and Region	Determine the app's language version

Also upload required content such as screenshots, app icon (1024×1024 PNG), and privacy policy link.

6. Upload IPA to the App Store

Traditional Method (Mac Users Only):

Upload via Xcode
Drag-and-drop upload via Transporter App
Command-line using altool / Fastlane (requires Xcode environment)

This makes submission difficult for non-Mac users.

Cross-Platform Solution: Happy Submission (Appuploader)

The new command-line tool supports Windows, Linux, macOS across all systems, allowing IPA upload to the App Store without a Mac.

Example command:

appuploader_cli -u ios@team.com -p xxx-xxx-xxx-xxx -c 2 -f ./release/MyApp.ipa

Parameter	Description
`-u`	Apple Developer account
`-p`	App-specific password (not login password)
`-c`	Upload channel (1=old channel, 2=new channel)
`-f`	IPA file path

Key Features:

Supports multiple systems;
Stable upload with automatic retry;
Does not carry Mac device information;
Can integrate into CI/CD automation pipelines;
Provides detailed upload logs.

7. Submit for Review and Release

After upload, return to App Store Connect:

Fill in app description, keywords, and supported device information;
Select build version → submit for review;
Wait for Apple review (typically 1–3 business days);
After approval, the app is automatically released globally on the App Store.

If rejected, App Store provides detailed reasons, and you can modify and resubmit.

8. Common Review Rejection Reasons and Suggestions

Reason	Description	Solution
Incomplete Privacy Declaration	Missing permission descriptions	Add fields like NSCameraUsageDescription in Info.plist
App Crashes	Program crashes	Fix issues through real device testing
Use of Non-Public APIs	Calling unauthorized interfaces	Replace with official APIs
Non-Compliant Screenshots	Size or display issues	Use 5.5" + 6.5" size screenshots
Duplicate App	Multiple versions of similar apps	Merge features and resubmit

9. Automated Submission Practice (Fastlane + Happy Submission CLI)

Development teams can simplify the submission process using automation tools.

# Build IPA
fastlane gym --scheme "MyApp" --output_directory "./build"

# Upload IPA
appuploader_cli -u dev@icloud.com -p xxx-xxx-xxx-xxx -c 2 -f ./build/MyApp.ipa

Can be integrated into Jenkins, GitLab CI, GitHub Actions for fully automated build and upload.

The Apple App Store submission process may seem complex, but the core logic is clear: account → certificates → packaging → upload → review → release.
Reference tutorial: https://www.applicationloader.net/tutorial/zh/1/1.html

Engineering Troubleshooting and Tool Combination for App HTTPS Packet Capture

ObjC_Coder — Fri, 28 Nov 2025 09:50:12 +0000

In mobile application debugging and online troubleshooting, app HTTPS packet capture is a fundamental skill for identifying network, authentication, and encryption issues. When encountering problems such as "unable to capture packets," "HTTPS handshake failure," or "request inconsistency with the server," engineers should troubleshoot in the order of network layer → TLS layer → application layer, and flexibly combine proxy tools, low-level packet capture, and data export methods. Below, we provide actionable processes, common commands, tool responsibilities, and an alternative packet capture solution Sniffmaster, explaining how to use tools to complete a full analysis chain with practical feature points.

I. First Define the Goal: What to Capture and Where
Before packet capture, clarify: Are you looking at the TCP three-way handshake (connectivity), TLS handshake (certificate/ALPN/Alert), or the application layer HTTP/2/1.1 request body and headers (signature, Cookie, CORS)? Prioritize capturing at the location closest to the issue occurrence (client proxy or edge/origin server capture), and record the reproduction time, device IP, and request-id to align with logs.

II. Tool Responsibilities and Combined Usage (Packet Capture Tool Matrix)

Proxy tools (Charles / Fiddler / Proxyman / mitmproxy): Used for decrypting HTTPS, breaking and modifying requests, and quickly verifying headers/body. Suitable for development environments or test devices where CA can be installed.
Low-level packet capture (tcpdump / tshark / Wireshark): Capture -s 0 pcap files at the gateway or backend for analyzing the three-way handshake, retransmissions, and TLS ClientHello/ServerHello. This provides authoritative evidence to determine if requests reach the backend.
Scriptable tools (pyshark / scapy / mitmproxy scripts): Suitable for batch statistics on TLS Alerts, automated replay, and continuous monitoring.
Alternative packet capture solution, Sniffmaster: When proxies are unavailable, apps use certificate pinning, or specific network policies block capture, it can filter traffic by App/domain and export pcap and single-packet binary files, supporting HTTPS decryption and mTLS/pinning analysis assistance, facilitating frame-by-frame comparison with backend pcap files.

III. Reproducible Troubleshooting Process (TCP → TLS → HTTP)

TCP layer: Confirm connectivity and port listening. Common commands:

nc -vz api.example.com 443
sudo tcpdump -i any host <client_ip> and port 443 -s 0 -w /tmp/cap.pcap

Check for excessive SYN, RST, or retransmissions.
\2. TLS layer: Check ClientHello (SNI, cipher), ServerHello, certificate chain, and TLS Alert:

openssl s_client -connect api.example.com:443 -servername api.example.com -showcerts

Filter for tls.handshake.type==1 and tls.alert_message in Wireshark. If incomplete chains, OCSP issues, or ALPN mismatches are found, prioritize fixing the certificate chain and stapling.
\3. Application layer: Use proxies to view HTTP/2 frames or HTTP/1.1 requests when decryption is possible, verifying signatures, timestamps, request body order, and header differences.

IV. Common Challenges and Solutions (App HTTPS Packet Capture Scenarios)

Certificate pinning / Custom TLS: Browsers can capture, but apps cannot; temporarily disable pinning in test builds or use alternative solutions that export pcap to export app traffic and compare with backend pcap files.
HTTP/3 (QUIC): QUIC is UDP-based and bypasses TCP proxies. When encountered, force fallback to TCP+HTTP/2 on the client or server for reproduction and capture.
Partial network/ISP issues: Collect affected users' ASN and region, capture edge pcap files, and compare certificate Issuers with app-exported pcap to determine if intermediate substitution or transparent proxies exist.

V. Alternative Packet Capture Process When Proxies Are Not Feasible
When proxies cannot decrypt or be configured, capture packets at the backend and simultaneously export app traffic as pcap, then analyze side-by-side in Wireshark: align timelines, compare ClientHello SNI, ServerHello and certificate chains, and check tls.alert.
Sniffmaster provides the ability to filter by App/domain, export Wireshark-compatible pcap and single-packet binary files, and supports interceptors and JavaScript scripts to modify requests/responses, significantly improving analysis efficiency in complex scenarios (use within compliance boundaries).

VI. Interception and Automated Modification (Advanced Debugging)
During development debugging, interceptors can temporarily modify request parameters or response bodies to verify fixes. Packet capture tools supporting JavaScript scripts can run custom logic at breakpoints, enabling automated test scenarios such as batch replacement of signature fields or simulating failure responses, facilitating quick identification of root causes.

Packet capture files often contain sensitive data (Tokens, personal information). In production environments, packet capture must have approval, limited time windows, and exported files should be encrypted, anonymized, and regularly destroyed. When delivering analysis conclusions, include: reproduction time window (second-level), relevant pcap files, Wireshark key frame screenshots, conclusions, and actionable repair suggestions (e.g., patch fullchain, adjust proxy/firewall, update client pin configurations).

Which IPA Encryption Tool is Good?—Multi-Tool Comparison and Implementation Recommendations for Engineering-Oriented Delivery

ObjC_Coder — Thu, 20 Nov 2025 10:34:16 +0000

For teams looking to "truly harden" their iOS applications, the challenge is not about finding the "most magical" tool, but rather selecting a tool combination suited to their delivery model and operational capabilities, and turning hardening into a reusable engineering capability. This article avoids flashy marketing and instead, from an engineering practice perspective, compares several common types of IPA encryption/obfuscation tools in terms of capabilities, pros and cons, and applicable scenarios, providing implementation recommendations and typical pipelines for direct reference by development/security/operations teams.

1. Clarifying the Problem First: Why There's No Single Answer to "Which Tool is Best"

Tool selection depends on several dimensions:

Access to Source Code: If source code is available, prioritize compile-time obfuscation (deeper protection); if not, only product-level obfuscation on the IPA can be performed.
Team's Operational Capability: Whether the team can maintain CI, KMS, approval processes, and rollback mechanisms.
Compatibility Requirements: Whether hot updates, third-party SDKs, or hybrid frameworks (Flutter/React Native/H5) are used.
Audit and Compliance: Whether mapping tables and keys require strict auditing and multi-copy backups.

Therefore, the definition of "good" should be: maximizing reverse engineering costs while preserving rollback and symbolization capabilities, under the premise of ensuring stability and maintainability.

2. Tool Categories and Pros/Cons (Engineering Perspective)

Source Code-Level Obfuscation Tools (e.g., Swift layer/compiler plugins) Pros: Can rename, encrypt strings, perturb control flow; high protection depth; controllable performance impact. Cons: Requires source code modification and compilation verification; ineffective against third-party/outsourced packages. Applicable Scenarios: Teams with self-developed, controllable source code.
Product-Level IPA Obfuscation Tools (operating on compiled IPAs) Pros: Can harden without source code, suitable for outsourced deliveries and historical versions. Can modify class names, resource names, perturb MD5, and output mapping tables. Cons: Requires strict management of whitelists and mapping tables; prone to crashes due to mis-obfuscation; requires additional handling for hot updates. Applicable Scenarios: Situations where source code is unavailable or secondary hardening of deliverables is needed. Representative Approach: Export symbols → edit mapping strategy → specify symbol file for obfuscation → re-sign and test (demonstrated below with Ipa Guard CLI).
Runtime/Dynamic Protection and Detection (anti-debugging, anti-injection, integrity checks) Pros: Adds real-time detection capabilities, can detect injection or tampering at runtime. Cons: Cannot replace static obfuscation; may hinder testing or debugging; requires switches. Applicable Scenarios: Supplementary measures against tools like Frida/LLDB.
Automation and Governance Platforms (CI, signing, KMS, crash symbolization) Pros: Turns hardening into a delivery capability, manages mapping tables and approvals, and supports rollback and symbolization. Cons: Requires operational investment and institutional setup. Applicable Scenarios: Medium to large teams or products with high compliance requirements (e.g., finance, government).

3. The Role of Ipa Guard (Product Hardening) in the Engineering Pipeline and a Practical Introduction

If your delivery form is "only receiving the IPA," product hardening tools are essential. Taking Ipa Guard's command-line mode as an example (engineering-friendly), the typical process is as follows:

Export Obfuscatable Symbols

ipaguard_cli parse game.ipa -o sym.json

After export, sym.json contains fields like confuse, refactorName, fileReferences for each symbol, facilitating decisions on which symbols can be modified and which need to be retained.

Edit the Symbol File (Critical)

Set confuse:false for non-obfuscatable bridging/Storyboard/hot-fix interfaces;
Modify refactorName (keep length unchanged, avoid duplicates);
Note references to H5/JS files in fileReferences, replace strings or exclude as necessary.

Obfuscate the IPA with the Specified Symbol File

ipaguard_cli protect game.ipa -c sym.json --email you@addr.com --image --js -o confused.ipa

Parameters like --image (modify image MD5) and --js (obfuscate JS) are useful in hybrid app scenarios.

Re-sign and Test on Real Devices

kxsign sign confused.ipa -c cert.p12 -p pwd -m dev.mobileprovision -z out.ipa -i

Always perform regression testing on all critical paths (launch, login, payment, hot updates) on real devices using development certificates before release.

Archive and Govern Mapping Tables Encrypt and upload the final sym.json and generated mapping tables to KMS, bind to build numbers, and require approval and audit trails for any access.

Engineering Tip: Encapsulate the above steps into CI (Jenkins/GitLab CI + Fastlane) to turn "hardening" into a capability triggered by a single commit, while retaining rollback paths.

4. How to Choose the "Most Suitable" Tool—Decision Checklist

When evaluating specific tools, scoring against the following checklist provides more practical value:

Supports hardening without source code (Mandatory/Bonus)
Can export and specify symbol files (Facilitates whitelisting and fine-grained control)
Outputs mapping tables and supports encrypted archiving (Necessary for audit and symbolization)
Provides options for perturbing resources like images/JS (Hybrid app friendly)
Supports command-line and easy CI integration (Essential for engineering)
Has good documentation on rollback and testing recommendations (Reduces release risks)
Can the team bear the governance costs (KMS, approvals, drills) (Organizational capability)

After evaluating each item, select tools based on your most valued criteria and prepare supporting processes (whitelist maintenance, canary releases, emergency rollback).

5. Practical Recommendations (Key Points to Avoid Pitfalls)

Strictly version whitelists and include them in the source code repository; any changes must be assigned responsibility and include regression test cases.
Treat mapping tables as keys, using KMS/HSM for encrypted storage and approval-based decryption processes.
Perform full-path regression testing on real devices after obfuscation (launch, push notifications, payments, hot updates, third-party SDKs).
Canary releases and gating: Start with 1–5% canary, monitor crash rates and key business metrics, and automatically roll back if thresholds are exceeded.
Regular dynamic validation: Security teams should periodically conduct smoke tests and reverse engineering sampling using Frida, Hopper, etc., as a basis for iteration.

6. Conclusion

"Which IPA encryption tool is good?" cannot be answered by a marketing slogan. A more effective approach is to select tool categories based on delivery model and team capabilities (whether source code can be modified, whether CI and KMS governance can be implemented, whether hot fixes exist, etc.), and integrate tool capabilities (such as Ipa Guard's symbol export/specification, resource perturbation, CLI integration) into a rigorous release pipeline.
The ultimate goal is not to achieve 100% irreversibility, but to raise the cost of cracking, tampering, and repackaging to commercially unviable levels, while ensuring the business remains maintainable, rollback-capable, and auditable.