Articles about Swift, Cocoa, software design and programming.
This article will look at how SwiftUI's approach to declarative views compares to CwlViews, why the two approaches differ and what Apple changed to make this possible. I'll end with some thoughts about how this will affect macOS and iOS development.
In this article, I'll look at the the biggest problem with non-declarative views and how frameworks have slowly become more declarative, over time. I'll take a guess at what approach a declarative view framework from Apple might use – although keep in mind, I have zero insider knowledge and there's only a month before WWDC proves how wrong I am.
CwlViews is a library that offers declarative construction for all common iOS and macOS view and application objects. The result hides many of the busywork tasks that consume much of Cocoa application programming, leaving behind a highly concise, declaratively constructed, view-state driven, reactively connected experience.
After a look at headaches due to Xcode 10's new build system, this article will largely be a log of changes to Cocoa with Love content, in reverse chronological order, as I go back through all my Swift articles and make sure everything is up-to-date for Swift 4.2, Xcode 10, iOS 12 and mac OS 10.14.
Last night, I removed my app StreamToMe from the iOS App Store, after 9 years on sale. This will be a discussion about what it's like to have an app on the App Store that is financially successful but eternally problematic, from a support and maintenance perspective. I'll talk about why I lost interest in StreamToMe and, at times, deliberately neglected my own product. Finally, I'll talk about why I've decided to simply pull it from the store – not open source it or sell it – even though it still works for many people. .
The upcoming CwlViews library offers a syntax for constructing views that has a profound effect on the Cocoa applications, making them naturally 'unidirectional' and eliminating the need for `UIViewController` subclasses. In this article, I look at what the Cocoa application design pattern becomes if we take away the need for a controller.
In this article, I look at constructing Cocoa views in code using a unique syntax that offers dynamic and constant options with no syntactic overhead, support for parameters inherited through the class hierarchy, support for large numbers of optional parameters without needing to push unused parameters onto the stack, avoidance of parentheses, and avoiding the need to specify types – all while remaining completely typesafe.
In this article, I'll look at View-state; a frequently ignored trait in typical MVC programs. I'll explore how treating View-state as a Model can lead to simpler navigation transitions, better debug logging, easier state restoration and tricks like time-travel.
In an effort to explain what effects application design patterns have on code, I deliberately write an application using the worst possible application design pattern, in the hope that obvious mistakes will reveal the benefits of using better patterns.
I present a small file for handling layout, similar to UIStackView or NSStackView but built around efficient Swift syntax and the aim of composing full layouts as a single expression.
