What is TIC Read Status 1:57 in iOS11/Xcode 9?
XcodeIos SimulatorIos11Xcode9Xcode Problem Overview
After updating to Xcode 9, using Swift 3 and the iPhone X simulator, my console is full of:
TIC Read Status [11:0x0]: 1:57
TIC Read Status [11:0x0]: 1:57
TIC Read Status [11:0x0]: 1:57
...
What is that and how do I fix it? Help is very appreciated.
PS: I prefer not to just "silence" it with an Environment Variable
in the build scheme.
Xcode Solutions
Solution 1 - Xcode
Apple staff gave the following answer:
TIC
expands to “TCP I/O connection”, which is a subsystem within CFNetwork that runs a TCP connection
1
and 57
are the CFStreamError domain and code, respectively; a domain of 1 is kCFStreamErrorDomainPOSIX and, within that domain, 57
is ENOTCONN
In short, a TCP read has failed with ENOTCONN.
As the TCP I/O connection subsystem has no public API, you must necessarily be using it via some high-level wrapper (like NSURLSession).
source: https://forums.developer.apple.com/thread/66058
EDIT/UPDATE:
Since we are all still having these annoying logs, I asked to the same Apple specialist from the above link about our situation, which is now specific for Xcode 9 and Swift 4. Here it is:
A lot of people are complaining about these logs, which I am having as well in all my apps since I upgraded to Xcode 9 / iOS 11.
2017-10-24 15:26:49.120556-0300 MyApp[1092:314222] TIC Read Status [55:0x0]: 1:57
2017-10-24 15:26:49.120668-0300 MyApp[1092:314222] TIC Read Status [55:0x0]: 1:57
2017-10-24 15:26:49.626199-0300 MyApp[1092:314617] TIC Read Status [56:0x0]: 1:57
His answer:
> It’s important to realise that this ENOTCONN does not necessarily mean that anything has gone wrong. Closed TCP connections are expected in all versions of HTTP. So, unless there’s some other symptom associated with this error, my recommendation is that you ignore it.
source: https://forums.developer.apple.com/message/272678#272678
SOLUTION: Just wait for newer versions/updates of Xcode 9.
Solution 2 - Xcode
Here is how TIC Read Status [11:0x0]: 1:57
breaks down:
TIC
expands to “TCP I/O connection”, which is a subsystem within CFNetwork that runs a TCP connection
11
is a connection ID number within TIC
0x0
is a pointer to the TIC object itself
1
and 57
are the CFStreamError domain and code, respectively; a domain of 1 is kCFStreamErrorDomainPOSIX and, within that domain, 57 is ENOTCONN
Solution 3 - Xcode
Note: Like what @David mentioned in the comment, it's a way to hide the warnings, so use this launch argument to avoid getting many repetitive messages and have a clean console. Once done debugging, keep it disabled as console doesn't provide useful information when it's enabled. For example libc++abi.dylib: terminating with uncaught exception of type NSException
.
For people who are wondering how to silence the warning and until a better fix is available you may keep following variable handy and toggle as needed.
Use OS_ACTIVITY_MODE = disable
environment variable under Arguments in the product schemes to avoid console getting flooded with such warnings.
Note B: Enable it to see the effect.
Source: https://medium.com/@adinugroho/disable-os-logging-in-xcode-8-ec6d38502532
Solution 4 - Xcode
The best way I found, concerning this log message and some others ( like NSURLSession errors that are not necessarily errors ) is to have my own log functions.
class Logger {
static var project: String = "MyProject"
static func log(_ string: String, label: String = "") {
DispatchQueue.main.async {
print("[\(Logger.project)] \(label) : \(string)")
}
}
static func info(_ string: String) {
Logger.log(string)
}
static func warning(_ string: String) {
Logger.log(string, label: "WARNING")
}
static func error(_ string: String) {
Logger.log(string, label: "ERROR")
}
}
Then I simply type [MyProject] in the console pane bottom-right filter, and that's it.
Note that by calling print on the main queue, it allows your logger to be used from threads without mixing up your console.
Ready to be improved and tweaked for your needs :)
Solution 5 - Xcode
I was having this same issue where I was getting '}' in response to a REST(GET) service.
Using:
URLCache.shared.removeCachedResponse(for: request as URLRequest)
after making my URL request, and resetting my URLSession object after getting the response as:
session.reset(completionHandler: {
// print(\(data))
})
Solved my problem.
Solution 6 - Xcode
We manage to solved this logging problem by disabling HTTP/2 on the web server, in our case we have migrated from classic ELB to application ELB that added support to HTTP/2 on AWS and we started getting "TIC Read Status [11:0x0]: 1:57" on XCode 10.1 / iOS 12 console. This looks like a temporary solution until Apple fix the problem with HTTP/2 if any. This solution may not work for everybody, specially if you are using third party APIs, but it gives you some insights on the problem.
Solution 7 - Xcode
It's a logging indicating that a TCP connection is lost/closed/not_valid or whatever. This can happen if your app has a running tcp-connection and the app is put in background for some time, or you turned off the screen of your phone. The OS decides to stop as much resources as possible to reduce battery drainage. If you bring the app to foreground, the tcp-connections you had before, won't work anymore. You need to recreate a new tcp-connection.
If it doesn't bother you, just ignore it.