Best Way to Link Frameworks?

Question

Created May ’23

Replies 4

Boosts 0

Participants 3

I released an App say 1.0 . Now , I am shipping a huge update say 2.0. But in 2.0 , I want to ship a framework of 1.0 , so that end users can fallback in case of any catastrophic issue in 2.0.

Now my 1.0 uses a dynamic framework(say version 1.5) and few static libs(say version 1.5)

Now my 2.0 app uses same libs and frameworks but different versions of them i.e. dynamic framework(say version 1.8) and static libs(say version 1.8)

So my app running is 2.0 , here is what I want

When 2.0 is running and 1.0 framework is NOT running , it should use dynamic framework(version 1.8) and static libs(version 1.8)
When 2.0 is running and 1.0 framework is running , it should use dynamic framework(version 1.5) and static libs(version 1.5)

Here is what I have done so far:

Dynamic Framework of 1.0 is compiled and dynamic framework(version 1.5) and static libs(1.5) are not embedded into the framework But when I integrate it in my container app(2.0) , My container app behaviour corresponding to these(dynamic framework and static libs) start throwing exceptions . If I remove the 1.0 framework then app behaves fine. So most probably linking issue

Any guidance to achieve this would be highly appreciated!

Boost

Answer 1

DTS Engineer OP

Apple

May ’23

Best Way to Link Frameworks?

So, let’s start with some basics. What platform are you targeting? And, if it’s macOS, are you shipping independently? Or via the Mac App Store?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0

Answer 2

asmaan OP

May ’23

Its iOS and will be distributed through iOS App Store

0

Answer 3

DTS Engineer OP

Apple

May ’23

Its iOS

OK.

What you’re suggesting is very strange, but it should be feasible. The main issue is conflicts between the two frameworks. For example, if both frameworks have a class called AppDelegate, things will end badly.

There are two ways you can get around that:

Switch to dynamic loading
Rename everything

The second option sounds pretty obvious: Rework your code — either the old version or the new version, or both — so that everything has a unique name. However, there’s likely to be some hidden traps in that. For example, if your app use Objective-C +load methods or C++ static initialisers, you might find that they have version conflicts.

The first option is a bit less obvious. The basic strategy would be to put both versions of your apps in their own frameworks and then write a tiny executable that using dlopen to load and start the chosen app. This gets around the conflicts associated with the second option — there’s only one every one version in memory at a time — but there’s still potential for grief. For example, if the framework has code that expects to find resources in the main bundle, you’ll have to rewrite that to look in the framework’s bundle.

Honestly, this sounds like a lot of work for very little gain. If I were in your shoes I’d think carefully about whether it might be better to spend your engineering resources on other tasks.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0

Answer 4

dssdgvsdgsd OP

May ’23

Since you suggested dlopen, so I have to say that but my problem is deeper than that.

I have filed a DTS ticket as you guys will need exposure to my code. You can look at ticket 2386741

0