In my app I have an option defined in the Settings.bundle that is used only for debugging purposes.
Is there a way of hiding this from code, for when the application is in production, without manually deleting the option from Settings.bundle/Root.plist ?
Something in the lines of:
#ifdef DEBUG
// Remove the option from the settings bundle
#else
// Show the option in (or don't actually remove the option from) the settings bundle
#endif
Thank you!
There're a few options:
use a separate dev target with special Settings.bundle,
modify Settings.bundle with a Run script at Build Phases for the single target adding the section for DEBUG configuration, check CONFIGURATION variable for that.
I'm almost certain there is no way to do that.
Related
I want to have some "god mode" boolean toggles to quickly change functionality inside my app.
The previous developer created #define macros for these in a file that's included (indirectly) in every other file, but there are some disadvantages:
Every change has to be commited in git
Every change forces a build of the entire project
Is an xconfig file suited for this case? I accomplished what I want by:
Creating an .xconfig file
Adding it to the project
Adding HACKS_TEST = YES to it
Adding preprocessor macro HACKS_TEST=${HACKS_TEST} to the project target
Adding static BOOL const IOHacksTest = HACKS_TEST
and upon logging it, the value is printed correctly. But, if I change the HACK_TEST's value in the .xconfig file, it still builds the entire project. Also, adding one 'hack', needs modifications in the .xconfig file, project target's preprocessor macro section and project's global file.
Is it possible to achieve this without the need of an entire project build?
Is there another solution that doesn't require these many modifications on new 'hacks' adding?
Is there another solution that is more appropriated to my needs and/or easier/better?
What is the best way to have them set to NO for the Release configuration?
Edit:
Along the selected solution, I also added this in the Globals.m file:
if #debug
BOOL IOHacksTest = YES;
#else
BOOL IOHacksTest = NO;
#endif
so for Release builds, all the "hacks" are turned off automatically.
Every change has to be commited in git
You can't, or really shouldn't try to, avoid this. If there's some setting that can affect how the whole project works, it should be archived with the project.
As you've discovered, putting the values in an .xcconfig file doesn't have much advantage over having #defines for everything - if you change the xcconfig file, yo have to rebuild everything.
To avoid that, you'll want to split the declaration and definition of the variables between a header and a source file. So, you'd have a goobals.h file that contains "extern" declarations, like this:
extern BOOL IOHacksTest;
And a goobals.m file that has:
BOOL IOHacksTest = YES;
Then you include goobals.h wherever you need the declarations. If you need to change a value, you only need to recompile a single file.
1, Is it possible to achieve this without the need of an entire
project build?
If you want code to be compiled differently, based on those changing values, then there is no way to do it. In fact, you want the project to be recompiled, because the generated code needs to change.
The best way to prevent an entire project build is to put those values into a header file, and selectively include that header file only in files that need to know about the values that could change.
Is there another solution that doesn't require these many modifications on new 'hacks' adding?
There is no way getting around it if you want compile-time detection. If you change the values, then the compiler has to generate new code. How could the compiler generate the right code if it does not know about the custom changes you want to make with your "changes?"
Is there another solution that is more appropriated to my needs and/or easier/better?
That depends on your actual needs, which you didn't state in the original question. If you must have compile-time knowledge of the changes, you can use the header files, or you can add values to .xcconfig files, or just set them in the project. However, you will still have to recompile all the code that is impacted every time the values change.
If you want the settings to be changed at run time, then this is precisely what NSUserDefaults is designed for. Set an initial value in the source code, or in the Info.plist file, and set it to user-defaults on the app's first launch. Thereafter, you can manage the values from user-defaults.
What is the best way to have them set to NO for the Release configuration?
static BOOL builtInDebugMode = !!(DEBUG);
EDIT
Also, what does !!(DEBUG) do? – Iulian Onofrei
That's a logical-not operator, employed twice. It ensures that its operand will always be either 1 or 0. It was there to guide you to how it could be done (i.e., consider DEBUG or NDEBUG at compile time).
By default, your xcode configuration will have DEBUG=1 for debug builds. You could set it to DEBUG=0 for release builds, and use the above code.
As long as your code properly handles DEBUG, this should be fine. Unfortunately, some code incorrectly uses #ifdef DEBUG rather than #if DEBUG which could cause issues.
Thus, you may be better off with something like...
#if DEBUG
static BOOL builtInDebugMode = YES;
#else
static BOOL builtInDebugMode = NO;
#endif
When compiled in debug mode, DEBUG will be defined as 1. When not in debug mode, it will not be defined at all.
Or, you could add a definition to your project file DEBUG_VALUE
You can set some value in NSUserDefault, is very easy to use, I think.
You can add buttons to your app's UI to toggle these values, or you can let app query some website for this value at first launch, depends your needs.
NSUserDefault is fast.
And you can query at launch, and use it util app quit.
In searching for this I could only find info for other languages. I would like to know the best practice for writing conditional statments such as:
if (DEV_MODE){
//do something
}else{
//do the real stuff
}
And then setting DEV_MODE on or off in some global file so I only have to change that to on or off instead of changing code in multiple places. I have some ideas but am looking for advice on the best way to do this.
Try this:
#ifdef DEBUG
// do stuff
#endif
The current version of Xcode automatically sets this macro in new projects. Go to your projects Build Settings to make sure. If it's not there you have to add it yourself:
(This question is not related to Xcode.)
That said, instead of polluting your code with C-style IFs, you can use preprocessor directives to filter out debug and release mode. As far as I know, it's a common practice to define the DEBUG macro to 1 if in testing mode, and not to define it if in release mode. (Also, Xcode may define this for you, I've seen this behavior having been relied upon.) The reason is that the use of the preprocessor is more readable, since it doesn't get into the indentation, it's better separated from the code visually. To sum up, try
#ifdef DEBUG
// do debug stuff here
#else
// do release stuff here
#endif
One extra argument for preprocessor macros is that you can conditionalize the global namespace, which you couldn't within C code. I. e., with preprocessor macros, you can write
#ifdef DEBUG
int functionOne()
{
}
#else
char *functionTwo(int a)
{
}
#endif
You couldn't do this without the preprocessor.
Preprocessor variables are what you want, in your build configurations define a variable (DEV_MODE for example), and then use preprocessor checks like:
#if DEV_MODE
//dev mode code
#else
//non-dev mode code
#endif
In your project settings there is a section called "Preprocessor Macros". In that section you can add a string for your Debug build such as "DEV_MODE" or whatever you want. Then you can do your conditions you listed above and when your app gets built for "Release" or any other setting that does not contain your macro your check should fail.
I have a few constants files "Constants.h" in my project that I am including in the Prefix.pch file to be available to all the classes in my project. They just contain a bunch of #define statements.
My classes don't recognize these constants (no autocomplete) and Xcode gives me "Undeclared Identifier" errors every time I use them. However when I run the project everything works fine (set to ignore errors).
Is there any way I can get rid of these warnings? #pragma ignore them in the prefix file or something? I've tried many options, including setting "precompile prefix header" to NO in build settings.
Any ideas?
EDIT:
I have tried deleting derived data and cleaning / deleting build folder to no avail.
It might be worth noting that I have 3 targets in my project, and another project within this project.
Also, some of the #imports import normal classes. Like a category extension on UIFont and an Analytics class. Could this affect it?
To fix this, I had to change the 'Precompile Prefix Header' flag to NO in my target's Build Settings. By doing this you'll lose any build performance achieved by having a cached compiled header file, but in my case, my Prefix Header is pretty small so I wont see a hit in the time it takes to build.
Try deleting the project derived data. Xcode sometimes needs to re-index your project to remove "errors" such as this.
Organizer > Projects > Your Project
Click on the "Delete" button to the right of the Derived Data row.
Immediately quit Xcode, and then reopen.
I had the PCH file importing .h file with a lot of macros (specifically, I use the MJGAvailability header that warns when I use features that are newer than my deployment target).
Replacing:
#import "MJGAvailability.h"
with
#include "MJGAvailability.h"
solved this issue for me.
I had a preprocessor macro in one of my targets that I moved from 'preprocessor macros' to 'preprocessor macros not used in precompiled headers' and that solved the problem.
I'm working on an iOS project in xcode and I'd like to include different codes depending on the build scheme. ie: For anything except the Distribution on an iOS Device scheme, I'd like to include a bunch of debug stuff. But for the Distribution on an iOS Device scheme, I don't want to include the debug stuff.
If I can add some sort of conditional code block it will be very helpful as it will eliminate the chance of me forgetting to change the flag manually.
Thanks!
By default when you create a new XCode 4 project it will add DEBUG to your GCC_PREPROCESSOR_DEFINITIONS (Preprocessor Macros) under build settings so you can do the following.
#ifdef DEBUG
//Debug only code here
#endif
If you need more preprocessor definitions add them under GCC_PREPROCESSOR_DEFINITIONS or OTHER_CFLAGS or OTHER_CPLUSPLUSFLAGS [prefix the last 2 with -D] for the correct build configuration.
If I added a user-defined setting in my build configuration, how can I read that setting in my Objective-C code?
I have two files in my project, debug.plist and release.plist. I want my MainApp.m file to read one of these files based on which build configuration is running. I set up a user-defined setting named "filename" in both the Debug and Release configurations to point to the appropriate file. But I don't know how my MainApp.m file can read the filename variable from the current running configuration.
Here's what I did, I'm not 100% sure if this is what you're after:
Go into the build Settings panel and choose the gear icon in the bottom left: add User-Defined Setting
Create your user defined setting, for example:
MY_LANG -> en_us
Then, in the Preprocessor Macro's setting, you can reference that value:
LANGCODE="$(MY_LANG)"
Now you can refer to LANGCODE in all your source files, and it will be whatever you filled out in your custom build setting. I realize that there's a level of indirection here, but that is intentional in my case: my XCode project contains a bunch of different targets/configurations with their own preprocessor macro's. I don't want to have to go into all of those, just to change the language code. In fact, I define the language code on the project level. I also use MY_LANG in a couple scripts, so just a preprocessor macro wouldn't do. There may be a smarter way, but this works for me.
You can access your user-defined build setting at run-time (as suggested in a comment by #JWWalker)
Add an entry to your Info.plist file, and set it to your User-defined Build Setting
MySetting -> ${MYSETTING}
Read its value from code
Objective-C
[[NSBundle mainBundle] objectForInfoDictionaryKey:#"MySetting"];
[Edit] Swift
guard let mySetting =
Bundle.main.object(forInfoDictionaryKey: "MySetting") as? String
else { print("MySetting not found") }
Swift 4
Lets say "filename" is the String you need in your app.
Add filename=YOUR_STRING to user-defined setting(for debug and release).
And add filename = $(filename) to info.plist.
Then in Swift code:
if let filename = Bundle.main.infoDictionary?["filename"] as? String {
// do stuff with filename
}
else {
// filename wasn't able to be casted to String
}
Your code can't read arbitrary build settings. You need to use preprocessor macros.
EDIT: For example, in the target settings for the Debug configuration, you could add DEBUGGING=1 in the Preprocessor Macros build setting, and not define DEBUGGING in the Release configuration. Then in your source code you could do things like:
#if DEBUGGING
use this file
#else
use the other one
#endif
I tried zmippie suggestion but it didn't work for me.
I got it working with this:
${MY_LANG}
In case anyone else is still stuck looking for how to do preprocessor macros, look for the Apple LLVM - Preprocessing section in Build Settings. Under it, you will see a section called Preprocessor Macros.
This is where by default, Xcode inserts the DEBUG=1 macro for the debug build configuration.
You can add your own here, and give them different values for debug, release and any custom build configs you may have.
To add one, double-click on the current value list for the config you want, and it'll display a nice little editor with one macro on each line. Just add your own macro name, and give it a value the same way the DEBUG one is done.
These can be checked during the preprocessor build phase using #if, #ifdef etc. to provide conditional code or values.
Hope that helps.