A tale of Lists:
How the story behind a library can teach us a sane approach on software development

Less than a 30 days and we’ll face the official version of Marzipan, the Apple’s vision for a Universal Platform. Officially it’s a port of the UIKit framework for macOS… pretty funny if you think UIKit was born from a rib of AppKit for OSX in late 2007.
But today is a very different worldthan 2000s; this is a world where most of the Apple devs never approached Cocoa programming and the AppKit itself when considered, at best, is the old mistreated father.

In the early days before WWDC 2018 lots of devs started dreaming about a new functional-inspired UI framework which is able to replace some of the oddities of the AppKit heritage in UIKit.

In a post-reactive world everyone is talking about stream, observable, function as first citizen as the next Holy Grail. I love it.

But we need to be serious about our job, dude.
A framework must be a tool to support and move a business, not a fancy playground for developers: it must be stable and reliable over the time (I’m in ❥ withSwift but actually I’m very happy to see Obj-C hanging around).

View the article

SwiftLocation 4.0.0 is here

Maintaining opensource projects, even if smaller is an hard work and require commitment and focus.
Pushing them forward, fixing unavoidable bugs, reviewing issues, answer to questions is somewhat another job.

During the past years I had worked to several libraries; most of them were born from a personal requirement both for side project or at my full-time job. With this gym I learned tons of new stuff about programming, algorithms, best techniques & pattern… behind every line of code there was an entire world made of time and dedication to make my seniority always fresh and updated.
But before everything else it’s just a passion.

View the article

Images prefetching for real man

Working with custom layouts and remote images can be tricky; it can easily become a chicken-eggs problem where you need the size of your images to reserve the correct space for your layout but you have to download all of them to make it right. It’s a bit mess and even if you use tables / collections you can not do a good prefetching.

Adjusting layout incrementally while you are downloading produce the well know web-like effect where every element become a crazy clown until the end of the download.

Your final result is a poor UX / UI experience and many disappointed users. So, if you are not enough lucky to deal with your backend colleague (or possibly kill your designer) you may be in trouble.

But don’t worry, I’m here to say compromise is possible.

View the article

June is passed and, as usual, the WWDC conference gave to us a new set of iOS beta versions to try.
While the first days of September are usually committed to test our apps on a pretty-usable iOS beta, these months are an irresistible opportunity to have fun (and swear) by playing with early iOS versions on our device.

If we can tolerate a certain amount of bugs and strage behaviours we should also to run our projects on these devices using the stable version of Xcode and not the beta one.
However “old” Xcode version are not able to run projects inside devices with iOS betas.

View the article

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.

View the article

As Apple’s developers we started facing the type-safe constraint in our code with the advent of Swift.

From my side I’ve always tried to fully embrace this approach even if often this means to come to a deal with several parts of the UIKit which are obviously created with a different – more dynamic – paradigm in mind.
Sometimes is easy, some other less, but they still a good excercise to think outside the box to keep our code safer and cleaner.

Recently I’ve re-faced an apparent trivial task; I would to read the configuration of an application saved inside the Info.plist file of the app.

View the article
@