Much of the debate I see around Auto Layout focusses on how it’s cumbersome to implement in code – as opposed to Interface Builder – but all of the 9 constraints would still need to be applied in Interface Builder to achieve this same layout and you’d still need to understand why each of these constraints is necessary.

[…]

The problem is that no matter how you apply them, constraints are not layouts; constraints are building blocks from which we can make layouts but an actual layout requires starting a different way.

[…]

A far better solution for programming a declarative system is to use an API that itself is declarative and builds the whole system as a single composeable expression and rather than constructing individual constraints separately, understands the whole system and can automatically include constraints needed for consistency.

The initializer is required, right? So all subclasses need to have access to it. But the implementation we provided here might not make sense for all subclasses—what if VerySpecialSubclassOfPoint doesn’t have an init(x:y:) initializer? Normally, the compiler checks for this situation and makes the subclass reimplement the required initializer…but that only works if the required initializers are all known up front. So it can’t allow this new required initializer to go by, because someone might try to call it dynamically on a subclass.

[…]

required initializers are like methods: they may require dynamic dispatch. That means that they get an entry in the class’s dynamic dispatch table, commonly known as its vtable. Unlike Objective-C method tables, vtables aren’t set up to have entries arbitrarily added at run time

[…]

In most cases you don’t care about hypothetical subclasses or invoking init(from:) on some dynamic Point type. If there was a way to mark init(from:) as something that was always available on subclasses, but dynamically checked to see if it was okay, we’d be good.

[…]

For more information on this I suggest checking out my write-up of some of our initialization model problems.

Called the PenLite, the tablet device was designed to work with a stylus, but Apple never fully followed through. It became an obscure example of a Mac prototype that never saw the light of day. More people know of Apple’s notorious Pippin video game console than the PenLite, despite the fact that it was clearly a more influential device on Apple’s trajectory.

[…]

Back in January 2010, as the buzz around the iPad, which had yet to be announced, was just starting to reach a fever pitch, developer Arno Gourdol wrote a blog post pondering whether Apple had finally gotten things right this time. He knew what the prototype looked like, its weaknesses, along with its potential.

[…]

While information on the PenLite is somewhat hard to come by online, there is information floating around. Perhaps the most obscure and intriguing is a 2012 YouTube clip, nearly an hour in length, that features early Apple engineer Thomas Gilley going through the paces of the PenLite as part of the long-running patent case involving Apple and Samsung.