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
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. ).
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
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.
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.
- when and why are the STDOUT/IN/ERR buffered: https://eklitzke.org/stdout-buffering
** 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!