Take the 2-minute tour ×

I've researched quite a bit, both on SO, as well google-ing all over the place, but I can't seem to find a straight-forward answer in regards to code obfuscation for iPhone/iPad apps written in Objective-C.

My questions are these:

  1. Is there a way to do it? If so, how?
  2. Is it worth it?
  3. Does Apple allow it, or have a problem with it, when the app is submitted to them?
share|improve this question
What are your objectives? –  xyzzycoder Apr 5 '11 at 18:46
Some people write obfuscated code without even trying. –  Caleb Apr 5 '11 at 19:26
add comment

5 Answers

up vote 21 down vote accepted

There doesn't seem to a code obfuscator for Objective-C. But let's assume for a moment that one does exist.

Apple will probably not reject an obfuscated app as long as it doesn't crash. The main question is: what is the point of obfuscation ? Normally, you want to obfuscate code to protect your knowledge, for example if your program uses a copy protection you want to make it harder for a potential cracker or if you're using some advanced algorithm you don't want the business competitors to be able to decompile it.

The copy protection is already been taken care of on iOS. Although through jailbreaking a normal app can be copied and run, I'd say the actual number of users who do this is fairly low (at least a lot lower than on "regular" computers like PC and Mac). Do you expect piracy such a big problem that you need to obfuscate ?

If you do have important knowledge to protect then obfuscation might be worthwhile. Obfuscation has its downsides: you can't debug your obfuscated app any more. Crash reports will be useless.

You might also want to read the article Obfuscating Cocoa.

Back to the fact there doesn't seem to be an obfuscator: What you can do is this trick: say you have a header like this:

@interface MyClass : NSObject {

- (void)myMethod;

You could do a cheap obfuscation like this:

#ifndef DEBUG
#define MyClass aqwe
#define myMethod oikl

@interface MyClass : NSObject {

- (void)myMethod;

This way you can still use meaningful symbols in your source, but the compiler would turn it into "garbage" when not compiling for debugging.

share|improve this answer
Thanks very much for the answers. that helps a lot! –  bpatrick100 Apr 5 '11 at 23:33
@DarkDust would this method prevent decompiling back to original method names? –  ewok Feb 22 '12 at 16:12
There are some major downsides to this approach. It is difficult to maintain KVC with it, or deal with dynamic method dispatch (opening up lots of opportunities for Release-only crashes). It doesn't work well for methods that take multiple parameters. And if myMethod exists in multiple classes, it could create some real interesting compile errors. It's a clever idea, and I love the simplicity, but I can't imagine it being worth the cost in any practical system. –  Rob Napier Feb 22 '12 at 16:31
@ewok: Yes, the original names would only exist in your source. In the compiled binary you'd have the "mangled" names. –  DarkDust Feb 22 '12 at 19:39
setValueForKey: will crash unless you happen to have an ivar with the same name that you didn't obfuscate (in which case it can have surprising side effects if your have non-trivial accessors). That means nib files will tend to cause crashes. Anything that constructs a selector from a string (NSSelectorFromString()) will crash for the same reason. If you have the same method in A and B but obfuscate differently in each .m, then if A calls [B method], it will have a compile failure. So you need a way to keep track of all of them. I'm not sure how @selector() reacts to this; might work. –  Rob Napier Feb 22 '12 at 20:04
show 2 more comments
  1. Yes, you can take a look at EnsureIT for Apple iOS
  2. It depends. Security normally introduce complexity, you have to balance it between usability.
  3. Apple should not have any problem with it. (Correct me if I'm wrong)
share|improve this answer
the only true useful answer here. thanks. –  jimpic Jun 24 '13 at 13:20
add comment

Further to the earlier answers there are now several 3rd party tools that offer some degree of obfuscation and integrity protection including :-

  1. Arxan,
  2. Metaforic,
  3. Cryptanium

They vary in capabilities and include :-

  1. Control flow obfuscation e.g. ARM instruction flows are mangled with redundant instructions to try to hide the original purpose of the code,
  2. Class and Method renaming - renames your methods and classes to meaningless names although you have to be careful where this is used as you can easily break your app because the Objective-C runtime is expecting to find certain names,
  3. String encryption - all static strings in the app are encrypted and code is inserted to decrypt the strings just before use in order to make static analysis harder
  4. Anti-debug - code is inserted to break the usual debuggers (not always successfully),
  5. Anti-tamper - usually builds a network of checksums that protect the binary code from modification,
  6. Objective-C runtime protection - usually checks obj-c registered method implementations to make sure that they are in the app and haven't been 'swizzled'.

All of these tools are very expensive and not without their problems so you really need an application that requires a high degree of integrity in order to consider them e.g. banking or where DRM is very important.

For these types of app you will also need skilled penetration testers to ensure that your app is not exposed in other ways as these tools are often only as good as the people using them and there are still other OS vulnerabilities that will need mitigating that the tools don't address.

share|improve this answer
add comment

The executable of an app is already encrypted by Apple, and the executable code segment of the app sandbox isn't writeable, so you can't do additional encryption. And the optimizer pass of the Objective C/C compiler already creates something very different from the original source code. Using more C and less Objective C will reveal less of your function names, as method names are embedded in visible plain text, but C function names are not. So any trade secret type code should probably be coded in plain C, and compiled with the optimizer turned all the way up. You could obfuscate your the UIWebView Javascript embedded within the app bundle, I suppose.

share|improve this answer
Is it really encrypted ? AFAIK it's only signed. –  DarkDust Apr 6 '11 at 6:20
@DarkDust - Take a look at the ARM binary executable before you submit an app to Apple, and what's inside the ipa/zip file after you download it from the App store. –  hotpaw2 Apr 6 '11 at 7:46
it's easy to decrypt and then you get all the plain selector names - so this is not the solution. –  jimpic Jun 24 '13 at 13:20
add comment

Probably not because Objective-C compiles out to processor instructions rather than being interpreted or compiling to byte code, so decompiling the code will already produce pretty obscure results. Obfuscation is something you usually only needed when you have to distribute the source of your code, like in interpreted languages like JavaScript, in order for it to run even when you want the code to remain secret.

share|improve this answer
Actually, due to the dynamic nature of Objective-C the binaries are full of class and method names. Just these strings already allows to gain some insight in how the program works. –  DarkDust Apr 5 '11 at 19:18
add comment

Your Answer


