3rd party framework for iOS 13 and above crashes on iOS 12

Question

Created May ’22

Replies 1

Boosts 0

Participants 2

My app uses a 3rd party framework built for iOS 13.1 for some functionality that will only be available to users with A12 or newer chipsets. We planned to disable access to that functionality on older devices at runtime and do not need to load/call any functions in the related framework.

The issue is that including the framework in the app causing crashes on iOS 12.5 and earlier with

dyld: Symbol not found: ___chkstk_darwin
  Referenced from: /private/var/containers/Bundle/Application/.../<framework> (which was built for iOS 13.1)
  Expected in: /usr/lib/libSystem.B.dylib

which makes sense to me but I'm hoping to work around it :)

I have reached out to the framework developers to look at building for a lower minimum OS version but they rely on features that came in with iOS 13 so are not sure if it can be done, how long it might take, or when they could look at it..

Since the framework is not needed on iOS 12.5 or earlier, looked into weak linking against it. This works about halfway. If I weak link the framework and don't embed it in the app, things work as I need. If I include it, I get the same crash as above.

Hoping for info/help with the following possibilities (if possible):

Is there a way to ignore specific undefined symbols without modifying the framework?
Is there a way to weak link that covers this case but I was doing it wrong?
Is there a way to ship the impacted framework only on iOS 13 and above, but from the same listing in the app store?

Any other options I'm not aware of ?

Boost

Answer 1

DTS Engineer OP

Apple

May ’22

This specific error is caused by the compiler adding an unconditional ___chkstk_darwin call because it knows that that symbol will always be present based on its deployment target. Except now it’s not )-:

Weak linking the framework won’t help because the framework is present, and so are the frameworks it depends on, so the dynamic linker is able to form a closure. Things then fail later on, as the dynamic linker tries to resolve symbols.

I have reached out to the framework developers to look at building for a lower minimum OS version but they rely on features that came in with iOS 13

Right. Keep in mind that the framework doesn’t need to work on iOS 12, it just needs to be complied with iOS 12 as its deployment target. They could do that and then marked all their symbols as only available on iOS 13 and later and things should work.

Another option is for you to not link to the framework at all but instead include it in your app and resolve symbols manually using dlopen and friends. That’ll work, but you’ll need a bunch of extra glue code.

The best option, IMO, is to drop support for iOS 12 (-: That’s a pretty small audience these days.

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

1