App crash on launch #9282
Comments
|
Could be related with Clip and fixed by xamarin/Xamarin.Forms#11280? |
|
As mentioned in the bugreport of VS for Mac: In my case it seems like the App Bundle shrinks by 13.3MB alone from the Xamarin.Forms 4.6 to 4.7 upgrade. So I guess something did get removed. This is btw. a Mapsui.Forms project so SkiaSharp is also involved. |
|
@Sebastian1989101 if you create a blank forms app and use |
|
@PureWeen I would have to setup it so deep that I can push a TestFlight version. Would take some time to setup such a project. Is there a way to compare a working app bundle archive to a broken one? So I would know where the changes are. As said, 13.3MB smaller - I'm pretty sure something is getting linked out. |
|
So when you build it as release in vs it works fine but it fails when it's released from TestFlight? |
|
@PureWeen Seems like this is only happen on a TestFlight build. At least I'm currently not able to reproduce it when running a release build in the simulator. Which does not mean that this is something we can work with. |
|
If you deploy to a physical device locally does it crash? |
|
@PureWeen Seems like running on a device with release build does also fail while a debug build runs fine. |
|
If you enable full linking with the simulator does it crash? if you add something likee this to app delegate does it fix the crash? |
|
@PureWeen setting it to Link All results in crashing. But my release builds are also only set to Link SDK so I tried this and it works in Debug on the Simulator. However, the build version for the AppStore and TestFlight is still smaller than expected with Forms 4.7 compared to 4.6 after the last VS for Mac update (before this update, 4.7 was also fine). I don't think that this is a problem of Mapsui or SkiaSharp just because it happens in this project. And yes, 4.7 seems to work in other projects and I have no idea why. It looks like something gets linked out on the Link SDK setting but I have no idea why and what. This are the configs for our latest TestFlight beta releases of this app: I don't know which version of Visual Studio for Mac I had installed in May but this is the current installation: |
|
Uploading a version without linking works btw. but the result is more than 100mb larger than usual. |
When you set it to link all, debug, and push to device does it work? |
|
@PureWeen no because link all did never worked for me. Thats why I only used Link SDK instead. Link all is also crashing in the simulator already only way to run it is Link SDK or None for the Simulator and only None for real devices with the current version. |
|
if you do link all in debug mode does it reveal a more useful exception |
|
I have no idea why you want a Link all result because as I already told you, this will fail for sure. But here is the log from Link all: |
|
And yes, |
The problem is that the constructor itself is being linked off the type because those types are instantiated via reflection. So you have to do one of these things
i.e. |
|
@PureWeen This makes sense if I want to switch to Link all sometimes but why does the Release build with the old settings (Link SDK) no longer work? I update this app since 2017 on a regular base and never had such issues and as said only change was Xamarin.Forms 4.6 to 4.7 and the VS for Mac update. |
|
I can't really do that much with the exception on the original post so I'm just trying to navigate towards a useful exception if at all possible. Without a repro and only You could try doing a beyondcompare of the app folders to see what exactly is different. As you said one is a lot smaller than the other. It sounds like there's a specific dll that isn't getting included for you in 4.7 for whatever reason |
|
My guess is, because only mit Mapsui / SkiaSharp projects are affected by this, that either Mapsui.Forms or SkiaSharp.Views.Forms are using something through Reflection (because both are based on older Xamarin.Forms releases) which is getting linked out. I will try to put a list together of used functions and include them in the linker file to prevent them from getting linked out. But this will take a few hours/days because I just work in my spare time on these projects. |
|
image not found sounds like something different than linking that just sounds like an entire dll is removed which is different than linking You can also trying linkskipping If it doesn't than it's not the linker doing anything to those libraries |
|
@PureWeen I did a bunch of testing for this issue today. As I found out this has nothing todo with the linking at all. Because there is another difference between this project and my usual projects. This projects includes a today widget and a apple watch extension. As soon as I remove the TodayExtension the app runs fine (which also matches pretty well with the missing size of the archive). Is there currently some kind of bug? I know that Xamarin support for the extensions is not very good at all but something like this might break some apps. |
|
@Sebastian1989101 is this relevant to your scenario? |
|
@PureWeen if I understand the linked topic correctly, this reflects to native written extensions? In this case, no. My TodayExtension was created with C# in VisualStudio it just stopped working with Forms 4.7 and the VS4Mac update. |
|
Given that you've isolated this down to
Can you attach a repro that demonstrates the behavior? |
|
@rolfbjarne mentioned that this looks like a Xamarin.iOS bug so I'm moving here for now But, not sure if they'll be able to pin it down without a reproduction |
Yes, we'll need a test project to reproduce this in order to fix it. |
rolfbjarne
added
iOS
|
This project does not 100% recreate the base issue but it shows already that the widget is not submitted to the device in a release build to a device. I'm not sure why it does not crash in this case like my real app does but it already shows that it is getting removed. Btw. this is with a fresh new project so I don't know why you need a test project if this can be recreated with the a new fresh project... |
I don't quite understand the behavior you're seeing. Do you mean that the today extension doesn't show up in the list of today extensions on the device?
We ask for a test project that can be used to reproduce the reported issue, because it's very common that there's something else going on (according to yourself it's not possible to reproduce the reported crash using a new fresh project), and then there's a lot of wasted time on both sides going back and forth trying to re-create the exact conditions that trigger the problem.
I just tried this project, and both the extension and the app showed up when executed in release mode. Then I upgraded the projects to Xamarin.Forms v4.7.0.1260, but both the app and the extension continued to work fine. |
|
@rolfbjarne I tested it with this project on 3 devices - all the same. The today extension is not included in a release build on a device (it works on the simulator for some reason). I also asked in my team others to test it and so far it is the same for all 5 who tested with it yet. The today extension is always just not commited to the device (3D-Touch / Force Touch just makes the background blur and wiggle once and the today extension is not accessable on the widget page). I still don't know why this app does not crash as our real app does but it seems like the today extension is just removed there as well. All who tested it from my team are using the latest stable release of Visual Studio for Mac as of today. |
|
@Sebastian1989101 one thing you can do to narrow it down is to compare the build options between Debug and Release (the Build/iOS* project option pages), and try to figure out which option causes the project to fail (either by making the Debug configuration look like the Release configuration one option at a time, or the other way around). |
|
What's going on with this? I have had the same problem after upgrading to Xamarin 4.8. After upgrading, suddenly I began receiving the iOS depreciated UIWebView warning from App Store Connect. After finding zero help on this I opted to change a few compilation options until I was able to create a warning-less build...and then this happens when I switch to "Link All" instead of "Link Framework SDKs Only". I got Xamm'ed twice in one day. A new record. In all seriousness, I have never seen so many problems with a technology. Russian Roulette would render better results. |
|
These additional mtouch arguments ridded the App Store Connect depreciated UIWebView warning... --optimize=experimental-xforms-product-type --optimize=+force-rejected-types-removal |
|
Sadly, I just discovered this causes an app crash when my UIWebView screen is accessed. |
|
@donaldashworth I'm sorry you're having such a hard time with out product. From what I understand you were able to find a solution to the UIWebView warning, but your app is still crashing? If that's the case, please open a new issue and describe your the problem there, since it might be something different that what's reported here, and having two separate problems in a single issue will lead to a lot of unnecessary confusion. |
|
@donaldashworth This issue is related to the today extension in iOS. The app crashes right away when a today extension is included. If you still use a UIWebView you should switch to a WkWebView because UIWebView is obsolete. |
|
We are Xamarin.Forms.WebView … nothing exotic going on. When using Xarmin 3.3.1 we encountered this App Store Connect warning. We develop on a Windows 10 PC Professional connecting to a MacBook Pro and were advised to use mtouch arguments “--optimize=experimental-xforms-product-type" in our Xamarin iOS project.
This muted the App Store Connect warning message until recently upgrading to Xamarin 4.8.0 in which the message returned, this time with a drop dead date of December 2020.
Nothing in our code has changed on the two screens we have that use Xamarin.Forms.WebView.
We are not using “UIWebView” by choice. Its usage is embedded in Xamarin.Forms.WebView. WebView is the only wed view available in Xamrin.Forms…no WkWebView. The class, itself, is not marked depreciated or obsolete (see below).
With all of this said, Xamarin 4.8 broke a few things for us, this warning is one of them.
namespace Xamarin.Forms
{
//
// Summary:
// A Xamarin.Forms.View that presents HTML content.
//
// Remarks:
// The following example shows a basic use.
[RenderWith(typeof(_WebViewRenderer))]
public class WebView : View, IWebViewController, IViewController, IVisualElementController, IElementController, IElementConfiguration<WebView>
From: Sebastian Kruse <notifications@github.com>
Sent: Thursday, September 24, 2020 02:04
To: xamarin/xamarin-macios <xamarin-macios@noreply.github.com>
Cc: Donald Ashworth <donald.ashworth@mmcinc.com>; Mention <mention@noreply.github.com>
Subject: Re: [xamarin/xamarin-macios] App crash on launch (#9282)
@donaldashworth<https://github.com/donaldashworth> This issue is related to the today extension in iOS. The app crashes right away when a today extension is included. If you still use a UIWebView you should switch to a WkWebView because UIWebView is obsolete.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#9282 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/APMOEMSFENVBLOF62O7PP23SHLVPTANCNFSM4PV5ADLA>.
|
|
We have not received the requested information. If you are still experiencing this issue please provide all the requested information then click the Reopen Issue button. Thanks! |
This issue has been moved from a ticket on Developer Community.
With the latest Xamarin.Forms 4.7 in combination with the latest VS for Mac Stable version, my app always crashes at launch (no other change involved, it works with Forms 4.6 without any problem and did work with 4.7 as well before the latest update). This crash only happens on Release Build while Debug runs fine.
The only message I get when trying to run this app in release is the following:
dyld: Library not loaded: @rpath/Mono.framework/Mono
Referenced from: /Users/sebastian/Library/Developer/CoreSimulator/Devices/F9AECBD1-5630-4236-99BF-DD72415098E2/data/Containers/Bundle/Application/BBC8B3D3-6D9C-4968-A5C3-CD0766F3AF8C/MyApp.iOS.app/BreathCompanion.iOS
Reason: image not found
Original Comments
Visual Studio Feedback System on 7/5/2020, 11:03 PM:
We have directed your feedback to the appropriate engineering team for further evaluation. The team will review the feedback and notify you about the next steps.
Original Solutions
(no solutions)
The text was updated successfully, but these errors were encountered: