Shiply (shiply.tds.qq.com) is a full-scenario release and operations platform for client-side apps and an important member of the Tencent Device Services Alliance (tds-union.qq.com), providing configuration and switch release, resource release, hotfix, in-app upgrade, store release, in-app testing, and other services to help businesses iterate and launch client features quickly and securely.

Want your product team to deeply experience your product like real users? Shiply app beta testing helps you launch efficient Dogfooding in minutes and break down beta distribution barriers!

"Eating your own dogfood" (also abbreviated as Dogfooding) is an English idiom commonly used to describe a company (especially a software company) using its own products.

The phrase may have first been used in 1988. Paul Maritz, a senior executive at Microsoft, wrote an email titled "Eating our own Dogfood" challenging the company to "increase the internal usage of our own products." The idiom has spread ever since.

Practicing Dogfooding is not simply "testing" a product—it is a practice that deeply integrates the user perspective into team culture and development process. Dogfooding goes beyond testing alone. It requires product owners, product managers, designers, developers, and colleagues from marketing, legal, admin, finance, and other roles representing "novice users" to become the main force of product trial.

It requires us to experience like real users and discover in real scenarios those bugs, awkward interactions, and unclear value propositions that are hard to reproduce in development and test environments.

Dogfooding has many successful industry cases—from computer software and mobile internet apps to today's AI applications, the Dogfooding philosophy remains enduring.

• Microsoft: As the company that coined "eating our own dogfood," nearly every Microsoft product goes through Dogfooding, and the process is embedded in their product release culture. For example, new versions of Microsoft Outlook are validated through Dogfooding.

• Amazon: Its famous "API mandate" requires all team service interfaces to be designed for internal team use first. Many Amazon.com features are implemented by calling internal APIs—the company is its own biggest user.

• Slack/Figma: All employees rely entirely on their own products for work communication and design collaboration—exemplary Dogfooding.

• Lyft: Known for friendly service and deep user care, Lyft requires employees (including executives) to drive as Lyft drivers for at least 4 hours per month. This helps them understand the passenger experience, discover driver needs and pain points, and detect performance issues.

• Facebook: In 2012, the Facebook Android app was slow and buggy, lacking many web features, while the iOS app was praised for performance and overall experience. Facebook encouraged employees (mostly iPhone users) to use Android phones to experience the app. They also blocked their own website internally, forcing employees to use the mobile version and truly feel user pain points. Eventually, the Facebook Android app underwent a dramatic transformation in performance and overall quality.

I. Why Dogfooding Is Needed​

Before taking action, it is critical for the entire team to understand its importance. The core value of Dogfooding lies in:

1. Discover real problems: Internal employees are the product's first users. They can discover in real work scenarios those bugs, poor user experiences, and counterintuitive designs that are hard to reproduce in test environments.

2. Build empathy: When developers become users themselves, they understand user frustration and needs more deeply, naturally putting user experience first in design and development.

3. Improve product quality and stability: Large-scale internal trial before feature launch effectively intercepts issues and improves final release quality.

4. Validate product value: If your own employees won't use your product, how can you convince external users? Dogfooding is the most direct test of product value.

5. Cultivate ownership: When employees use the product they build every day, they naturally develop pride and responsibility and actively think about how to make the product better.

II. Who Should Participate in Dogfooding​

• Developers: Focus on performance, stability, and technical details. They encounter very hidden bugs.

• Designers: Focus on interaction flow, visual consistency, and usability. They keenly spot counterintuitive design.

• Product managers: Focus on whether features solve target problems, whether workflows are smooth, and whether value propositions are clear.

• Non-technical roles (such as marketing and finance): They are the best representatives of "novice users." Their confusion often best represents real new user confusion.

Dogfooding Scenarios​

• Internal trial: Quickly trial new features within a small organization to validate stability and collect feedback

• Cross-department review: Product, operations, marketing, and legal can all install and experience conveniently for more efficient collaboration

• Outsourced collaboration: Controllable permissions and validity periods ensure delivery efficiency and enterprise security

III. How to Implement Dogfooding​

However, turning Dogfooding from concept into daily practice—especially for client apps—often faces technical and management "roadblocks":

• Low distribution efficiency and cumbersome process: Sharing packages via IM? iOS and Harmony won't install! Enable iOA for intranet access, install Blue Shield, find build artifacts in pipeline lists to install? Cumbersome processes and permission requests are enough to deter non-technical staff!

• Chaotic version management: "Which version did you install?" Legacy solutions lack version control; testers install wrong packages; feedback cannot align; troubleshooting efficiency drops.

• UDID collection and signing nightmare: iOS and Harmony real-device testing requires collecting device UDIDs in advance, manually generating Profile files, and repeated packaging. Complex, time-consuming, error-prone processes are huge obstacles to expanding test scope.

• Insufficient permission and security control: Test packages leak casually; new features risk early exposure. Lack of effective access control and download tracking.

• Lack of data insights: "Who downloaded?" "Who actually tested?" "Which version has the most feedback?" Without data support, it is hard to measure Dogfooding effectiveness and drive improvement.

• High barrier for non-technical members: Product, operations, marketing, legal, and other non-technical colleagues are valuable "novice user" perspectives, but complex install processes often shut them out.

These pain points directly block widespread, deep, and sustained Dogfooding, making "eating dogfood" difficult.

IV. Shiply App Beta Testing: Help Dogfooding Launch in Minutes!​

Don't worry! The Shiply app beta testing platform transforms a manual, fragmented, error-prone, inefficient beta distribution process into a standardized, centralized, automated, highly collaborative process. Launch and run Dogfooding efficiently in minutes!

4.1 Why Choose Shiply​

Shiply is a one-stop beta distribution platform built for development, testing, IT, product, and business teams

• Full platform coverage: Supports iOS, HarmonyOS, and Android simultaneously—one solution for all client-side beta needs

• Minimal integration, launch in minutes:

  • No SDK integration required! No pipeline plugin integration required (optional)!

  • Just upload install packages on the Shiply platform / select packages from pipelines directly; the system automatically generates download pages.

  • Testers scan QR codes to install—goodbye to cumbersome steps.

• Enterprise-grade security, strict leak prevention:

  • Access control: Supports password-protected install, organization-based authorized access (whitelist + email domain).

  • Download validity: Links can be set permanently valid or for custom time periods—flexible security boundaries.

  • One-time short links: Click "Install Now" to generate one-time token links (default: 1 download within 5 minutes); auto-expire after timeout or over-limit.

• Beta records: Automatically records employee beta participation (current); supports ranking and incentives to sustain active Dogfooding culture (planned)

• Version management, goodbye to chaos:

  • Unified version library: Clearly manage all historical versions.

  • Automatic update reminders: Automatically notify testers when new versions are uploaded.

4.2 How to Use Shiply App Beta Testing​

One Step to Start Beta Distribution​

No SDK integration, no pipeline plugin integration—just upload an install package to start beta distribution!

Invite Beta Testers​

Through App Beta Testing list -> Invite Testing -> Add Test Users, you can invite users to download beta packages.

After inviting beta users (no user consent required), the platform pushes beta version links to users.

When administrators release new beta versions, beta users receive version update notifications to quickly install new beta versions.

Smart Download Page​

• Multi-platform unified download page: Any platform download page auto-detects and displays the corresponding latest install package

• Install permission verification: Supports password-protected install and organization-authorized install—strictly controls in-company access.

• Download validity: Permanently valid or custom time periods—flexible exposure and security boundaries.

Data Visibility and Control​

• Statistical analysis: View download growth trends by time range; supports province-level statistics

• Beta records: Distinguish "view only / downloaded" status; connect user behavior with version effectiveness

• Certificate validity: Remind certificate status in version details to avoid expiration risk

V. FAQ​

Q: Is SDK integration required?

A: No. Upload install packages to use beta distribution and download page capabilities. Which package types are supported?

Q: Does it support pipeline package upload?

A: Yes, pipeline upload is supported after completing pipeline authorization.

Q: Does it support feedback collection?

A: Shiply focuses on install package distribution; the company has multiple feedback collection platforms available for integration.

VI. Summary​

Practicing Dogfooding is essentially building a deep "product empathy" culture. It requires the team—from leaders to every member—to sincerely place themselves in users' shoes and drive the product toward greater stability, usability, and value through firsthand experience. This is not just a testing step—it is a product philosophy and expression of team cohesion.

However, cultural adoption cannot succeed without efficient tool support. Pain points in traditional beta processes are the real barriers blocking widespread, deep Dogfooding. The Shiply app beta testing platform was built to break down these barriers. Through minimal distribution, strict security control, flexible version management, and clear data insights, it minimizes Dogfooding startup cost and maximizes execution efficiency.

Choosing Shiply means:

• Lower participation barriers: Let all relevant parties, including non-technical colleagues, easily become "dogfood tasters" for richer user perspectives.

• Higher feedback efficiency: Ensure feedback is based on correct versions and accelerate issue identification and fix loops.

• Secure and controllable: Firmly guard enterprise assets and sensitive information boundaries while enabling open collaboration.

• Quantify practice effectiveness: Clearly understand Dogfooding coverage and participation through data and continuously optimize processes.

Visit Shiply (shiply.tds.qq.com) now, upload your install package, and start an efficient, secure Dogfooding journey! Make "eating your own dogfood" no longer a hassle—once successful, your product team will have unmatched insight and improvement momentum.

Problems Unity Apps Face When Updating​

Teams using the Unity engine—whether game developers or teams building 3D interactive applications—commonly encounter the following challenges:

Scenario 1: Emergency Bug Fixes

Sudden crashes or rendering anomalies occur in production, operations is pushing hard, and R&D finds it's just a small issue—but after fixing it, you still have to go through packaging, submission, review, and store listing. By the time it actually goes live, one or two weeks have often passed. For games, this means retention loss; for e-commerce 3D displays or industrial visualization apps, it directly affects conversion or production decisions.

Scenario 2: Package Size Bloat

As 3D asset precision and texture maps increase, package size keeps growing—500MB is not uncommon. But app store data is clear: once package size exceeds 100MB, download conversion drops significantly; beyond 200MB, many users simply won't download. This is a real loss for game user acquisition, e-commerce app acquisition, or enterprise internal distribution.

Scenario 3: Version Fragmentation and Multi-Scenario Management

