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.

You know, every image is a stream of binary data, well-structured where the size of the canvas, along with some other interesting infos, is made explicit at the very beginning of the file itself: so if you start downloading only a bunch of data just to get these info you can stop the download immediately and obtain the size of your image. Typically this operation require only few bytes (even if your downloaded block maybe larger around 50kb or less) of download per image, regardless of the real file size.

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.

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

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