I can not use Realm within my framework as a framework because apple rejects nested frameworks.
However maybe there is no problem in using Realm as a pod depedence within my framework. Or is there a problem?
How does objective C be a single namespace I will not have collisions?
In my framework I want to capture GPS coordinates.
What is the benefit of using Realm for this versus file system?
Thanks
You're correct that the iOS App Store doesn't allow nested dynamic frameworks. The suggested solution is to place frameworks at the same directory level in your app bundle.
The benefits of using Realm are well documented on the official website: https://realm.io
Related
Years ago, using ObjC and frameworks (and frameworks inside frameworks), it was common from time to time the “duplicate symbols” error. For example, if you created a framework including RestKit and then the app that wanted to use that framework was using RestKit too, you had that error. One way to fix it was to rename the included source code into your framework using a prefix. Or just avoid using 3rd party dependencies on your framework. Note we used to use static libraries, rather than dynamic libraries.
Is it possible to have the same problem with pure swift apps/frameworks and dynamic libraries today? As far as I understand, swift uses the concept of module for namespaces, something we didn’t have with ObjC.
I mean, is it possible to create a framework that uses Alamofire (let’s say version 5), and then create an app that uses Alamofire (let’s say version 5.0.1) AND your framework that uses Alamofire too?
I am using a similar setup and i did not face any such duplicate symbols in my project.
Let me share my experience.
I have a project setup like the one below.
Main Project -> uses PromiseKit via Cocoapods
My Framework -> uses PromiseKit via Cocoapods
Main Project uses My Framework
I did not face any such issue while running this setup. IMO, hope it is taken care by Swift compiler.
Is it possible to create a framework which only works on a specified app bundle identifier?
I want to prevent to reuse ur framework by shipping out my app source code / project which is using a selfmade framework
If you ship source code, you cannot prevent the code from being reused. If you want to ship the compiled framework, you can use the approach described in the answer of Reinier Melian.
You could also consider creating a pure library instead of a framework. See here and here for the differences.
I’m going to port my iOS app to OS X (and perhaps tvOS after that). It uses the wonderful Realm for persistence. I’m currently in the process of breaking out the data model in my application into a dynamic framework, which I intend to use in both the iOS and OS X targets, to share that code, since it’s completely independent of UI.
I’m wondering what the best way to get Realm included here is. I will no longer need / want it as a dependency on the app itself, but I’d like the app to depend on the dynamic framework, then for that framework to depend on Realm. I don’t mind how this is done, i.e. I’m not particularly tied to Cocoapods.
The idea is that the apps themselves don’t see or care about Realm, or the persistence model used inside the framework. Like so:
iOS App -> Dynamic Framework -> RealmSwift
OS X App -> Dynamic Framework -> RealmSwift
tvOS App -> Dynamic Framework -> RealmSwift
-> = Depends on
I’d also like, if possible, for this to be smart, and include either the iOS or OS X builds of Realm, so that all I need to do is build the respective target in my Xcode project, and it’ll grab the right framework, right version of Realm, and all will be well.
How might I go about this? Is Cocoapods going to allow this? Is the dynamic framework the right idea in the first place? Should I make a podspec for the dynamic framework?
You can create middleware by defining s.dependency "Realm" in the podspec for your dynamic framework, if you think of it as just another pod in your app then you can have a nice abstraction layer that keeps you working above Realm specifically, I do this with analytics via ARAnalytics.
In terms of real-world linking, you'll have to link Realm to your app though, the runtime doesn't easily allow scoping a dependency specific to another library, as they exist inside a flat object graph.
I've got an iOS dynamic framework written in Swift and would like to know what ways I can "export" the framework for use in external projects, while leaving the implementation unexposed.
The "best" solution I've come across so far is from this article, but for some reason autocompletion stops working when I'm trying to use classes from the framework in a project.
Right now I'm using a Xcode workspace to use the framework within a project. However, as mentioned I don't want to have the implementation exposed.
I understand that Swift doesn't have separate interface and implementation files found in Objective-C, but am just curious as to how other people approach this.
If I am building a Framework that depends on Parse, would this cause issues for apps already using Parse and would like to use my framework? More specifically, if I initialize my Parse app in the framework, and then the app using this framework initializes Parse again, would they interfere?
Yes, they will and that's the reason CocoaPods exist, to ease the pain of dependency of frameworks.
Framework must not depend on another framework is the bottom line. If you do , it will leads to collisions, if the other framework also includes that framework.
I would suggest you to learn CocoaPods. The dependency problems will find the solution.