First release of SwiftRichString was take place in December 2016; as many other works it’s born for my own needs; NSAttributedString  management is one of the part of UIKit which owes lots from the Objective-C heritage and even if something is changed with Swift 4 it still have plenty room of improvement to fit well in a post Swift world.

SwiftRichString introduced the concept of Style  to define and collect a type safe collection of attributes you can apply to a plain or already-attributed string. The new 2.x branch is a total rewrite of the library which suits better with protocol oriented programming approach with several room for future improvements.

Main highlights includes:

  • a new optimized codebase; with a protocol oriented approach we have more room to improve the library keeping it clean and typesafe.
  • a new central repository for styles allows you to register styles with a name and used them all around the app without code duplication.
  • integration with Interface Builder allows you set the style to UI controls (currently UILabel , UITextField  and UITextView ) from globally registered styles and leave the library to render the content automatically!
View the article

TableViews are everywhere; for years before the introduction of Collection Views they were one of the fundamental block of every application’s.

Even if now we are able to replace the entire functionality with the combo of UICollectionView  & UICollectionViewFlowLayout  (take a look at “The case for deprecating UITableView) they still play a key role during the everyday work life of any iOS developers.

Frankly I always hated the way in which we prepare and manage contents inside table for several different reasons:

  • tons of boilerplate code to declare data source & delegates. I loved the datasource/delegate pattern, but we can do better and we can do it in Swift, of course.
  • it’s weak: declare cell via identifiers (literals!), cast and finally use them; in our new strong-typed world this is a nightmare we need to avoid.
  • complex tables are a nightmare to prepare and manage; usually you will end up in a world full of if/switch conditions to allocate one cell instead of another, do an action if the you tapped this or another cell and so on. I just want to declare content and do actions.
  • Your view controllers are easy to become full of apparently-non-sense-conditions used to manage the content of your tables.
View the article

How we can make Cocoa a little less verbose and a little more type safe.

When I’ve started working with Cocoa in later in 2001 I was coming from some experience in Java and a little less of pure C. Cocoa was simply amazing (check out this cool old article from Ars Technica) and the difference with the old Mac Toolbox was huge.
A brave new world was coming and I was pretty exciting of all opportunities which a complete full-featured framework like that could offer to me.
Lots of years are passed since these days, the old NeXT heritage was taken from iOS with UIKit and we lived the mobile revolution also and especially thanks to a complete solution which really helped to create an fertile environment for what we call The App Economy (which, of course, was started on macOS).

View the article
@