Alberto De Bortoli

Senior iOS Software Engineer @ JUST EAT
Co-author of objc-zen-book
I like to do things properly
London, baby

about me

MSc at the University of Padua. I currently work at JUST EAT as Senior iOS Software Engineer, previously at Beamly, Badoo, EF Education First in London and at H-umus in Italy. I held iOS courses at Digital Accademia.
Read on →

Notes on the Developer Portal. For Dummies.

Let’s make it clear. This is a post for dummies. There are some others tutorials online but I thought I could write something better focusing on the right details rather than wasting time on a brainless walkthrough. Well… here are my 50¢.

It’s since 2008 that I work with the iOS platform and still, when it comes to managing certificates and provisioning profiles within the Developer Portal, I lose my mind. Just like when you start a new bottle of vodka and you cannot remember the entire trip that brought you to the bottom of the previous bottle.

After having read this post you’ll hopefully have a better understanding of what and why you need to setup in terms of certificates and provisioning profiles for building an iOS app on device or for archiving for release. If not, at least you have some handy tutorial for dummies.

Let’s start from scratch. No keys, no certificates, no provisioning profiles, clean Mac install.

written in Apple, certificates, code signing, developer portal, iOS, provisioning profiles Read on →

From the Eyes of an iOS Dev at JUST EAT

It has been almost 6 months since my last blog post. Things have changed quite a lot since then. Six months ago I was still excited about my travel to San Francisco for the WWDC 2014, my girlfriend still had to move from Italy to London with me and definitely I wasn’t planning to switch job again any time soon.


I’ve been attracted by JUST EAT as a company since March 2014 but at that time it was too early for me to consider to change job. I met Ben Chester (the tech lead of the iOS team) when he gave a talk at Badoo offices (when I was still working there) and that evening he blew my mind. Later, I had a few chances to have a chat with the passionated guy he is and I immediately thought “Damn! I want to work with this guy, with brilliant guys like him and I want to work at JUST EAT!”.

Since then, I heard people talking extremely good about JUST EAT as a job place because of the values, the work environment, the company culture and the engineeristic approach to things. Every time I started with “Do you know JUST EAT as a company?” the answer was something like “Oh yeah! They are freaking cool! I have a friend working there, they do amazing stuff and he’s very very happy!”. They definitely were all good signs. Signs I decided not to underestimate anymore these days.

Another good sign was also the exposure and lots of information that the company promotes online with its tech blog giving a good insight of the technologies used, the people and teams working there and a good description of the Engineering. Benefits are also compelling.

JUST EAT offices hosted NSLondon a few times. Meetups, you know, are the perfect occasions to reach out the developers’ community. I noticed too many cool companies failing at this.

After months of interest about JUST EAT and thoughts spinning in my head, I said to myself “let’s see if I have what it takes”. I decided to apply for the Senior iOS role in later October 2014 kicking off the process taking the test task. I joined the Consumer iOS app team at the begin of 2015 and after 2 months of excitement I’m summarizing some thoughts here.

written in GitHub, JUST EAT, London, iOS, open source, work Read on →

Working on Tasks With an Eye on Open Source Contributions

Have you ever realized that developers are never happy with the legacy code?

The definition of “legacy code” may vary:

  • code inherited from the previous developers of your company
  • code that doesn’t have test suites
  • code that is older that 10 minutes (…)

We all rarely find good code when joining a company, weird uh? Some reasons why good code is so hard to find can be:

  • the developer that worked on the code was good but couldn’t care less about doing things properly
  • the developer that worked on the code was simply unexperienced and created bizzare things
  • the developer that worked on the code was terrible at architecture design
  • too many developers worked on the same code without understanding what was already been done
  • code was not developed using the black box approach and without reusability in mind

All points but last are summarized here:

written in GitHub, Objective-C, iOS, open source, work Read on →

Flow Controllers on iOS for a Better Navigation Control

Since I’m in London conversations with iOS developers have reached high levels with no doubts. I love to discuss with friends and iOS devs about new ways to improve our coding. Often my best practices are very appreciated among them and a bunch of devs start applying day-by-day what they learnt. “An Aspect Oriented Programming Approach to iOS Analytics” and “CocoaPods: Working With Internal Pods Without Hassle” are 2 examples of good best practices. A friend asked for a post about the specific topic of flow controllers so… here we go. :)

