I have a project setup with two separate projects in two separate schemes, the only difference between the two targets is that they have different bundle ids and different icons. However whenever I change the second target and build it the changes are copied to the first target. I'm not sure what's going on, the only thing I could think of is they have the same product name so the app executable name is the same. Does someone know if this is causing it and if so how could i fix, or is something else going on?
Thanks
Presuming that in your new target have you specified a new plist file
and that the target points to this plist file and as you pointed out you also changed the product name in the build settings, the only thing I can think of at this point is that your schemes are both pointing to the same executable. Open both schemes in the scheme editor and look at what the executable field is pointing to. They may both be pointing to the same thing.
Related
Hi I have been working on my first iOS app. I have completed all of its requirements. Now its time to distribute. But before distribution I want to manage things well.
I searched for it and got "Target" as what I wanted. now just suppose the following requirement:
I have Client 1 and Client 2, and they both have different web addresses and Images and App Master password.
Now the 1 thing is to change them manually before making the build. But I wanted more proper way. So I thought of creating a Config file per target per client. but I am not getting it done.
Because after adding "Config" file for client 1 I am unable to create the 2nd "Config" file for Target 2 which indicates the client 2.
Please help me I am confused. Thanks in advance
Once you have different targets, you also have different property list attached to it. This allows you to customise some elements of your configuration for a specific target.
In this example, I duplicated my target and have now two targets, two schemes and two .plist files. I can customise one .plist without affecting the other target.
Another way to solve this problem is to create two configuration files in Swift. For instance, you can create a AppConfig struct foreach app configuration and attach it to one target at a time. It could be under AppConfig.swift and AppConfigDemo.swift, both with following code but different url in it.
struct AppConfig {
let urlString = "https://myclienturl.com"
}
The key is to include each file into the right target. Here, this AppConfig.swift is available with Test target. It won't be accessible in TestDemo target. You can do the same foreach one of your client.
Make sure they have different names, Info.plist and Client2-Info.plist (for example).
and you can set targets config file in its build settings. just search for Info.plist and set the relative path to the configuration you need.
I want my iOS app to read default settings from a configuration file. It will be a plist file. The source code should have the path and name of the file hard-coded and my code wold just open the file and read the contents at startup. But I would need to have two files with the same name and path in the Xcode project to do it this way. Of course, each file would be for a different target and only one would get included in the distribution package.
I have not investigated renaming files in a build script. I hope there is a better way.
I have considered having different file names and then searching for the file within the known relative path. This seems easy and is the option I will go with if there is no simpler or more clever way to do this.
So is there a way to pick from two different files, based on the selected target of the app, and have that file end up in the distribution package with a specific name (always the same name)?
There are different approaches that can achieve it. One is to create >different targets, each one of which employs different Info.plist. Each >time a target is selected, a different Info.plist will be used, hence we >will be able to differentiate variables like token, URLs for different >builds. The alternative approach is to put your build configuration >settings into .xcconfig files and refer those in your project info.
It could also be achieved by using Bundle Identifiers
I hope this link will be helpful to you,
https://www.appcoda.com/xcconfig-guide/
https://www.appcoda.com/using-xcode-targets
I thought it would be interesting to attempt building multiple apps using the same code base, where the only differentiating data is held in a few plists. For example, one plist holds some theme info - a few key/values to drive the color scheme used in the app. I'll call the original version of this theme.plist.
I soon learned that I should create multiple targets in my project, and have been able to add these successfully. Each one, via it's own appname-info.plist, has a different name and bundle id - it's neat seeing all three on my home screen without any real extra work.
But right now they are all identical. I haven't figured out how to use a different set of data for each one.
My first thought was to have some folder for each target - each with its own theme plist named theme.plist - and somehow distribute each target with a different folder. But researching that idea doesn't get me much google juice.
So what about multiple theme files? Ok, so far that looks better - I can create an app1-theme.plist and 'app2-theme.plist' with different values for the same keys in each. And Xcode even lets me use some flags to say which targets should include each resource.
But I don't know how to load the appropriate plist at runtime. I need to examine something (the bundle ID?) and then assign the appropriate name of the theme plist to something (what)?
It seems like this might have something to with #ifdef, whatever that might be...?
Can someone explain how I should be looking to accomplish this? Am I on the right track? I'm happy to put some reading time in but I don't even know what to look up yet.
You are just about there. Xcode supports having multiple files with the same name in a project, one way you can do this by storing them in different folders within your project folder.
Unfortunately at this point Xcode won't give you a lot of help, so open your project in the Finder, create one subfolder for each of your apps, in those folders place a copy of the plist. Now add each copy in turn to your project, making sure you add each to just one of your targets.
You might want to create a group in Xcode called, say, "Theme files", to keep them altogether.
HTH
What you are trying to do is trivial. If you select a file from your project, and bring up the "File Inspector" in the utilities area (Press Command option 1) you should see a section "Target membership". Each target in your project will be listed, with a checkbox next to it. If you check the checkbox for a file and target, that file is built into that target. Un-check the checkbox for a file and target and that file is not copied over to the specified target (you may need to run a clean, and delete the app from the target device, to get rid of files that used to be included but that you have un-checked. Xcode generally won't automatically remove things that used to be included.
You could create a directory in your bundle and teach your app to scan that directory for plist files. Then include a different set of files in that directory for each target and each target app's behavior will change.
I have a project that I maintain for a client; let's call it MyDataAssistant. When the project goes into beta, the client likes to have a "separate app" built for them, which I create using a different provisioning profile and a modified bundle identifier (MyDataAssistant-BETA). It's a pain to always be going back and forth and changing the bundle identifier, code signature settings, and especially the icon. I understand that you can have multiple targets and multiple build settings (within each target?) in a project, but I'm not clear on what the difference is, or how to use them appropriately.
Additionally, the client would like a third version with read-only capabilities. I can accomplish this by just making a flag return from a certain part of my code, but I would like it if that flag could be toggled in the build (target?) settings.
Please advise on how to manage this kind of project with multiple "variations" of the build.
Add a new configuration to your project by duplicating the release one for example.
Give it a name "Beta"
Add a User-defined build setting
Call it MY_DATA_ASSISTANT_BUNDLE_ID_SUFFIX for example and set the value to be -BETA only for the Beta configuration.
Edit the MyDataAssistant-info.plist file by setting the bundle identifier to com.YOURCOMPANYNAME.MyDataAssistant$(MY_DATA_ASSISTANT_BUNDLE_ID_SUFFIX)
This will make it have different values for the different configurations.
You can also set the display name to have a different value by setting it to $(PRODUCT_NAME)$(MY_DATA_ASSISTANT_BUNDLE_ID_SUFFIX)
Set the right provisioning profile for each configuration. (Of course after creating the beta one in the provisioning portal as if it was for a new app with the bundle identifier having the suffix "-BETA")
Create a new scheme!
Give it a name: MyDataAssistant-BETA
Change its build configuration to "Beta" for all the actions and you should be ready to go.
If you want to have different icons for the beta version you can use the $(MY_DATA_ASSISTANT_BUNDLE_ID_SUFFIX) in the MyDataAssistant-info.plist file for the icons names and of course add them to the target.
I would recommend creating two targets. This will allow you to share what files you want between variations, as well as have custom source, or config files in each. The simplest implementation of this would be to have an identical target except for the info.plist file.
Simply right click on your current app target in project settings, and hit duplicate.
I am trying to add 3 targets to my existing project. Dev, QA, and Prod.
The problem is that when I rename the target, during the build it looks for the target name as my project root folder, so I get a bunch of build error because all my header search path, library search paths are now broke.
Is it possible to make it so that Xcode uses the same project root name regardless of what the target name is?
Did you change the name in the box below? I had similar problems with names getting out of kilt, and it turned out this was the key if I recall. I should add if you have one target and want to duplicate it, you can select the one, then right click and get a duplicate contextual menu.
EDIT: Then, go to the Manage Schemes and make sure the name is correct there, and not "Project Copy". If all else fails grep you project in Terminal looking for "Copy" - you might have to edit the project file with vi (with it closed in Xcode!)
I found out what the problem was: $(SRCROOT)/$(PRODUCT_NAME) in my frameworks search path. $PRODUCT_NAME is being used to find the root directory of the project, and since all the targets are pointing to the same project I ended up hard-coing the project name. $(SRCROOT)/MyProject.