混淆 Objective-C 代码以获得可重用的 iOS 包
可能的重复：
Objective-C 代码混淆
我正在尝试组合一个可以在多个中重用的 iOS 包应用程序。我希望能够将其捆绑起来供其他人轻松插入和使用，并且我希望混淆代码，以便没有人可以阅读它。
在构建框架、静态库或其他解决方案来实现此目的之间，您会推荐什么？为什么？
Possible Duplicate:
Objective-C Code Obfuscation
I am trying to put together an iOS package that can be reused in multiple apps. I would like to be able to bundle it up for others to easily plug in and use, and I would like to obfuscate the code so that no one can read it.
What would you recommend between building a framework, a static library, or another solution to accomplish this and why?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果您要为 iOS 进行分发，您有两个选择：
既然您询问的是隐藏内容，我认为#2 不是您正在寻找的内容。
至于#1，你能做的最好的事情就是不要告诉第 3 方用户更多的东西。他们仍然能够使用运行时来查找方法、属性和实例变量等。如果你在 C 语言中做所有事情（即没有 Objective-C 类），那么他们仍然可以使用诸如
otool转储符号。简而言之：
可能不值得尝试“混淆”您的代码。只需告诉他们需要了解的内容，然后给他们一个 .a 文件和他们需要的标头。
If you're distributing for iOS, you have two options:
Since you're asking about hiding stuff, I don't think #2 is what you're looking for.
As for #1, the best you can do is just not tell 3rd party users about more stuff. They'll still be able to use the runtime to find methods and properties and instance variables, etc. If you're doing everything in C-land (ie, no Objective-C classes), then they can still use things like
otoolto dump symbols.In short:
It's probably not worth trying to "obfuscate" your code. Just tell them about the stuff they need to know about, then give them a .a file and the headers they need.
框架是共享代码的标准 Cocoa 方法。您可以将框架作为已编译代码库和公共标头集合进行分发，而无需使任何底层 Objective-C 源代码可见。当然，专门的黑客仍然可以读取机器代码，但这将是一项艰巨的任务，并且可能不值得他们花费时间。
如果您确实担心敏感代码，您可以考虑基于互联网的服务，其中您的库调用您控制下的远程服务器来执行一些业务逻辑。这种方法涉及更多，并且无法为您的客户提供足够的灵活性。
A framework is the standard Cocoa approach to shared code. You can distribute a framework as a compiled code library and a collection of public headers without making any of the underlying Objective-C soure code visible. Of course, a dedicated hacker could still read the machine code, but this would be a big undertaking, and probably not worth the time they would have to spend on it.
If you are really concerned about sensitive code, you could consider an internet-based service, in which your library calls out to a remote server under your control to perform some business logic. This approach is quite a bit more involved, and does not offer as much flexibility for your customers.