Cocoa framework development: sharing between projects - cocoa

I am currently developing a handful of similar Cocoa desktop apps. In an effort to share code between them, I have identified a set of core classes and functions that can be common across all of these applications. I would like to bundle this common code into a framework which all of my current applications (and any future ones) can link against.
Now, here's the hard part: I'm going to be developing this framework as I go, so I need each of my desktop apps to have a reference to it, but I want to be able to edit the framework source code from within each of the app projects and have the framework automatically rebuilt as required.
For example, let's say I have the Xcode project for DesktopAppNumberOne open, and I decide that one of my framework classes needs to be changed. I would like to:
Open and edit the source file for that framework class without having to open the framework project in Xcode.
Hit "build" on DesktopAppNumberOne, and see the framework rebuilt first (because one of its sources has changed), then see parts of DesktopAppNumberOne rebuilt (because one of the frameworks it links against has changed).
I can see how to do this with only one app and one framework, but I'm having trouble figuring out how to do it with multiple apps that share a single framework.
Has anyone had success with this approach? Am I perhaps going about this the wrong way? Any help would be appreciated.

Make an XCode Project for you framework.
In the 'Groups & Files' Panel > See the Blue Project Icon at the very top left? Drag and drop that into the 'Groups & Files' Panel of any other project you like.
So, make an app project, and drag in the project icon from your framework project.
CMD-i on your app target. Here you set your dependency on the framework and Link against it.
A few points
Linking multiple apps to one framework can be stressfull. You will either need to install your framework into /Library/Frameworks or equivalent or bundle up into each app.
For development purposes, i find setting a custom, common build directory for each of the projects eases things. I set each project to build into /Code/Build/Debug. This means that framework search path for debug build can be $CONFIGURATION_BUILD_DIR. For your release builds you will still have some work todo with install paths, rpaths, etc. Pain in the Ass!
XConfig files are your friends. The Open source google mac toolbox stuff is a good example of how to use them. You will probably need at least a Project_debug.xconfig, Project_release.xconfig, Target_framework.xconfig, Target_application.xconfig.

Related

React Native - multiple targets

