In my app, i currently have all my code separated into a static library, to make it easier to set up the xcode project targets for the actual app and for unit tests for my code. The problem with this is that i want to put most of my xib files in the static library as well, but it seems that when i run my app and try to reference the xib it can't find it unless it is included in the actual app's target instead of the static library target. Is it possible to have xib files and other resources included in static libraries that can be referenced by code in that same library, and if so, how?
No it isn't possible, because a static library is not the same as a "bundle".
A bundle is a directory that may contain all manner of files including resource files (xib), executable files and static libraries. It exists on the filesystem as a group of individual files.
A static library is a single file that contains classes, code and variables that were linked together by the library creator. It does not "contain" other files, it is essentially a database of compiled code.
Although it would be possible to put the data for the xibs in there, Xcode would have no way of knowing that it was in there, as it looks for them as individual files on the filesystem.
In Mac OS, you may create a "Framework" which is essentially a bundle of code, resources, settings etc which may be reused by multiple projects. However, Apple does not seem to support custom framework creation for iPhone OS.
Bundles
https://developer.apple.com/library/content/documentation/CoreFoundation/Conceptual/CFBundles/BundleTypes/BundleTypes.html#//apple_ref/doc/uid/10000123i-CH101-SW1
Static Libraries
http://en.wikipedia.org/wiki/Static_library
Reply to comment (won't fit in comment box)
No worries, I've been trying to do pretty much the same thing as you for the last week - I'd like to ship a "framework" of xibs, include files and .a libs to a client without giving them all the source code. I couldn't find a good way to do this with bundles either.
For whatever reason, Apple are being particularly obtuse about this - I can't see a reason for them to be so in the case of static libraries (dynamic libraries fair enough).
My solution for now is to manually create a package folder "Foo" that contains the following subfolders:
"include" -> put .h files here
"res" -> put .xib files here
"lib" -> contains "iphoneos" & "iphonesimulator" subfolders each with libFoo.a
Then zip this up and send to the client. The client then:
Unzips the package where ever they like.
Adds the "res" folder under the resources group.
Changes the following target settings:
Other Linker Flags = -Objc -lfoo
Header Search Paths = /include
Library Search Paths = /lib/$(PLATFORM_NAME)
I can probably automate the package creation with some build steps at my end, but the client is stuck with four slightly fiddly steps to get set up.
I found a perfect solution for this that does all the above automatically and more
https://github.com/kstenerud/iOS-Universal-Framework
Its an xCode plugin
It worked for me like a charm,
It works only for XCode 4 and above
Yes You can. add a xib file in your library as you would do for any normal project. Then in library project target add the xib file in copy Files section along with .a file.
In your main project where you are using the library, drag and drop the xib file where .a file for library is located.
Answer in including Xib files to your static library.
This time we have Xcode 11, you just create a bundle target in addition to your library target. The bundle template is available on macOS. Then from the library code, reference the bundle to be able to reference the nib. You distribute the library with the bundle.
A detailed video about using Xibs with static libraries below:
https://www.youtube.com/watch?v=WQI02KR9kQw
When distributing you could also create an SDK. JSON.framework did this in their SVN, and I successfully replicated this. You can see how this was done in http://hltypes.svn.sf.net/ in the hltypes-ios.xcodeproj and the iOS folder in the project.
Primarily you need to "install" into your build folder, and then you need to copy the specially formatted SDKSettings.plist. Then add the path to the SDK into "Additional SDKs" list in application project. Downside of composite SDKs are the need to restart Xcode 3.x whenever this mini-SDK is updated, and Xcode's insistence on constructing a composite SDK created from Apple's base SDK and your mini-SDK (which means you need to wait quite a bit).
Application project still needs to have .xib and other resources manually added.
Related
I am developing a Swift iOS app with watch and widget extension.
So far I had a Shared folder where files were checked for all targets that needed them. This works, but I noticed that these files then get compiled for each target.
I would prefer to have the shared core of the app to be built once, and then used as dependency for each of the targets, saving up the compilation time.
What is the good practice for sharing code and assets between app targets?
So far I looked into static library and framework. I ruled out the static library, as I would also like to share assets in addition to code, so that means that I should just create a new framework, and move files in there?
I tried this way, added a framework as dependency to all targets, but it doesn't seem that the framework gets rebuild when a code inside it changes, am I doing it right? Thanks!
Frameworks seems to be the right path, the problems I had with getting it built were all caused by this:
I'm not sure why this happens, but one way to solve your issue is to go into your build settings and defining the Framework Search Paths to a folder which contains the frameworks in question. If the frameworks are placed in your project directory, simply set the framework search path to $(SRCROOT) and set it to recursive.
I had to do this in Project Build Settings instead of Target Build Settings.
https://stackoverflow.com/a/31077255/38729
I have an existing iPhone application, and I just wanted to make a static library out of the code, so that I can use it by a separate test application (within the workspace). The application compiles fine, but when I try to compile the library version (which has the same code files) I get the following error:
Lexical or Preprocessor Issue - "MyClass.h" file not found
However, the application still runs, even through there is this error. In fact when I compile the application (which uses the static library) it initially says no errors, and then after a second or two the above mention error then appears.
I'm basically doing:
Create a new target in the project using the Coco Touch Static Library
Add the .m files in the targets "Compile Sources"
Adding the .h files in the targets "Copy Headers"
Adding the same set of libraries in the "Link binaries with libraries"
Go into the Profile and modified the Target to be RELEASE
Any suggestions? Am I missing a step here?
I'll have a stab at this :-) I think it might be that MyClass.h has been set to private. Thus it is not added to header directory when you create the static library. You should check to see if this is so by checking the output header directory. If the header file is missing, then it's pretty sure thats whats going on.
Secondly, why use a seperate app for testing and therefore require building a static library at all? I have several static libraries and apps which I unit test with GHUnit. I do it by simply adding a new app target and configuring it to run the GHUnit iOS app. I can then add the classes I want to test and any testing frameworks such as OCMock without having to create separate projects. Basically it sounds like your testing methodolody is perhaps more complex than necessary. :-)
So, the issue turned out to be I had "-ObjC" set in the "Other Link Flags" option, which I'd put there as at one stage trying to get things working I read this was required - Dereks advice to review the compilation log worked well here
I have 2 projects and I want to use in the first project, a class (i.e. view controller) of the second. Instead of importing all the files of the second project in the first one, is there a way to link it like a framework or library?
I tried the following unsuccessfully:
Dragged-dropped SecondProject.xcodeproj and checked SecondProject.app as a target
Added it as a dependency project in the first project dependencies
Pointed to the header files by adding in the "Header Search Paths" a path pointing to the second project which I copied in a subfolder of the first project.
When I include "SecondProjectViewController.h" I get no errors but when I try to instantiate it I get the "OBJ C referenced from" error.
Any help is deeply needed and appreciated! =)
F.
As an experienced developer I would suggest not sharing code this way across projects. The simple reason is that changes in one project will then directly effect other projects, often rendering them un-compilable. For example, if you share a controller class and decide to implement a change with a new import, then any project that uses that class will be broken until you open then in xcode and ensure that the imported class is available.
A better method is to compile your first project as a static library or framework. I'd also recommend ensuring that it is version some way. For example, in my projects I create static frameworks and store them in a directory called "v0.0.1", "v0.0.2" etc.
The framework can then be dragged and dropped into a second project to use it. The second project then refers to it via the directory path. The advantage of doing this is that if I then change the first project, the second one if not effected by the changes until I choose to update the frameworks path.
Sharing files between projects will work for small cases, that being 2 or 4 projects, but once you have more than that it rapidly becomes un-manageable.
You have only a few steps to go:
4) in First project, click the disclosure triangle in the Groups and Files section for the Second Project reference. this will display the targets of Second Project.
5) Drag the target reference (e.g., static library) from Second Project to the target in First Project's link phase.
That should clear up all the linker errors for the symbols which exist in Second Project's library. Of course, you'll have to remove those sources (based in second Second) which are compiled and linked from First.
Managing static libraries for huge codebases is dead easy this way (although I prefer the build up to the minute (as well as several build variants), and don't reference archived binaries as Derek does). Learning to minimize changes which break builds takes time to learn. dynamic libraries are a bit different - depending on their distribution, you may want to version (as Derek outlined). It's good to share, but you should put the shared exported symbols in a library, which is a dependency of both apps. Just be careful not to add too much unnecessary objc symbols to the library - objc symbols and their references cannot be stripped from the final executable and they will cause runtime collisions if they appear in two images (dylib, app, static lib) within the same process.
You can add the view controller's files to your 1st project regardless of where they are on disk -- the project will make a reference to their location.
I'm currently stuck trying to get my objective c generated files to compile in my iPhone project. Basically it keeps telling me there is no such directory for the following four imports:
Thrift/TProtocol.h
Thrift/TApplicationException.h
Thrift/TProtocolUtil.h
Thrift/TProcessor.h
I'm following all the instructions on the Thrift wiki and have downloaded and compiled the Thrift framework in XCode but there is no information specific to iPhone development. I'm almost certain it's a problem specific to an iPhone project because if I create a new command line project in XCode, I can import those files just fine.
After retaining the services of some kind of sorcerer I have figured out how to get Thrift to work with the iPhone/iPad (or at least get it to compile okay).
First, you want to grab the objective-c files with this command instead of from the wiki:
svn co http://svn.apache.org/repos/asf/incubator/thrift/trunk/lib/cocoa/src/ thrift-cocoa
Then, make a new Xcode project by going to New Project, selecting Framework & Library and Cocoa Framework. Click create and save it somewhere nice. Right click on Targets and select Add -> New Target. Choose Cocoa Touch and then Static Library. Give it a nice name. Go to the target's Build tab in info and change the Base SDK to iPhone Device (I'm using 3.2 but you can use whatever) and change Architectures to either Standard (armv6 armv7) or Optimized (armv7). Under the General tab add the Foundation and Cocoa frameworks.
Drag all of the files and folders you got from the svn repository into the Classes folder in the project. Check the copy items box and check the boxes next to both targets. Remove TSocketServer.h and .m from the Static Library's Copy Headers and Compile Sources folders respectively. You can now build the Static Library (and Framework optionally).
Open the project you want to use Thrift in and go to your target's General tab in info. Add the Static Library you just created to the Linked Libraries list. It should be named libYOUR_TARGET_NAME.a. Under the build tab go to Header Search Paths and add the path to the Thrift project you just created and check the recursive box.
Finally you just need to change the import statements in the Thrift generated code by simply removing the brackets and replacing them with quotes. You can now build you iPhone project again.
Try adding those .h files to your Xcode project.
I realise that the view/controller stuff will be different between Mac and IPhone apps but the model code may well be similar/the same. So whats the best way to organise a project(s) so that the model code is/can be shared?
Copy/paste - just duplicate it and manually keep it in sync
Have 2 xcode projects point at the same workarea - one for Mac and one for IPhone and share the code.
Common library - presumably you can't do this (or can you)
Thanks for any tips.
There are a few ways to do this. The first thing you can do is is create a project that builds as a framework on Mac OS X. Since you cannot use frameworks on iPhone, you can make static library target that contains the same code files. That basically works, but the header paths will be different. If you want the header paths to be the the same (i.e. <Myframework/MyFramework.h>) you will need to modify the the install path of the static library headers so that they are copied into "$SDK_ROOT/usr/local/include/MyFramework", and make sure /usr/local/include is an included header search path. You will then need to install the library and headers into each SDK_ROOT.
I started out doing the above, but I found it to be a royal pain. So I ended up doing something that is a variant of #2. Basically, I get the header paths to be equivalent by making a directory named "Externals" in my iPhone project root, then a directory named with the appropriate name ("MyFramework") in the externals folder. That is the folder I copy I drag the framework files into.Findally I add the Externals folder as a system header path (which is admittedly sort of a gross hack). You need to manually add new files to the iPhone project, but I have found that to be less of a pain the installing static libs into my build root.
I'm not sure if the suggestion from the previous answer would work. If you look at my previous question, you'll see that I've failed to load a custom framework on the iPhone even though the framework works fine on Mac.
I would go with method 2.
You could develop your application in JavaScript, CSS, and HTML. You would use the WebView and UIWebView objects on the Mac and the iPhone respectively. You can do pretty much anything you want in the WebView objects, even make calls down to Objective-C.
The QuickConnectiPhone installer, found here https://sourceforge.net/projects/quickconnect/, installs QuickConnectMac and QuickConnectiPhone templates into Xcode.
This way you can quickly create an application in one environment and then migrate the view to the other. In fact the QuickConnect framework is highly modular.
If you don't want to develop in JavaScript the same modular framework is found on the Objective-C side of the templates installed.
It should make it much easier for you to do what you are attempting.