Post

Replies

Boosts

Views

Activity

Reply to Crash: [NSTaggedPointerString count]: unrecognized selector sent to instance 0x8000000000000000
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!
Jun ’21
Reply to How to detect if an iPad has GPS
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.
Topic: App & System Services SubTopic: Hardware Tags:
May ’21
Reply to Background location updates stop in iOS 16.4
Hi. Do you have a source for this? By the way, enabling the showsBackgroundLocationIndicator flag has worked for me too.
Replies
Boosts
Views
Activity
Apr ’23
Reply to Background BLE beacon region monitoring not working in iOS 15 which was previously working on iOS 14
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.
Topic: App & System Services SubTopic: Core OS Tags:
Replies
Boosts
Views
Activity
Oct ’21
Reply to Xcode 13 Building Woes
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.
Replies
Boosts
Views
Activity
Aug ’21
Reply to Crash: [NSTaggedPointerString count]: unrecognized selector sent to instance 0x8000000000000000
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!
Replies
Boosts
Views
Activity
Jun ’21
Reply to How to detect if an iPad has GPS
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.
Topic: App & System Services SubTopic: Hardware Tags:
Replies
Boosts
Views
Activity
May ’21