This year I had the privilege of attending WWDC for the first time. I knew the labs were very important, and I want to share a resolution to fix a problem for our big project at Peak: Autocompletion on Swift code was not working most of the time in the IDE, and with the help of an Apple engineer in the labs we got it sorted.

Update on 30/10/2017:

The issues described here seem to be fixed with latest release version of Xcode 9.0.1 (9A1004). Also the ‘internal’ menu doesn’t seem to be accessible anymore. If you know how to access it I’d love to hear from you!

This weekend I wanted to setup Precompiled Bridging Headers for my project. This setting is available in the new Xcode 8.3 beta. Then building for latest official XCode (8.2.1) the code will not compile because the Swift compiler doesn’t recognize it. How do we use different build settings for different Xcode versions? Only possible with xcconfig files.

There’s an undocumented build setting called XCODE_VERSION_MINOR that we can use here. And after some variable substitution we’ll make it work. Here’s the gist:

There’s times when you need to investigate regressions in your project, and you don’t know have any clue as why something is happening. Git bisect is the best tool for this cases, but it can be painful to use in non small projects using CocoaPods and Xcode. I want to share what I’ve been doing to ease the pain.

Have you encountered this error when upgrading to the latest CocoaPods (1.1.0), or sharing a library between your iOS App and your extension?

'sharedApplication' is unavailable: not available on iOS (App Extension) - Use view controller based solutions where appropriate instead.

If yes, continue reading, as you might have encountered same issue as myself. I’ve recently had to upgrade a project to using Cocoapods 1.1.0. Things stopped compiling, and I had to investigate the root cause of the problem. It has to do with iOS App extensions, unavailable APIs and how fragile our tooling is ;).

Last thursday I gave a talk at NSLondon meetup called ‘Minimum Viable Tooling’. The topic was examples of approaching tooling and automation for small teams. I showed real examples of what we do at Peak, where I currently work. One of the things people showed interest in after the talk was how we deal with localizations.

In this post I will replicate the simple solution from scratch, so you can follow along and get started with your own projects. And we will be using Swift for the scripting, just because we can!

Today I want to share a small utility we’ve been using for a while at Peak, my current workplace, to control the system time inside the application and save time while testing or debugging.

Much of the literature and writing related to sofware development focuses on the creation, new ideas, fresh ideas and things to improve in your next project. But when is it a good moment to delete the old stuff in an long term project? Here’s my short rant about this; I recently deleted a chunk of code in my current project and just felt I wanted to write my thoughts.

Having worked in companies developing their own products, I’ve faced many times the problem developers encounter when building iOS applications: Your biggest 3rd party dependency - the OS SDK - is changing under you every year. How does your team deal with this in a maintainable way?

I wrote a while ago a tip, mostly for my future reference, how to set up a HDD with Raspberry Pi formatted using exFat. After more intensive testing on my Samba setup, I’ve decided to go back to NTFS as my format of choice.

A few days ago I switched my HDD on my Raspberry Pi to a SSD drive. I use the Pi as a NAS serving files at home and I wanted to use a HDD for music with less storage but more reliability. This drive runs 24/7. I also chose exFat for the filesystem. I write this as a future self-reference, but may be useful for somebody else, so here it goes.