Navigation on iOS

There are very few ways to present UIViewControllers on iOS either through UINavigationController or UIViewController:

// UIViewController
[viewControllerInstance presentViewController:modalViewController
                                   completion:^{ / ... / }];

// UINavigationController
[navigationControllerInstance pushViewController:detailViewController

The thing I never liked is that UIViewController instances have the ability to push things on their own using the associated UINavigationController and to present other UIViewController instances within their logic. It’s not… their responsibility.

written in Architecture, Design, GitHub, Objective-C, iOS Read on →

Objective-C, Zen and Some Satisfaction

I’m very proud to announce my last work with Luca Bernardi

“Zen and the Art of the Objective-C Craftsmanship”

Available on GitHub.

We started writing this book on November 2013. The initial goal was to provide guidelines to write the most clean Objective-C code possible: there are too many guidelines out there and all of them are debatable. We didn’t aim introducing hard rules but, instead, a way for writing code to be more uniform as possible across different developers. With time the scope moved to explain how to design and architecture good code.

The idea underneath is that the code should not only compile, instead it should “validate”. Good code has several characteristics: should be concise, self-explanatory, well organized, well documented, well named, well designed and stand the test of time. The main goals behind the curtain are that clarity always wins over performance and a rationale for a choice should always be provided. Some topics discussed here are general and independent from the language even if everything is tied up to Objective-C.

Then something happened…

On June 6th, 2014 Apple announced the new programming language to be used for iOS and Mac development in future: Swift. This new language is a radical departure from Objective-C and, of course, has caused a change in our plan for writing this book. It boiled down to the decision of releasing the current status of this essay without continuing our journey in unfolding the topics we originally planned to include. Objective-C is not going anywhere but at the same time continuing to write a book on a language that will not receive the same attention as it used to, is not a wise move.

During the very first 2 days after the release, the fuzz in the iOS community on Twitter was great! We really hope you will enjoy it and will improve your craftsmanship skills ;-)

written in GitHub, Objective-C, architecture, best practices, code, design, iOS, programming, style, zen

Road to Circular Progress Pull to Refresh at Beamly

Pull to refresh, this friend of ours

The Pull to refresh became one of the most popular concepts used in mobile iOS apps. Loren Brichter, the author of Tweetie for iOS introduced it for the first time in 2011 and it stood the test of time. Several implementations of the pull to refresh lie out there and the most used on iOS is for sure the SVPullToRefresh by Sam Vermette. Back in 2012, the concepts of Objective-C runtime and associated objects were still obscure to most of the iOS developers but Sam used the properly to add an extra view to the UIScrollView without the need for subclassing.

Apple built a native pull to refresh publicly available as of iOS 6, called UIRefreshControl, but customizations are hard to achieve and still, too often developers fallback to an ad hoc implementations. The most common customization is implementing a circular progress view like the one used in the Pinterest app. This leads to a much cooler UI rather than the well-known yet obsolete rotating arrow, and it is recognizable and intuitive to all iOS users.

The concept proposed here has two main individual transitions that are dependent about the position of the finger:

  1. App logo becomes visible (alpha/opacity property)
  2. Circle progress becomes filled

You can see the final behaviour in the gif below, but I definitely recommend downloading and running the Beamly iOS app by yourself to get the right feeling.

written in Design, GitHub, Objective-C, Pull to refresh, UI, UX, iOS Read on →

Asynchronous Message Passing With Actors in Objective-C

Actors, these strangers

Although we are all in love with Objective-C, the power of a language itself is given by its inner features. Languages like Ada have a built-in concurrency model, while Objective-C needs external libraries (let’s say libdispatch) to try to achieve the same power of expression found in richer languages.

The same happened for the implementation of the Actor Model. The standout language for the feature of asynchronous message passing using the actor model is Erlang. From Wikipedia:

The actor model in computer science is a mathematical model of concurrent computation that treats “actors” as the universal primitives of concurrent digital computation: in response to a message that it receives, an actor can make local decisions, create more actors, send more messages, and determine how to respond to the next message received.

