What I want to do is pretty simple : adding Charts framework (here on github) to an Objective-C project.
And I simply don't know how to do this. The readme says : drag charts.xcodeproj into your project, but where exactly ? On the same level ? Inside the project or inside a specific directory (like Products, Frameworks...) ?
Then, the readme says you should import the bridging header but an other documentations I read that this header is only needed when you include Objective-C code into a Swift project and not the other way around.
Then, among different posts or tutorials, some changes in project configuration seem to be needed but I don't know exactly which ones.
This is my first ios development on an already existing project, and I'm pretty sure this is not as complicated as it seems but everything is new to me right now and I'm pretty lost.
Related
I converted my entire Objective-C framework to Swift. After building it, when I check the framework's Header files, it is still displaying the old Objective-c functions.
I deleted all the Objective-C files from the framework project. I have tried cleaning and building the project. But with no success.
You deleted the Objective-C files from the Xcode project, but did you also remove them from the file system and any source control you might be using?
Also, your Build Settings in your Xcode project can be searching for library/header files even after you've removed them from explicit inclusion in the Project Navigator in Xcode.
Just make sure the search paths don't look for old Obj-C stuff. Be careful of recursive searches like MyXcodeProject/**. The ** will recursively search all subfolders and their subfolders for things to include.
Better to specify folders directly in the search paths if you can. If you know you don't need search paths, you can just clear them all.
...although, you may want to leave the default exclusions in place:
Remember that you can't subclass a Swift class in Objective-C.
Therefore, the class you migrate can't have any Objective-C
subclasses.
Once you migrate a class to Swift, you must remove the corresponding
.m file from the target before building to avoid a duplicate symbol
error.
To make a Swift class available in Objective-C, make it a descendant
of an Objective-C class.
Command-click a Swift class name to see its generated header.
Option-click a symbol to see implicit information about it, like its
type, attributes, and documentation comments.
from: https://developer.apple.com/documentation/swift/migrating_your_objective-c_code_to_swift
Also, delete your DerivedData, do a clean build and restart the xCode.
How can you see "Header" files in Swift based framework even after removing Obj C files. Definitely there's the build issue. If build is proper, then you are not referring/using to the right framework (in the app) after building it. This is most common mistake that I observed with many developers.
Maybe this can help, try it on your framework's Target Build Settings:
Disable modules (Enable modules (C and Objective-C))
Make sure the Swift version is set (Swift Language Version)
i have a huge project written in objective c with many pods in it and i would like to export the entire thing as a framework. is it possible? i have never did such thing before. my project also has a big assets library and frameworks inside of it like Firebase/Fabric/Facebook and much more. how will i handle the info.plist file of the existing project in the new framework?
i have tried this tutorial
https://www.raywenderlich.com/126365/ios-frameworks-tutorial
but it doesn't mention having previous pods in my existing project.
Sorry if this is too basic, I'm a kind of a rookie on app development.
I've been trying to add this GitHub framework for SpriteKit easing to my XCode project. The only steps for installation (that doesn't require CocoaPods) the framework provides are: 1: Drag the Pod/Classes folder into your project. 2: Import the frameworks in the _Archive folder.
However, it doesn't seem to work after doing this. I can't import the framework into my swift files, and I can't use the actions. I may've done the 2nd step wrong, I may not have done it as it's supposed. I've searched all over the internet for ways to import a GitHub framework into XCode, but every answer seems to be different and specific for each case.
I think you may have missed the second step (you say there is 'only step'). The second step is to drag the framework from the _Archive folder. You can find it in the clone of the project folder. Also, try the sample project and see how it's organized. Make sure that you add the framework to the Link Binaries... section in the project Build Phases.
the Dropbox iOS SDK has its own Framework bundle but in order to customize it easily I ve chosen to include its Xcode project as a subproject.
How should i refer to its .h classes?
I ve added the .xcodeproj from the "Add files" button and I ve added in the Header Search Path the following value:
$(PROJECT_DIR)
The subproject looks to be at the same level with the main project.
Shouldn't the importing itself link the dependencies?
(I m really frustrated by the import system in Xcode)
Your basic approach seems sound (and is pretty close to how I handle lots of vendor projects). Since you've added $(PROJECT_DIR) to your header search path, and assuming that the framework is in a directory named "Dropbox", then you can refer to the packages a couple of ways:
#import <Dropbox/Header.h>
#import "Dropbox/Header.h"
I prefer to think of the sub-projects as "system-like" and so tend to use angle-brackets, reserving double-quotes for internal code. But either approach is really fine.
Shouldn't the importing itself link the dependencies?
No. You still need to link the dependencies. #import does just exactly one thing: inserts the requested file into the current file. That's all it does. It is identical to you taking the referenced file and copy/pasting it into your code (that's basically how it's implemented in the pre-processor). That this is used for "header" files is a matter of convention. It has nothing to do with how the compiler works. You technically could import a .m file that included a method in it as a way to do code reuse. (I've seen that done in projects I've worked on. Please don't do this....)
When dealing with ObjC modules, it's a little different (using #import rather than #import). But if you're just importing headers as you seem to be, think of it as "stick this other file right here, exactly as written."
Short version of the question:
So basically what I'm looking to do is to take an existing library written in C (https://github.com/lsalzman/enet) and turn it into a static library for iOS.
I am just looking for an easy to understand step by step of how to accomplish this in Xcode.
Long version:
I've gone over some tutorials for making a simple static library that's written in Objective-C (http://www.raywenderlich.com/41377/creating-a-static-library-in-ios-tutorial), and I generally understand what is happening there, but I'm failing to understand how to do this with existing code written in C.
I think I'm getting close, but I'm not so sure.
I start out by making a "Cocoa Touch Static Library" project in xcode.
I add all of the enet .h and .c files
make sure the enet stuff is in my "User Header Search Paths" in build settings.
hit build - it compiles!
The generated .a file is 517kb, so I'm pretty sure it's building the enet stuff in at this point.
My problem right now though is that the header file for the library is basically empty:
#import <Foundation/Foundation.h>
#interface enet_ios : NSObject
#end
I'm thinking I either need to write a wrapper in Objective-C that talks to the enet library, or I need to reconfigure my xcode project somehow so that enet.h is the 'entry point' into this library and not xcode's pre-generated .h/.m files. I'm not really sure how to do that, though. Ideally I'd just like to skip any sort of wrapper and use what the enet library is already providing me.
Thanks for taking a look!
Question, are you trying to call the functions using objective c syntax / object orient notation? Then you do need a wrapper object, no way around that.
But if you are fine calling C functions directly, which is completely acceptable in IOS/Objective C, then it is a matter of making sure your header files from the enet library (the ones in the include directory I see in the github link you shared) are also distributed with the static library. This is a limitation of the static library. You can copy them with the *.a, but they must be copied with the static library. This does differ from a Framework, which has included .H and assets, which developers are not easily able to create with Apple's tools for IOS.
I find that library management with Objective C to be painful on its own and static libraries a challenge for this and many other reasons. One more suggestion, definitely more elegant and portable but slightly overkill for personal use, would be building the project as a cocoapod. You can do this by forking the project and converting it to cocopods. There are lots of examples of how the project structure should look on cocopods and other OSS like AFNetworking. This seems to be the defacto standard way people are creating IOS libraries. See http://cocoapods.org/ for more details. This will include the source code as the pod and compiled against the target application.
This is the only way i deal with my own libraries and third party libraries. It has gotten to the point that if the library doesn't use cocoapods, i don't use the library or fork it and do make it a pod myself....