We have a Filters framework that contains many image processing filters (written in Swift and Metal) and the resources they require (like ML models and static images). But not every app we have uses all the filters in Filters. Rather we want to only build and bundle the required filters and resources that are needed by the app.
The only way we can think of to achieve that is to create different framework targets in Xcode, one for each app. But that would require that the Filters framework project “knows” all of its consumers (apps) and we would rather like to avoid that. Especially since the filters are in a separate repository.
Is there a way to, for instance, pass some kind of configuration file to the framework that is used at build time to decide which files to build and bundle?
You can use Target Membership to assign files into specific targets. See image below.
Make sure you are on the File Inspector tab on the right side of Xcode. Select the files you want to limit to a target and in the Target Membership area, you can select which target the selected file belongs to or don't belong to. For public resources, make sure to select public for the visibility scope.
For files that don't require compilation, e.g. image files, once you've selected the target membership, the file will be automatically added to the Build Phases' Copy Bundle Resources area.
Alternative One
Alternatively, you can use add a Copy Files Phase in the Build Phases. With the Copy Files Phase, you can copy files to subdirectories instead of the root of the framework bundle.
Alternative Two
Yet another way is to add a Run Script Phase in the Build Phases. The script can be in any language but usually shell script. You can do whatever you need in the script including compiling code manually but you need to know where the files goes by using environment variables and placed the files in the correct location. I think this will be the most manual and most hassle to use for selecting files based on targets.
Alternative Three
If you really want to go fancy, you can even break down all the components into targets and use Aggregate target to tie the different components into the target you are building for. I would not recommend this usually and reserve this for very special needs that other methods could not achieve.
Related
I have over 100 projects in my XCode and when I add a new file or class I have to select each target one by one to add it to it. Is there a way to select multiple targets instead?
The usual way is to have targets that don't duplicate each others files. E.g. some targets are libraries that are used by some others, and eventually there's an app or a unit test target that uses them. In this case there's no need to have the same file in multiple targets.
So consider refactoring the common files to a common library target that you can reference from the other targets. In this case when you add a file, you can add it to just that library, and it will be automatically resolved (linked) in the other targets.
Note also that in this case the file you add is only compiled once, and the compilation result is reused in various dependant targets, as opposed to compiling a separate version of that file for each target.
If that's not an option for you, an alternative is to generate the Xcode project file using some tool like CMake, GN, or a custom script that can write xcodeproj files (there are libraries to do that in various languages).
In my case I have 50 Folders where each of it has subfolders and images. I could drag them into the apps main bundle but there are many duplicate filenames and it would be more practical to access them in the structured way.
Your wording "it would be more practical to access them in the structured way" seems to suggest that you think the Resources folder cannot contain a folder tree of files, it can. However if you let Xcode itself copy your resource files into the bundle it will flatten the tree without any option to preserve it (for reasons unknown). To address this you can copy the files into the bundle using a build script.
In outline, you need to fill in the gaps with some reading:
First add your files and folders into your project. Use one group per folder, in Xcode 9 creating a group creates a corresponding folder in the project directory but in prior versions you must create the group and then associate it with a folder – check the documentation of whatever Xcode version you are using.
Mark all the folders and files added in this way as not part of your build target. This prevents Xcode copying the files automatically into the bundle, and flattening your folder tree in the process.
Now in the target settings go to the "Build Phases" tab and add a new build script phase. Add a shell script which uses something like ditto to copy the folder tree into the bundle. Various environment variables are set which reference the project and the bundle, check your Xcode documentation or just run a dummy script and dump them out (it is an option, or use printenv). You can use these environment variables to determine the source and destination for your copy.
In your app itself you can locate the root folder of your tree using standard bundle methods. From there you can use whatever method you choose to traverse it/reference items with in it, in exactly the same way you would if the folder tree was not inside the bundle.
HTH
I have made an empty single-view application in Xcode 6 (FWTest) and added a Cocoa Touch Framework (FWTestKit) as a target and asked it to embed in FWTest. Then I add an image (photo.png) to the framework, that I expect to be in Frameworks/FWTestKit.framework/Versions/A/Resources/photo.png when I build & archive my app. However, I find it in Frameworks/FWTestKit.framework/photo.png
How can I make it at least be in a Resources folder? Preferably a versioned folder so I can ship different versions of my framework?
When I add this framework to another app, do I need to do anything special to make sure the resources are bundled along with it, so that when I reference a resource from within my framework I can be sure it'll be available also when used in another app?
Cheers
Nik
You should add your photo.png into separate folder (let's call it "gica" ). Then drag folder into project, check Copy items if needed and create folder reference. Then (important) in build phases, drag photo.png again in Copy Bundle Resources, keeping Copy items if needed and create folder references. After you compile you should have now desired folder structure [It is keeping gica/photo.png].
I think you need to revise the architecture about versioning. Anyway if you still need to place the image inside the folder. Try creating a run script.
In your build phases instead of adding your images to copy bundle resource phase. You can create a shell script to copy your images to desired folder. Please note build phases are run in the order they placed. My point is you can customise xCode Build process through your own shell scripts.
I have 3 applications that share a lot of functionality. It is only the content and styling changes between them.
Instead of simply duplicating the project for each app, is there a way to make a "base" application and then have the 3 applications extend this?
Simply duplicating the project would be horrible to maintain, whereas extending a "base" would allow them to all update simultaneously.
I know you could create the project and then copy all files from the old project into the new. This would keep the files up-to-date, however if any files were added or removed, you would have to manually do that.
Have one base project that uses multiple targets. Each target can include a subset of the files in your main project, and/or add their own independent files. Each target can also have its own set of preprocessor defines set up in the build configuration.
You can add more targets to your project in Xcode.
Create a project that builds a static library for the reusable components. You can use an Aggregate target to package any associated resources, such as nib files, storyboards, images, etc.
Your app projects can all then consume the static library and resources. Any changes to the static library will be available to all the dependent projects.
I've got a relatively large Xcode project that produces a single app. However, I have many clients/customers who require deep customization and branding of said app. These configurations include different graphics, a few different interfaces and implementations, and, perhaps most importantly, .xcconfig files.
My Xcode project has a dedicated group that points to a particular client's customization folder on disk, so by opening the Xcode project and building, you get a build of the single app with the current client's customizations. To switch to another client, I change where that group points to on disk. (I also change and switch-back the xcconfig "Based On" settings in the project's Info pane to reload the full xcconfig inheritance; Simply changing the group containing one or more xcconfig files doesn't reload this!) This has worked great for 100+ clients. It's a little tedious to switch this folder every time you need to build the app for a different client and ensure the xcconfig is correct, but it works.
Now I'm in the process of automating builds via the command line, and running into troubles. The quick and dirty solution to pointing the aforementioned Xcode group at a different customization folder was to copy the ProjectName.xcodeproj/project.pbxproj file to ProjectName.xcodeproj/project-template.pbxproj and put placeholders inside this file that can be grepped and replaced with the name and path of the desired customization folder. Then, temporarily overwrite project.pbxproj with the modified project-template.pbxproj, and build to get the correct app.
As you've probably observed, the project.pbxproj was duplicated and modified, and will therefore get out of sync as developers modify the original and forget to also update the template. And besides, I shouldn't really be messing with pbxproj files in this fashion anyway -- that's Xcode's private stuff.
So, is there a better way to tell Xcode about a folder full of resources, code, and config files perhaps during the Build Phase with a script or environment variable, rather than at the project group level? The most complicated bit seems to be the xcconfig chain, since each client has their own xcconfig file that inherits from the single app's Debug, Development, and Distribution xcconfig files.
Sorry for the long-windedness of this question, but it's a little complicated! Any suggestions would be greatly appreciated!
I think you would way better off using the targets feature in Xcode. Have one project and the resources of every clients in that project.
You can then duplicate the target you already have (right-click on your target, by selecting the project file in Xcode's Project Navigator).
All your targets will be compiled with the same code. You just need to change the resources in Build Phases > Copy Bundle Resources to have different app created for each target. No need to look at Xcode's internal files.
You can even change the code in your source files by adding a preprocessor macro in your build options (something like FIRST_CLIENT=1) and then look for these definition in your file with #if FIRST_CLIENT.
I have a project set-up like this and it works pretty well :