That said, languages like Ada and Erlang are semantically more powerful than Objective-C, as some features are expressed at the language level rather than through libraries provided in the user space.

Adopting the Actor Model means avoiding the Object Orientation orthodoxy and forcing the developer to write software as a collection of smaller communicating programs that do not share state. Software written using the Actor Model approach is inevitably more “pure” than its traditional counterpart as the paradigm expresses a better level of abstraction, no matter which language is used.

written in Actor Model, Actors, Asynchronous message passing, Concurrency, Objective-C, Thread safety, iOS Read on →

An Aspect Oriented Programming Approach to iOS Analytics

[Update 09/06/2014]

On May 2014 Peter Steinberger released Aspects inspired (a little :-) by this article and Orta and Ash Furrow improved ARAnalytics with a DSL based, again, on this article -> Tweet

Analytics are a popular “feature” to include in iOS projects, with a huge variety of choices ranging from Google Analytics, Flurry, MixPanel, etc. Most of them have tutorials describing how to track specific views and events including a few lines of code inside each class.

On Ray Wenderlich’s blog there is a long article with some sample code to include in your view controller in order to track an event with Google Analytics:

- (void)logButtonPress:(UIButton *)button {
    id<GAITracker> tracker = [[GAI sharedInstance] defaultTracker];
    [tracker send:[[GAIDictionaryBuilder createEventWithCategory:@"UX"
                                                           value:nil] build]];

The code above sends an event with context information whenever a button is tapped. Things get worse when you want to track a screen view:

- (void)viewDidAppear:(BOOL)animated {
    [super viewDidAppear:animated];

    id<GAITracker> tracker = [[GAI sharedInstance] defaultTracker];
    [tracker set:kGAIScreenName value:@"Stopwatch"];
    [tracker send:[[GAIDictionaryBuilder createAppView] build]];

This always looked like code smell to me. Do you see the nasty thing here? We are actually making the view controller dirty adding lines of code that should not belong there it as it’s not responsibility of the view controller to track events. You could argue that you usually have a specific object responsible for analytics tracking and you inject this object inside the view controller but the problem is still there and no matter where you hide the tracking logic: you eventually end up inserting some lines of code in the viewDidAppear:.

Here comes the idea.

written in AOP, Analytics, Aspect Oriented Programming, Google Analytics, Objective-C, iOS Read on →

CocoaPods: Working With Internal Pods Without Hassle

CocoaPods is cool. I was honoured to have a chat with Fabio Pelosin, the main contributor, at the NSLondon meetup some time ago and see how much passion those guys put in this project.

I was one of the first supporters back in 2012 and I have some Pods in the Specs repo (ADB prefixed). Recently, I spent several days going through some hidden aspects of CocoaPods, ending up reading some source code from the Core and Xcodeproj.

During one of the last few NSLondon(s) of 2013, Orta explained the advantages of CocoaPods and Abizer Nasir, in the following meetup, discussed the usage of Git submodules. Basically comparing their visions.

What I’m going to explain here is a solution to a common scenario:

Manage the versioning of internal private pods within projects without hassle.

written in CocoaPods, Objective-C, Podfile, iOS, podspec Read on →

The Cost of Moving

I have friends in Italy who are eager to move to London. We all have. Most of these friends are concerned about the cost of moving within London, for some idiotic reasons people think that buses and underground are too expensive. Well… that’s bullshit. The aim of this article is to compare the cost of moving within Italy and London and prove that London is much more cheaper than expected. The assumptions here are: in Italy you need a car for living, while in London not. Don’t you think it’s the same? Bullshit again, in big cities like London you just need a public transports subscription. You really don’t want to own a car (which is a huge relief for me since I moved to London).

So… the goal to reach here is: “One wants to move around the city, to go to work or out for having fun.”. You may achieve that in different ways in Italy and London. Find below what my personal expenses were in Italy and now, that I moved to London.

Don’t misunderstand me, it might be that here I’m comparing apples to oranges to you, but just try to follow me in the process.

Let’s go bananas and run some numbers.

written in Italy, London, Oyster, car, cost, moving, price Read on →