Without going into the why, I need to use an entire app for various classes and libraries it has and includes.
Is there a way I can use the entire project as a dependency? When I choose "static library target" I lose all the hundreds of classes in the "compile" step. Effectively I would like to be able to package the project such that I can use it elsewhere.
Is there an easy way to do this aside from building my new app out of the old app and changing the app name/launch targets?
You have to find a way to transport every element into the new XCode project. iOS app consists of:
main.m file - You probably won't need to copy that, as it's usually just one line.
Source files and headers for: appDelegate, ViewControllers etc. - I don't understand why you would "lose all the hundreds of classes" during compile time. You're the one that chooses what is to be included in the static library. Add all the header files you need to "Copy headers" in the static library target "Build Phases". Add all the source files into "Compile sources". There are many tutorials and StackOverflow posts on how to do that. (example: How can I create static library and can add just .a file on any project in ios)
Storyboards, xib files, *.plist files, images and other resources - you need to put these in a *.bundle file . Just create a new target (which is a bundle) and include all the needed resources in it. Then you'll have to find a way to use them in the new XCode project. For example setting the default *-info.plist or *.pch file: How to tell Xcode where my info.plist and .pch files are or setting the main storyboard.
So you end up with two files: one framework/static library and one bundle file. It shouldn't be that hard to configure new XCode project to use resources from the bundle and classes from the static library.
I'm not sure if I understood your question.
You can add your old app as a project to your workspace and add it as a "target dependency" to use it.
The easiest and safest way to do this is to copy the whole workspace and change the initial view controller.
Related
I currently have an Xcode workspace with an app project and the pod project (as commonly happens). I would like to "export" some of the files containing classes and structs that would be preparatory for a new project that should begin soon. These files are totally separate from each other and should not be exported as a library or framework because that should require to keep everything updated. Instead, I would rather bring these files out of the app project, but keep them into the workspace. Is it possibile? If so, how can I achieve this goal?
When you want to keep your common code and be able to maintain it as one code on both projects then I suggest you still use a framework. It is hard to tell from your question what you mean by "because that should require to keep everything updated" but using a framework within your workspace works awesomely in Xcode and any change you do within framework is instantly reflected in your code. So no extra deployment work is needed at all. To do so you simply do the following:
Create a new project selecting Framework
When creating the project select your workspace from dropdown menu (it is at step where you select project folder location)
In Xcode file navigator in newly created framework project open "Products" directory which should contain (in red) FrameworkName.framework
Open your main project target settings and open General, scroll down to Frameworks, Libraries... and drag that .framework file in this list
That is all. Now you can use your framework in your code. Simply import it in any Swift file you want to.
If at this point you are worried that you need to add import MyFramework into each and every Swift file where you use it then there is a shortcut. You can simply add a new Swift file and use type aliases to avoid this problem:
import MyFramework
typealias Class1 = MyFramework.Class1
typealias Class2 = MyFramework.Class2
typealias Class3 = MyFramework.Class3
Not the cleanest solution but it does the job.
On the other hand if you wish to extract files and use them in a new project but not share the code. So then each of the projects may eventually end up with different implementations of these files then you need to duplicate the files. You can do that easiest with file system by copying source files themselves.
You can then put them into workspace under whatever you want. If you wish that currently none of the projects contain these files you may simply select files in Xcode and uncheck Target Membership for all projects on file settings.
I have a project with multiple targets sharing most of their functionality. I have to add new targets often and I want to make it as quick as possible. Is there a way to not have to add all the libraries, sources code files and resources to every newly added target? I need some sort of parent target/project which can hold the .h, .m files as well as .string, .bundle, .xib etc. This way the new target can only define its name and icons and a few other minor details.
I want to create a project with a handful of categories that add useful functionality to UIKit.
I want to keep this as a separate project so that it can be source-controlled separately (and eventually hosted on github, and downloadable as a dependency via cocoa pods...but let's skip this for now.)
But all the Xcode 6.1 project templates imply an app inside. When I select an empty project it complains about missing base SDK. But this cannot be set without a target present. It is quite confusing. I don't need a target. Do I?
The project should be just a shell for a number of categories + a accompanying summary header file.
I want to be able to drag this project as a subproject to any other proper app project, import the summary header file and expose those categories to the main project.
Any advice?
You need a target. Every source file that should be compiled must be a part of a target.
You could reference each source file from the target(s) in your app's Xcode projects, but that'd be tedious as you'd have to add to every project manually when you add source to your shared repository.
Either create an embedded framework project or a static library. Unless you are really going to share code between an app and an app's extension, go with the static library. It is a lot easier to manage.
Create a project that has a static library target, add the files to that static library.
Then create a workspace that has your static library project and your app(s) project(s) in it. Modify the app targets to link against the static library.
I want to create two targets for my application iphone and ipad version.
My question is : Do I need to copy all the files from one target to another , because i found out that there are two AppDelegate files in my project, and what about resource and library files? This is the first time when i am trying to setup a multitarget project.
No, there is no need to copy source files. You can click on each file and tell Xcode which target they belong to (The Target Membership section of the File Inspector tab in the right pane).
Any files that are meant to be different (like the delegate classes you mention) obviously won't be added to both targets.
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 :