{"id":41081,"date":"2023-11-15T16:01:52","date_gmt":"2023-11-15T21:01:52","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=41081"},"modified":"2023-11-15T21:39:24","modified_gmt":"2023-11-16T02:39:24","slug":"xcode-15-logs-nil-as-an-empty-string","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2023\/11\/15\/xcode-15-logs-nil-as-an-empty-string\/","title":{"rendered":"Xcode 15 Logs nil As an Empty String"},"content":{"rendered":"

Jeff Johnson<\/a>:<\/p>\n

[The] functions os_log<\/code> and NSLog<\/code> now log nil<\/code> as an empty string. The previous behavior, going back forever as far as I remember, was to log nil<\/code> as (null)<\/code>.<\/p>

[…]<\/p>

I don’t know whether this is a bug or intended behavior, but it makes debugging our apps markedly worse, because now there’s no easy way to identify nil<\/code> objects or to distinguish between nil<\/code> and @\"\"<\/code> in the log output.<\/p><\/blockquote>\n

This only affects logging within Xcode itself. Still not good, though.<\/p>\n\n

Jeff Johnson<\/a>:<\/p>\n

I’ve now found three different bugs in the new Xcode 15 console.<\/p>

[…]<\/p>

Fortunately, I’ve found a way to restore the previous console behavior from Xcode 14 and earlier. This is actually noted in the Xcode 15 release notes<\/a>, but I wanted to highlight the solution here in case, like me, you hadn’t read the release notes recently[…]<\/p>

[…]<\/p>

You need to set the environment variable IDELogRedirectionPolicy<\/code> to the value oslogToStdio<\/code> in the Run section of your app’s Xcode scheme. I wish there were a way to make this behavior the default in Xcode Settings!<\/p><\/blockquote>\n\n

Jeff Johnson<\/a>:<\/p>\n

Since then I’ve had some back and forth with Apple on that bug in Feedback Assistant. I’m going to screenshot the entire exchange below. For context, if you’re not familiar with Apple’s bug reporting system, they constantly ask developers to “Please verify this issue” with the latest betas, despite having done nothing to fix the issue in the latest betas, in the hope that the issue (or maybe the developer) will magically go away.<\/p>

[…]<\/p>

The ultimate outcome of this case was that Apple blatantly lied to me—“As you’ve indicated, this issue is resolved”—and then Apple refused to hear any contradiction to their lie—”this Feedback will no longer be monitored, and incoming messages will not be reviewed.” This kind of response reinforces what I said earlier in the exchange: “It makes me not want to file feedbacks at all. It feels like you don’t care.” The coup de grâce was “We appreciate your feedback.” No, Apple absolutely does not appreciate our feedback.<\/p><\/blockquote>\n\n

In this case, Apple considers it resolved because the problem doesn’t occur on Sonoma. But Xcode 15 is supposed to work on Ventura, and it should<\/em> be fully functional there considering that Apple doesn’t support Xcode 14 on Sonoma.<\/p>\n\n

Previously:<\/p>\n