I'm creating a RN app that is meant to be some kind of wrapper. It should have multiple targets (like in Xcode) and all its content (images, text, etc.) should be target dependent. Unfortunately, I cannot find any useful informations about how to achieve this without opening Xcode or Android Studio project and create those targets manually (like here). Is there any other solutions for this?
I was still struggling with described problem but I finally found a solution. It's not easy, needs writing a bit of boilerplate code and looks more like a workaround but I hope it will help someone in the future. What I did is I have completed my wrapper app with the resources for one of my targets so I can have visual effect. In the project's root directory I've created a folder with subfolders for each target. Inside each I have put files (images, source code files, other assets) that are target-dependent. Then I've created bash script that takes one argument - target's name. Based on it, it replaces all the target-dependent files from target's subfolder to the original file's destination in the project structure. In this proces all meta-data informations are also replaced so after firing .sh file I can build the app and upload it to both stores. It's really time consuming to create all these apps separately and publish them and it's maybe not the best solution, but at least it works!
On android, you can edit build.gradle files, java or properties, without having to launch Android Studio (which simply uses Gradle)
You can build different type flavours by only changing app/build.gradle
On iOS, that's another story. Project file (.pbxproj) is a mess,and other Workspace/Scheme files are not easy to read or script. So XCode is the way to Go.
I tried to have dynamic target & Info.plist, there are tools to script that like PlistBuddy
in the end, I saw there are many ways to launch a React Native app for developpers. Some prefer the command line, and only VSCode.
Others want to play with native IDE.
By the way, native IDEs are VERY useful.
e.g. : you want to fine-tune your application performance, using XCode view hierarchy debugger or android Studio Layout Inspector (and be sure you don't use to many views), or use any other performance tools these IDEs offer...
In the end, I used react-native-config along with multiple almost similar configs (Info.plist < target < Scheme for each), here's a post giving an overview of the setup.

Does adding a framework to a project folder increase binary size?

I've had an issue with frameworks and absolute paths in the past. If I link (without copying to project folder), frameworks like facebook, then every time I go to a different computer I have add the framework back in.
Should I just drag it to the project folder, then add?
If I place the framework in the project folder, does that increase the binary size?
Follow up question: Sometimes when I add a framework to the project folder, it still has the absolute path, so every time I launch the project, I get a missing framework compile error. So I have to remove the reference and drag back in. How can I avoid it?
Thanks.
The app size should not be affected by simply copying framework from other location to project directory.
Also the compiled objects links to framework binary, most times framework is not embedded in app file. But it really depends on what framework you are dealing with, in Xcode 6, you may need to embed a framework in Embedded Binaries (with signing) to your project, and thus app size is affected.

Managing Static Library project as a module like Framework on iOS project in Xcode4

Many people including me trying to make a kind of Static Library framework for iOS to archive some kind of modularity. Framework is best way to do this, but it doesn't provided by Apple, and workarounds don't work well.
https://github.com/kstenerud/iOS-Universal-Framework/tree/master/Fake%20Framework/Templates
Fake framework cannot be referenced from linking tab in Build Phases.
Real framework needs modification of system setting. And still not work smoothly on every parts.
Problem is static library need header files, and it's impossible to reference header files on project at another location on different project without some script. And script breaks IDE's file management abstraction.
How can I use static library project like a convenient module manner? (just dragging project into another project to complete embedding)
I've since updated the template to do away with the script target. It now builds the universal framework from your regular target, so you can include it in workspaces or as a project dependency.
With a real framework target, you can just add it to "Link Binary With Libraries", and it will show up fine.
With a fake framework, Xcode doesn't recognize the target type, so you need to add the link command manually. For example, assuming your framework is called Foo:
Expand the "Products" group of your framework project, then drag "Foo.framework" into the "Link Binary With Libraries" build phase of your app target.
In your app target, edit "Other Linker Flags" in the build settings and add: "-framework Foo"
Framework template link for anyone not sure what we're talking about: https://github.com/kstenerud/iOS-Universal-Framework
Solution.
Goto Project or Target's Build Settings.
Find Public Headers Folder Path. (definition name = PUBLIC_HEADERS_FOLDER_PATH)
Set it as YourLibrary.framework/Headers. I have used ${PRODUCT_NAME}.framework/Headers for automatic syncing with project name.
Goto Build Phases and find Copy Headers step.
Move all required headers to Public pane.
Now all header files will be formed like Framework and copied with product binary. IDE will copy all of them as a unit into some temporary folder like app's build folder. So referencing app project can use the headers automatically.
This is a trick. The created directory structure is not real framework. Because it doesn't contain any binary. However we don't need real framework to archive just this functionality. IDE works with frameworks without any binary. And I don't want to hack IDE without documentation about internal structure.
This works well, however you'll experience some problem when you Archive. This happens because Xcode4 behaves specially when Archiving. Here's workaround.
For each embedded library project, SKIP_INSTALL = YES in target build settings.
For final product project, FRAMEWORK_SEARCH_PATHS = "${OBJROOT}/UninstalledProducts". Take care about this setting should be set only for Release build mode.
Now it'll be archived well.
At the case of cross platform library, there can be many projects for many platforms. But sometime Xcode will show some product as red color even it compiled successfully.
This is a bug of Xcode. IDE display depends SDKROOT of Project build setting. So if you set the SDKROOT differently on Target, it won't work. You can check the the product will become black color after changing the SDKROOT of the Project build setting. See this Open Radar entry for details.
http://openradar.appspot.com/9636211
If you wish to fix this bug, please report this to Apple's Radar. Duplicated bugs will make attention of Apple. Just copy & paste my report :)
I found this : http://db-in.com/blog/2011/05/creating-universal-framework-to-iphone-ios/
It seems to work.

Installing IB plugin

I have created IB kit plugin now i want to use that plugin in other Xcode project
how to do that? I have tried developers guide but not able to get that done ..please answer
First of all, I assume that you want your plug-in to be embedded within your application's bundle. If not, you can place the IBPlug-in framework in a standard location like /Library/Frameworks.
Creating the Plug-in
Once you have an IBPlugin project created in XCode using Apple's template, you need a little tweak:
Change the name of your framework target so it differs from the Plug-in's. For instance, you could call it MyIBPluginFramework.
In the Target Properties > Build : Modify the Installation Directory of MyIBPluginFramework to #loader_path/../Frameworks.
Also set its Dynamic Library Install Name to #executable_path/../Frameworks/$(CONTENTS_FOLDER_PATH)/$(PRODUCT_NAME).
Set the Installation Directory of MyIBPlugin to #loader_path/../Frameworks/Resources.
(when built, the plug-in is placed in the Resources directory of the framework).
At this point, it should work both in Interface Builder and in IBCocoaSimulator.
Embedding in an application
Drag the IBPluginFramework.framework folder to the Linked Frameworks group of the application's project. Edit your application target: append to Frameworks Search Paths the path #loader_path/../Frameworks/MyIBPluginFramework/Resources.
You're now able to link against the framework and the plug-in, but the framework must be copied to the Frameworks directory of your application when building. Add a Copy Files phase to your target, and drag the framework into.
I cannot garantee success (I managed to make mine work, but might have forgotten to relate a step here), but you're given the big lines.
I thought that usually you put plugins in to the application specific folder found in the Library folder either at the root or user level, e.g.
/Library/Interface Builder 3.0/
On my system I have another folder under that called "Library", and under that called "User Objects" which is empty.
So I would try putting it in each of these folders in turn, restarting XCode and Interface Builder each time (just to be sure)
/Library/Interface Builder 3.0/
/Library/Interface Builder 3.0/Library
/Library/Interface Builder 3.0/Library/User Objects
Hope that helps.

Xcode 3.1.1 and static libraries

I'm an experienced VS.NET user and trying to get up and running on Xcode 3.1.1.
Here's what I'm trying to accomplish:
I'd like a static library ("Lib") to have its own xcodeproj file. I'd an executable application ("App") that makes use of Lib to reference Lib's xcodeproj file so that changes to Lib cause App to relink. Ideally, I'd like to be able to edit Lib's source files inside App's Xcode workspace so I don't have to task around all the time to make changes.
I figured out from the online help that I can simply drag the static lib xcodeproj in to my app's project and it gets the reference. I see that once my static lib xcodeproj is in my app's project, I can simply drag it to the App's target and it understands that App depends on Lib. This seems like the right path, but things aren't quite working the way I'd like yet.
Here are my questions:
It seems that simply having App depend on Lib doesn't cause App to link with Lib. It seems that I have to explicitly drag libLib.a from the Lib folder into App's "Link Binary With Libraries" build stage. In VS.NET, simply specifying the project as a solution dependency adds it to the link line. I just want to make sure I'm not missing anything.
When I have App open in Xcode and I drag Lib.xcodeproj into it, I don't get any of Lib's source files there. I only get libLib.a under the "Lib.xcodeproj" folder. In VS.NET, I can edit Lib's source files right there and rebuild it, etc... but with this approach in Xcode, changes to Lib.cpp don't cause Lib to rebuild when I rebuild App. Ideally, I'd get all of Lib's source files and targets to show up when I drag Lib.xcodeproj into App. Is there any way of doing this?
Thanks in advance for any responses!
You're correct that making target A depend upon target B (whether within the same project or across projects) does not cause target A to link against target B. You need to specify them distinctly; this is because they're separate concepts, and you might have dependencies between targets that you don't want to link to each other — for example, a command-line tool that gets built by target C and is used as part of the build process for target A.
Also, you're correct that referencing project B from within project A will not let you see project B's source code in project A's window. That's because Xcode does not have the same "workspace" model that Visual Studio and Eclipse do; you above alluded to the existence of "a workspace containing project A" but Xcode doesn't really have any such thing, just a window representing project A.
Open the App project. Right-click on the App target and choose "Get Info." Then go to the "General Tab" and find "Direct Dependencies." Click the ( + ) (plus sign) button to add a direct dependency. The Lib.xcodeproj should appear among a list of possibilities for you. Choose the Lib target from that list.
That should accomplish that the Lib project must build (or rebuild) when you build the App target.
(Editing my own post now. I realize I said nothing about point number 2 in the question. I am actually still thinking about number 2. I am not sure if that is possible or not.)
I'm also novice to Xcode 3.1, just played with mentioned by you issues and found that there is no problem regarding to your second question. Whatever application you use to edit the dependence library source code, your main project will rebuild the dependence target. I checked it by:
edited the source file, of the library your app depend on, by notepad application.
Selected dependence library project reference, mouse right-click, and select 'Open With Finder', then selected wanted source file and edited it.
Everything working well.
I am also a fairly new user of Xcode. Most of what I know I learned from an Xcode book by James Bucanek (ISBN 047175479x). It is an older book that was written for/with Xcode 2.2, but I find that pretty much all of it still applies for me today, and I currently use Xcode 3.1
You can probably find a cheap used copy if you are interested.

Resources