I am a new iOS developer and developing an app with costumed project which has no typical compile options like debug, release, distribute. So I have to config compile options of xcode by myself. That brought some difficulties to me.
Source codes of this project is very sensitive as the app's rival competitor will be interested in the information of source code. To erase information concerned with source code's information, I need help to config compile options of xode. For example, I can find name of functions by profiling this app with intruments and I have no idea how to erase it even after I have set option to turn off "generate debug symbols" of xcode.
How can I erase overall informations concerned with source code? Any help is appreciated. Thank you.
It looks like you're trying obfuscate you code. Take a look at this question regarding obfuscating Objective-C code. The problem with obfuscating is that it's possible to reverse it if someone really wants to, so it might be more trouble than it's worth.
Related
I have a plugin's resource codes and I want to edit. Because I want to change plugin's prefix but it isn't possible unless edit plugin. I tried edit with Eclipse but I had a lot of errors.
If you have source codes of some plugins, there meight be a problem, that they are using some api for example WorldEdit api, but you don't have it added in your project. You have to look into code and find out what they use. Then download the api and add it in Build Path - Right Click the project->Build bath->add external Jars. I hope this will help.
You may be getting errors from imports, API's, etc.
The best way to change this is to contact the developer of the plugin, who has the project themselves. It's not a good idea to change code unless you have full permission; but I will still tell you some possible ways to fix it.
Your imports may be faulty, check those.
Actually REVIEW the code yourself– Don't mess around with things you don't know what they do.
CHANGE YOUR PACKAGE NAMES (This got me before, simple mistake)
If there are comments in the code, use those to your advantage
Google your errors.
If you are new to Java, don't skip to changing code already. TRUST ME. Learn all you can before skipping to other "higher level" developer styles.
Like I said, these are vague and simple ways to fix it; the best way to have your feature implemented is to contact the developer.
*I understand that this thread is old; I'm just saying this because there are currently no answers that describe this for other Google travelers of the internet.
Anyone please let me know what is this all about? I am stuck since a week on this and no help from searching. I posted my query to the developer of Alamofire but still no response. Please help! I am totally confused what is wrong in the integration of Alamofire. I have followed every step and this issue is coming with XCode 6.3 as before it was running properly.
When I am adding the Framework under "Copy Frameworks", it is adding the Framework twice showing different paths but when I am Going to there location, it is taking me to the same location. Here is the screen shot.
I have also created the video for that issue. May be that can help in a better way. Please see HERE
Moreover, latest SDK contains framework for MAC OS as well but I didn't add that. I hope all the above information will help you in helping me. Thanks!
This is going to be incredibly difficult to debug without a sample project that is set up in the same manner as your actual one. If you had imported Alamofire project into your project, you wouldn't see two versions of Alamofire appear when you add it to the Copy Frameworks build phase. If you truly want to resolve this quickly, you have two options.
Option 1
Push up a sample project to Github and link it here. We can then take a look at the project and pretty quickly access what the issue is. The main reason it's so difficult here is that there are roughly 10 different things that could be the cause of the issue. Therefore, it's much faster for you to create a sample project than for us to go round-and-round (which we've already started with #Masterfego).
Option 2
Take the leap and try out CocoaPods. It is a fantastic dependency management system that will forever alleviate these annoying types of project management issues. CocoaPods itself has fantastic documentation. Also, the Alamofire README breaks down in detail how to add Alamofire to your project using CocoaPods.
Recommendation
I would highly encourage you to choose Option 2. That is definitely the fastest way forward and you won't regret moving to a more robust dependency management system. It makes managing library updates and new installations extremely simple.
If you do end up going with Option 1, then I'll take a look at your sample project and revise my answer.
I have created a Mac app that can generate iphone ebook app project source codes.
I know I can using xcodebuild to build the project to get the release binary file.
Is it possible to hide the source codes of .m files(maybe store in memory) and build project using xcodebuild?
Welcome any comment
Thanks
Marc
It sounds to me like you are attempting to generate source code for others to use, but then hide it so they cannot see whats been generated. Basically not possible. You could generate obfuscated code which would make it harder to read, but not impossible.
Realistically what you are trying to do is generate template code for others to use. If you don't want them to be able to see it, then you presumably don't want them modifying it. The easiest answer is to simple not do it. Instead, create a compile static framework containing your code and IP, and then only generate templates which makes calls to your framework. Thus your code is protected.
Your question lives on the edge of being programming related, and I'm not exactly sure what problem you're trying to solve.
However, you can create a RAM disk, store your project there and run xcodebuild against that. Just be aware that you're not really protecting the .m files so much as limiting how long they are easily visible.
TL;DR Version:
This question has arisen due to the fact that I have multiple frameworks (which I have built) and a client project that uses said frameworks. Now, when I open up the client project and try to debug into the framework, it doesn't work.
However, if I have the project associated with the framework open, then debugging appears to work (though there are some weird issues with breakpoints I don't see being triggered).
I have looked at Apple's docs, and perhaps the answer is buried there somewhere, but I couldn't find it on a skim of the Xcode Debugging Guide.
Long Version:
The reason this question is important to me is that a coworker and I had a disagreement about how headers are imported in the frameworks we build.
I have a tendency to use framework headers (with client apps) in the fashion:
#import "FrameworkA/HeaderA.h"
#import "FrameworkB/HeaderB.h"
He, on the other hand, favors importing the framework headers (with client apps) like this:
#import "HeaderA.h"
#import "HeaderB.h"
and specifying the header search paths in the build target of the client application.
Complicating matters further is the fact that some of these frameworks have interdependencies. For example, FrameworkB has headers from FrameworkA referenced in his format:
#import "HeaderA.h"
His argument for doing this is that debugging only works if we import headers this way. It seems dubious to me that there would be a relation between header importing style and debugging, but I am not really certain how XCode chooses the file to link to during debugging, hence the question.
Thanks in advance for any assistance with this query.
you add project references to the target, and make sure Xcode knows where to find the debug symbols.
#import <FrameworkA/HeaderA.h>
that's the way to go (for internal and external declarations). the reason? the other approach is more likely to cause issues as libraries evolve. the additional qualification disambiguates any case (unless of course there are two FrameworkA/s in your search path), it's best to qualify the file explicitly now, rather than when your clients tell you they cannot use your library with other libraries, or that they can only use them in some conditions. then you have to go fix the issues and reship (this stuff has a way of happening at inconvenient times =p). it's one simple measure to ensure you've developed a robust interface.
perhaps the most important part that people overlook is the location of the products: use a customized central build location for your targets -- many people use the default location, which is by the xcodeproject. otherwise, Xcode may not be able to locate debug information.
finally, debugging complex projects in Xcode can be quite... let's call it 'problematic'. So don't expect the debugging experience to be perfect, even if you've configured everything correctly. all the more reason to integrate assertions and unit tests into your development cycle early on with Xcode. truth is, the debugger may be useless no matter how hard you try - this is not a new issue. hopefully LLDB will improve our debugging experiences.
good luck
I just have a question about binary file in an iPhone app.
When an iPhone developer wants to submit their app to testers or App store they build the binary file of their appliction. My question is it possible to edit your app's binary to get the source code, or just simply edit the binary for someones purpose.
If it is posible how can I prevent it to happen.
In general, getting source from compiled code is technically possible, but not to the extent you fear. Decompiling isn't usually done for a few reasons.
One of the things a compiler is optimize a lot of different things in your application, e.g. unrolling some loops or inlining some functions. That would make a decompiled code very different from the source and harder to modify.
Symbols are generally lost when compiling. I don't know the process for every compiler (Especially not for iPhone apps), but I know Visual Studio keeps a separate database for debugging. Without that database, var UserPreferences would turn to _a or something along those lines.
All that said, you can't completely keep someone from decompiling your code, but there's pretty much nothing you need to do to make it hard for them to get something useful.
As Alex said you cannot prevent someone from decompiling your binary if they really want to do so however unless you have some secret code or something they can't get any other way it is usually less work to write a clone of your app then decompile it and use the result.
If you do have a secret code or something you need to hide from people (usually as part of a DRM or DRM-like system) one way to made it harder to get to would be to not directly put the code in your app. Use a state machine or something to build the code so it is harder to figure out what is going on. That might buy you a week, anyway.