I am using Swift, Xcode 6. Is there any good reasons to separate common code between watch app and main app into a separate Cocoa Touch Framework (embedded into the project)? By code I mean core data models, maybe some helper extensions etc. I have not intension to use this framework in other projects. Instead of creating framework, I can just add files to both targets.
Also, is there any problems with swift, framework versions that I can run into when creating new releases of the app?
Related
Im currently working on creating a Swift Framework, my framework currently includes OpenCV as a Linked Framework. I have read up on the standards for distributing frameworks, and many people say that frameworks shouldn't be compiled/packaged with other 3rd party frameworks as this can cause issues like framework collisions etc...
So I knowing this I have been trying to work out how to build my framework but without packaging OpenCV with it, so the application will have to depend on OpenCV in order to use my framework.
I've had a look into Cocoa Pods and how the dependency management there will handle this for me. The problem with Cocoa Pods is the distribution, we need to be able to carefully control who can gain access to the framework.
So in conclusion, what would be the best way to create my framework without including the 3rd party dependency? Im open to any ideas!
This is the first framework I've created and some help or pointers would be very appreciated.
iOS8:
I'm trying to create a Database framework (DBKit) that will be used amongst our apps. DBKit requires Couchbase (ObjC) and Alamofire (Swift) frameworks.
I'm trying to avoid using Umbrella framework as it's discouraged by Apple.
Questions:
When creating a framework, how do I tell the framework to use Couchbase and Alamofire within the Demo Project?
Is using Cocoa Pods to manage frameworks inside a framework a good idea?
Believe you should be linking to the respective external libraries from within your application and NOT your own framework.
For Couchbase, you can simply drag in the frameworks to the 'Supporting Files' folder within your iOS project.
I have a bunch of code in an iOS project (named "MyLibs") I re-use across different apps. I drag the MyLibs project into the workspace of whatever app I'm creating. I don't use unit tests per se, but I have buttons than run through all the tests very easily in the iPhone app.
I'm learning Cocoa and would like to divide up my library into libs I can use on both projects. I was thinking it would be MyCommonLibs (or MyFoundationLibs), MyIOSLibs and MyCocoaLibs.
However, when creating a new project, I must choose between an iOS app or a Cocoa app. It looks as though the iOS Framework and Library -> Cocoa Touch Static Library is appropriate because it links against the Foundation framework. On the other hand, I'd prefer to use an application template if there is no major drawbacks to it.
I need to be able to use MyCommonLibs in both app types, as some of them are useful to both, such as NSArray categories, etc.
Which template should I use for the MyCommonLibs and must I use a Library, Framework (in the Mac OS templates) or can I just use a normal application template (as I've been doing thus far)?
Create an iOS Framework & Library project. Let's call it TestLib.
Add a new target (File > New > Target) of type MAC OS X Framework & Library.
This way, you can compile both an iOS library and a MAC OS X library from the same project.
You can choose which files are included in each target. So if you want to make a class available for both iOS and MAC OS X, you add it to both, and if you want to make it available for only one platform, you can add it to only one lib.
As you can see in the screenshots below, SharedClass is available in both libs, iOSOnlyClass is available for iOS only and MACOnlyClass is available for MAC OS X only.
You can also add targets for unit tests in the same project.
To organize your code, you can put the shared classes in a group, and the classes of each target in a separate group.
Not many libraries such as GHUnit suggest you to use them as a Framework.
While most libraries such as Facebook iOS SDK just require you to drag the project into existing XCode project.
So when you are building a library which suppose to be re-use by other project in the future, should you use Framework or just like many current opensource projects, don't use Framework provided by XCode.
There is a reason why those opensource projects are provided as static libraries or just source code and not Framework, Frameworks are currently not supported by iOS SDK.
You can only use Frameworks provided by Apple - parts of SDK itself. Your code cannot be linked against your own or third party Frameworks.
So stick with one of those ways - I personally prefer static libraries.
This question comes from this other one I asked earlier: Calling custom Objective-C from a pyobjc application?
I want to re-use a small part of the app logic from my iPhone app in its server-side component, which runs on OSX. Based on what I was told in the other question, it looks like I need to compile a "framework" for both iOS and OSX from this little piece of app logic.
If we assume that I am able to isolate all the code that is to be in this framework into a single .h/.m pair of files that has no other non-Cocoa dependencies, what would be the easiest way in XCode to build this framework for each architecture and avoid double-coding all this logic on the server?
I tried adding a new OSX framework build target to my iPhone project, but this doesn't get very far and XCode bails out pretty quickly with:
target specifies product type 'com.apple.product-type.framework', but there's no such product type for the 'iphonesimulator' platform
Any help much appreciated, as I am currently dupe-implementing to keep things moving forward, but this is pretty obviously becoming a huge waste of time and source of errors when the implementations become slightly out-of-sync.
Depends on what you used in your custom class. If you did not use anything from UIKit / AppKit then the class is probably going to live well on either platform, otherwise, you’d have to use target conditionals and include separate code specially written for both platforms.
You can have multiple targets in one Xcode project, their Base SDK set separately for the Mac / iDevices.
Adam's comment to my original question answers this question. Although still interested to see if there is a way to do it all from a single XCode project, the solution I have now is plenty good enough for what I wanted to achieve.