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.
Thanks for the detailed description Ryan we will look into this.
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.
@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.
@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.
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.
I will verify that the issue is fixed later today.
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.
@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).
Created attachment 19099 [details]
Verbose log file
@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));".
Created attachment 19135 [details]
@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.
Created attachment 19136 [details]
@Ryan, thanks, I found a bug in the implementation, which I'm fixing now:
@Ryan Thanks for reporting this issue.
Now, Could you please check if this issue is 100% fixed for you, when you get a chance?
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.
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.
Notice (2018-05-21): bugzilla.xamarin.com will be
switching to read-only mode on Thursday, 2018-05-25 22:00 UTC.
Please join us on
Visual Studio Developer Community and
GitHub to continue tracking
issues. Bugzilla will remain available for reference in read-only mode.
We will continue to work on open Bugzilla bugs and copy them to the new
locations as needed for follow-up. The See Also field
on each Bugzilla bug will be updated with a link to its new location
After Bugzilla is read-only, if you have new information to add for a
bug that does not yet have a matching issue on Developer Community or
GitHub, you can create a follow-up issue in the new location. Copy and
paste the title and description from this bug, and then add your new
details. You can get a pre-formatted version of the title and
In special cases you might also want the comments:
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.