Users are spread across different versions, increasing operations compatibility costs. More complex still, many teams need to host multiple 3D scenarios in one app (such as an e-commerce platform's "virtual shoe try-on + 3D showroom + AR placement"). Traditional approaches either pack everything into the initial package or guide users to external downloads—creating a fragmented experience.

Scenario 4: Dynamic Content Operations

Holiday marketing campaigns, quarterly new product 3D showcases, real-time data dashboards for industrial digital twins—these need frequent updates but are constrained by release cycles, often going live after the optimal window has passed.

The root cause of these problems is that in traditional mode, Unity content is tightly coupled with the install package—once content changes, you can only release a new version. The Shiply Android Unity plugin solution was built to decouple the "app framework" from "real-time content."

What Is Shiply Pluginization?​

Core concept: Split Unity content into "dynamically deliverable plugin modules." The host app keeps only the base framework (30–50MB); real 3D content is downloaded on demand and replaced directly during hot updates, completely freeing you from app store release dependency.

Core capabilities at a glance:

Real business value:

1. Extreme initial package slimming to lower acquisition barriers

The host keeps only the base framework; 3D content downloads on demand. App stores show a lightweight app, significantly improving download willingness—applicable to game user acquisition, e-commerce app acquisition, and enterprise internal distribution.

2. Real-time content delivery to capture operational windows

Online issue fixes or marketing content updates take effect network-wide within 10 minutes after plugin delivery. No more waiting for review windows—holiday marketing and trending operations can go live instantly.

3. Scientific gradual rollout and risk control

Under the same version, deliver different content packages by region, user group, or device performance; roll back in seconds when data is unsatisfactory. Especially important for high-ticket 3D e-commerce displays or industrial visualization apps.

4. One app hosting diverse 3D scenarios

Main scenarios stay resident; event showrooms, new product previews, training modules, and data visualization panels load on demand and clear when done. Achieve "one app, unlimited 3D content."

How to "Pluginize" a Unity App​

Overall architecture:

Key technical points:

1. Bytecode transformation (Transform)

Android requires Activities and Services to be registered in the Manifest, but plugins are delivered dynamically and cannot be pre-registered. During compilation, Activities in plugins are automatically replaced with ShadowActivity, executed by proxy through the host shell Activity—so Unity projects require almost no changes.

2. Component proxy (Proxy)

UnityPlayerActivity must correctly receive touch, key, orientation, configuration change, and other events. The host provides proxy Activities that forward system events to Activities in plugins, ensuring Unity interaction logic is not broken.

3. ClassLoader isolation

Host and plugin SDK versions often differ, especially ad, payment, and analytics libraries—sharing them directly causes conflicts. Each plugin has an independent ClassLoader for mutual isolation, making multi-game coexistence safer.

4. Unity adaptation layer

Unity validates libunity.so integrity and path at startup; path changes after pluginization cause startup failure. Native-layer adaptation makes Unity believe it still runs in a normal environment, supporting Unity 2019–2022+, IL2CPP, without modifying Unity source code.

Comparison with Lua Dynamic Delivery Solutions​

Lua hot update frameworks like xLua and ToLua can also achieve hot updates—why choose Shiply pluginization?

Lua focuses on script-layer dynamic delivery; Shiply focuses on entire Unity runtime dynamic delivery. These two approaches solve different problems and are not direct substitutes.

Typical scenario comparison:

Scenario 1: Fixing core C# bugs

• Lua approach: Bug is in the C# layer; Lua cannot modify it—must release a new version. Wait 7–15 days for review.
• Shiply approach: Modify C# code directly, package a new plugin, hot update takes effect network-wide in 10 minutes.

Scenario 2: Adding new 3D content modules

• Lua approach: If level logic involves C# code, split into "C# framework + Lua scripts"—development complexity doubles.
• Shiply approach: Develop normally; pack the entire level as a plugin for delivery.

Scenario 3: Integrating a new SDK (e.g., new ad SDK)

• Lua approach: SDK is Native/Java code; requires Lua binding layer—significant effort.
• Shiply approach: Integrate SDK normally; deliver with the plugin.

Scenario 4: Initial package slimming

• Lua approach: Not achievable. Lua VM and C# core code remain in the initial package.
• Shiply approach: Initial package contains only host framework (30–50MB); games and 3D content download dynamically.

Typical Shiply Pluginization Application Scenarios​

Scenario 1: Gaming

Dynamic event dungeon launch: Holiday event plugins delivered on demand, automatically cleaned up after events end; initial package stays under 100MB, significantly improving download conversion.

Multi-game aggregation platform: Publishers integrate multiple Unity games into a single host app—tap to play with unified account, payment, and data management.

Scenario 2: 3D E-commerce and Retail

Dynamic virtual try-on updates: Footwear e-commerce can launch new 3D shoe models weekly without app updates; apparel e-commerce can dynamically update virtual try-on asset packs at season changes—users experience new products without re-downloading the app.

3D home showroom: Furniture apps can deliver by "living room/bedroom/study" scenarios or dynamically load style-specific showrooms based on browsing preferences—reducing initial package size while improving personalization.

Scenario 3: Industrial Visualization and Digital Twins

Dynamic device digital twin loading: Factory management apps can dynamically load specific equipment 3D twin models and real-time data panels based on engineer permissions or current tasks—without packing entire factory data upfront.

On-demand training simulation modules: Enterprise training apps can deliver different 3D simulation training modules by role (operator/maintenance/administrator)—reducing initial install size and supporting rapid training content iteration.

Scenario 4: Education and Culture

Virtual laboratories: Education apps can dynamically load 3D experiment scenarios by subject (physics/chemistry/biology) or experiment unit—supporting continuous teaching content updates.

Museum/exhibition digitization: Cultural apps can dynamically launch 3D showrooms during special exhibitions and auto-clean up after exhibitions end—enabling flexible "permanent + special exhibition" operations.

Scenario 5: Tools and Finance

Operational mini-games: Finance or utility apps can launch Unity interactive games during holiday campaigns without app store redirects; quickly take down after events without affecting main app size.

Technical Highlights Recap​

Conclusion​

Shiply pluginization solves the fundamental problem of "how Unity real-time content is dynamically delivered"—not limited to script-layer hot updates. Whether for rapid game content iteration or flexible operations in 3D e-commerce, industrial visualization, education, and training, this solution provides:

• Smaller acquisition package (improved download conversion)
• Faster delivery speed (capture operational windows)
• More flexible scenario management (one app, diverse content)
• Lower risk control cost (gradual rollout and second-level rollback)

If you are looking for a Unity app hot update solution, or want to integrate multiple 3D scenarios into one app for unified operations, welcome to learn about and try Tencent Shiply Plugin Solution, or scan WeChat to contact a technical consultant for tailored architecture advice. For more product information and solutions, visit TDS Tencent Device Services.

Shiply (https://shiply.tds.qq.com/) is a one-stop client-side release platform and an important member of the Tencent Device Services Alliance (https://tds.qq.com), providing configuration and switch release, resource release, RN hot update, Flutter dynamic delivery, Android plugin framework, hotfix, in-app upgrade, store release, in-app testing, and other services to help businesses iterate and launch client features quickly and securely.

Preface: The Potential and Real-World Challenges of RN Dynamic Delivery​

As a widely used cross-platform development framework, React Native (RN) significantly improves app iteration efficiency with its "write once, run everywhere" approach, making it a top choice for many teams accelerating business innovation. RN dynamic updates are a core advantage of the RN framework—in theory, teams can quickly publish compiled RN artifacts to iterate code and resources rapidly and respond more flexibly to market demand.

In practice, however, RN dynamic delivery faces multiple challenges:

• Release efficiency is limited by update package size and gradual rollout capability; emergency fixes may still lag due to slow transfer and difficult coverage;

• Full package updates consume user data and enterprise bandwidth, affecting user experience and increasing operational costs;

• Weak risk control makes rollback difficult when updates fail, easily triggering user complaints;

• In global scenarios, cross-border data transfer must comply with GDPR, CCPA, and other regulations; public cloud services may pose compliance risks;

• Dependence on third-party tools means service shutdowns (such as CodePush ceasing operations) can directly interrupt business iteration.

To address these core issues, conventional mobile R&D platforms (such as Firebase, mPaaS, and EMAS) typically provide only general basic release capabilities and struggle to meet complex business scenarios. Tencent Shiply, as a professional mobile R&D platform, provides not only general configuration and resource release management but also dedicated release management services and one-stop solutions for dynamic artifacts across various frameworks—helping businesses iterate quickly with real-time updates.

The Tencent Shiply React Native hot update solution is one such offering, providing a dynamic delivery management system that balances efficiency, risk, cost, and compliance.

This article explains how Tencent Shiply helps teams achieve more efficient RN app iteration across four dimensions: reducing update costs, strengthening risk control, meeting compliance requirements, and ensuring service sustainability.

I. Reducing Update Costs: Optimizing Traffic and User Experience​

Current Pain Points​

Traditional RN dynamic updates often rely on full package push. Even when only a small amount of code or resources change, users must download multi-MB full update packages. This not only consumes user data (especially on mobile networks), reduces willingness to update, but also increases enterprise CDN bandwidth costs due to frequent large file transfers, limiting iteration frequency.

Shiply Optimization Approach

• Smart delta updates: Shiply uses intelligent delta algorithms to push only the changed portions of code or resources, significantly reducing update package size.

• Silent background updates: Shiply supports silent background download of delta update packages. Users complete updates without awareness or manual confirmation, avoiding update blocking due to data usage concerns.

• Higher iteration frequency and impact: Thanks to low-cost updates, one business successfully increased weekly iterations to 3–4 times, and improved user experience also drove positive DAU growth.

Core Value​

Shiply effectively controls update costs (user data and enterprise bandwidth) through delta technology, making high-frequency, fine-grained iteration possible and improving app iteration efficiency and user experience.

II. Strengthening Risk Control: Ensuring Secure and Reliable Releases​

Common Issues​

Under traditional update mechanisms, full updates are common. If an update package has issues, rollback typically requires repackaging, resubmitting for review, or manual intervention and notification—long processes with potentially broad user impact.

Shiply Security Measures​

• Fine-grained targeting and gradual rollout strategies: Flexibly target gradual rollout audiences by user tags (region, device, OS version, etc.), supporting gradual rollout from a small user base (e.g., 5%) to 50% and full rollout, controlling impact scope.

• Automated circuit breaker: With Bugly platform real-time monitoring of key post-update device metrics (exception rate, performance metrics), the system automatically pauses update push when exception rate exceeds preset thresholds (e.g., failure rate > 3%) and sends alerts to responsible parties.

• Rapid rollback: When issues occur, one-click rollback to a stable version ensures service continuity for most users. For example, one business successfully executed 3 rollbacks within 90 days without negative public sentiment.

Core Value​

Shiply provides fine-grained gradual rollout strategies, automated risk monitoring and circuit breaking, and rapid rollback mechanisms, significantly reducing update risk and ensuring business stability.

III. Meeting Compliance Requirements: Securely Deploying Global Business​

Compliance Challenges​

GDPR, CCPA, and other regulations impose strict requirements on user data processing (especially cross-border transfer). When using public cloud hot update services, unclear data flows may trigger compliance risks, with potential impacts including fines and business restrictions.

Shiply Solution

• Strict security audits: The solution design follows security best practices; core services pass audits by Tencent's professional legal team and meet major data protection regulations (GDPR/CCPA).

• Overseas independent deployment: Core components and data can be deployed overseas, ensuring user data stays within overseas regions and avoiding cross-border transfer risks.

• Proven in practice: A leading consumer electronics customer successfully used Shiply's overseas deployment solution, running stably across multiple overseas regions for 12 months without compliance incidents.

Core Value​

Shiply provides solutions that meet international security and compliance standards, especially through overseas independent deployment options, helping enterprises conduct hot updates securely while meeting data sovereignty requirements worldwide.

IV. Ensuring Service Sustainability: Tencent In-House, Stable Assurance​

Background Considerations​

Dependence on third-party technology stacks carries uncontrollable risks (for example, the CodePush shutdown in March 2025 affected user projects). Service stability and long-term support are important dimensions in enterprise technology selection.

Shiply Advantages​

• Strong technical investment: Continuously developed and maintained by Tencent's professional team with years of technical accumulation.

• Large-scale validation within Tencent: Shiply core technology is widely used for dynamic update needs across multiple Tencent apps with hundreds of millions of users (such as Mobile QQ, QQ Browser, Tencent News, Tencent Video), tested in complex scenarios and high-concurrency traffic.

• Long-term support commitment: As Tencent's in-house core technology solution, Shiply commits to long-term stable support and technical iteration.

Core Value​

Choosing Shiply means choosing Tencent's mature, stable, continuously iterated RN hot update solution with long-term support guarantees, reducing uncontrollable risk.

V. Side-by-Side Comparison: Why Shiply Is a Strong Alternative After CodePush Shutdown?​

When Microsoft App Center terminated service and CodePush shut down, developers faced a dilemma: costly self-hosted operations or finding a reliable alternative.

The following compares Shiply with mainstream solutions across core enterprise concerns:

Shiply RN hot update not only supports CodePush's "minute-level hot update" capability but goes further through compliance closed-loop design and Tencent ecosystem integration (Bugly monitoring), with simple usage and low integration cost for businesses.

VI. Exploring a New Paradigm: Finer-Grained Feature Delivery and Management​

Current Limitations​

Traditional app version updates typically bundle multiple features or fixes with high coupling, high trial-and-error cost, and difficulty quickly adjusting individual features.

Exploration Direction with Shiply​

• Feature-level gradual rollout and A/B testing: Shiply supports publishing and testing new features as independent modules. If results are poor, quickly roll back that feature without affecting the main app; if results are good, roll out fully without waiting for version review cycles.

• On-demand precise updates: Combined with very small delta packages and user profiles, theoretically target specific user groups with specific feature updates or experiments.

• Data-driven decision loop: Shiply integrates with Bugly to monitor Crash rate and other key data, supporting strategies (such as automatic circuit breaker or rollback when exception rate exceeds thresholds) to form a smarter release decision loop.

Core Value​

Shiply goes beyond traditional fix updates, providing support for more flexible, fine-grained feature management and experiment release capabilities to improve app iteration efficiency and outcomes.

Conclusion

Efficient app iteration capability is key to enterprise competitiveness, and meeting compliance requirements is the foundation for business expansion. The Tencent Shiply RN hot update solution effectively combines efficiency with security and compliance through innovative delta technology, intelligent risk control, compliant data deployment options, and Tencent ecosystem technical and resource guarantees—providing strong support for enterprises facing rapidly changing market challenges.

If your business uses React Native and faces app release efficiency bottlenecks, hot update compliance requirements, update cost concerns, or service sustainability worries, welcome to learn about and try Tencent Shiply RN Hot Update Service, or contact a Shiply Account Manager for consultation. You can also visit TDS Tencent Device Services for more product information and solutions.

Shiply (https://shiply.tds.qq.com/) is a one-stop client-side release platform and an important member of the Tencent Device Services Alliance (https://tds.qq.com), providing configuration and switch release, resource release, RN hot update, Flutter dynamic delivery, hotfix, in-app upgrade, store release, in-app testing, and other services to help businesses iterate and launch client features quickly and securely.

Introduction: Shiply is a one-stop client-side release platform under Tencent Device-oriented Service (TDS), supporting configuration switches, dynamic resources, hotfixes, app upgrades, app store distribution, and more. Drawing on years of release experience and evolving business needs, the platform has gradually shifted release standardization from ad hoc, surface-level, issue-driven approaches to tool-based, systematic implementation and practice. Shiply and Bugly continue to explore a comprehensive monitoring and rollback system in product and technology, building a secure line of defense for online releases and safeguarding every safe release for the business.

I. Background​

As continuous delivery paradigms such as DevOps continue to evolve, hot releases (including remote configuration delivery, offline resource delivery, and similar capabilities) have become a key tool in continuous delivery. In e-commerce, short video, local services, information feeds, and many other business scenarios, hot releases play a critical operational role.

Traditional application releases (cold releases) typically involve collaboration across multiple teams and are high-pressure, high-risk activities because each release includes a large volume of changes. To reduce the risk of such large-scale changes, more and more teams are turning to DevOps for more agile continuous delivery. DevOps also blurs the boundary between developers and operations, increasing developers' need to control production environments. On the client side, this is mainly achieved through release management systems such as remote configuration and offline resources (hot releases).

For example, developers can use feature flags for gradual rollout (phased release) and observe results based on A/B testing and other metrics to decide whether to fully roll out new features. If results fall short, they can turn off the feature and optimize or retire it in subsequent iterations.

However, the widespread use of hot releases in software systems can also lead to release mistakes and operational incidents. Examples are not hard to find:

From these cases, we can see that hot release mistakes not only affect software stability but can also damage product reputation and cause invisible user churn.

II. What Risks Exist in Releases?​

Cold releases (package releases) carry risks such as privacy compliance, stability, and performance. The corresponding detection, review, and monitoring mechanisms are relatively mature, with dedicated owners at each stage, so impact is controllable and the probability of causing a real incident is low.

Hot releases, by contrast, often lack experience in risk identification and corresponding processes and standards, which sometimes leads to incidents. Common risks include:

We can learn about secure release practices from post-incident improvement measures:

• Improvement measures

  1. Add validation and alert interception for XX service whitelist generation results;

  2. Add gradual rollout validation logic for XX service whitelist updates to detect anomalies early;

  3. Add rapid recovery capability for XX service whitelists;

  4. Strengthen coordinated recovery capability on the product side.

Among these, the key improvements are adding content validation, alert interception, gradual rollout validation, rapid rollback, and damage control recovery. These are essential for a standardized release process. In addition, basic capabilities such as version management and change log review should also be in place.

Every online release carries risk, and the release process depends heavily on human experience and risk identification ability. After incidents, most teams improve through post-mortems and experience summaries, then constrain release behavior with standards and mandatory processes to avoid recurrence. Most software engineering implementations go through these four stages:

1. Wild West stage: Rely on the experience and judgment of individual executors.

2. Standardization stage: Form center- or department-level standards with mandatory approval processes.

3. Standardization stage (organization-wide): Form business group (BG) or company-wide standards.

4. Automation stage: Codify experience into standards, turn standards into tools, systemize processes, and automate execution.

Each team needs considerable time to evolve from the Wild West stage toward automation—from relying on executors' risk awareness to relying on systematic release risk controls. Shiply is the solution built for this goal.

Shiply adds defense and rollback mechanisms at every node of the release process as a one-stop release platform. It implements three levels of risk control:

• Prevention: Prevent human-factor risks during release through standardized, automated secure release processes.

• In-flight monitoring / automatic rollback: Detect issues accurately and roll back automatically through gradual rollout strategies, A/B comparison, and metric monitoring.

• Post-release rollback / hotfix: Degrade with minimal loss through rollback capability, or fix live issues without a new release through hotfix capability.

This fundamentally shifts release security from "human assurance" to "platform assurance," turning human experience into automatically executed standards.

III. Shiply Secure Release​

3.1 Pre-release — End-to-End Secure Release​

Feature	Description	Screenshot
Content validation	The platform creates validation scripts for each configuration. Portable validation scripts allow custom validation of configuration content. Configuration values are validated whenever a release task is created or modified
Change comparison	After editing delivery content, use diff comparison to review modifications
Versioned change history	Release management provides two fundamental capabilities: traceability and reproducibility, improving security across the software lifecycle and team collaboration efficiency. Traceability means that, with proper authorization, anyone can find any change history for the software—for any software change, you can accurately answer the 5W1H: who, when, what, why, and how. This is an important safeguard in software organization information security management.
Gradual rollout validation	The platform supports rich gradual rollout strategies to meet various business scenarios ● Gradual rollout by custom duration + custom batches ● Gradual rollout by custom duration + custom cumulative user count ● Whether to schedule release after gradual rollout ● Whether to pause release after gradual rollout
Release review	Reviewers can clearly see the owner's modifications to the release task to assess the impact on production.

3.2 In-flight — Monitoring and Rollback​

When a release enters the gradual rollout phase, we want to detect problems early while only a small number of users are affected. In practice, metrics fluctuate significantly when the gradual rollout audience is small, which can cause false positives. Conventional monitoring often relies on dashboard Crash rate metrics, but this makes it hard to detect newly introduced individual issues. By the time problems move the dashboard, impact is already large and monitoring loses its early-warning value.

Shiply secure release can accurately detect issues from a small gradual rollout sample through the following approach:

1. Build multi-dimensional monitoring capability

We support monitoring of multiple metrics and observation across the full issue lifecycle:

• Support monitoring of Crash, ANR, FOOM, ERROR, privacy compliance, and custom business metrics.

• Detect new gradual rollout issues, worsening existing issues, and worsening issues in the gradual rollout cohort.

2. A/B comparison during gradual rollout

We scientifically evaluate each release quality through A/B comparison:

• A/B control: Set control and experiment groups to ensure fairness and comparable results.

• Traffic allocation: Allocate traffic appropriately based on experiment needs to ensure representative data.

• Experiment metric monitoring: During gradual rollout, monitor metric changes for experiment and control groups in real time.

• Alert confidence: Based on the normal distribution relationship between gradual rollout device volume and Crash rate fluctuation, algorithms compute alert confidence to reduce false positives with small samples and improve alert reliability.

3. Improve alert accuracy

We reduce false positives through alert confidence and dynamic alert thresholds:

• Set alert thresholds based on gradual rollout audience size: In early gradual rollout, set higher thresholds to reduce false positives. As rollout expands, gradually lower thresholds to increase sensitivity.

• Set alert thresholds based on historical data: Reference historical data and combine with current business conditions to set reasonable thresholds.

• Improve alert actionability: When alert information is received, the responder should be able to take corresponding actions.

4. Automatic rollback

We support automatic issue correlation analysis and automatic rollback:

• Automatic issue attribution: Through A/B comparison, the platform automatically analyzes the correlation between issues and release tasks, avoiding long manual analysis and attribution delays that cause rollback timing to be too late and impact to expand.

• Automatic rollback: When issue metrics reach circuit-breaker thresholds, the platform automatically stops the release task and triggers circuit-breaker rollback.

3.2.1 Shiply × Bugly Monitoring Integration​

Shiply and Bugly continue to explore a comprehensive monitoring and rollback system in product and technology, building a secure line of defense for online releases and safeguarding every safe release for the business.

The Shiply platform uses monitoring capabilities provided by Bugly to monitor Crash, ANR, FOOM, and other issues. Configuration switches, resources, package gradual rollout, and store releases all have monitoring and rollback capabilities.

• The platform monitors all gradual rollout tasks by default; businesses can configure alerts and circuit breakers themselves.

• The platform enables new Issue alerts for all apps by default, covering most scenarios.

• Users can enable Crash rate, spike Issue alerts, and circuit breakers.

• The platform also supports monitoring, alerts, and rollback for ANR, FOOM, Error, and other metrics.

• Tasks that go through the gradual rollout process automatically enter monitoring; the system fetches Crash and other metrics every 5 minutes and performs attribution diagnosis against release tasks.

• Support viewing trends of Crash rate and other metrics over time, including Crash rate, affected devices, and total connected devices at each time point.

3.2.2 Shiply Secure Release Monitoring and Rollback Results​

Through integration with the Bugly monitoring and release system, new issues caused by releases can usually be diagnosed for correlation with Crash, Error, and release tasks when affected devices are fewer than 100, with timely notification for the business to resolve through configuration changes or rollback—preventing issues before they expand and avoiding online incidents.

3.3 Post-release — Rollback / Hotfix​

When a release issue is detected, you can stop the current task directly. The platform uses delivery task matching funnels to automatically match the previous release and achieve automatic downgrade. You can also manually downgrade to a target version. Shiply also provides hotfix solutions for convenient, user-invisible live issue fixes.

IV. Conclusion​

Release is a process of risk management. Using configuration, resources, and other hot releases as examples, this article introduced the risks of online releases and the significant unreliability that human factors introduce during release.

The Shiply platform ensures stable, efficient, secure, and compliant end-to-end release through codifying experience, turning standards into tools, systemizing processes, and automating execution. Multiple Shiply delivery capabilities support a three-level risk control mechanism of "pre-release defense — in-flight monitoring and rollback — post-release rollback," greatly reducing the risk of online incidents.

In exploring online monitoring and rollback mechanisms, Shiply integrates with the Bugly platform to support monitoring, alerts, and rollback for Crash, ANR, FOOM, ERROR, privacy compliance, and custom business metrics. It also addresses the "alert ocean" problem to make alerts timely and precise—able to alert when affected device counts are still small, with automatic rollback support to enable unattended release!

We have invested significant effort in release risk control, but we know the fight against risk has no end. We continue to improve our understanding, insight, and defense against release risk to safeguard every safe release for the business!

Shiply (https://shiply.tds.qq.com/) is a one-stop client-side release platform and an important member of the Tencent Device Services Alliance (https://tds.qq.com), providing configuration and switch release, resource release, RN hot update, Flutter dynamic delivery, hotfix, in-app upgrade, store release, in-app testing, and other services to help businesses iterate and launch client features quickly and securely.

Introduction: This article summarizes cross-compilation practices for dependent third-party libraries on the Harmony platform during Shiply platform C++ SDK Harmony adaptation under Tencent Device Services. Shiply supports powerful Harmony platform capabilities including remote configuration, remote switches, remote resources, in-app update prompts, app store submission, app preview submission, enterprise signed package internal distribution, and more. Welcome to contact a Shiply Account Manager for consultation.

Overview​

Based on complete cross-compilation practice of bzip2 and OpenSSL libraries on the OpenHarmony platform, this document summarizes experience and methods for C/C++ third-party library cross-compilation using the lycium framework. Through this practice, we successfully compiled bzip2 and OpenSSL—two core libraries—for OpenHarmony 3.2 Release on macOS, covering three mainstream architectures: armeabi-v7a, arm64-v8a, and x86_64.

Project Background and Technology Ecosystem​

OpenHarmony Third-Party Library Adaptation Status​

OpenHarmony, as Huawei's open-source distributed operating system, faces unique challenges in C/C++ third-party library adaptation:

1. Diverse build methods: Open-source C/C++ libraries use cmake, configure, make, and other build approaches
2. Architecture support requirements: Must support armeabi-v7a, arm64-v8a, x86_64, and other mainstream architectures simultaneously
3. Toolchain differences: OpenHarmony uses LLVM toolchain, which differs from traditional GCC toolchain
4. Runtime environment: OpenHarmony runtime environment differs from Linux, Android, and other systems

tpc_c_cplusplus Project Positioning​

tpc_c_cplusplus is an important repository for OpenHarmony third-party library adaptation, with main functions including:

1. Third-party library adaptation script management: Stores compilation configurations for C/C++ third-party libraries adapted to OpenHarmony
2. Technical documentation: Provides third-party library adaptation guidance and best practices
3. Toolchain support: Provides lycium cross-compilation framework and related tools

lycium Framework​

lycium is the core framework for OpenHarmony third-party library adaptation—a shell script-based automated cross-compilation toolchain. This document analyzes lycium framework architecture, working principles, and technical characteristics to help developers better understand and use this framework.

Problems lycium Solves​

1. Diverse build methods: Open-source C/C++ libraries use different build systems (cmake, configure, make, etc.); lycium unifies these through HPKBUILD configuration files.
2. Complex architecture support: Must support armeabi-v7a, arm64-v8a, x86_64, and other architectures simultaneously
3. Toolchain differences: OpenHarmony uses LLVM toolchain, which differs from traditional GCC toolchain
4. Complex dependency management: Complex dependency relationships exist between third-party libraries
5. Automated builds: One-click source download, cross-compilation, and artifact packaging
6. Test validation: HPKCHECK scripts support automated testing

lycium Directory Structure​

lycium/
├── build.sh              # Main build script
├── test.sh               # Test script
├── script/               # Core script directory
│   ├── build_hpk.sh      # Single library build script
│   └── envset.sh         # Environment variable setup script
├── template/             # Template files
│   ├── HPKBUILD          # Build configuration template
│   └── HPKCHECK          # Test configuration template
├── Buildtools/           # Build tools
│   ├── toolchain.tar.gz  # Cross-compilation toolchain
│   └── README.md         # Tool documentation
├── CItools/              # Continuous integration tools
├── doc/                  # Documentation directory
├── usr/                  # Compilation output directory
└── docker/               # Docker support

lycium Architecture Layers​

┌─────────────────────────────────────────────────────────┐
│                    User Interface Layer                    │
│  build.sh (main build script)  test.sh (test script)      │
└─────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────┐
│                    Business Logic Layer                    │
│  Dependency Resolution │ Build Scheduling │ Environment   │
│  Management │ Error Handling                              │
└─────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────┐
│                    Build Execution Layer                   │
│  build_hpk.sh │ envset.sh │ HPKBUILD │ HPKCHECK           │
└─────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────┐
│                    Toolchain Layer                         │
│  LLVM Toolchain │ Cross-Compilation Tools │ Build System  │
│  Adaptation                                               │
└─────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────┐
│                    Platform Layer                          │
│  OpenHarmony SDK │ Operating System │ Hardware Architecture│
└─────────────────────────────────────────────────────────┘

Technical Architecture Analysis​

Cross-Compilation Technology Stack​

macOS + DevEco Studio SDK
    ↓
OHOS_SDK Environment Configuration
    ↓
LLVM Cross-Compilation Toolchain
    ↓
lycium Framework Build
    ↓
Multi-Architecture Binary Artifacts

Key Technical Components​

1. OpenHarmony SDK: Provides LLVM cross-compilation toolchain
2. lycium Buildtools: Supplementary cross-compilation tool package
3. HPKBUILD configuration: Defines compilation parameters and dependencies
4. Automation scripts: Implements full compile, test, and package workflow

Compilation Practice Summary​

1. Compilation Environment Preparation​

1.1 Basic Tool Check​

First check whether required basic compilation tools are installed:

# Check basic compilation tools
which gcc make pkg-config autoconf autoreconf automake

Check results:

• ✅ gcc: /usr/bin/gcc
• ✅ make: /usr/bin/make
• ✅ pkg-config: /opt/homebrew/bin/pkg-config
• ✅ autoconf: /opt/homebrew/bin/autoconf
• ✅ autoreconf: /opt/homebrew/bin/autoreconf
• ✅ automake: /opt/homebrew/bin/automake

Missing tools can be installed using Homebrew

1.2 OHOS SDK Environment Configuration​

Check OHOS_SDK environment variable configuration:

echo $OHOS_SDK

Configuration result:

• ✅ OHOS_SDK: /Applications/DevEco-Studio.app/Contents/sdk/default/openharmony

1.3 Cross-Compilation Toolchain Check​

Check cross-compilation toolchain in SDK:

ls -la $OHOS_SDK/native/llvm/bin/ | head -10

Toolchain files:

• ✅ aarch64-unknown-linux-ohos-clang
• ✅ aarch64-unknown-linux-ohos-clang++
• ✅ armv7-unknown-linux-ohos-clang
• ✅ armv7-unknown-linux-ohos-clang++
• ✅ clang, clang-15
• ✅ Other LLVM tools

1.4 cmake Version Check​

Check whether cmake version meets requirements (3.26+ required):

which cmake && cmake --version

Check results:

• ✅ cmake path: /opt/homebrew/bin/cmake
• ✅ cmake version: 3.31.6 (meets 3.26+ requirement)

1.5 Compilation Tool Package Configuration​

Extract and configure cross-compilation tool package provided by lycium:

# Enter Buildtools directory
cd lycium/Buildtools

# Check tool package files
ls -la lycium/Buildtools/
# Output:
# -rw-r--r--   1 mellow  staff  2323 Dec 19  2023 README.md
# -rw-r--r--   1 mellow  staff   146 Dec 19  2023 SHA512SUM
# drwxr-xr-x@  2 mellow  staff    64 Aug 12 10:38 toolchain
# -rw-r--r--   1 mellow  staff   438 Aug 12 10:23 toolchain.tar.gz

# Extract tool package
tar -zxvf toolchain.tar.gz

# Copy compilation tools to SDK directory
cp toolchain/* $OHOS_SDK/native/llvm/bin/

Extracted tool files:

• ✅ arm-linux-ohos-clang++
• ✅ aarch64-linux-ohos-clang++
• ✅ x86_64-linux-ohos-clang
• ✅ aarch64-linux-ohos-clang
• ✅ x86_64-linux-ohos-clang++
• ✅ arm-linux-ohos-clang

2. bzip2 Library Configuration Check​

2.1 Library Directory Structure​

Check bzip2 library configuration files and directory structure:

ls -la thirdparty/bzip2/

Directory structure:

thirdparty/bzip2/
├── docs/                              # Documentation directory
├── HPKBUILD                           # Build script
├── HPKCHECK                           # Test script
├── README_zh.md                       # Chinese documentation
├── README.OpenSource                  # Open source information
├── SHA512SUM                          # Checksum file
└── build directories/                 # Directories generated by compilation

2.2 Build Script Analysis​

View key configuration in HPKBUILD build script:

cat thirdparty/bzip2/HPKBUILD

Key configuration information:

• Library name: bzip2
• Version: 1_0_6
• Supported architectures: armeabi-v7a, arm64-v8a, x86_64
• Build method: make
• Compilation tools: Uses cross-compilation toolchain from OHOS SDK

3. bzip2 Compilation Execution Process​

3.1 Start Compilation​

Execute compilation command in lycium directory:

cd lycium
./build.sh bzip2

3.2 Compilation Output Log​

Build OS Darwin
OHOS_SDK=/Applications/DevEco-Studio.app/Contents/sdk/default/openharmony
CLANG_VERSION=15.0.4
x toolchain/
x toolchain/arm-linux-ohos-clang++
x toolchain/aarch64-linux-ohos-clang++
x toolchain/x86_64-linux-ohos-clang
x toolchain/aarch64-linux-ohos-clang
x toolchain/x86_64-linux-ohos-clang++
x toolchain/arm-linux-ohos-clang
cp: the -R and -r options may not be specified together
Start building bzip2 1_0_6!
Downloading bzip2-bzip2-1_0_6.zip
bzip2-bzip2-1_0_6.zip: OK
Compileing OpenHarmony armeabi-v7a bzip2 1_0_6 libs...
Compileing OpenHarmony arm64-v8a bzip2 1_0_6 libs...
Compileing OpenHarmony x86_64 bzip2 1_0_6 libs...
Build bzip2 1_0_6 end!
ALL JOBS DONE!!!

Compilation status:

• ✅ Source download successful
• ✅ Three architecture versions compiled successfully
• ✅ No errors during compilation

4. bzip2 Compilation Result Verification​

4.1 Generated File Structure Check​

Check generated library file structure:

ls -la usr/bzip2/

Generated directory structure:

usr/bzip2/
├── arm64-v8a/          # 64-bit ARM architecture
├── armeabi-v7a/        # 32-bit ARM architecture
└── x86_64/             # x86_64 architecture

4.2 Detailed File Check​

Check generated files for arm64-v8a architecture:

ls -la usr/bzip2/arm64-v8a/

File structure:

arm64-v8a/
├── bin/                # Executable directory
├── include/            # Header file directory
├── lib/                # Library file directory
└── man/                # Manual page directory

4.3 Key File Verification​

Generated files:

• ✅ Static library: libbz2.a (207,002 bytes)
• ✅ Header file: bzlib.h (6,245 bytes)

Executable files (can delete executables if only integrating static library):

• ✅ bzip2 (218,176 bytes) - Main compression tool
• ✅ bunzip2 (218,176 bytes) - Decompression tool
• ✅ bzcat (218,176 bytes) - View compressed file contents
• ✅ bzip2recover (32,800 bytes) - Recover corrupted compressed files
• ✅ Other tool scripts: bzdiff, bzgrep, bzmore, etc.

5. OpenSSL Library Compilation Record​

5.1 OpenSSL Library Configuration Check​

Check OpenSSL library configuration files and directory structure:

ls -la thirdparty/openssl/

Directory structure:

thirdparty/openssl/
├── docs/                              # Documentation directory
├── HPKBUILD                           # Build script
├── HPKCHECK                           # Test script
├── README_zh.md                       # Chinese documentation
├── README.OpenSource                  # Open source information
├── SHA512SUM                          # Checksum file
├── openssl_oh_test.patch              # Test patch file
└── openssl-OpenSSL_1_1_1u/           # Source directory

5.2 Build Script Analysis​

View key configuration in HPKBUILD build script:

cat thirdparty/openssl/HPKBUILD

Key configuration information:

• Library name: openssl
• Version: OpenSSL_1_1_1u
• Supported architectures: armeabi-v7a, arm64-v8a, x86_64
• Build method: configure (autotools)
• Special configuration: Uses patch file to fix test issues

5.3 OpenSSL Compilation Execution Process​

Execute compilation command in lycium directory:

cd lycium
./build.sh openssl

5.4 Compilation Output Log​

Build OS Darwin
OHOS_SDK=/Applications/DevEco-Studio.app/Contents/sdk/default/openharmony
CLANG_VERSION=15.0.4
x toolchain/
x toolchain/arm-linux-ohos-clang++
x toolchain/aarch64-linux-ohos-clang++
x toolchain/x86_64-linux-ohos-clang
x toolchain/aarch64-linux-ohos-clang
x toolchain/x86_64-linux-ohos-clang++
x toolchain/arm-linux-ohos-clang
cp: the -R and -r options may not be specified together
Start building openssl OpenSSL_1_1_1u!
Downloading openssl-OpenSSL_1_1_1u.zip
openssl-OpenSSL_1_1_1u.zip: OK
openssl_oh_test.patch: OK
Compileing OpenHarmony armeabi-v7a openssl OpenSSL_1_1_1u libs...
patching file 'util/check-malloc-errs'
patching file 'util/find-doc-nits'
patching file 'util/find-unused-errs'
patching file 'util/openssl-format-source'
Compileing OpenHarmony arm64-v8a openssl OpenSSL_1_1_1u libs...
Compileing OpenHarmony x86_64 openssl OpenSSL_1_1_1u libs...
Build openssl OpenSSL_1_1_1u end!
ALL JOBS DONE!!!

Compilation status:

• ✅ Source download successful
• ✅ Test patch applied successfully
• ✅ Three architecture versions compiled successfully
• ✅ No errors during compilation

5.5 OpenSSL Compilation Result Verification​

Generated directory structure:

usr/openssl/
├── arm64-v8a/          # 64-bit ARM architecture
├── armeabi-v7a/        # 32-bit ARM architecture
└── x86_64/             # x86_64 architecture

File structure:

arm64-v8a/
├── bin/                # Executable directory
├── include/            # Header file directory
├── lib/                # Library file directory
├── share/              # Shared file directory
└── ssl/                # SSL configuration directory

6. Compilation Result Summary​

6.1 Successfully Compiled Libraries​

✅ bzip2 library:

• Version: 1_0_6
• Architectures: armeabi-v7a, arm64-v8a, x86_64
• Main files: libbz2.a, bzlib.h, bzip2 executable

✅ OpenSSL library:

• Version: OpenSSL_1_1_1u
• Architectures: armeabi-v7a, arm64-v8a, x86_64
• Main files: libcrypto.a, libssl.a, openssl headers

Technical Challenges and Solutions​

1. Cross-Compilation Toolchain Configuration​

Problem: OpenHarmony uses LLVM toolchain; cross-compilation environment must be correctly configured

Solution:

# Set environment variables
export OHOS_SDK=/Applications/DevEco-Studio.app/Contents/sdk/default/openharmony

# Supplement compilation tools
cp lycium/Buildtools/toolchain/* $OHOS_SDK/native/llvm/bin/

2. Multi-Architecture Compilation Support​

Problem: Must support multiple CPU architectures simultaneously

Solution:

# Configure multiple architectures in HPKBUILD
archs=("armeabi-v7a" "arm64-v8a" "x86_64")

# Set compilation parameters for different architectures
if [ $ARCH == "armeabi-v7a" ]; then
    cc=${OHOS_SDK}/native/llvm/bin/arm-linux-ohos-clang
    host=linux-generic32
elif [ $ARCH == "arm64-v8a" ]; then
    cc=${OHOS_SDK}/native/llvm/bin/aarch64-linux-ohos-clang
    host=linux-aarch64
fi

3. Test Validation Issues​

Problem: Test cases for libraries such as OpenSSL may fail in OpenHarmony environment

Solution:

• Apply test patches to fix known issues
• Distinguish false positives from real errors
• Avoid using problematic features such as dlopen

4. Build Method Adaptation​

Problem: Different libraries use different build systems

Solution:

• make method: Use native Makefile directly
• configure method: Use autotools configuration
• cmake method: Use CMake build system

Best Practices Summary​

1. Environment Preparation Best Practices​

# 1. Check basic tools
which gcc make pkg-config autoconf autoreconf automake

# 2. Verify SDK configuration
echo $OHOS_SDK

# 3. Check cmake version
cmake --version  # Requires 3.26+

# 4. Configure toolchain
cd lycium/Buildtools
tar -zxvf toolchain.tar.gz
cp toolchain/* $OHOS_SDK/native/llvm/bin/

2. HPKBUILD Configuration Best Practices​

# Basic information configuration
pkgname=your_library
pkgver=1.0.0
pkgdesc="Library description"
url="https://example.com"
archs=("armeabi-v7a" "arm64-v8a" "x86_64")
license=("MIT")
depends=()
makedepends=()

# Source configuration
source="https://example.com/your_library-1.0.0.tar.gz"
downloadpackage=true
autounpack=true
buildtools="make"  # or "configure" or "cmake"

# Build directory configuration
builddir=your_library-1.0.0
packagename=$builddir.tar.gz

3. Compilation Process Best Practices​

# 1. Prepare phase
prepare() {
    mkdir -p $builddir/$ARCH-build
    # Set architecture-related environment variables
    if [ $ARCH == "arm64-v8a" ]; then
        setarm64ENV
    fi
}

# 2. Build phase
build() {
    cd $builddir/$ARCH-build
    # Execute compilation commands
    $MAKE
    cd $OLDPWD
}

# 3. Package phase
package() {
    cd $builddir/$ARCH-build
    $MAKE install
    cd $OLDPWD
}

4. Test Validation Best Practices​

# 1. Write test script
check() {
    cd $builddir/$ARCH-build
    # Run test cases
    $MAKE test
    cd $OLDPWD
}

# 2. Verify on device
./test.sh your_library

Application Integration Guide​

1. Library File Integration​

# Copy library files to project
cp -r lycium/usr/your_library/ your_project/cpp/thirdparty/

2. CMakeLists.txt Configuration​

# Static library linking
target_link_libraries(entry PRIVATE 
    ${CMAKE_CURRENT_SOURCE_DIR}/thirdparty/your_library/${OHOS_ARCH}/lib/libyour_library.a)

# Header file paths
target_include_directories(entry PRIVATE 
    ${CMAKE_CURRENT_SOURCE_DIR}/thirdparty/your_library/${OHOS_ARCH}/include)

3. Dynamic Library Integration​

# Dynamic libraries need to be copied to libs directory
cp your_library.so your_project/entry/libs/${OHOS_ARCH}/

Common Issues and Solutions​

1. Compilation Failure Issues​

Problem: Errors occur during compilation

Solution:

• Check OHOS_SDK environment variable settings
• Verify cross-compilation toolchain configuration
• Confirm source download succeeded
• Check sufficient disk space

2. Architecture Mismatch Issues​

Problem: Library file architecture does not match target platform

Solution:

• Confirm correct architecture version (arm64-v8a or armeabi-v7a)
• Check archs configuration in HPKBUILD
• Verify compilation output architecture

3. Missing Dependency Issues​

Problem: Library depends on other third-party libraries

Solution:

• Configure depends field in HPKBUILD
• Ensure dependency libraries are compiled first
• Check dependency library architecture support

4. Test Failure Issues​

Problem: Test cases fail in OpenHarmony environment

Solution:

• Apply necessary test patches
• Distinguish false positives from real errors
• Avoid using incompatible features

Summary​

Through this bzip2 and OpenSSL library compilation practice, we successfully validated:

1. Technical feasibility: lycium framework effectively supports C/C++ third-party library cross-compilation
2. Multi-architecture support: Successfully compiled library files supporting multiple architectures
3. Quality assurance: Ensured library functional integrity through test validation
4. Tool maturity: Compilation toolchain and framework are relatively mature

References​

• lycium Framework README

• OpenHarmony Third-Party Library Adaptation Guide

• bzip2 Integration Guide

• OpenSSL Integration Guide

• OpenHarmony Third-Party Library Repository

• OpenHarmony Knowledge Base

Introduction: Shiply is Tencent's full-scenario release platform for apps, providing one-stop dynamic release solutions. Multiple client-cloud integrated services effectively lower technical barriers, reduce R&D costs, and help businesses quickly build stable, high-quality mobile applications. It is also an important product member of the Tencent Device-oriented Service (TDS) alliance (tds.qq.com).

Born from Tencent, Shiply distills years of mature release experience in mobile applications. It provides release management support for numerous Tencent apps with tens or hundreds of millions of users, supports agile development and rapid iteration for many internal innovative products, and is an indispensable release management platform for Tencent's internal client applications.

Over the past decade, the core evolution of client technology architecture has been improving dynamic delivery capability, placing unprecedented demands on app release infrastructure:

• Native technology: Evolved from monolithic architecture to componentization and pluginization, with core goals of module hot-plugging and issue hotfixing—shortening fix paths and improving iteration flexibility.

• Cross-platform technology: From Hybrid through RN and Flutter to KMM (Kotlin Multiplatform Mobile), evolution focuses on hot reload in development and hot update at runtime—to accelerate development and achieve runtime seamless updates.

Today, the scope of "release" has fundamentally changed: it is no longer limited to traditional install package release (store listing), but extends to dynamic release of offline packages, plugin packages, hotfix patches, cross-platform dynamic artifacts, and more—even real-time delivery of in-package resources and app configuration.

Shiply continuously explores release forms and expands release categories, building a unified release platform covering the full client lifecycle. This capability system aims to seamlessly support full-scenario release needs across different technology stacks—whether for technical optimization, new feature launches, or high-frequency operational campaigns, providing efficient, stable, and flexible release assurance.

I. Overview of Shiply Full-Scenario Release Capabilities​

Shiply provides full-scenario, full-lifecycle software delivery management, including two major release modes: install package release and dynamic release.

Traditional Install Package Release

• In-app beta distribution: Internal distribution of iOS/Harmony enterprise-signed packages and Android DailyBuild packages within the enterprise.

• In-app upgrade: Android APK in-app self-upgrade; iOS/Harmony update prompts.

• Invite and open testing: For example, iOS (TestFlight) and Harmony (AppGallery) invite testing and open testing.

• App store submission: Supports automatic package upload and submission for iOS (App Store), Android (major phone manufacturer app stores), and Harmony (AppGallery).

Dynamic Release

Deconstruct install packages into code (executable binaries, library files), configuration, and resources for partial dynamic updates:

• Cross-platform release (cross-platform code): For build artifacts of various cross-platform frameworks (Kuikly, Hippy, Flutter, React Native, etc.), supports synchronized release across multiple platforms and products, greatly improving release efficiency.

• Hotfix release (native code): Publish patches to urgently fix online issues without submitting a new install package to app stores.

• Remote resource release (resource files): Supports on-demand loading and updates of any files such as on-device AI models, themes, fonts, skins, images, animations, and SO libraries.

• Remote configuration release (configuration files): Supports dynamic updates for DSL dynamicization, routing and API dynamicization, dynamic tuning parameters, feature switches, and other scenario configurations.

Shiply's dynamic release solution aims to achieve seamless updates of app features, data, configuration, and visual styles, freeing you from dependence on app store review processes.

II. Core Value of Dynamic Release​

2.1 Meeting Agile Business Iteration Needs​

• Refined operations drive high-frequency release: Mobile internet has entered stock competition; slowing user growth requires enterprises to shift to refined operations. Businesses need frequent updates to optimize experience, run A/B test innovations, and conduct campaign operations. Traditional app store review processes (iOS takes 1–3 days) cannot meet demand; dynamic release enables "minute-level" hot updates, avoiding iteration delays that cause user churn.

• Hotspot scenarios drive rapid feature launch: Video, news, sports, and similar products must quickly respond to holiday campaigns, social hotspots, and live sports events. Sudden campaigns can cause traffic spikes requiring dynamic feature adjustments.

2.2 Solving Pain Points of Lagging Install Package Updates​

• Long user upgrade cycles: Traditional install package updates depend on user willingness to upgrade; version coverage improves slowly and version fragmentation is hard to eliminate. Dynamic release achieves user-invisible updates, ensuring all users immediately use the latest features.

• Cost of forced updates: Forced updates easily trigger user resistance; in stock competition, there is user churn risk. Dynamic release reduces risk through progressive updates.

2.3 Addressing Multi-Platform, Multi-Product Technical Challenges​

• Platform diversification: Domestic phone manufacturers' software capabilities continue improving; self-developed systems such as Harmony OS and Hyper OS keep emerging.

• Product diversification: To reach lower-tier markets, "Lite" and other multi-version apps are often needed.

As platforms and products multiply, feature reuse becomes key to reducing development costs and improving iteration efficiency, driving cross-platform development frameworks and cross-platform dynamic release needs.

2.4 Value for Users and Developers​

Seamless dynamic release can solve many pain points for users, developers, operations, and business teams:

• For users: Annoying update popups, forced exits, update failures, new version bugs affecting usage.

• For developers/operations: Tight release windows, high launch risk, user churn, slow issue fixes, poor user experience, more negative reviews, business losses.

III. Dynamic Release: Cross-Platform Release​

3.1 Pain Points of Cross-Platform Release​

Cross-platform development frameworks (Kuikly, Hippy, Flutter, React Native, etc.), with "write once, run everywhere" advantages, have become industry standards for efficiency and quality. But their release complexity far exceeds traditional release train mode:

• Release efficiency bottleneck:

  • Platform differences require separate builds for iOS, Android, Harmony, Web, and other platforms—multi-end release workload doubles;

  • Cross-platform development's flexibility of "page" as release unit means more pages lead to higher release frequency.

• Cross-app reuse complexity: Modules (such as weather modules) often serve multiple host apps (such as QQ and TIM), further amplifying release scale.

• Dependency management challenges: Module versions and host app compatibility, upgrade/downgrade management are complex.

3.2 Cross-Platform Release Solution​

To address these complex release challenges, Shiply launched the "Cross-Platform Release" solution to deeply optimize the release process.

• Bind different platform resource IDs per module: Modules support binding resource package IDs under different platforms and products, enabling unified release process management.

• Cross-end module dependency issues:

After splitting into finer modules, dependencies may form between modules. Updating a single module depends on updating underlying modules, creating dependency update dilemmas.

Shiply supports multi-module aggregated release. When the client pulls any module, the Shiply SDK updates associated modules locally together, solving potential issues from inconsistent dependency module release and download timing.

• Separately configurable release conditions

  • Flexible release: Flexibly choose to release to one or more products.

  • Powerful rules: Includes 20+ built-in system conditions for audience, region, network, system version, device model, and more. Supports profile and A/B experiment audience targeting; supports ultra-large audience packages at tens of millions scale. Provides global conditions, condition templates, custom conditions, and other rule filling methods. Supports user-defined attributes as delivery conditions—release conditions can expand infinitely.

• Automatic delta: The platform automatically generates delta packages for the last N published tasks, saving up to 60–80% traffic with significant bandwidth savings.

• Unified gradual rollout strategy

Rich gradual rollout strategies: batch gradual rollout, proportional gradual rollout, smooth gradual rollout, scheduled release after gradual rollout, and more. Proportional gradual rollout addresses different product user scale differences.

Automated gradual rollout process: Gradual rollout batches flow automatically; gradual rollout runs unattended.

• Unified release process control

  • Full release lifecycle management: Standardized process (test, experience, approval, gradual rollout, full release, rollback, stop) provides complete release lifecycle management. Mechanisms at pre-release, during release, and post-release stages ensure release safety.

  • Independent process control: Supports pause, stop, and rollback for any product in aggregated release—unified multi-end control with maximum flexibility. When a specific product's release has issues, targeted damage control is possible.

3.4 Release Monitoring and Rollback Mechanisms​

Cross-platform development improves feature reuse and development efficiency but also brings longer logic chains. From a temporal dimension, chains include: download chain, load chain, and usage chain.

For example, when using the Hippy framework (similar to RN), steps include bundle startup download or pre-warm download, bundle decompression, Hippy engine initialization, bundle loading, JS loading and execution, page rendering, and more—each step may have performance issues and quality risks. Therefore, we need to upgrade our measurement indicator system to address new challenges from cross-platform release.

Full-chain release monitoring and rollback: Based on Tencent's Aegis frontend monitoring framework, Shiply developed monitoring SDKs for Hippy and Kuikly cross-platform frameworks. Through SDK integration with the Bugly monitoring platform, full-chain monitoring, alerting, and rollback for both cross-platform artifacts is achieved.

• Download chain: Supports monitoring of configuration pull success rate, package download coverage, and load success rate

• Load chain: Supports page load time, second-open rate metrics, and drill-down analysis of detailed metrics.

• Execution chain (runtime): Supports error logs, network request error codes and latency, various custom reports

• Native core metrics: Supports monitoring, alerting, and rollback for Crash, ANR, FOOM, ERROR, privacy compliance, and custom business metrics

3.5 Cross-Platform Release Support Status​

Shiply currently supports cross-platform aggregated release for H5, Hippy, and React Native framework artifacts, and also supports Flutter, Kuikly, and other framework dynamic SDK + release solutions:

• Flutter dynamic delivery: Supports hotfix and dynamic delivery at the Dart language layer in Flutter. Fully in-house solution focused on high performance and native development experience—performance and usability far exceed traditional JS and AST approaches.

• Kuikly dynamic delivery: Supports multi-end dynamic delivery on Android, iOS, Harmony, and more. On Android, uses native-like Dex loading mode—20% faster first screen vs SO mode. On iOS, achieves native-indistinguishable first screen and smoothness.

In June 2025, we surveyed usage of popular cross-platform frameworks Flutter and RN in the market:

• Flutter overall penetration is about 13%, highest in travel apps (29.5%).

• React Native overall penetration is about 9%, highest in travel products (18.2%).

Cross-platform framework penetration in apps still has significant room to grow. Shiply Pro (external service) will gradually open related capabilities to help industry apps better leverage cross-platform development and push features to market faster and more securely through dynamic release.

3.6 Cross-Platform Release Summary​

Shiply's cross-platform release solution systematically solves high-frequency release challenges in cross-platform, cross-app scenarios. It can coordinate complex cross-platform, cross-app release tasks simultaneously. Its core lies in a flexible release rules engine and powerful client-side SDK capabilities that solve inter-module dependency issues, support automatic downgrade, one-click rollback, and other key operations—completely breaking cross-platform release barriers. Only by achieving high-frequency dynamic release can cross-platform frameworks deliver maximum value.

IV. Dynamic Release: App Hotfix​

4.1 Hotfix Use Cases​

Facing sudden online issues, traditional fix processes are slow and costly. Shiply hotfix technology provides real-time response capability:

Emergency Bug Fixes

Login failures, startup crashes, payment blockers, and other core experience issues are no longer helpless situations.

Improve Online Fault Tolerance

Strict version quality control means heavy process constraints and significant test resource investment. Finding 5% of issues requires 80% effort in full regression testing. Losing flexibility and agility also means losing market timing. Hotfix improves online fault tolerance, appropriately reducing ineffective test investment and getting products to market faster.

Lightweight Version Rapid Upgrade

New features from development launch through version coverage to data collection often need long cycles to close the loop. App hotfix provides lightweight update capability—for small feature changes, rapid user-invisible upgrades are possible.

4.2 Shiply Hotfix SDK Solution​

Android hotfix solutions by fix granularity fall into three categories: function-level, class-level, and Dex-level.

Comparison of these approaches:

Overall, each approach has pros and cons in performance impact, compatibility, and usage limits.

Shiply Hotfix SDK uses a hybrid engine (Tinker, Redirect) combining multiple approaches. Based on massive business practice, it is deeply optimized for patch stability, compatibility, and activation speed. Businesses need not concern themselves with engine differences; optimal packaging can be flexibly chosen at release time.

Fix capability: Except for system-managed resources such as AndroidManifest.xml and RemoteView, supports dex, res, and so fixes for feature-level updates.

• Tinker engine: Supports Dex, SO library, and resource replacement (comprehensive), provides rollback capability (safety), active community (WeChat open source). Essentially application and optimization of Android class loading mechanism.

• Redirect engine: Function stubbing approach. Redirect does not use annotation-based diff marking but uses DexDiff to analyze differences and automatically extract fix code—lower usage barrier for developers and avoids annotation invalidation from compile-time inlining optimization. We also strengthened auto code generation (class inheritance and few other features cannot be supported at principle level), maximizing support for adding/removing variables, functions, classes, lambda, etc.—keeping stubbing modification limits minimal.

4.3 Shiply Hotfix End-to-End Management Solution​

Shiply app hotfix provides one-stop patch release management including: task management, branch management, pipeline plugins, gradual rollout management, approval and rollout, gradual rollout, real-time data statistics, and release quality monitoring integration.

Shiply ensures fast, secure, stable release through standard release processes and supporting tools, connecting multiple systems involved in release to make release simpler and more reliable.

4.4 Shiply Hotfix Implementation Results​

Shiply has provided capability support for 30+ apps within the company, covering peak devices exceeding 1 billion/day, with patch load success rate up to 99.9%+. Over the past year, Shiply hotfix capability significantly improved stability and user experience in core scenarios for multiple company products:

• Core module stability and performance optimization: Quickly fixed crashes and stutters in Business A files, photo albums, local documents, preloading, and cold start.

• Critical user experience fixes: Ensured Business B screen casting experience, core pages (such as Olympics carousel) UI consistency, and process stutters.

• Business-critical flow assurance: Resolved Business C ad and splash screen loading, live room core features, and underlying page navigation anomalies.

• Basic functionality and compatibility adaptation: Hotfix and compatibility adaptation for Business D kernel engine, skins, mall, push, voice, and other high-frequency modules.

V. Conclusion: Evolution Hidden, Value Maximized​

In today's intensely competitive app market, product competitiveness is "evolution speed × iteration cost × user experience"—dynamic release capability has become one of the core engines of rapid app evolution. Shiply is committed to hiding the complexity of technical iteration behind the scenes. Through full-scenario, one-stop release capabilities, it helps developers create the ultimate smooth experience of seamless feature upgrades and invisible issue fixes for users—when technical iteration is invisible, product value shines brightest.

In the past six months, Shiply has also begun offering commercial services externally. With high-reliability, large-scale validated technical solutions, it has landed in consumer electronics, automotive, healthcare, e-commerce, content, social, and other industries—continuously providing high-quality dynamic release services, cross-end dynamic frameworks, app hotfix, and other capability support.

Welcome to visit Tencent Shiply to start a free trial and embrace a new paradigm of app release!

Or contact a Shiply Account Manager for consultation. You can also visit TDS Tencent Device Services for more product information and solutions.

Apple's ITMS (iTunes Store) errors are usually related to submitting apps or content to the App Store, especially issues when using tools such as Transporter, App Store Connect API, and altool. Apple defines and manages these errors mainly to ensure developers comply with technical specifications and review guidelines, while providing tools and documentation to help developers resolve issues.

• When submitting apps to App Store Connect, Apple's automated system runs pre-checks to detect common errors (such as signing and metadata format) and returns error codes and descriptions directly.
• Developers must fix issues based on error prompts and resubmit.

I. ITMS Error Types​

ITMS errors are typically numbered in ITMS-XXXXX format (e.g., ITMS-9000), covering the following common types:

1. Metadata errors
   • Issues related to app name, description, screenshots, keywords, and other metadata.
2. Binary file issues
   • Signing, architecture, or format errors in build versions (IPA files).
3. Compliance issues
   • Violations of App Store Review Guidelines (such as missing privacy policy, use of private APIs, non-compliant data collection).
4. Certificate and provisioning profile errors
   • Expired signing certificates, incorrect device permission configuration.
5. Server or network issues
   • Submission failures caused by Apple server outages or unstable developer networks.

II. How to Handle ITMS Errors​

1. Developer Support Channels​

• Contact Apple Technical Support: Submit issues through "Contact Us" in App Store Connect.
• Developer Forums: Search for similar cases or ask questions in Apple Developer Forums.
• Xcode and Transporter logs: Use detailed logs generated by tools to locate root causes.

2. Review Team Feedback​

• If the app passes pre-check but is rejected by the review team, developers receive an email with specific guideline clauses (such as violations of Guidelines 4.3, 5.1.1, etc.) and must fix and resubmit based on feedback.

III. ITMS Errors: Compilation and Binary Issues​

ITMS-90668​

Error Message

ERROR ITMS-90668: "Invalid Bundle Executable. The executable file contains incomplete bitcode."

Cause
Binary file does not correctly enable Bitcode or compilation parameters are incomplete.

Solution

1. Option 1: Disable Bitcode
   Check whether Bitcode is enabled in the binary file:

   otool -arch arm64 -l ./MXFFI | grep __LLVM | wc -l
   
   • Result 0 means ENABLE_BITCODE = NO
   • Non-zero result means ENABLE_BITCODE = YES

2. Option 2: Force remove Bitcode and re-sign

   # Remove Bitcode 
   xcrun bitcode_strip Flutter.framework/Flutter -r -o Flutter.framework/Flutter 
   # Re-sign Framework 
   codesign -fs "certificate name" Flutter.framework 
   # Re-sign entire App 
   codesign -fs "certificate name" --entitlements ${appPath}/entitlements.plist ${appPath}
   

ITMS-90087​

Error Message

ERROR ITMS-90087: "Unsupported Architectures. The executable contains unsupported architectures [x86_64,i386]."

Cause
Binary contains simulator architectures (x86_64/i386).

Solution
Add a build script to remove invalid architectures:

APP_PATH="${TARGET_BUILD_DIR}/${WRAPPER_NAME}" find "$APP_PATH" -name '*.framework' -exec lipo -remove x86_64 {} -output {} \;

ITMS-90209​

Error Message

ERROR ITMS-90209: "Invalid Segment Alignment. The binary does not have proper segment alignment."

Cause
Binary file segment alignment is abnormal.

Solution

1. Upgrade Xcode to the latest version.
2. Recompile third-party libraries using lipo.

ITMS-90125​

Error Message

ERROR ITMS-90125: "The binary is invalid. The encryption info is missing or invalid."

Cause
Binary file encryption information is missing.

Solution
Ensure binary encryption flags are not manually modified; use Xcode's default build process.

TMS-90048​

Error Message

ITMS-90048: This bundle is invalid - Your archive contains paths that are not allowed: [._Symbols]

Cause
The archive (.xcarchive) submitted to App Store Connect contains a hidden file ._Symbols that is not allowed.

On macOS 15.4, the APFS file system may automatically generate hidden files starting with ._ during file operations (such as rsync) to store Finder metadata or resource forks. During iOS builds, when the Symbols directory is generated, system file operations may trigger creation of the metadata file ._Symbols.

Solution
Solution 1: After building, unzip the IPA and delete ._Symbols
Solution 2: Submit through Product > Archive in Xcode

ITMS-90426​

Error Message

ITMS-90426: Invalid Swift Support - The SwiftSupport folder is missing. Rebuild your app using the current public (GM) version of Xcode and resubmit it.

Cause

SwiftSupport folder is missing

Solution

1. Set Build Settings -> Always Embed Swift Standard Libraries to YES
2. Repackage, then unzip the IPA and verify the SwiftSupport folder is included

IV. ITMS Errors: Version and Configuration Issues​

ITMS-90060​

Error Message

ERROR ITMS-90060: "Invalid CFBundleShortVersionString '1.2.2.1'. Must be a period-separated list of three non-negative integers."

Cause
Version number format does not meet the three-segment requirement.

Solution
Check CFBundleShortVersionString in all dependency libraries and change to three-segment format (e.g., 1.2.2).

ITMS-90062​

Error Message

"This bundle is invalid. The value for key CFBundleShortVersionString [...] must contain a higher version"

Cause
Submitted version number is lower than the approved version.

Solution
Ensure both CFBundleShortVersionString and CFBundleVersion are higher than the most recently approved version.

ITMS-90725​

Error Message

ITMS-90725: SDK Version Issue - This app was built with the iOS 15.5 SDK. All iOS apps submitted to the App Store must be built with the iOS 16.1 SDK or later, included in Xcode 14.1 or later."

Solution
Upgrade Xcode to 14.1 or later and recompile using iOS 16.1+ SDK.

ITMS-90098​

Error Message

The bundle identifier contains disallowed characters

Solution
Check and modify Bundle Identifier to ensure it does not contain disallowed characters

ITMS-90186​

Error Message

Invalid Pre-Release Train. The train version is closed for new build submissions

Cause

The pre-release train for this version is closed; new build submissions are not accepted

Solution
Check version settings in App Store Connect and ensure the submitted version number is correct

V. ITMS Errors: Privacy and Permission Issues​

ITMS-91053, ITMS-91056, ITMS-91061​

Error Message

ITMS-91053: Missing API declaration - Your app's code in the "Runner" file references one or more APIs that require reasons, including the following API categories: NSPrivacyAccessedAPICategoryDiskSpace. While no action is required at this time, starting May 1, 2024, when you upload a new app or app update, you must include a NSPrivacyAccessedAPITypes array in your app's privacy manifest to provide approved reasons for these APIs used by your app's code. For more details about this policy, including a list of required reason APIs and approved reasons for usage, visit: https://developer.apple.com/documentation/bundleresources/privacy_manifest_files/describing_use_of_required_reason_api.

ITMS-91056: Invalid privacy manifest - The PrivacyInfo.xcprivacy file from the following path is invalid: "PrivacyInfo.xcprivacy". Keys and values in your app's privacy manifests must be valid. For more details about privacy manifest files, visit: https://developer.apple.com/documentation/bundleresources/privacy_manifest_files.

ITMS-91061: Missing privacy manifest - Your app includes "Frameworks/X.framework/X", which includes X, an SDK that was identified in the documentation as a commonly used third-party SDK. If a new app includes a commonly used third-party SDK, or an app update adds a new commonly used third-party SDK, the SDK must include a privacy manifest file. Please contact the provider of the SDK that includes this file to get an updated SDK version with a privacy manifest. For more details about this policy, including a list of SDKs that are required to include signatures and manifests, visit: https://developer.apple.com/support/third-party-SDK-requirements.

Cause
On February 29, 2024, Apple released Privacy Updates for App Store Submissions, explicitly requiring new or updated apps to include a PrivacyInfo.xcprivacy privacy manifest file; otherwise review may be rejected. Some third-party SDKs integrated as binaries also require signatures.

Developers need to create a PrivacyInfo.xcprivacy privacy manifest file for the SDK.

• NSPrivacyAccessedAPICategoryFileTimestamp
• NSPrivacyAccessedAPICategoryUserDefaults
• NSPrivacyAccessedAPICategoryDiskSpace
• NSPrivacyAccessedAPICategoryUserDefaults

Solution

Manually create PrivacyInfo.xcprivacy (modify according to your situation)

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>NSPrivacyTracking</key>
    <false/>
    <key>NSPrivacyCollectedDataTypes</key>
    <array/>
    <key>NSPrivacyAccessedAPITypes</key>
    <array>
        <dict>
            <key>NSPrivacyAccessedAPIType</key>
            <string>NSPrivacyAccessedAPICategoryUserDefaults</string>
            <key>NSPrivacyAccessedAPITypeReasons</key>
            <array>
                <string>CA92.1</string>
            </array>
        </dict>
        <dict>
            <key>NSPrivacyAccessedAPIType</key>
            <string>NSPrivacyAccessedAPICategoryFileTimestamp</string>
            <key>NSPrivacyAccessedAPITypeReasons</key>
            <array>
                <string>C617.1</string>
            </array>
        </dict>
    </array>
</dict>
</plist>

If you have many third-party SDKs, consider using automated fix scripts:

• https://github.com/crasowas/app_privacy_manifest_fixer

• https://github.com/ymoyao/cocoapods-privacy

App Store privacy manifest analyzer:

• https://github.com/crasowas/app_store_required_privacy_manifest_analyser

ITMS-91061​

Error Message

ITMS-91061: "Missing privacy manifest. Third-party SDK must include a privacy manifest."

Solution
Contact third-party SDK providers to obtain updated versions that include privacy manifests.

ITMS-90683​

Error Message

"Missing Info.plist key. Your app's code references [...] but the Info.plist file does not contain [...]"

Cause
Accessing sensitive data (such as location, camera) without providing privacy descriptions.

Solution
Add corresponding keys in Info.plist:

• NSLocationWhenInUseUsageDescription
• NSCameraUsageDescription

ITMS-90078​

Error Message

"Missing push notification entitlement [...] entitlements do not include the 'aps-environment' entitlement"

Cause
App contains APNs-related APIs but does not declare push notification entitlement

Solution

1. Enable push notifications in project Capabilities
2. Check whether third-party libraries implicitly reference APNs APIs; use nm or otool to inspect symbol references in binaries

VI. ITMS Errors: Signing and Provisioning Profile Issues​

ITMS-9000​

Error Message

ERROR ITMS-9000: "The binary you uploaded was invalid."

Cause
Provisioning profile expired or was deleted.

Solution
Regenerate and download provisioning profile; repackage with valid profile.

ITMS-90165​

Error Message

ERROR ITMS-90165: "Invalid Provisioning Profile Signature. The provisioning profile [...] is not valid"

Cause

Provisioning profile signature is invalid (caused by Apple updating signing mechanism)

Solution

1. Re-edit and download provisioning profile.
2. Delete old files and repackage.

ITMS-90046​

Error Message

ERROR ITMS-90046: "Invalid Code Signing Entitlements"

Cause
Code signing entitlements are invalid—possibly due to provisioning profile issues or non-standard Bundle Identifier naming

Solution
Check provisioning profile configuration and ensure Bundle Identifier naming meets requirements

ITMS-90535​

Error Message

Invalid Code Signing Entitlements

Cause
Bundle Identifier, version number, or other information in third-party info.plist files is not correctly configured

Solution
Modify third-party info.plist files and add correct Bundle Identifier, version number, and other information

VII. ITMS Errors: UI and Icon Issues​

ITMS-90809​

Error Message

ERROR ITMS-90809: "Deprecated API Usage. UIWebView is no longer accepted."

Solution
Replace UIWebView with WKWebView and recompile.

ITMS-90022, ITMS-90025​

Error Message

# ITMS-90022
Missing required icon file. The bundle does not contain an app icon for iPhone / iPod Touch of exactly '57x57' pixels, in.png format for iOS versions < 7.0
# ITMS-90025
Missing recommended icon file. The bundle does not contain an app icon for iPhone / iPod Touch of exactly '120x120' pixels, in.png format for iOS versions >= 7.0

Solution
Add icons of corresponding sizes in AppIcon.appiconset in images.xcassets and configure in Contents.json

ITMS-90705​

Error Message

Launch storyboard not found. Make sure you specify the launch storyboard filename without a filename extension for the key UILaunchStoryboardName in the Info.plist

Cause

Launch storyboard not found; UILaunchStoryboardName value in Info.plist is incorrect

Solution
Check UILaunchStoryboardName value in Info.plist and ensure it matches the launch storyboard filename without extension

ITMS-90096​

Original Error Message

Missing recommended icon file. The bundle does not contain an app icon for iPhone / iPod Touch of exactly '57x57' pixels, in.png format for iOS versions < 7.0

Cause

App is missing LaunchImage or LaunchImage configuration has issues

Solution
Add launch images of corresponding sizes to project root and modify info.plist, or check whether LaunchScreen.storyboard exists

VIII. ITMS Errors: Other Common Issues​

ITMS-90474 / ITMS-90475​

Error Message

ERROR ITMS-90474: "Invalid Bundle. iPad Multitasking support requires these orientations: 'UIInterfaceOrientationPortrait,UIInterfaceOrientationPortraitUpsideDown,UIInterfaceOrientationLandscapeLeft,UIInterfaceOrientationLandscapeRight'. Found 'UIInterfaceOrientationLandscapeLeft,UIInterfaceOrientationLandscapeRight' in bundle '...'."

ERROR ITMS-90475: "Invalid Bundle. iPad Multitasking support requires launch story board in bundle '..."

Cause iPad split-screen adaptation requires full-screen declaration

Solution
Add to Info.plist:

<key>UIRequiresFullScreen</key> <true/>

ITMS-90529​

Error Message

ERROR ITMS-90529: "IInvalid package. Applications built with sdk 9.0 or later must be packaged as proper IPA files"

Cause

Incorrect packaging method; not using .ipa file format

Solution
Place compiled .app in Payload folder and compress as .ipa file.

ITMS-90983​

Error Message

ERROR ITMS-90983: "Missing purpose string in Info.plist for media classification."

Cause

iOS 16 and above require purpose strings for media classification in Info.plist

Solution
Add media classification descriptions in Info.plist:

• NSMediaLibraryUsageDescription
• NSAppleMusicUsageDescription