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!

I recently read a great post by Benjamin Encz about bridging Swift to Objective-C by creating bridging types that can be exposed to the older language. I wondered if his idea can be improved and automated using meta-programming with Sourcery by Krzystof Zablocki. The answer is a very impressive ObjC-like uppercase YES.

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:

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!

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?

Swift is finally open source! This is great because of many reasons, namely the transparency and chances to learn from the people responsible of building the foundational language you work on. I’ve been checking how easy was to build the runtime, REPL and compiler, and it turns out the team made an excellent job to make the process very easy. Let’s see how to do it.

In a previous post, I wrote about the choice of paradigms that Swift presents for it’s target audience. I also gave my opinion on how people with different backgrounds might see and approach the Functional Programming paradigm.

In this post I want to share how I started to take advantage of FP with Swift for the practical domain of iOS developers: Building apps.

It’s a very exciting time to be an iOS or Mac developer. The platform moves very fast and we got a new toy (language) to play with: Swift. It’s the perfect time to reevaluate, learn and evolve as a programmer, because you will be forced to adopt this new language (yes, I think Swift is the future, 100%).

I want to relate this to the fact that most iOS engineers, or mobile application developers, are traditionally familiar with Object Oriented Programming paradigm. But Swift offers more than different syntax and OOP.

I’m referring to some features inspired by functional languages. If you’ve ever had an interest, but never the chance or motivation to go forth and look into this paradigm, now it’s the perfect time to do it.

Having problems code signing and distributing your application written in Swift? I’ve encountered some, found solutions for them, and I’ve written a sum up for Badoo Tech blog.

Hopefully it will help anybody with similar issues and increase discoverability of the solutions.

Today I introduce a small Swift DSL to improve how complex and chained animation code looks, and reads.