grahl/ch

Diving into Swift Part 2

This is the second post on Diving into Swift, if you haven’t read the first part, consider reading it for a general overview of the Xcode/Swift ecosystem.

Here are now the three areas in which I struggled the most and want to give advice to newcomers to Swift, who are used to scripted languages.

Optionals

An optional value either contains a value or contains nil to indicate that a value is missing. From “The Swift Programming Language”

Understanding optionals is critical to writing Swift code, and I can only echo what Touch Code Magazine describes as “the Swift code I see published on the Internet tends to rather randomly unwrap Optionals”. Xcode will complain if you haven’t marked an optional as such or force-unwrapped, so you can stumble towards runnable code with the help of the IDE. However, I highly recommend reading their article, to understand when you need to do which and why.

Especially understanding the if-let pattern is required if you have any complex interactions which depend on optionals.

Asynchronicity

In the PHP world you execute all as fast as you can and if something slows down your page load you do it in a batch job or via Ajax. Thread-what? That won’t work here for two reasons 1) don’t block the main thread, or your UI will become non-responsive and 2) the core libraries are all optimized for asynchronous operation.

A good example for this is fetching data from the web and responding to it. If you use NSURLSession in a function, this will background that operation. Should you use data from that asynchronous callback in an if-let-construct (i.e. change a variable in the function’s scope) and at the end of a function containing it return said data, then don’t be surprised if the breakpoint of the function return is hit before the network request has occured. This is fun to debug.

You could force this request to become synchronous with a semaphore but the better solution is figure out a way to react dynamically to the request once it comes back or put the network operation into a place before you need to depend on that data (Easily possible in my case, not always possible, of course.)

Understanding & debugging storyboards

While it is quite nice that a GUI editor makes drag-and-drop for creating screens possible, it also comes with many frustrations. You should keep the following in mind:

  • Base values are good for adding elements and connecting them.
  • Final values are required for the actual positioning. 
  • Even though you can do portrait and landscape for iPhone and iPad in one app. Don’t (for now). It reduces unnecessary complexity, since each element on each screen variant is likely to require subtle different constraints.
  • Also, don’t assume that just because you removed an IBOAction or Outlet, that the link was dropped. You have to find the element in the storyboard and unlink them (via right-click) or you will get a build or runtime error.

I don’t actually have any good solutions or tutorials for working with storyboards and their constraints. My recommendation would be to use a layouting tool such as Sketch first, so that you can start cleanly in Xcode and only add what constraints you actually want to set and then add required missing constraints. Feel free to tweet me recommendations for better storyboard work though (@grahl).