fixed in 15.4 RC 👍

Not fixed in beta 4 🙁

Fixed in 15.3. Thanks for no upvotes!

Here are the missing files: [https://www.icloud.com/iclouddrive/027-JUISnmGAy_Zj0Lu5H3NEA#xcode-objc)

Took me one month to figure out that the reason for this regression is the simple lack of the two template files. So in order to make this work, you need to find an older copy of Xcode and copy over the files CategoryNSObject and ExtensionNSObject found at Xcode.app/Contents/Developer/Library/Xcode/Templates/File Templates/MultiPlatform/Source/Objective-C File.xctemplate and voilà everything is working again!

Did you find a solution?

My request was granted today, it took 13 months. The e-mail only contained one link.

I was able to reproduce the problem in the debugger: Thread 68: "Cannot remove an observer <NSDictionaryController 0x7fc4f530e290> for the key path \"value\" from <_NSDictionaryControllerKeyValuePair 0x60000093e2b0> because it is not registered as an observer." The problems were a) I use NSString as the value, but check for an NSNumber, hence it should be NSString *dictIdent = self.loggedConfigs[identString]; but that didn't cause the actual crash b) The method was called from multiple dispatch queues at the same time, causing a mutating while enumerating crash.

I came across this post while searching for if_data64 for a Mac app I'm currently writing. On the Mac, this works and is well documented in the man page for ifmib, which even contains a code example. On iOS it is exactly as eskimo said though, you need to import headers from the macOS SDK to make the code compile, but at runtime it will fail with an EPERM error (Operation not permitted).

Correct, it doesn't solve the delay between 1 and 4. It does solve the problem of keeping a map of sequence numbers and send times though.

On the send side there’s not a lot you can do; there’s no equivalent of  SO_TIMESTAMP on the send side. /sbin/ping solves the problem by calling gettimeofday() and putting the result into the data field of the outgoing packet, because as of RFC 792 the Echo Reply packet has to contain the data field from the Echo Request.

I have solved the problem by buying a 2nd Mac, thanks Apple...!

&gt; The modern way to do this is the volumeTotalCapacityKey URL property.Just for completeness, the resulting values appear to be the same on 3 different devices I tested.&gt; I need to stress that this is a marketing value rather than a technical value.My app is a disk benchmark, DiskBench. On SSDs, the performance strongly correlates with the capacity, so in this special case it is not purely marketing.&gt; There is no good way to get this marketing value.Which means it is private API?&gt; I recommend that you file an enhancement requestThanks, but I need to be as far backward compatible as possible.