Additionally, it seems like supportsSecureCoding isn't called either on macOS 12 but it on macOS 11.
Post
Replies
Boosts
Views
Activity
Here's my radar for the issue: FB9188075
I managed to reproduce the crash in a sample project, attached to the radar.
I ran some tests and oddly enough in my case the issue is only occurring on my iPad, not my iPhone. Anyone else?
I have the same problem. Works fine on macOS but crashes on iOS. Have you filed a radar?
For those who'd like to dupe this and for Apple folks: FB9137313
Also, I've noticed that the callback returns a different internal port than the initial one. Somehow internalPort is always set to 3095 in my case.
I guess it's radar time.
Never mind:
config.trailingSwipeActionsConfigurationProvider = { indexPath in
...
}
How did you manage to use it? Can't figure it out!
Since this was mentioned during WWDC and demoed on iOS 14 (https://developer.apple.com/wwdc20/10026 at 11:40), I can only assume that it's an issue with Beta 2 and that it'll be back in the next beta.
Any updates of Metal working with SwiftUI this year?
So I had 2 users that contacted me in the past couple of days that told me that the app is crashing again (Termination Reason: Namespace CODESIGNING, Code 0x1). I've checked that both the certificate and profile did not expire and they are fine.Please see FB7678285 and case ID 734264013
Thanks to @jordanpittman for suggesting a fix:ItemsView(items: $store.data[selectedFolderIndex!].items).id(selectedRowIndex)Source: https://swiftui-lab.com/swiftui-id
I'll file a DTS when I have some time. As you may guess, it's been a support nightmare having to tell users to download the updated binary and it'll be like that for weeks.This bug also breaks apps I no longer maintain but that are still used by some. I managed to re-sign the binary but you can imagine how bad this.At least the updated binary will give me some time until 2038 (hopefully).Certificate:Validity
Not Before: Apr 1 21:30:25 2020 GMT
Not After : Apr 2 21:30:25 2025 GMTProvisioning profile:<key>ExpirationDate</key>
<date>2038-03-28T21:44:40Z</date>I'll update this post once I have a bug number.
My reply is being moderated for some reason. Also, this issue isn't exclusive to macOS 10.15.4. I had a user on El Capitan reporting the issue.
Hi Quinn,Presumably this is a Developer ID app, not a Mac App Store app, and thus by “distribution certificate” you mean your Developer ID Application certificate?Yes, this is a Developer ID app and a Developer ID App Cert was used to generate the provisioning provile. Sorry about the confusion.Does your app have a provisioning profile?Yes it does.Have you actually checked the expiry dates involved? If you do the following, what do you see?Here's the result:Validity
Not Before: Apr 1 20:33:20 2015 GMT
Not After : Apr 1 20:33:20 2020 GMT<key>ExpirationDate</key>
<date>2020-04-01T20:33:20Z</date>Finally, I want to be clear about one thing: While Developer ID certificates and provisioning profiles have an expiry date, the system is meant to ignore them. There have been circumstances where that’s not happened, but such problems are bugs. A Developer ID-sign product should not expire.Well this sounds like a bug to me as now apps signed with this certificate and provisioning profile are refusing to launch and just crash!