Post marked as Apple Recommended
Hi. Do you have a source for this?
By the way, enabling the showsBackgroundLocationIndicator flag has worked for me too.
Post not yet marked as solved
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.
Post not yet marked as solved
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!
Post not yet marked as solved
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.
Post not yet marked as solved
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!
Post not yet marked as solved
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!!
Post not yet marked as solved
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
Post not yet marked as solved
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.
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.
Post not yet marked as solved
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?
Post not yet marked as solved
There are some Location Services API that allows an application to be launched in the background as a result of a location event, as part of iOS 13 your application will need to use one of these APIs and has the "Always" authorization by the user.Location Services APIs that allows an app to be launched in the background:https://developer.apple.com/documentation/corelocation/getting_the_user_s_location/using_the_significant-change_location_servicehttps://developer.apple.com/documentation/corelocation/cllocationmanager/1423531-startmonitoringsignificantlocatihttps://developer.apple.com/documentation/corelocation/getting_the_user_s_location/using_the_significant-change_location_servicehttps://developer.apple.com/documentation/corelocation/getting_the_user_s_location/using_the_visits_location_servicehttps://developer.apple.com/documentation/corelocation/monitoring_the_user_s_proximity_to_geographic_regionsYou can take a look and see which one fits better for your use case.
Post not yet marked as solved
I encourage you to test this out yourself using a real device. I believe that what should happen is that the location permission should be the same that was before the phone were upgraded to iOS 13, but if you test this yourself you will have more confidence about it.
Post not yet marked as solved
Hi guys, I have also noticed in our case that the application does not receive location updates in the background when this has the "Provisional Always" location access. We have noticed in simulator tests that once the "Always" prompt is shown by the system in the background, the application starts receiving location updates in the background as expected regardless of if the user chose "Keep Only While Using" or "Change to Always Allow".The application has enabled the location updates background mode and set the allowBackgroundLocationUpdates property to true.This is happening on iOS 13 public beta 4 (17A5547d). This is not an issue on iOS 12.Is anyone seeing the same behavior?
