Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
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
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.
The following crash only happens on the iOS simulator.
ObjCRuntime.RuntimeException: Cannot get the method descriptor for the selector 'oneSignalApplicationDidBecomeActive:' on the type 'Com.OneSignal.Sample.iOS.AppDelegate', because the selector does not correspond to a method
at at (wrapper managed-to-native) UIKit.UIApplication:UIApplicationMain (int,string,intptr,intptr)
at UIKit.UIApplication.Main (System.String args, System.IntPtr principal, System.IntPtr delegate) [0x00005] in /Users/builder/data/lanes/3969/7beaef43/source/xamarin-macios/src/UIKit/UIApplication.cs:79
at UIKit.UIApplication.Main (System.String args, System.String principalClassName, System.String delegateClassName) [0x00038] in /Users/builder/data/lanes/3969/7beaef43/source/xamarin-macios/src/UIKit/UIApplication.cs:63
at Com.OneSignal.Sample.iOS.Application.Main (System.String args) [0x00008] in /Users/Kasten/Documents/OneSignal/OneSignal-Xamarin-SDK/Samples/Com.OneSignal.Sample.iOS/Main.cs:12
The crash can be reproduced by running the Com.OneSignal.Sample.iOS project in the OneSignal.sln below.
This does not crash on real iOS devices, only an issue with the simulator.
If the following lines are added to the AppDelegate.cs in the project the issue no longer happens.
public void OneSignalApplicationDidBecomeActive(UIApplication application)
public void OneSignalApplicationWillResignActive(UIApplication application)
public void OneSignalApplicationDidEnterBackground(UIApplication application)
public void OneSignalApplicationWillTerminate(UIApplication application)
The sizzling is done in our native OneSignal iOS library noted in the links below.
Please fix this simulator issue in a future Xamarin release and / or provide a work around that works at the plugin level rather than the app project level as I have listed above if possible.
The OneSignal library does not do method swizzling correctly.
In particular the _cmd argument is not correct when the library call the original implementation (for the exception you mention the _cmd argument is 'oneSignalApplicationDidBecomeActive:', when it should be 'applicationDidBecomeActive:'), which Xamarin.iOS requires to look up the correct managed method to call.
More information is available here: https://blog.newrelic.com/2014/04/16/right-way-to-swizzle/
It might be possible to add "--registrar:static" to the additional mtouch arguments in the project's iOS build to work around this problem.
Thanks for the work around flag. This is definitely better than having to include an export for each method just for iOS Simulator compatibility.
I went back and forth on with implementation of swizzling to use in our SDK between C functions and Objective-C selectors as the link you sent noted. I was able to get everything working the Object-C way and even works to call the original (by calling the renamed selector). Even though the article considers this "the wrong way". It has been battle tested in a large number of apps working this way without interfering with developer's AppDelegate selectors in native apps as well as other SDKs like Unity and Cordova. I also feel the Object-C implementation is easier to read.
However it does sound like the Objective-C way could change how the original selector sees itself as selector name. Will need to test this to see if our implementation has the same issue.
Anyway I think we will just tell our developers to use "--registrar:static" for now. Changing all our swizzling to use C functions is going to be an under taking in handling and testing all edge cases we have already solved and tested over the years.
You can mark this tick as resolved on your end.