• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Thoughts on Cocoa source code
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Thoughts on Cocoa source code


  • Subject: Re: Thoughts on Cocoa source code
  • From: Stephane Sudre via Cocoa-dev <email@hidden>
  • Date: Thu, 10 Oct 2019 21:36:02 +0200

On Wed, Oct 9, 2019 at 7:19 PM Turtle Creek Software via Cocoa-dev
<email@hidden> wrote:
>
> Why is Cocoa source code hidden?
>
> Many of the frustrations we had with the 64-bit update attempt were caused
> by Cocoa's lack of visible source. It was a "black box" that often required
> trial-and-error to figure out. Yeah, the headers are visible, and Apple has
> info online. But sometimes that was not sufficient to understand the actual
> implementation details.

Cocoa source code is not really hidden if you use the proper tools and
know how to use them and that you should not rely 100% on them.

With Hopper Disassembler, you can see any Obj-C framework source code
in /System/Library/(Private)Frameworks.

Although most of the time you don't need to see the source code, there
are some areas that are poorly covered by the developer documentation
and being able to see the implementation details is very useful. For
instance, if you ever had to write a custom subclass of NSCell or a
subclass of NSControl with multiple cells, the official documentation
was almost totally useless and this was a good opportunity to find out
about the private API Apple was keeping to itself to make the AppKit
controls work.

It's true that having access to the source code can also help finding
issues and suggesting patches. But it's also true that if Apple had
been doing a proper job at checking the warnings and static analysis
outputs of its own IDE, numerous issues could have been fixed without
having needed to be reported by 3rd party developers.

If you combine otool, classdump and Hopper Disassembler, you can find
how some Cocoa methods are working in any Obj-C executable pretty
easily.

https://www.hopperapp.com

http://stevenygard.com/projects/class-dump/

Checking cocotron can also be helpful if you want to see how someone
else implemented most Foundation and AppKit legacy APIs.
_______________________________________________

Cocoa-dev mailing list (email@hidden)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

  • Follow-Ups:
    • Re: Thoughts on Cocoa source code
      • From: Turtle Creek Software via Cocoa-dev <email@hidden>
References: 
 >Thoughts on Cocoa source code (From: Turtle Creek Software via Cocoa-dev <email@hidden>)

  • Prev by Date: Re: Thoughts on Cocoa source code
  • Next by Date: Re: Thoughts on Cocoa
  • Previous by thread: Re: Thoughts on Cocoa source code
  • Next by thread: Re: Thoughts on Cocoa source code
  • Index(es):
    • Date
    • Thread