4 ms·

I cannot have read that correct. For people on the Apple Dev ecosystem, do you really have no access to SDK code as a reference? Not even some high level abst

by araes 3y ago

I cannot have read that correct. For people on the Apple Dev ecosystem, do you really have no access to SDK code as a reference? Not even some high level abstraction version? I got to that assembly code part and just sat there and re-read it again and again. "You've got to go straight to assembly mode?" I cannot have read that correct.

tl 3y ago
You might want to clarify your question: > do you really have no access to SDK code as a reference? You get headers but no source. While Darwin is in theory open source, UIKit, et. al. are not. > I got to that assembly code part and just sat there and re-read it again and again. If you're referring to the screenshot, Xcode dumps you into disassembly in cases where the stack is not in your code. 0 -[MoTextView endFloatingCursor] is the author's code. The remainder is UIKit. Also, most of the line items are _prefixed which indicates a private method upon whose existence (much less implementation) is not reliable. As the author mentions, the stack on the left is usually enough to diagnose problems. It's also one more thing that makes me fight using Swift; all of the name-mangling and opaque to the Objective C runtime additions make this problem even harder.
jasonjmcghee 3y ago
I recently have been building in Swift and indeed this seems to be the case. It's endlessly frustrating. Also privatizing variables seems to be quite aggressive in standard libraries and I often find myself wanting to use that internal stuff.
- meindnoch 3y ago
  >I often find myself wanting to use that internal stuff And then curse Apple when the internals change and your app breaks?
  - jasonjmcghee 3y ago
    I would never
    - papereditor 3y ago
      It's a calculated risk. You can make unique experiences with private stuff. Apple ships betas, so there is plenty of time to see if stuff breaks with the latest OS.

by araes 3y ago

tl 3y ago

You might want to clarify your question: > do you really have no access to SDK code as a reference? You get headers but no source. While Darwin is in theory open source, UIKit, et. al. are not. > I got to that assembly code part and just sat there and re-read it again and again. If you're referring to the screenshot, Xcode dumps you into disassembly in cases where the stack is not in your code. 0 -[MoTextView endFloatingCursor] is the author's code. The remainder is UIKit. Also, most of the line items are _prefixed which indicates a private method upon whose existence (much less implementation) is not reliable. As the author mentions, the stack on the left is usually enough to diagnose problems. It's also one more thing that makes me fight using Swift; all of the name-mangling and opaque to the Objective C runtime additions make this problem even harder.

jasonjmcghee 3y ago

I recently have been building in Swift and indeed this seems to be the case. It's endlessly frustrating. Also privatizing variables seems to be quite aggressive in standard libraries and I often find myself wanting to use that internal stuff.

meindnoch 3y ago
>I often find myself wanting to use that internal stuff And then curse Apple when the internals change and your app breaks?
- jasonjmcghee 3y ago
  I would never
  - papereditor 3y ago
    It's a calculated risk. You can make unique experiences with private stuff. Apple ships betas, so there is plenty of time to see if stuff breaks with the latest OS.