Having Xcode Code Completion Problems?

After installing Xcode 8, I had some problems with code completion as well as getting to the documentation when holding down the Apple key when clicking a keyword.

Deleting derived data

When serching for the problem on the interwebz, the go to recommendation was deleting derived data, and restarting Xcode. So I did, and to my frustration it did not help. Neither did rebooting my Mac.

Solution TL;DR

I suddenly discovered that only UIKit was imported, while Foundation was not imported once in any of my source files. This should not have any impact, because the source would build and run without any problem, but Xcode SourceKit did stop working when I did not have any reference directly to it. The moment I added import Foundation to a UIViewController, and Apple + clicked a keyword, it worked just great.

Bug or Not?

First of all, the frameworks I did import in my source files does depend on Foundation, so I can’t find any good reason for why this would happen. Also in a couple of other completely different projects, documentation as well as code completion did reappear after I imported Foundation in that first project. So I guess its a SourceKit related bug that suddenly disables documentation and code completion. The solution was for the project somehow re-index the code, and then kind of resetting SourceKit.
And just to make it clear, I deleted derived data, restarted Xcode, cleaned up and jumped through all hoops before the import Foundation trick did the trick 😉

So yes, I guess its a bug, and I have filed a radar (rdar://28479377). Hopefully Apple will mark it as duplicate, and have it fixed in the next release.

Porting from Objective-C to Swift

May was a super busy month, so nothing got published. I have been writing a couple of articles, they are coming, but I’m not completely satisfied with them. So in the mean time I have a little piece regarding porting.

I don’t like to mix sweet and salt flavors, so a chocolate bar sprinkled with sea salt and hot pepper is not my kind of stuff, not even a PBJ sandwich. Jam is great, same with peanut butter, but I can’t stand the mix. Same with my iOS projects. They all are written in Objective-C or Swift, not both.

On this project I’m working on at the moment, I was searching for a different way of pointing out some spots on some graphics. The points in the graphics where very small, and hard to see when picking them, so I thought of the loupe in iOS when selecting text. An effect like that would be perfect. So instead of writing it myself, I searched the inter-webs and found an open sourced project doing exactly what I wanted. Its called iOS-MagnifyingGlass, written by Arnaud Coomans.

Continue reading Porting from Objective-C to Swift

My Quest to Skinnier ViewControllers

Fat ViewControllers are a pain in the rear. So I have been researching different solutions to cope with the problem. There are different approaches batteling this, but none of the solutions I have found are exactly what Im looking for. VIPER is one approach, but its architecture is too fragmented, a project built with this paradigm gives you a lot of small classes and extensions, making the Xcode project a jungle of goups and small files, and adding an extra layer of complexity. For some this is just what they are looking for, but for me its not. Chris Eidhof has also a really interesting approach with intentions. I tried this but so far I have not gotten it to work for me the way I wanted. So because I write Swift in active projects, I needed an approach I was comfortable with, and found in the Ray Wenderlich Swift Style Guide.

The easiest way is to show this in code.

How I used to do it

Ray Wenderlich Style Sheet

My form of skinny ViewControllers

Instead of showing everything into one single file, I ended up with putting each of the extensions into seperate files, using a really simple naming convention. I have the UIViewController, MainVC, in a ViewController group. The DataSource goes into a DataSource group, and calling it MainDS. And the ViewDelegate? You guessed it right, it goes into a ViewDelegate group with the name MainVD. So for the program logic, I put MainLogic into a Logic group. All data models goes into a DataModel group. So, with an easy glance, I know where each file is depending on what I want to edit. Not a lot of searching for where I put something, everything goes into its respective group. The only stuff going into MainVC.swift file, are vars, outlets and actions.

This is probably not the perfect way of arranging a project, but for me it works fine. I really hope you could give me some feedback on it, and pointers on how to enhance the design pattern.


Im really happy with all the feedback I got in very short time, and one tip was to organize all the files in one group for each ViewController. So in MainVC, MainDS, MainVD and so on goes into a Main group. This is a really good idea, and Im going to give it a try in ome of my ongoing projects. Keep the good ideas coming, I really appreciate it!

Starting another Swift blog

The best way to learn is to teach, my old math professor told me. And he’s right. That’s the main reason for me to start blogging.

Im Geert-Jan Nilsen, 40, married, two kids, and programming Swift. I started coding assembly way back with an Amiga 500, and later switched to Mac, and found HyperCard. I made a patient journaling system for a local hospital in it, and later migrated it to SuperCard because the support of color and AppleEvents. Then the app evolved from a simple HyperCard Stack to a Server/Client system using AppleEvents over AppleTalk. A couple of years later I bought Prototyper and Think! C wich became Symantec C++. Fast forward, from 2006 Cocoa and Objective-C was the blend, first for OSX, later iOS. And now Swift.

When HairForceOne presented Swift for the first time, my emotions went from extatic to almost depressive, because now all my investment in C was straight out of the window. But after just a couple of hours checking out the Playgrounds, I was completely sold. Swift has been the best ever happened to me. The new way of thinking gave me a completely new look on the platform, and brought inspiration.

I could never have gotten to where Im today without the two greatest concentration of Swift-geniouses, StackOverflow and #swift-lang@freenode. And because of all the help I got from them, I decided to give something back to the community, and OpenSourced an important part of my first commercial product made in Swift, a signature capturer for concent forms, delivery apps, and so on. You can find it here on GitHub.

Another inspiration for starting Yet Another Swift Blog, is @andrewcbancroft and his great blog. Be sure to visit it.