I need to obfuscate my iOS mostly C and Objective-C based app.
https://github.com/obfuscator-llvm/obfuscator/
llvm-obfuscator provide quite well solution without much additional work related. Obviously it will not prevent people from reversing it but at least it will lift a bar a little. App it self is designed good enough to protect few security related mechanisms but I would like to compile it with custom compiler to make it even more harder. But it raises few questions
If apple actually allow compiling with custom compilers
How it may affect speed and stability of application, o-llvm is
quite old 3.6.1 while apple already published their llvm 8.0 - not
sure what has been added improved or changed
o-llvm does not support latest xcode. I have abandoned idea and wrote my own obfuscation script which encrypts all variables and methods except Cocoa ones. It's not that good like o-llvm but it works great.
Related
This is to my requirement where, I would like to distribute libraries in binary form so as to protect intellectual property, license agreements etc. So use of Cocoapods, Carthage, SPM is ruled out to solve this.
Since ABI (application binary interface compatibility) is yet to be adapted or even announced by Apple,what is the best way to handle this.
Reading this nice insight about ABI and similar concern, it looks solution is ad-hoc -- to release binary libraries for all coming Xcode where Swift language is upgraded.
While not that similar question is there on stack Swift compatibility between versions for a library
Answer to my own question looks to go on with ad-hoc way and wait & watch until Switch 4.0 (may) to come and help.
I tried all other ways suggested on this (toggle SWIFT_VERSION settings and use of .xcconfig to set version ).
If I create an Xcode project with the iOS Single View Application template and choose Swift for the language, will the compiler exclude from the release build (binary) functions that never get called?
I'm wondering because I want to include a third-party library that has a lot of superfluous classes & functions, and I want to keep my app small & fast.
While I agree with comments, it is unlikely to impact performance in any significant way even if it was included...
Xcode 6 uses Apple LLVM Compiler Version 6.1, depending on how closely related it is to LLVM Developer Group's version the optimization feature is available http://llvm.org/docs/Passes.html with options such as -dce: Dead Code Elimination, -adce: Aggressive Dead Code Elimination.
One way to know for sure what is included is checking the assembly output using -emit-assembly option in the swift compiler and review the output, or opening the binary in a disassembler such as Hopper ( http://www.hopperapp.com/download.html )
The first thing I tried is to create a static library but later I found out that it's not supported yet. Apple Xcode Beta 4 Release Notes:
Xcode does not support building static libraries that include Swift
code. (17181019)
I was hoping that Apple will be able to add this in the next Beta release or the GA version but I read the following on their blog:
While your app’s runtime
compatibility is ensured, the Swift language itself will continue to
evolve, and the binary interface will also change. To be safe, all
components of your app should be built with the same version of Xcode
and the Swift compiler to ensure that they work together.
This means that frameworks need to be managed carefully. For instance,
if your project uses frameworks to share code with an embedded
extension, you will want to build the frameworks, app, and extensions
together. It would be dangerous to rely upon binary frameworks that
use Swift — especially from third parties. As Swift changes, those
frameworks will be incompatible with the rest of your app. When the
binary interface stabilizes in a year or two, the Swift runtime will
become part of the host OS and this limitation will no longer exist.
The news is really alarming for me a person who writes components for other developers to use and include in their apps. Is this means that I have to distribute the source code or wait for two years?. Is there any other way to distribute the library without exposing the code (company policy)?
Update:
Is Swift code obfuscation an option at this point ?
Swift is beta now, and even for 1.0 Apple has been pretty clear they're after a restricted feature set -- better to do a small number of things well than to try to do everything.
So for now, there's no way to distribute binary static libraries. Presumably that'll change sometime after Swift 1.0. For now, you can:
Distribute source
Ship a binary framework (instead of a library) if you're okay with the ABI being fragile
Use ObjC for library code
You can always combine approaches, too: e.g., implement the critical (secret) details of your library in ObjC, and ship Swift source that wraps it in a nice Swift API.
Obfuscating code written in a language that's very much subject to change sounds like a recipe for a maintenance nightmare.
I believe the whole approach is wrong. You cannot do something that is not (yet) doable by the technology you are trying to use.
Rationale: Swift is a new language, currently in Beta, and therefore changing. As I see it, this fact means not only that you are not able to ship static libraries, but that (real) developers will not be actually use third-party static libraries. What's the actual use of a library that may not work in the next release of the compiler? The issue gets bigger if you whant to use more than one library, because they might not be compatible! Therefore, even if you would be able to ship static libraries, they wouldn't be actually useful for production environment. So, what's the point?
Suggestion: write your static libraries in Objective-C (or C or whatever "non-beta"). Developers who need third-party libraries (e.g. yours) shouldn't expect them to be written in Swift until Swift is stable. You don't use experimental materials to build real bridges, right? You use well-tested, predictable ones.
From Xcode 9 beta 4, Xcode supports static library with Swift sources.
I have been searching around for a method to port an iOS xcode built project to OSX xcode project. Unfortunately, I have found that because there is no UIKit or storyboard for OSX xcode (just individual .xib's). Is there a way around this?
If you're a registered Apple developer there's a new video up that goes through some of the basics and the design patterns you should be aware of, just named "Bringing Your iOS Apps To OS X".
The UI paradigm of any non-trivial iOS applications is entirely different to that of one for MacOSX.
Necessarily, you will need to redesign the View layer of the application. However, the Model layer ought to cleanly port over and at least some of your controller classes might be reusable, although MacOSX doesn't have anything equivalent to a UIViewContoller.
Besides this, many of the frameworks your app might be using are either available for both iOS and MacOSX (usually in cut-down form on the former), or a similar.
If your logic and UI are well separated, you have a chance at some good re-use, but at a minimum you will need to rebuild the UI layers of your app; it's going to take time.
If you don't have the time to invest, and if you are willing to try something experimental, there are a couple 3rd party frameworks available that attempt to bridge the UIKit AppKit gap.
You can probably consider many of these as risky 'shots in the dark', but they are worth a look. Keep in mind the long term support ramifications as well.
Chameleon
UMEKit
The Boost Graph Library is a header-only library and does not need to be built to be used.
it contains some pre-made functions that I want for my iOS application:
dijkstra_shortest_paths
astar_search
However, Boost is not officially supported on iOS (or Android) due to lack of regression testing, and I'm not experienced enough with either Boost or iOS to be comfortable testing it.
Is anyone using Boost.Graph on iOS, and if so is it stable?
Yes, most definitely it's stable.
Apple's LLVM compiler (which is what you should be using for iOS apps) is one of the most C++11 compliant compilers available today, and as such can compile and run boost with absolutely no issues.
Not to mention the fact that iOS is also fully POSIX compliant, which makes most frameworks out there viable for use on iOS. When in doubt, try it and then if it doesn't work, come back and ask a question.
Leverage what is already there, and use it well!
As such boost libraries are stable, but Boost Graph libraries are failing on all darwin flavours (darwin- 4.4_0x intel- darwin- 12.0 intel- darwin- 11.1 darwin- 4.4)
http://www.boost.org/development/tests/release/developer/summary.html
May be you can try other alternatives, like LEDA (http://www.algorithmic-solutions.com/news/archive.htm)
Thanks.