I am having the same issue while running pod lint against a framework compiled with Xcode 12 beta 4 and 6, error is:     The following build commands failed:     Ld /Users/<username>/Library/Developer/Xcode/DerivedData/App-fvgguosjareejfejmqgeiwccnzmo/Build/Intermediates.noindex/App.build/Release-iphonesimulator/App.build/Objects-normal/arm64/Binary/App normal arm64     (1 failure)    Testing with xcodebuild This was not happening with Xcode 11.x versions. Did you find any workaround for this?

I am experiencing the same error when trying to build a framework for the simulator SDK on Xcode 12. This seems that it is an issue related to the linker or xcodebuild command itself, this was not an issue for me on Xcode 11. In my case, adding the arm64 architecture to the excluded architecture build setting worked so that we were able to send a provisional framework for our client only supporting simulator on Xcode 12. This seems that the error is being found on Crashlytics in your case. Adding arm64 to the excluded architectures should help with this issue, sadly this does not seem to be the case. I also reported this as a bug using the Feedback assistant. I'm hoping this helps for its resolution.

Did anyone find another solution for this? The solution described in https://developer.apple.com/forums/thread/657913 let me compile for simulator, but not for real devices.

enum ScreenSection : Int { case firstSection case secondSection case thirdSection } extension TableDelegate: UITableViewDataSource {    func numberOfSections(in tableView: UITableView) -> Int {      return 3    } @available(iOS 11.0, *)   func tableView(_ tableView: UITableView, trailingSwipeActionsConfigurationForRowAt indexPath: IndexPath) -> UISwipeActionsConfiguration? {            let section = ScreenSection(rawValue: indexPath.section) <- Here it is crashing     guard let screenSection = section else {      return nil      } More code... Thank you for the responses! Claude31, I just attached some code that shows the numberOfSections and the line where the app is crashing. eskimo, thank you for that explanation. I went ahead with trying your example on a playground and indeed, I get a EXC-BAD-INSTRUCTION error for the first and third case. But I don't understand why a trap fires if the indexPath has a count other than 2. I'm also curious if this is somehow related to saying that the table view should have 3 sections? Do you know if there is something wrong about the code itself? Because I'm receiving that indexPath from the trailingSwipeActionsConfigurationForRowAt function as you can see. Or this is a bug in the language? or how could I fix this? Checking the indexPath.count and saying that this needs to be 2 in order to access the IndexPath.section property? Thank you in advance

I see. I took this from our crash reporting service. I am attaching a crash log from the user device (this is the same user that was experiencing the crash). I'm guessing this is a full crash log since this includes the termination signal and reason, etc. Is this correct? Unfortunately, I haven't had the chance to symbolicate this myself. This is needed or are we more interested in the exception/termination data? Unsymbolicated crash log - https://developer.apple.com/forums/content/attachment/398569ca-e3c8-4c85-ab60-f9e185cfd51d Thanks a lot!!

so the count is 0. So, we’ll still not sure how you got here, but at least we know why you crashed. So since the count is 0, this confirms that the app is hitting a IndexPath.section assert. This is still weird for me why this is happening, but for the users' sake I will put some defensive code checking that the count property is equal to 2 before accessing to the indexPath.section property. Hopefully, this will prevent this crash. In the case that for some reason this does not work, I will need to go back to this. Thank you for confirming this and for helping me out!

Thanks eskimo. While the Core Telephony Framework provides APIs to access the carrier data, cellular data state, and so on, this does not seem to provide an API to return if the device is cellular capable or not. While it might be true today, it’s easy to imagine Apple adding GPS to a device that doesn’t have cellular. Right, a new device like this would break this implementation. But until then, we would have a hacky way to detect this, which does not seem bad. I also think it's a good moment to think if this is really needed.

Yes, properties() is called on the main thread. Also data is being accessed from the main thread, and from a background thread that corresponds to the first async work. func properties() { let group = DispatchGroup() group.enter() UNUserNotificationCenter.current().getNotificationSettings { (notification) in let value = … some calculation … self.data.updateValue(value, forKey: "my_wonderful_key") group.leave() } group.enter() MyClass.someMethod { (granted) in let value2 = … some calculation … self.data.updateValue(value2, forKey: "my_wonderful_key_2") group.leave() } group.notify(queue: DispatchQueue.main) { print("Yay. Operation completed!") completionHandler(self.data) } } As you can see, in the first block, data is being accessed in the getNotificationSettings completionHandler which is executed on a background thread. On the other hand, in the other two (2) blocks data is being accessed on the main thread, since those two blocks MyClass.someMethod and group.notify run in the main queue. One more thing is that I have crash reports for all these 3 lines: self.data.updateValue(value, forKey: "my_wonderful_key") self.data.updateValue(value2, forKey: "my_wonderful_key_2") completionHandler(self.data) So I wonder if the fact that data is accessed from a background thread in the first block is causing that the app is crashing then when the same data is accessed from the main thread in the block 2 and 3? if that would be the cause, just wrapping the code with an async block in the main queue would work? That way the data is only accessed from the main thread group.enter() UNUserNotificationCenter.current().getNotificationSettings { (notification) in let value = … some calculation … DispatchQueue.main.async { self.data.updateValue(value, forKey: "my_wonderful_key") group.leave() } Thanks!

I am seeing this same behavior on Xcode 13 beta 5. This takes a huge amount of time to build the project regardless of this was already built or not.

We are still seeing this issue on iOS 15.1 on the app that we work on as you say this had been working fine on iOS 14 and below. I reported this bug using the feedback assistant and I encourage you to do the same. Hopefully, this is sorted out soon.

Hi. Do you have a source for this? By the way, enabling the showsBackgroundLocationIndicator flag has worked for me too.