I see there’s many libraries, open source, like Cocos2d, ShareKit, FormatterKit, etc. that seems up to date. (Check GitHub).
But still, implementation, snippets, samples and manual are intended to be written in Objective-C.
But, a method is a method… I think… If I get an instance of any framework/library of these and I call the method in a full Swift enviroment, would I be affected behind the scenes?
After June WWDC Swift gonna get serious, Apple is pushing hard, I’m just getting ready for the move and I don’t want my Apps to implement a soon-to-be deprecated library implementation in Objective-C.
I do not understand your question so much that I will regard your question as "Is it possible to use the Objective-C&Swiftin the same project?"
Yes, Apple claimed that developers can use Bridging-Header to implement double languages development, whatever your main developing language is ObjC or Swift. The specific details and theories about it you shall check from there.
Next I want to tell you some errors occurred in my project when I used Bridging-Header.
I always meet this kind of problem like import 'file not found'. I think you can try to check your file&folder hierarchy. Such as you have a root folder named Project, as is often the case, there is another Project in your previous Project, the root folder.
And Checking the Objective-C Bridging Header in the Build Setting. Sometime error can occurred for Project/Project/Bridging-Header.h. And the error can be corrected by changing the definition as Project/Bridging-Header.h.
If the location of Bridging-Header.h is not matching with the definition in the Build Setting, the error like import file not found will occur.
I just tell your my solution for Bridging issue I already met, I hope it can help you.
Related
I am working on a project that up to now, despite the mess, it was working ok. Today, believe it or not, I have been updating it to Swift 5.
The project has iOS and tvOS targets as well as frameworks, tests, and top selves extensions. The project also was started using Objective-C and over the years has become 90% Swift.
I am not sure at what point something went wrong but, when compiling, I get the following error for all my top self extensions (mostly all tvOS Targets).
I have found similar questions but I can't understand whats going on.
Any ideas?
You are probably missing an import StoreKit in the Swift files that define IAPHelper. Sometimes this gets imported transitively, and Swift doesn't necessarily need it, but the Swift bridging header does.
Ultimately you need to make sure there's an ObjC #import StoreKit; that is evaluated before this line of code.
First, I have to thank Rob for his tips. I wish he could get the points!
After troubleshooting with the tips provided:
Add StoreKit to your linked frameworks list. -> Didn't work
#import StoreKit; before #import <...-Swift.h> -> Showed error use of #import when modules are disabled
I also saw that "...-Swift.h" was only declared in the Build settings of my "...Topself" targets. Still quite unsure why as I would have thought the whole project still have ObjC dependencies... Still quite new to this challenge.
Furthermore, If I unfold the error I could see that there was some kind of error trying to find "...-Swift.h" file.
At this point, I remembered that I am using cocoapods (I don't like you, you don't like me relationship) and I hated to see the warning "...Overrides Enable modules (C - Objective-C)" so I set it to default for the whole project.
Turns out that that for all "...TopSelf" targets, the default value is NO.
By Overriding Enable modules (C - Objective-C) to YES, clean, and build, everything started working again.
I have an Objective-C project whose .ipa was tested with this tool online: https://www.immuniweb.com/mobile
It reports that my app has a high risk security issue, pointing to the canAuthenticateAgainstProtectionSpace in the NSURLConnectionDelegate protocol.
This method has been deprecated by iOS after 8.0 version. My app is not using it directly anywhere and I suppose this is not used by apple also even indirectly, since it is deprecated.
I tried a sample ipa (new project with nothing in it) with Objective-C project and the same issue came for that as well. But it did not come for a sample ipa which supported Swift. Even if this is just a warning, is there a way to fix other than just supporting Swift language only?
The tool has detected that the .h file that defines the NSURLConnectionDelegate protocol declares the canAuthenticateAgainstProtectionSpace function. This is, of course, to be expected.
It would make more sense for the tool to report implementations of the method, not simply declarations of it
Since you haven’t implemented this method you don’t need to worry about flaws in your implementation.
As for getting rid of the issue...Don’t use the tool? It doesn’t seem very good based on this.
Is there an option to tell it not to scan .h files?
TBH it seems like a bug in the tool if not any of your Libraries or Frameworks internally uses that.
In your test for the sample Objective C project it's reported as bug however for a sample swift project it's not reported Hence I guess it's more of bug from the tool side.
I would suggest you to report this issue to them.Hopefully they will get you back with some suggestions.
or
you can try some other pen-testing tools as well.
I think I just must be stupid.
I'm having a lot trouble understanding very basic things concerning frameworks in Xcode/iOs/Swift. While I've certainly gotten some things to work, I've gotten more and more confused about what I'm actually doing. And the documentation on the web just confuses me more.
When I see discussions about how to import particular frameworks (e.g. https://github.com/danielgindi/Charts is the library I'm playing with, but I've seen this pattern repeated in other libraries) they seem to always tell me include the Xcode project file as a child project of my project, in addition to linking things as an embedded binary. This confuses me. Is it not possible to link an already compiled framework to my project without including all the source code of the project?
That is, can't I just take a library.framework file, and add it to my embedded libraries list and be done with it?
In the frameworks I've played with (again https://github.com/danielgindi/Charts is my primary example, but this is true in many others I've played with) I can't seem to use the framework without Carthage or CocoaPods. For me at this stage, that is just confusing... I accept that they are useful tools to automate a difficult process, but I'd really like to understand what that process actually is before I let a tool automate it for me. As I search the web I just seem to always be led back to these tools as being the correct way to do things.
So here are my questions.
If I find a framework library on the web... do I need its source code or can I somehow just link to a compiled version of the framework?
In my reading, it seems that libraries made with Swift are somehow second-class citizens because Swift is a newer thing. Is that still the case? (The articles I read about this seems to date from 2014-2015).
Is there are good place to understand how Apple expects me to add a framework to a project, without using CocoaPods or Carthage?
No need to add source code. Just add the framework to Target ->
General -> Linked Framework and Libraries -> Tap on + and select
your framework.
In my opinion, many new libraries are being written is Swift. So you won't be left behind for using swift.
Apple has documentation about adding frameworks to XCode. But I would suggest to use Cocoapods , as its easy to manage libraries.
Cheers :)
I have 2 frameworks created by me that use (both of them) a library also created by me.
The first framework initialize the library and makes all its workflow. After finishing the first framework, the second one must start.
But when the second one is going to start, after initializing the library, the app using both frameworks crashes with a exc_bad_access error.
Apparently the library is created correctly, but if i comment the line of code to initialize the library in the second framework, the workflow continues (it crashes later because it has no library initialization).
Is there anything I'm doing wrong? Should I use two separate libraries instead?
EDIT:
Imagine the situation:
Framework A has this methods: start, stop. And while it works it delegate to the methods: infoFromA,frameworkAFinished.
Framework B has this methods: start, stop. And while it works it delegate to the methods: infoFromB,frameworkBFinished.
Both start methods initialize the static library mentioned (lets call it problematicLibrary).
Both frameworks present some views to make its functionality. So lets make an example of the app workflow.
At the app view viewWillAppear method, I start the Framework A just using:
[FrameworkA start]; , this will initialize the library and present a view. With this view (using my problematicLibrary) some info will be delegated to the infoFromA delegated method. And after all the info is delegated, it will delegate to frameworkAFinished.
When the FrameworkA has delegated to the frameworkAFinished I start the next Framework: [FrameworkB start]. As the other Framework, it will initialize the library and present a view. While debugging, all the initialization of the library is done (create the instances of the needed objects and a new instance of the library is created) and while its presenting the view it goes through the viewDidLoad method and then it throws an exc_bad_access error at the problematicLibrary initialization line (which has been done before and continued to present the view!!) without going into any other method from the view.
I have checked if the initialization is doing well, and all the variables were at null value before the initialization, and a new memory address is given to the library object.
This sounds strongly like a symbol conflict to me. I'm just surprised the linker didn't catch it, but I assume that's because you're using a static library in both your frameworks instead of simply yet another framework.
Generally speaking, I'd warn that "this is a bad idea™". What you're trying to introduce into your design is basically dependency management. Like a lot of blog articles and specifically this SO answer suggest, you should avoid packaging frameworks (and by extension libraries) into frameworks.
What most likely happens in your scenario is this (I admit I'm guessing a bit here): You linked the library into Framework A. Thus, the library becomes a fixed part of it. Its symbols are in it, even if you did not expose them to the app in any header files or the like. As long as you use only that, everything works smoothly. Then comes Framework B, of which the library is also a fixed part. Even though you can't see it from your app, the very same symbols are inside it. This, however, clashes with the symbols that were already loaded by Framework A, hence a crash (as said, this would usually be caught by the linker, but I guess you "tricked" it by building the frameworks beforehand and packaged the library in them). Maybe somebody else can explain this in more detail, but that quickly becomes besides the point as to how you would go for a solution. From how I see it, it just won't work this way.
So here's a suggestion for how you can solve your problem:
If you really, really need to split like this (two frameworks used in your app using the same dependency), I'd suggest removing the library from the frameworks (i.e. make them depend on it, but not package the actual .a file in them) and documenting that properly. Then add the library to your app project, just like you added the frameworks.
If you want to make this fancy and easily installable into other apps, I'd recommend setting up a private CocoaPods repository and turn your frameworks into private pods. You can then easily define the library (or rather "new Framework C") as a dependency for Framework A and Framework B. When you then pod install in your app, cocoapods figures out the dependency and adds Framework C automatically to your project. This scenario is exactly what cocoapods (or any dependency manager for that matter) was designed for. It automates and helps in the project setup, so that the final build (the app) doesn't have to figure out dynamically what it can and can't use. The end result is the same.
Trying to duplicate that "in code" quickly becomes messy. Frameworks trying to figure out things of the surrounding app/project that uses them (like "is my dependency so-and-so already linked? if not, can I load my own version of the library?") can lead to a lot of pain.
Okay, in response to your comment I'll try my hand at a more detailed How-To for the non-cocoapods setup. As a preface, though, let me say that that's kinda hard to do on top of my head, as I have no ready sample project to toy around with. Since this is one of those "set it up once and then forget aout it for a long time" I have to admit my recollection of these things is a bit fuzzy, so consider this as a sort of "rough direction". There might be things you need to configure differently than how I recall them. Other SO user are thus hereby invited to edit and correct my answer here, too. :)
First, I have to say I am not exactly sure whether you need to convert your static library into a framework or not for this, I think you don't so I'll go from here (I have never used a static library in that way).
That means you can leave the project that builds your library as is. On second thought, you probably have to do this to be able to link against the library without making it a part of the framework that uses it. I will still refer to this code as "library" in the below points, but assume that you're able to turn it into a dynamic framework as well.
The projects building Framework A and Framework B should be changed. I don't know how you have this set up (as one project with various targets, whether you have a "development application" as part of it to test the frameworks on themselves, etc.), but the important thing is that in the target that builds a framework, the library should be linked (i.e. in the "Link Binary With Libraries" build phase), but not copied (i.e. it must not be in the "Copy Bundle Ressources" build phase). It might be tricky to set up any development/test target you use to run, depending on how you did that so far. For example you might have to manually edit Library Search paths in your build settings to be able to properly compile the framework.
Lastly, you need to change your final app's project settings, obviously. The library that was originally part of Framework A and B now needs to be linked to from its project directly, and, obviously, it needs to be copied into the bundle as well. Note that any projects that include either of your frameworks (A or B or both) in the future must do so, otherwise they won't work, because these frameworks expect the library to be present (but no longer "bring it with them").
In spite of this long-ish text wall, it shouldn't be that complicated, I think, but you may still want to check out how cocoapods can support you with something like this, perhaps it's helpful in the future. The linked article expects basic knowledge on how to use a pod and write one, but the other guides on the site explain that pretty well. I am just saying this because in the end, when using cocoapods in a project to add multiple libraries/frameworks that introduce dependencies, it basically sets up your project in the way I described above. It uses some fancy shell scripts that ensure everything is copied to the correct folders and such, but overall speaking that's how it works: A pod's podspec tells cocoapods what additional pods to include in your app for it to work (a dependecy the pod expects to be there, but doesn't "bring in" by itself).
Check if they are both compiling for the same target.
Check if they have access to the same target membership.
Check build phases to see that they are both there.
I think because the first library is not 'well' referencing the second one.
Also i think that you can't import a framework inside another one.
To make things easier, you can merge the two frameworks on a single one.
Also you can add a callback (using protocols or closures) that informs for the end of the first workflow, and you use this callback to initialize the second framework. This way the initialization will not be made automatically.
My company makes a static library for iOS apps. One annoying step for developers is that they have to manually link against all the required frameworks that the library uses, and failing to do so leads to somewhat confusing compiler errors.
I would have previously thought this wasn't possible, but the company Chartboost claims to automatically link against non-default frameworks like AdSupport and StoreKit. Based on my testing in their sample app (available from the linked page), so far this appears to be the case (Even when disabling "Enable Modules" and "Link Frameworks Automatically" in the app that links against the static library).
Is there some way to enable this feature when creating a static library? I've tried enabling modules and the "Link Frameworks Automatically" LLVM options in Xcode, but so far haven't been able to get it working.
There's a piece of code called CBDynamicallyLoadedDependencies that calls dlopen() on the appropriate system library before making the function or method call.
My original answer wasn't correct. the dlopen() call is just in the x86 code. On the device, it's something different, but my ARM assembly isn't strong enough to figure it out. All I can say is that there's a piece of code that's acting as a trampoline to the desired functions and that references the system library files (like /System/Library/Frameworks/AdSupport.framework/AdSupport).
But the point is that it's not a simple project trick that makes it work normally. There's internal code involved.
They might use modules you mentioned and #import instead of #import, which should make the libraries link automatically.
For reference, check this question.
This might not be what you're looking for, but if you don't yet support Cocoapods, I would strongly advise taking a look:
http://cocoapods.org/
(Edit: Cocoapods is essentially linked to Xcode. Other IDEs will need another solution.)
You can advertise Cocoapods to developers as the "easy" way to work with your library, and the manual method as...well, the manual method. ;)
I'm not aware of any industry resistance to Cocoapods, so I don't see a downside to supporting it, and it does solve the problem you're talking about (albeit in a roundabout sort of way).
Also I've found Chartboost VERY developer-friendly. You might even reach out to them and ask.