After working on multiple projects, it’s common to encounter an issue: multiple apps derived from the same codebase are rejected by the App Store for being duplicate apps (Guideline 4.3).

I once maintained a set of utility apps with consistent functional frameworks, only differentiated in content and UI. During the first submission, several versions were directly rejected, with a clear reason: structural similarity was too high.

Later, instead of focusing on “copywriting packaging,” we prioritized application structure, resource characteristics, and binary layer differences, redefining a workflow.

1. First, Identify Where “Similarity” Actually Lies

After receiving a rejection, don’t rush to change the UI; start by inspecting the IPA layer.

Unpack the IPA:

unzip app.ipa

Navigate to:

Payload/App.app

Focus on three types of content:

1. Executable File

strings AppBinary | grep Manager

If different apps output:

UserManager
OrderManager
VipService

Exactly the same, this layer has already formed a structural fingerprint.

2. Resource Directory

assets/images/home_banner.png
config/app_config.json

If multiple apps have identical resource paths, they can be identified.

3. H5 / JS Content

main.jsbundle
index.html

If the content is completely identical, merely changing the UI is insufficient.

2. Beyond Functional Differences, Structural Changes Are Needed

Functional differences (e.g., adding modules, modifying interactions) are indeed important, but at the technical level, it’s also necessary to ensure internal structures are no longer completely identical.

We made two types of adjustments:

  • Code structure differentiation
  • Resource structure differentiation

These parts were completed without altering the business logic.

3. Apply Differentiation to Binary Symbols

If the source code remains unchanged, processing can be done at the IPA layer.

After loading the IPA with Ipa Guard, you can see:

OC classes
Swift classes
OC methods
Swift methods

Code Obfuscation

In different apps, we implemented different obfuscation strategies:

For example:

App A:

UserManager → a82kd3

App B:

UserManager → x92ls1

The same class is mapped to different names in different packages.

After this processing, even if the functionality is consistent, the binary structure becomes different.

4. Resource Path Refactoring (More Critical Than UI)

Many people only change UI images but overlook path structures.

For example:

assets/images/home_banner.png

If all apps are the same, they can still be easily identified.

In Ipa Guard’s resource module, you can:

  • Batch rename
  • Automatically update references

Resource Obfuscation

After processing:

home_banner.png → a91ks.png

Going further, we used different strategies in different apps:

  • App A uses short random names
  • App B uses long random names

This creates differences in the resource structure itself.

5. Handle Resource Fingerprints (Avoid “Same Content” Identification)

If resource content is completely identical, even renaming may be identified.

Ipa Guard provides MD5 modification capability:

md5

Different before and after processing.

The effect of this step is:

  • Content unchanged
  • Fingerprint different

6. Front-End Resources Should Also Participate in Differentiation

If the app includes WebView or React Native modules:

main.jsbundle
index.html

Processing can be done during the build phase:

terser main.js -o main.min.js

Different apps use different compression strategies or variable naming rules.

Then, use Ipa Guard to modify file names.

Clean Debug Information (Reduce Comparable Content)

Debug information is also a characteristic.

Check:

strings AppBinary | grep NSLog

If multiple apps have identical log content, they may also be identified.

In Ipa Guard, you can enable debug information cleaning.

Signing and Installation Testing

After all processing is complete, re-signing is required.

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

During testing, focus on:

  • Whether pages load normally
  • Whether functionality is affected
  • Whether resources load

App Store review doesn’t just look at functionality; it also considers similarity between apps. Functional differences are one part, but code structure and resource characteristics are equally important.

Reference link: https://ipaguard.com/blog/162