After a Swift project is released, without additional processing, class and method names often appear directly in the binary. Opening the IPA with strings or Hopper easily reveals names like:

UserProfileViewModel
PaymentManager
SubscriptionService

These names inherently carry business semantics. For apps involving membership, payment, or recommendation algorithms, such exposure is not ideal.

In a pure Swift project, we performed a complete obfuscation process. The goal was to make the decompiled structure difficult to understand quickly. This workflow is divided into two parts: Compilation Phase Processing + IPA Layer Supplementary Processing.

1. First, Confirm Whether Swift Symbols Are Exposed

After building the Release version IPA, you can directly check:

strings AppBinary | grep ViewModel

If the output is similar to:

UserProfileViewModel
OrderListViewModel
VipCenterViewModel

It indicates that symbols have not been processed.

Swift retains certain symbol information by default, especially when stripping or obfuscation is not enabled.

2. Reduce Symbol Information at Build Phase

In Xcode, you can adjust some build parameters:

Strip Swift Symbols = YES
Dead Code Stripping = YES

After rebuilding, check again:

strings AppBinary

The output will be reduced, but core class names still remain. This step reduces debug symbols rather than completely obfuscating them.

3. Avoid String Exposure of Business Logic

In Swift projects, strings can also become analysis entry points, for example:

"vip_purchase_success"
"user_login"
"payment_callback"

If these strings are directly written in the code, they will be compiled into the binary.

You can perform simple processing in the code, such as:

  • Using a mapping table to replace key strings
  • Or decoding at runtime after simple encryption

For example:

let key = decode("YTFiMmMz")

Although not completely hidden, this reduces direct readability.

4. Handle Reflection and Dynamic Calls

Some logic in Swift may rely on strings, for example:

NSClassFromString("MyApp.PaymentManager")

If class names are modified, such calls will fail.

Before preparing for obfuscation, you need to organize:

  • Which classes are called via strings
  • Which methods are used by selectors

These need to be added to a “preservation list” to avoid subsequent obfuscation affecting runtime.

5. Perform Swift Symbol Obfuscation at IPA Layer

Relying solely on build phase processing, class names can still be analyzed.

At the IPA layer, you can directly replace symbols in the binary.

After loading the IPA, Ipa Guard parses Swift symbols and lists:

Swift classes
Swift methods
Method parameters
Variables

In the interface, you can filter, for example:

UserProfileViewModel
PaymentManager
SubscriptionService

Code Obfuscation

After executing obfuscation:

UserProfileViewModel → a92kd3

Check again with strings:

strings AppBinary | grep UserProfile

The original name will no longer appear.

6. Handle Method Parameters and Variables

In Swift projects, method parameter names may also expose logic, for example:

func purchase(productId: String, userId: String)

Ipa Guard supports obfuscating parameter names:

productId → a1b2
userId → c3d4

After processing, even if decompiled, it is difficult to understand parameter meanings.

7. Handle Associations Between Resource Files and Swift Logic

In Swift projects, much logic is driven by resource files, for example:

config/payment.json
assets/vip_banner.png

If these file names remain unchanged, they can still assist analysis.

In the resource module of Ipa Guard, you can select:

  • Images
  • JSON
  • HTML
  • JS

After execution:

payment.json → k39sd.json
vip_banner.png → a82kd.png

File Names

8. Modify Resource MD5 and Identifiers

If multiple apps share resources, identical file content may become an identification basis.

After enabling MD5 modification:

  • File content remains unchanged
  • MD5 changes

Verify:

md5 payment.json

The result will be different.
md5

9. Clean Up Debug Information

In Swift projects, log information may also expose logic.

Check:

strings AppBinary | grep print

If debug information exists, it can be cleaned up during IPA processing.

Ipa Guard supports deleting some debug information to make the binary more concise.

10. Re-sign and Verify

After obfuscation is complete, re-signing is required.

You can use:

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

Or complete signing directly in Ipa Guard.
Re-signing

After installation, test:

  • Page loading
  • Network requests
  • Reflection calls
  • Dynamic logic

If some functions are abnormal, you need to return to the obfuscation configuration for adjustments.

Swift code obfuscation cannot rely solely on compilation parameters. Class names, method names, parameter names, and resource file structures all affect app readability. By stripping symbols at the build phase and combining with Ipa Guard for binary obfuscation at the IPA layer, supplementary protection can be achieved without modifying the project structure.

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