Tag Archives: swift

What’s new in Swift 5.0

A new version of the Swift programming language is coming: Swift 5.0. It’s slated to be released early 2019, with a fair number of changes. How does this Swift update affect practical iOS development? And who’s making these changes anyway?

In this article, we’ll walk through some of the proposed and accepted changes for Swift 5.0. We’ll also discuss how the process of making changes to the Swift language works, and why that’s relevant for iOS developers.

Version 5 of Apple’s Swift language used for iOS and MacOS application development will arrive in 2019 with ABI (application binary interface) stability in the standard Swift library a primary focus.

ABI stability is half of what is needed to support binary frameworks. The other half, module stability, will be a “stretch goal” for Swift 5 and may not make it into the release, Apple’s roadmap notes.

Continue reading What’s new in Swift 5.0

How to use Swift classes all across an Objective-C project

The most universal solution is to change SWIFT_OBJC_INTERFACE_HEADER_NAME (“Objective-C Generated Interface Header Name”) under Project’s, not Targets, Build Settings, to:

  • $(PROJECT_NAME)-Swift.h — one per project;
  • $(SWIFT_MODULE_NAME)-Swift.h — one per module (default value).

Then import the Project Header, example:

#import MyProjectName-Swift.h

UIAlertView in Swift

In Swift and iOS 8 SDK you can present an alert view as shown in the code below :


var alert = UIAlertController(title: “Alert Title”, message: “Message”, preferredStyle: UIAlertControllerStyle.Alert)alert.addAction(UIAlertAction(title: “OK”, style: UIAlertActionStyle.Default, handler: nil))
self.presentViewController(alert, animated: true, completion: nil)

You can also add destructive and cancel actions by setting the style property to Destructive and Cancel respectively.

IBAction and Outlets


An action is a piece of code that’s linked to some kind of event that can occur in your app. When that event takes place, the code gets executed. You can define an action to accomplish anything from manipulating a piece of data to updating the user interface. You use actions to drive the flow of your app in response to user or system events.

You define an action by creating and implementing a method with an IBAction return type and a senderparameter.

  1. - (IBAction)restoreDefaults:(id)sender;

The sender parameter points to the object that was responsible for triggering the action. The IBAction return type is a special keyword; it’s like the void keyword, but it indicates that the method is an action that you can connect to from your storyboard in Interface Builder (which is why the keyword has the IB prefix).


Outlets provide a way to reference objects from your interface—the objects you added to your storyboard—from source code files. You create an outlet by Control-dragging from a particular object in your storyboard to a view controller file. This creates a property for the object in your view controller file, which lets you access and manipulate that object from code at runtime. For example, in the second tutorial, you’ll create an outlet for the text field in your ToDoList app to be able to access the text field’s contents in code.

Outlets are defined as IBOutlet properties.

  1. @property (weak, nonatomic) IBOutlet UITextField *textField;

The IBOutlet keyword tells Xcode that you can connect to this property from Interface Builder.

Swift, Apple’s new programming language

If anyone outside Apple saw Swift coming, they certainly weren’t making any public predictions. In the middle of a keynote filled with the sorts of announcements you’d expect (even if the details were a surprise), Apple this week announced that it has created a modern replacement for the Objective-C, a programming language the company has used since shortly after Steve Jobs founded NeXT.

Swift wasn’t a “sometime before the year’s out”-style announcement, either. The same day, a 550-page language guide appeared in the iBooks store. Developers were also given access to Xcode 6 betas, which allow application development using the new language. Whatever changes were needed to get the entire Cocoa toolkit to play nice with Swift are apparently already done.

While we haven’t yet produced any Swift code, we have read the entire language guide and looked at the code samples Apple provided. What follows is our first take on the language itself, along with some ideas about what Apple hopes to accomplish.

Why were we using Objective-C?

When NeXT began, object-oriented programming hadn’t been widely adopted, and few languages available even implemented it. At the time, then, Objective-C probably seemed like a good choice, one that could incorporate legacy C code and programming habits while adding a layer of object orientation on top.


Successor to Objective C has “none of the baggage of C.”
But as it turned out, NeXT was the only major organization to adopt the language. This had some positive aspects, as the company was able to build its entire development environment around the strengths of Objective-C. In turn, anyone who bought in to developing in the language ended up using NeXT’s approach. For instance, many “language features” of Objective-C aren’t actually language features at all; they are implemented by NeXT’s base class, NSObject. And some of the design patterns in Cocoa, like the existence of delegates, require the language introspection features of Objective-C, which were used to safely determine if an object will respond to a specific message.

The downside of narrow Objective-C adoption was that it forced the language into a niche. When Apple inherited Objective-C, it immediately set about giving developers an alternative in the form of the Carbon libraries, since these enabled a more traditional approach to Mac development.

Things changed with the runaway popularity of the iPhone SDK, which only allowed development in Objective-C. Suddenly, a lot of developers used Objective-C, and many of them already had extensive experience in other programming languages. This was great for Apple, but it caused a bit of strain. Not every developer was entirely happy with Objective-C as a language, and Apple then compounded this problem by announcing that the future of Mac development was Cocoa, the Objective-C frameworks.

