I have made a library that make by swift cocoa touch framework, and now I need to export it to file .framework that can import for another project. In fact, I'm workground that copy the framework from product forder, but I think it is not a correctly solution (such as it may be archive and export, but I can't do it). Please help me. Thanks.
If I understood correctly you made a swift framework and want to include the framework to another project.
You can just drag the framework .xcodeproj from Finder to your new project and start using it.
Related
This question will be easy for Xcode pros but for a MonoTouch developer it seems to be impossible to resolve. :-)
I'm using Xcode 4.5 and I want to target iOS 5.1 and above and iOS Simulator 5.1 and above.
I have a a library project here and it is coming with a prebuilt binary named "DemoLib" (no extension and it is 11MB in size). The library is a fat lib for Simulator and iOS 5.1+.
I can use that library without any problem.
However if I try to build the library myself, I end up with a "DemoLib.a" file (notice the extension and the size of 30MB). How can I get the same build result? What is a .a file compared to the file without extension?
I tried to build the project "for running", and "for archiving" in Xcode. Both results in the same 30MB .a file.
I was expecting some dropdown in Xcode where one could select "DEBUG" or "RELEASE" build and the latter one would create the smaller lib.
Of course I could never tell without seeing the framework's project file. Having said that, there is an excellent guide to creating and compiling iOS frameworks here: https://github.com/jverkoey/iOS-Framework
Using the above guide, you should be able to recreate your framework's project from scratch, add the files you have to it, and properly compile it.
Hope this helps! :)
Did it come with a Makefile? Create a new target, set the build settings of the target to what's in the Makefile, then set your project to depend on that new target.
A file with the .a is a static library, which means it depends on nothing external and all the code it needs is compiled inside it. I think no extension generally implies dynamic library, which means it'll depend on some dependencies being present on your system to link against. Maybe that's why the .a is so much bigger. I think Xcode will build static by default because iOS does not allow the use of dynamic libraries.
The dropdown for what to build is in your scheme. Command+shift+< to view your scheme. Within the scheme you can edit which environment each method of building will use.
I've been reading about how to create a new plugin for Phonegap and seems to get it by following this tutorial.
http://wiki.phonegap.com/w/page/36753496/How%20to%20Create%20a%20PhoneGap%20Plugin%20for%20iOS
However, I'm having a hard time grasping how to extend an existing plugin. (not creating a new one)
Been reading this tutorial.
http://hiediutley.com/2011/03/28/phonegap-tutorial-series-3-extending-the-phonegap-api/
I can't seem to get where I can possibly add line of codes to the .m file for example. In my XCode, I only see the .h files but not the .m file.
Or is there a better way to extend an api?
Thank you,
Tee
EDIT: This answer is no longer completely correct.
The latest versions of Cordova / PhoneGap do not come as a compiled framework and it is much easier (especially since 2.2.0) to tweak the version of cordova a particular app uses as it is simply a sub-project in XCode.
To get at the .m files you would have to download the PhoneGap (Cordova) iOS source and make your changes them compile your own version of the PhoneGap framework.
That is not as hard as it sounds, but can be a bit daunting if you are not super comfortable with Objective-C and command line compilation tools.
To paraphrase the README from the iOS source, for example:
$ git clone http://git-wip-us.apache.org/repos/asf/incubator-cordova-ios.git
Make your changes, then...
Launch "Terminal.app"
Navigate to the folder where the Makefile is (./PhoneGapLib ?)
Type in make then press Enter
This should build "PhoneGapInstaller.dmg" into the dist folder. This is what you use to install your new version of PhoneGap.
Another option is to take the .m and .h files of the API you are extending (by simply getting them from the GitHub source repository) and making them into a new plugin with your own name. As an example, rather than extend the Camera API and make changes to Camera.m and recompile etc... I chose to make a plugin unoriginally called MyCamera that had the code from the Camera API and my own extensions. Most of the APIs in PhoneGap (at least in iOS) are basically already plugins in their own right, so they don't need much tweaking to be turned into a plugin just for your purposes.
This method also means you can upgrade PhoneGap later and not clobber all your extensions.
I am trying to import one of my xcode projects into another, and I was just wondering if there were some best practices for this task, or if anyone has any advice how to make this happen?
Thanks.
Not sure exactly what you mean by import.
If you want to do a framework then you'll want this.
Framework Docs
If you want to do a shared library then you'll want this.
Shared Libs
Just click on .xcodeproj file and it will be automatically opened in whatever version of xcode installed in your system and if the project was created in an older version just click on "Modernise Project" which you can find at the bottom of your xcode and xcode will take care of the rest.
I have had some issues with the AWS IOS SDK framekit, since it was not built to work with OSX apps. I found a modified version of the SDK that Brad Larson created.
The directory structure looks something like:
AWSiOSSDK.framework/
src/
--Amazon.Runtime/
--Amazon.S3/
..
--AWSCocoa/
----AWSCocoa_Prefix.pch
----AWSCocoa.xcodeproj
----etc
--include/
So if I go into the xcode project, and build AWSCocoa it compiles. But when I look at the timestamp on the AWSiOSSDK.framework, it hasn't changed. So I don't know what compiling this AWSCocoa gets me, or where I can find the files it creates. So assuming that building AWSCocoa.xcodeproj is supposed to build a new version of the framework compatible with OSX development, where do I find and link what I've built?
The AWSiOSSDK.framework bundle is a precompiled framework, probably left over from my earlier experiments in making a Mac version of this (since you can't use frameworks like this with iOS, only static libraries). Ignore that.
If you are using Xcode 4, your built framework will be created somewhere in your ~/Library/Developer/Xcode/DerivedData/ directory. To find where it lies, go to your project navigator in Xcode 4, expand the Products group, right click on AWSCocoa.framework, and select Show in Finder. This is no different from any other third-party framework you would compile.
Nominally, you'll want to add this framework as a target dependency in your application so that it is built alongside that. You'll also have to make sure that the framework is copied into the appropriate location within your application bundle so that it can be used by your application at runtime.
I have a more general question on working with libraries on with Xcode when building iPhone apps. I've created a framework from a project I've been working on to use some parts of it in other apps. That works pretty good, so far. But I have no idea how to debug into the files included in the included framework.
I hope to get some kind of 'best practice' on that.
Thanks a lot
–f
There have been a lot of discussions of how best to reuse code with static libraries. I've settled on the method described here by Clint Harris (which I think is what Shawn is suggesting as well). Creating a project dependency in this way automatically compiles the library for your project's target (simulator/device, debug/release) so you don't need four different copies of the compiled library sitting around. It also lets you step into the library source when debugging, as you want. Finally, updates to the library are included in any of the linked projects the next time those projects are compiled (so you don't have to recompile and redistribute the library binary to those projects yourself).
Generally, I'll include the Xcode project for the library as an external project dependency of the main application's project. The advantage of project dependencies, is that you can add a build phase that builds a fresh copy of your library along with the main project, and of course it will let you set breakpoints in the library's code.