Bug 61039 - When code sharing is enabled (default for extensions) Xamarin.Sdk includes /System/Library/PrivateFrameworks/IOSurface.framework/IOSurface
Summary: When code sharing is enabled (default for extensions) Xamarin.Sdk includes /S...
Alias: None
Product: iOS
Classification: Xamarin
Component: Tools ()
Version: master
Hardware: PC Mac OS
: High major
Target Milestone: 15.6
Assignee: Sebastien Pouliot
Depends on:
Reported: 2017-12-07 23:21 UTC by Vincent Dondain [MSFT]
Modified: 2018-02-02 01:26 UTC (History)
3 users (show)

Is this bug a regression?: No
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description Vincent Dondain [MSFT] 2017-12-07 23:21:21 UTC
### Steps to repro:

1. Create an iOS main app + iOS extension.
2. Make sure that both the main app and its extensions have the same linker behavior (don't link) and supported architecture (e.g ARM64), otherwise you won't get `Xamarin.Sdk.framework`.
3. Build for device.

### Actual behavior:

When running `otool -L ...MainApp/bin/iPhone/Debug/MainApp.app/Frameworks/Xamarin.Sdk.framework/Xamarin.Sdk`

See `/System/Library/PrivateFrameworks/IOSurface.framework/IOSurface` (this shouldn't be there since it breaks submission).

### Expected behavior:

When running `otool -L ...MainApp/bin/iPhone/Debug/MainApp.app/Frameworks/Xamarin.Sdk.framework/Xamarin.Sdk`

Only see `/System/Library/Frameworks/IOSurface.framework/IOSurface`, nothing private.

### Workaround:

Pass `--nodevcodeshare` to mtouch's extra arguments to disable code sharing.

Version information: https://gist.github.com/VincentDondain/284e611feeed438c4c079eb9d61c7580 (also doesn't work on, xcode9.2 stable).
Comment 1 Sebastien Pouliot 2017-12-08 14:03:38 UTC
This is a bit uncommon as:

- the "managed" linker will remove the IOSurface API in most cases (unless used by application)

- if the min OS set for the application includes support for IOSurface then the "native" linker will do the "right thing"
Comment 2 Sebastien Pouliot 2017-12-20 15:04:27 UTC
PR master https://github.com/xamarin/xamarin-macios/pull/3118
Comment 4 Mick Byrne 2018-02-02 01:26:08 UTC
We're actually facing this issue in an app that I've been attempting to submit for a few hours now. This app includes:

- A main iOS app that uses SceneKit and textures (which I'm assuming uses IOSurface somewhere down there).
- An iOS extension
- Targeting iOS 10+
- Both apps targeting the same architecture, "ARMv7 + ARM64" and linker behaviour, "Link Framework SDKs Only" for Release | iPhone configuration.

When we do the release build, we end up getting rejected by Apple (after the .ipa is uploaded through Application Loader). The message from Apple is:

"The app links to non-public libraries in Frameworks/Xamarin.Sdk.framework/Xamarin.Sdk: /System/Library/PrivateFrameworks/IOSurface.framework/IOSurface"

Things I have attempted that didn't work:

- Changing the linker behaviour to "Link all"
- Adding the "--nodevcodeshare" mtouch argument
- Switching to the beta channel and updating everything (as I see this issue is fixed in the latest preview of Xamarin.iOS) - after the update, the app would build but immediately crash when installed on a simulator.

Finally I had to change the target iOS to 11.0; not a great outcome but at least we can ship our app.

I appreciate your attention to what is, as Sebastian pointed out, a pretty rare combination of scenarios.