The Adventures with NSTask & co. (Part 3)

Even though I was not able to resolve the issue, still I figured that I’d rather release the source code for the XcodeUpdates, than keeping it to myself until the release.

And by doing that, I was able to share the info about the app with the community of #iOSDevHappyHour – with exactly 18 people! And what is best, almost all of them, if not all, followed the Twitter account!

Also, some people mentioned that the source code for a mac app written in SwiftUI would help them studying. Which is a big deal for me, because I care a lot about products I make.

As a consequence, sharing the source code attracted some people on Twitter and the beloved by the community @Steve Troughton-Smith re-shared my tweet about it. So that tweet on its own gathered more than 20000 views, which means that at least this amount of developers know about the existence of XcodeUpdates!

And the good news: I received the TSI response the next day after sharing the code.

Apple Developer’s Response

Apparently, I have discovered a gem:

Unfortunately, this is one of those cases where the underlying “issue” is actually part of very longstanding (30+ years) architectural choices FAR below the underlying API

Apple Engineer

I was very surprised and did not feel that I have hit a dead-end for this project, even though after such an introduction one might expect to feel disappointment.

Instead, this only motivated me, even though I did not read through the whole email yet.

As it seems, I have hit a case where STDOUT would do 100% buffering of any output because NSTask is not a TTY (TTY actually stands for TeleTYpewriter. ).

When xcodes calls exit(), it flushes all of the buffered input/output, this is why the problem appeared to be only when exit() was not called, i.e. when there was an ongoing operation executed.

Those details aren’t something our documentation has every covered, mainly because they’re actually defined by a combination of the C language standard, POSIX, and long standing conventions common to most operating systems (particularly Unix variants)

Apple Engineer

There are multiple ways to resolve this issue, and even though the response from the Apple Engineer did not include any kind of proposal, and was just an explanation of how things work, I understood how to resolve this and have chosen the easiest solution – added calls to fflush() function with both stderr and stdout as an argument. 

This has resolved the issue intermediately, however, I’d rather set my own “mode” to the stdout to always use no buffering (which is described in detail in the very good article that was shared with me).


I have set the goal to learn SwiftUI when I was starting XcodeUpdates. I did not know that it would become OSS, or if I would be able to distribute it in the Mac App Store or not.

But the outcome is far beyond any of my expectations. 

This is the second, conclusive product that I was able to build from 0 to 100% in 2020 (first one is VisualDataConverter that is available for download on the Mac App Store).

P.S. I also wrote a secret project in Summer, from 0 to 90%, but I had to stop. You know, private API is not a solution most of the time. I, for sure, will write a post about it later on.

P.S.S. I also have written design and documentation for another secret project that I will deliver in 2021. So stay tuned! I hope it’s going to be a hit.


** This is one of the most informative feedback I’ve received from an Apple Engineer for the last 10 years of solving issues w/ standard frameworks. Thank you, an Apple Engineer!


2 thoughts on “The Adventures with NSTask & co. (Part 3)

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s