8

I need to distribute a closed-source library (in the form of a dynamic .framework) which uses C++ internally and exposes an Objective-C API at the module boundary. The library will be used by numerous clients in their apps.

As I understand, by default the C++ runtime is linked dynamically via libc++.dylib. So the question is: is the runtime compatible between iOS releases / compiler versions? Can my clients run into binary compatibility issues when using my library (e.g. OS is shipped with a different runtime version, producing subtle bugs in my library)?

Sidenote (as to where this question is coming from): On Windows, you would usually want to link the C++ runtime statically if you want to ensure that the binary works on all systems without the need to ship the specific version runtime component. So I wonder if the same problem existent on iOS.

ivanmoskalev
  • 2,004
  • 1
  • 16
  • 25

3 Answers3

3

Only Apple knows if or when some C++ library is no longer supported. My guess would be that apps depending on a no longer supported runtime would stop working completely or would not build with your library in the first place. I have found this info here (Xcode 10 (iOS 12) does not contain libstdc++6.0.9) indicating that, over the years, support for older runtimes may be dropped and then you'd need to build another library.

Speaking from past experience, we had an app - I know, not quite the same as a library - in the App store with a C++ core and Objective-C shim and did not care about C++ runtime compatibility. That never became an issue. Instead, from time to time (over several years and iOS iterations) there were slight user interface quirks that needed to be ironed out (I think with iOS7 - ok, you may not have an UI) then the forced move to 64-bit, then some API change where Apple wanted things that way or another... When there as an issue then we did a build with the latest XCode and that would have helped keeping things running, but the old version kept on working.

The upshot is, you'll need to be prepared to maintain your library and maybe something else 'gives' before the C++ runtime becomes a problem and then you'll just have to do another build for your customers.

J.R.
  • 1,880
  • 8
  • 16
  • The dropped support for an old version of libstdc++ that you mention only affected the development of new apps or new versions of an app. It did not affect unchanged apps in the App Store or on devices. – Codo Feb 22 '19 at 12:03
  • Agreed. It would not be incomprehensible though if Apple dropped on-device support completely after a long time (5 years? 10 years?) and it is not unreasonable to expect that a maintained app is re-build every now and then. – J.R. Feb 22 '19 at 20:49
3

In the past new iOS versions have provided excellent compatibility with existing apps. If an app was built for an old iOS version, it would also run on new iOS versions. It seems that Apple simulates old iOS versions - including their visual style and quirks. If you run an app built for iOS 6 or earlier, it will still have the grayish look and not the new style introduced with iOS 7.

Once an app is updated, the story is different: you will need to use the latest Xcode, new rules apply and many old features will have been decommissioned. As part of this, Apple might remove APIs, switch to a new C++ compiler, change the standard C and C++ library etc.

So:

  • A released app in the App Store should continue to work for many years with your C++ library.
  • However, for the development of new apps or new version of an existing app, you will need to check the compatibility of your library regularly and possibly provide updated versions.
Codo
  • 75,595
  • 17
  • 168
  • 206
3

If you are using libc++.dylib which is system wide library, then any application can also use it. So by definition whoever delivers this library (Apple), is responsible for maintaining backward binary compatibility of this library. If compatibility would have been broken, thousands of application would be corrupted.

On other hand if you are using some custom version of this library then it should be shipped with *.framework. In this case there is no risk of breaking compatibility since it is shipped with framework.

So basically there is no reason for you to worry about that. If something is gets broken then lots of applications will be broken.

Marek R
  • 32,568
  • 6
  • 55
  • 140