Bug 45800 - Issues with providing bindings for a UNNotificationServiceExtension framework
Summary: Issues with providing bindings for a UNNotificationServiceExtension framework
Alias: None
Product: iOS
Classification: Xamarin
Component: Tools ()
Version: XI 10.0 (iOS10)
Hardware: Macintosh Mac OS
: --- normal
Target Milestone: (C9)
Assignee: Rolf Bjarne Kvinge [MSFT]
Depends on:
Reported: 2016-10-21 18:55 UTC by Ryan Lepinski
Modified: 2017-02-02 18:39 UTC (History)
6 users (show)

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

Verbose log file (219.38 KB, text/plain)
2017-01-05 18:28 UTC, Ryan Lepinski
Updated logs (720.35 KB, text/plain)
2017-01-09 17:07 UTC, Ryan Lepinski
Sample project (17.44 KB, application/zip)
2017-01-09 17:07 UTC, Ryan Lepinski

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 Ryan Lepinski 2016-10-21 18:55:21 UTC
The extension limitation where app extensions can only access frameworks in the main apps bundle makes providing framework bindings for  frameworks that provide UNNotificationServiceExtension near impossible.

While trying to provide the AirshipAppExtension framework as a separate package, I ran into the following issues:

- Framework packages that are added to an extension must also be added to the main app bundle. However if the main app does not reference the package that includes the framework, the framework will not be loaded into the application bundle. I tried force loading, preserve attribute, etc... nothing would cause the framework to show up in the app bundle. I was able to work around this using 2 different methods by either manually referencing the package in the main app, or including the framework in a package that the main app was actually using.

- When I tried one of my workaround to get an app extension framework for a UNNotificationServiceExtension in the app bundle, it would work fine until the app ran on an older iOS device. I received this error: 

Dyld Error Message:
Dyld Message: Library not loaded: /System/Library/Frameworks/UserNotifications.framework/UserNotifications
  Referenced from: /private/var/containers/Bundle/Application/B6FB66F7-2D65-408A-9EC0-BB0CE5731EBA/Demo.app/Frameworks/AirshipAppExtensions.framework/AirshipAppExtensions
  Reason: image not found
  Dyld Version: 390.7

I eventually tried writing a C# library that accomplished the same thing, but I ran into a memory issue described here - https://bugzilla.xamarin.com/show_bug.cgi?id=43985.

It would be awesome if framework for packages referenced in an extension project would be dropped in the framework directory of extensions bundle. This would remove the limitation and make sure that any packages referenced in the extension will work fine.
Comment 1 Alex Soto [MSFT] 2016-10-23 20:57:18 UTC
Thanks for the detailed description Ryan we will look into this.
Comment 3 Ryan Lepinski 2016-10-31 17:20:46 UTC
Rolf, looks like the fix is to copy the frameworks into the main app bundle's framework directory. I believe this will still cause the dyld issue above. Extensions have their own framework directory that can be used to make sure the frameworks are only loaded when the extension is loaded. It will also allow an extension to use a different version of a framework than the main application.
Comment 4 Rolf Bjarne Kvinge [MSFT] 2016-10-31 17:24:17 UTC
@Ryan, you ran into the dyld issue because in your workaround you made the main app link with the framework, which prevents it from working on older iOS versions (since older iOS versions don't support user frameworks).

With the fix, the main app won't link with the framework, so you won't run into the dyld issue.

I also checked with Xcode, and frameworks used in extensions end up in the main app's Frameworks directory.
Comment 5 Ryan Lepinski 2016-10-31 17:36:14 UTC
@Rolf, awesome. I was not 100% sure what caused the dyld issue. I will try it out once its released.

For Xcode, I am pretty sure the default behavior is to not copy any frameworks over and instead you have to add a build phase step that explicitly copies the framework. When you add that it ends up in AppBundle/Plugins/AppExtension/Frameworks. The default build settings for an extension looks in both directories, so as long as the dyld is fixed this should be fine.
Comment 6 Mohit Kheterpal 2017-01-03 11:53:23 UTC

It would be helpful for us if you verify this issue at your end with new Xcode. And feel free to reopen it, if you are still facing this issue.

Comment 7 Ryan Lepinski 2017-01-04 17:44:57 UTC
I will verify that the issue is fixed later today.
Comment 8 Ryan Lepinski 2017-01-04 23:27:57 UTC
This does not appear to be 100% fixed. I see the frameworks.txt file in the generated extension directory, but extension package is not listed. Only the Mono.framework:


I tested https://www.nuget.org/packages/urbanairship.appextensions and https://www.nuget.org/packages/urbanairship and both failed to list the framework. The generated app bundle also does not have the expected frameworks.
Comment 9 Rolf Bjarne Kvinge [MSFT] 2017-01-05 09:37:15 UTC
@Ryan, can you attach a verbose build log from your test project (see https://developer.xamarin.com/guides/android/troubleshooting/troubleshooting/#Diagnostic_MSBuild_Output for how to make build logs more verbose, and also please add "-v -v -v -v" to the additional mtouch arguments in the project's iOS Build options).
Comment 10 Ryan Lepinski 2017-01-05 18:28:00 UTC
Created attachment 19099 [details]
Verbose log file

Attaching logs
Comment 11 Rolf Bjarne Kvinge [MSFT] 2017-01-09 11:38:35 UTC
@Ryan, it looks like you're not using any code from the urbanairship assemblies in your project.

It's not enough to add a reference to the nuget/project/assembly for the corresponding assemblies to be put in your app, you also need to somehow reference any code from those assemblies (this can be as simple as a "Console.WriteLine (typeof (Some.UrbanAirshipType));".
Comment 12 Ryan Lepinski 2017-01-09 17:07:10 UTC
Created attachment 19135 [details]
Updated logs

@Rolf, my mistake. I recreated the extension to give it a better name for the logs but forgot to extend the class again. After extended the class things are still not working. I attached new logs and the sample project I am using to reproduce the issue.
Comment 13 Ryan Lepinski 2017-01-09 17:07:36 UTC
Created attachment 19136 [details]
Sample project
Comment 14 Rolf Bjarne Kvinge [MSFT] 2017-01-10 15:39:33 UTC
@Ryan, thanks, I found a bug in the implementation, which I'm fixing now:

master: https://github.com/xamarin/xamarin-macios/pull/1460
cycle9: https://github.com/xamarin/xamarin-macios/pull/1461
Comment 16 Mohit Kheterpal 2017-02-01 17:07:06 UTC
@Ryan Thanks for reporting this issue.

Now, Could you please check if this issue is 100% fixed for you, when you get a chance?

Comment 17 Ryan Lepinski 2017-02-02 18:37:18 UTC
Looks like framework.txt is updated with the proper frameworks and I confirmed all the expected frameworks end up in the app bundle. Appears to be fixed! Awesome job @Rolf!

I am currently unable to fully test the UNNotificaitonService as I do not have a iOS device on hand (requires remote notifications), but I can report back on Monday.
Comment 18 Mohit Kheterpal 2017-02-02 18:39:59 UTC
Thanks @Ryan for verifying this issue. 

As of now I am closing this issue by marking it as Verified. Please feel free to reopen it if you are still getting this issue.