User Profile

We have some crash which we cannot reproduce in our builds. I can see the one of this crashes in TestFlight and want to research it. I click "open in Xcode" in TestFlight. The crash is supposed to be opened in Xcode's organizer. But the crash opened by Xcode has another build number. I know I can list crashes by the small control on the bottom of the organizer. There is no one crash with the same build number that noted in TestFlight. So it's look like crash never downloaded to the Xcode. It looks like for some reason Xcode does not see crashes listed in TestFlight. I've also check all crashes Xcode knows about. It looks like Xcode does not see the big part of crashes listed in TestFlight. What could it be?

I have a VoIP-call app, and when the user answers call, sends app to the background and then taps "Touch to return to call" green bar on the top – I want to take additional steps after he returns to the app (show him the in-app call screen instead of the screen presented before the user sends app to the background). Is there any way to detect/handle these events? Like app delegate's application(continue userActivity:)? I can't use applicationWillEnterForeground because this event occurred not only when the user taps "Touch to return to call" but even if he just taps the app's icon or returns to the app using the application manager.

Hi!Being an iOS developer I always wonder why text input controls on Mac have the ability to set text formatters while iOS controls have not.The basic idea of text formatter is to handle a request for text change and apply it in very own way (like insert other text instead of proposing or deny it at all).We also have an UITextInput protocol who has the method looks right.I thought that the right way to format user input is to write an UITextField subclass and override UITextInput required method:public override func replace(_ range: UITextRange, withText text: String)But this method got never called.I know two workarounds: 1. Set delegate and handle `shouldChangeText(_:replacementText)` and subscribing to control's `valueChanged`.Both cases are conceptionally incorrect in my opinion and here is why:1. Delegate method should only return `true` or `false`. Changing text right in this methods looks like a horrible side-effect.Just imagine that we really only want to know whether a text changing os possible. Changing the text is not appropriate at the moment of checking.2. Handling 'textDidChange' notification is better, but conceptionally it's like an attempt to quickly heal a wound instead of preventing it. Also, we have no information what part of the text changed, only speculate about. Did user paste the text? Did he change just the word in the middle or paste the whole text which was identical to previous text except the word in the middle?So my questions are:1. Is there any way to handle and transform user input before it goes to control?2. Do you have an idea why overriding `replace(_ range: UITextRange, withText text: String)` does not work?

Hello!Recently I discovered, that one of our users with one device has two registered apns tokens, and both treated as valid by APNS server.I sent two notifications using a local tool. Both notifications were successfully pushed without any "Invalid Token" response from APNS server.Both notifications are delivered to the device and only one of them is shown (that's good). For another one I can see following logs in Console:default 12:16:09.461559 +0300 apsd 2017-09-08 12:16:09 +0300 apsd[84]: isAppSpecificTokenValid? <_token_> found cached token NO default 12:16:09.462125 +0300 apsd 2017-09-08 12:16:09 +0300 apsd[84]: Received incoming push notification for topic: <_app_id_> but for a completely unknown token <_token_> default 12:16:09.462632 +0300 apsd 2017-09-08 12:16:09 +0300 apsd[84]: <APSCourier: 0x1002025e0>: Responding with REMOVED status for message received with topic: 'app_id' to device token (instead of per-app token)Is it ok that this token still alive (more than one day) and Apple service does not respond with "Bad token" response?Because we sent more notifications than needed and neither server nor client can't find out that this token is obsolete.