Cocoa Touch Framework library - versions and memory distribution - ios

I am going to create a Cocoa Touch Framework library and I am confused how they work on iOS. What would happen if there are different apps installed on a device that use different versions of that library?
Would each app has access to its own version of the framework or they will share some single version of it?
How would that single version would be determined then?
Logically thinking each app should own its own version, but I am not sure how frameworks and dynamic libraries work on iOS. Thanks for the help.

Related

FCM integration in IOS swift framework

how to do FCM integration in ios framework. I have did and tested in application but i want to do in framework so that i can sell to someone to use my code. The problem i'm facing when u create xcode project on touch framework you cannot enable APNS option. Can anypne get me out of this. Thank You
First thing is first:
As you already stated that, you've successfully integrated FCM into your cocoa touch library, here one thing i wanted to suggest.
If you're shipping your solution as framework to third party. I'm assuming you are using Cocoapod. Declare the Firebase related pods (which you are using) as Dependencies. Cocoapod will automatically manage this dependency tree. If you are preparing just plain framework and included Firebase related frameworks within it, it's wrong. Because the third party developer cannot update the Firebase related frameworks while new SDKs are released. Another thing that, the third party developer may use firebase's other services which required them to integrate firebase sdks within their app. In that case duplicate class declaration error may arise.
Enabling APNS
Yes you cannot enable APNS from capability for touch framework. Instruct your third party developer to enable required fields for their project. Include it in your integration guide or README.md what ever you are using to help third party developer integrating your cocoa touch framework.
From https://github.com/firebase/firebase-ios-sdk/blob/master/docs/firebase_in_libraries.md
Conclusions:
The Firebase SDKs may be used from an embedded dynamic framework in your project (e.g. for code reuse purposes) only when Firebase is not used from the app directly.
The Firebase SDKs should never be used from vendor dynamic frameworks because the version of Firebase compiled into the dynamic framework will conflict with the versions compiled into the app or included in any app bundles.
Conclusions:
Using the Firebase SDKs in static frameworks and libraries is safe, meaning there will be no symbol collisions, for both vendor and in-app internal libraries.
If the static framework is used from an app and its extensions, then it will be copied to each target, increasing the app download size.
If the static framework is used from an app and its dynamic dependencies, then it will be copied in both the app and its dependencies, which will result in undefined behavior.

Is that a good idea to keep CommunicationManager framework in my iOS project

I have an old iOS app where it is using Communication Manager framework to communicate with my server. Since communication framework library files architectures are 32bit and I can not change the app architecture to 64bit because of these lib files. So I removed the communication manager framework totally and added AFNetworking for this app.
In my other old app, it is also using communication manager framework but that app is not using those 32bit lib files directly. Project is finding these lib files by library search path, but it's not included in the project 'Linked Framework and Libraries' section. Somehow communication framework is using AFNetworking framework, which is also used in this 2nd project. And this project architecture is 64bit.
NOW, is that a good idea to remove the communication manager framework totally from my 2nd project as well and use AFNetworking or just keep it as it is since it is not causing any problem now and app architecture is 64bit. I know from next iOS release Apple is going to support 64bit architecture app only.
Note: I didn't develop any of these apps from scratch.

Creating pod from Unity iOS project

I have created a game with Unity.
I have exported it as a Xcode project.
I want to create a pod from that Xcode project.
My problem is that the exported Unity project has a Native folder that contains way too many files.
When installing my podspec for the Unity project my computer runs out of ram when trying to write up the Pods.xcodeproj.
Has anyone faced a similar problem as this one?
No you can perfectly do that. But in order to achieve what you are asking, you should your game as a view in native ios and then use cocoapods to add extra capabilities to your ios app. In this case your game becomes like a component in your native ios app and you can play with the rest of your app as you wish here is a guide that can help you;
https://github.com/jiulongw/swift-unity
You probably should not do that. Unity creates a XCode project that is not supposed to be versioned or reused in any way. It is just necessary to create a working iOS version of your game and sometimes used for debug proposes but it is an ephemeral thing. If you want to redistribute your game you should do it using the Unity project itself.

iOS Framework which can support iOS7

I have very simple requirement for my iOS SDK
-Support iOS 7 and above.
-Include some swift code to my SDK
Problems:
-With iOS 8, Xcode allowed us to develop cocoa touch frameworks, but they can only be run on iOS 8 and above.
-If I create a static library, I cannot include swift code.
-I was using using Real Framework, but Real Framework does not get installed with Xcode 7.
So, What does a poor developer do ?
You can always have an alternative distribution method for your SDK for users that are targeting iOS 7.
You can offer an SDK in a single concatenated file, that is simply merging all your project source files, which user can drop into project tree and compile together with all the other source files. This applies only when you have either Swift-only or Objective-C only SDK
If SDK user uses workspaces, he may embed your SDKs .xcodeproj directly in his project
Anyway both methods require source code distribution as the user needs to compile the code from within his project. Dependency maintenance is also more difficult.
For a reference you can check how it is done in:
https://github.com/SwiftyJSON/SwiftyJSON
It is a Swift library, but integration with iOS 7 based projects is the same.
I could not find any solution for this. I compromised:
I am NOT using swift code.
I am distributing static library (.a file and a .h header file) instead of a framework. (this is to support iOS 7)

Developing an iOS app and an iOS framework in parallel: What's the easiest way to manage the dependency?

I'm working on an iOS app which depends on an iOS framework which other devs on my team and I also maintain.
What's the best way to configure my project so that the framework builds as a dependency for the iOS app? My current configuration requires me to build the framework, and then drag it into the XCode project for the application.
I don't know how it handles frameworks, but I highly recommend using CocoaPods for these kinds of code-sharing projects:
http://cocoapods.org/

Resources