What’s wrong with Objective-C?

Objective-C has served Apple incredibly well. By controlling the runtime and writing its own compiler, the company has been able to stave off some of the language limitations it inherited from NeXT and add new features, like properties, a garbage collector, and the garbage collector’s replacement, Automatic Reference Counting.

But some things really couldn’t be changed. Because it was basically C with a few extensions, Objective-C was limited to using C’s method of keeping track of complex objects: pointers, which are essentially the memory address occupied by the first byte of an object. Everything, from an instance of NSString to the most complex table view, was passed around and messaged using its pointer.

For the most part, this didn’t pose problems. It was generally possible to write complex applications without ever being reminded that everything you were doing involved pointers. But it was also possible to screw up and try to access the wrong address in memory, causing a program to crash or opening a security hole. The same holds true for a variety of other features of C; developers either had to do careful bounds and length checking or their code could wander off into random places in memory.

Beyond such pedestrian problems, Objective-C simply began showing its age. Over time, other languages adopted some great features that were difficult to graft back onto a language like C. One example is what’s termed a “generic.” In C, if you want to do the same math with integers and floating point values, you have to write a separate function for each—and other functions for unsigned long integers, double-precision floating points, etc. With generics, you can write a single function that handles everything the compiler recognizes as a number.

Apple clearly could add some significant features to the Objective-C syntax—closures are one example—but it’s not clear that it could have added everything it wanted. And the very nature of C meant that the language would always be inherently unsafe, with stability and security open to compromise by a single sloppy coder. Something had to change.

But why not take the easy route and adopt another existing language? Because of the close relationship between Objective-C and the Cocoa frameworks, Objective-C enabled the sorts of design patterns that made the frameworks effective. Most of the existing, mainstream alternatives didn’t provide such a neat fit for the existing Cocoa frameworks. Hence, Swift.

Is it any good?

Swift isn’t a radical departure in many ways. Apple likes certain design patterns, and it constructed Objective-C and Cocoa to encourage them. Swift does the same thing, going further toward formalizing some of the patterns that have been adopted in a somewhat haphazard way (like properties). Most of the features Swift adds already exist in other programming languages, and these will be familiar to many developers. The features that have been added are generally good ones, while the things that have been taken away (like pointer math) were generally best avoided anyway.

In that sense, Swift is a nice, largely incremental change from Objective-C. All the significant changes are in the basic syntax. Use semicolons and parentheses—or don’t, it doesn’t matter. Include the method signature in the function call—but only if you feel like it. In these and many other cases, Swift lets you choose a syntax and style you’re comfortable with, in many cases allowing you to minimize typing if you choose to.

Most of the new features have been used in other languages, the syntax changes get rid of a lot of Objective-C’s distinctiveness, and you’re often able to write equivalent code using very different syntax. All of this enables Swift to look familiar to a lot of people who are familiar with other languages. That sort of rapport has become more important as Apple attracts developers who’d never even touched C before. These people will still have to learn to work with the design patterns of Apple’s frameworks, but at least they won’t be facing a language that’s intimidatingly foreign at the same time.

In general, these things seem like positives. If Apple chose a single style, then chances were good that a number of its choices wouldn’t be ones we’d favor. But with the flexibility, we’ll still be able to work close to the way we’d want.

Close, but not exactly. There are a couple of specific syntax features I’m personally not a fan of and a number of cases where a single character can make a radical difference to the meaning of a line of code. Combined, the syntax changes could make managing large projects and multiple developers harder than it has been with Objective-C.

What’s Apple up to?

For starters, it’s doing the obvious. Swift makes a lot of common errors harder and a number of bad practices impossible. If you choose, you can write code in Swift pretty tersely, which should make things easier for developers. It adds some nice new features that should make said developers more productive. All of those are good things.

More generally, though, Apple is probably mildly annoyed with people like me. I spent time getting good at using autorelease pools, my apps didn’t leak memory, and I didn’t see the point in learning the vagaries of the syntax required to make sure Automatic Reference Counting didn’t end up with circular references that couldn’t be reclaimed. I wasn’t a huge fan of the dot notation for accessing properties, so I only used it when it couldn’t be avoided. In short, I was a dinosaur in waiting.

People like me are why the runtime and compiler teams can’t have nice things. If everybody’s using the same features, it’s easier to get rid of legacy support and optimize the hell out of everything that’s left. A smaller memory footprint and better performance mean lower component costs and better battery life, which are very good things for the company.

Apple promised better performance with Swift, and you can see some places where it might extract a bit. Constants are a big part of Swift, which makes sense. If you make a stock-tracking app, the price may change every second, but the stock’s name and symbol change so rarely that it’s just as easy to make a whole new object when this happens. Declare the name and symbol constants, and you can skip all the code required to change them in a thread-safe manner. Presumably, the compiler can manage some optimizations around the use of constants as well.

Unlike the dinosaurs, we can see Chicxulub coming. Two or three years from now, when Apple announces that the future is Swift and it’s ready to drop Objective-C, we won’t be at all surprised. And I won’t be at all upset, because I’ll have spent the intervening few years making sure I know how to use the new language.