I am currently building multiple applications that all share the same CoreData stack. This includes models, network requests, etc. Basically all of the business logic is held in this repository (let's call it DataKit). The DataKit project generates a static library called DataKit.a
Now I have two apps, App A and App B. Both of them need to include the .xcdatamodeld in DataKit. How I have done this in the past, is to copy the .xcdatamodeld file from DataKit and put it into the App A or App B project. This is really ugly and I am trying to figure out a cleaner way to include the .xcdatamodeld file without having to copy it into the App project.
I've tried adding the .xcdatamodeld file to a Copy Files phase in the Build Phases for DataModel.a but it didn't work.
Anyone have any suggestions/tips?
The .xcdatamodeld file is an abstract representation of the managed object model that is compiled into a .momd file. The .momd file is what Core Data opens. For your projects, you would need to either have the .xcdatamodeld in the Compile Sources phase, or the .momd file in the Copy Files phase of the target that is dependent on the library. Obviously, this is pretty cumbersome when attempting to distribute code as a library. Frameworks allow you to include resources (such as momd files), and are in general much more flexible than libraries. iOS 8 allows dynamic frameworks, previous versions of iOS allow static frameworks even if the tools do not exactly support it.
You could include a method in your framework that returns the correct data model. It is not necessary to be stored in the bundle as a separate file / directory.
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 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.
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.
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'm writing an iOS project in Xcode 4 that uses several third-party libraries. One of those libraries contains a file with the same name as a file in my project. I'd like to put both files in separate groups, but it seems like Xcode only allows one instance of each filename in the entire project.
Is there a way around this other than renaming one of the files?
Edit: The files are Objective-C source files (.h and .m). I'm not familiar with mapping groups to folders. How do I tell Xcode to make my groups separate folders on disk?
You can directly Drag & Drop a folder onto the Xcode project and then select Create Folder references for any added.... I don't think you can directly create folders through Xcode. You can however add a Build Phase for copying files which will allow you to create folders in your bundle.