An introduction to Swift
CC Attribution - NonCommercial - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Goldshtein, Sasha
At WWDC 2014, Apple announced Swift, a new programming language for iOS and OS X. In this session, we will review Swift’s fundamental concepts, including built-in types and collections, optionals, closures, protocols, extensions, generics and custom operators. We will see how Swift improves upon Objective-C in terms of type safety, readability and developer productivity. During the session, we will demonstrate Swift’s capabilities by building a simple iOS application from the ground up. Prior development experience with iOS or Objective-C is not required.
 Alright. Hello everyone. Thank you for coming and I hope you're enjoying NDC so far. I've got to say I've been to a lot of conferences but never did I have a stage suspended between heaven and earth. You just got to look, I mean, it's not quite stable this whole construction. Just look at my water bottle and I hope I don't fall anyway. So the other thing on behalf of all speakers, you know, in this particular slot after lunch, I have just one piece of feedback for NDC organizers. The food is way too good and there's way too much of it. And so I hope you'll be able to stay awake for this talk on Swift. If you have any questions throughout then please do raise your hand or shout out and I'll try to make this interactive and then at the end I'm going to, we're probably going to have some time for questions. I do have another talk back to back 20 minutes later so if you don't catch me immediately after this one please feel free to stay on touch on Twitter otherwise just meet me and I'll be happy to talk. So how many of you, just to get a general feeling, how many of you are iOS developers? Okay, so not a whole lot but there are some. And how many of you are using Objective C today? Maybe Billy Mac apps, iOS, well everything, okay. So basically I wrote down in the abstract that there is no prerequisite here to know iOS or Objective C. This is just an introduction talk to Swift and it's actually been pretty successful, this idea of mine to do a general introduction talk to Swift because Apple has just announced a few weeks ago that they're planning to make Swift a programming language for things other than just iOS and OS X. Generally it's a pretty good systems programming language which can be pretty successful in spaces where people are using Rust and Go and C++ of course and Objective C. So here's a graph, here's a picture and that's some pretty biased statistics based, it's language popularity based on Stack Overflow searches and GitHub repos and a bunch of other informal sources like that. And so what would you say happened to Objective C popularity around 2009, the end of 2008, what happened? What? The iPhone and more specifically the release of the App Store, right? If we just had an iPhone but we couldn't build apps for the iPhone, I don't think Objective C would have been that popular outside of Apple. But in late 2008, Apple released, well announced the Apple Store, App Store and people were able to submit applications to run on iPhones and it's been pretty popular since and what happened, what happened to Objective C popularity somewhere around this peak in 2014? Swift happened, yeah. And again this is an informal survey of developers but it does look like iOS developers and Mac developers are slowly moving to Swift, actually not so slowly, it's just been a year since Swift has been released and it's gaining really nice popularity. It's still not one of the top ten programming languages but it is extremely popular and I'd like to show you why in this talk. So basically what we're going to do, I'm going to give you a couple of reasons why Objective C is a horrible, horrible language and then I'll give you a few reasons why Swift is an elegant, beautiful, incredibly concise language to use and then I'll build a little app with you, just you know, completing pieces of code here and there to show you what Swift is capable of and then we'll have some time for reflection questions, future directions, stuff like that. By the way, I'm not affiliated with Apple in any way so all the stuff I'm going to say is just based on public information. So here's, you know, exhibit A of how Objective C is a horrible, horrible programming language. If you, for the Objective C developers in the audience, this is going to look familiar but otherwise, I just want to point out this is a simple method that takes an array and a string and it tries to see if that array contains that string and it's supposed to return the index of the object of that string in the array and it turns out if you pass in a string which is null, then you get back a value called NSNotFound which is basically the maximum unsigned integer value and that says no. There is no null in that array because arrays cannot contain nulls. That's the way the Objective C runtime works but if you pass in a null array, then the Objective C behavior is that you get zero as the result of this function and there are some good reasons for this but for me it's just another proof that Objective C is a horrible, horrible programming language. Here's another example, exhibit B. So here you can see on the left hand side the variable type is NSMutableArray. On the right hand side, the type is NSArray and actually NSMutableArray is a subclass of NSArray but this code still compiles. There is a sort of a downcast there and the interesting thing, the cast succeeds at runtime. It is only after the cast that when you try to use an NSArray as if it were mutable, so for example if you try to add an object to an array which isn't mutable, then you get an exception at runtime. What are you talking about? Of course there is no selector called add object on the NSArray class. What are you talking about? Exhibit C. For those of you who are still unconvinced, here we have an NSMutableArray. This is a mutable array. That's all right. And then it doesn't really quite have a type for the elements. So I can add a string, I can add a number. Okay, fine. That's fine. Many languages are dynamic with types, you know, kind of loose with types but then you can take out that int and put it in a variable of type NSString. That compiles just fine as well and that line runs as well. And you can even take that string which isn't a string and print it out and it prints 17. That works all right. It's only when you try to treat it as a string by for example calling a method which only strings have, then you get a crash at runtime. I bow my head in shame at this point. I've been writing some Objective C for a while for several years and this is not the kind of stuff that makes you proud as an Objective C developer, I think. Right? Objective C guys and girls, right? Okay. So enter Swift and Swift has been announced in just June 2014 and one of the, I mean, they could pretty much announce anything, I think. They could say this is, you know, based on Haskell. This is based on Lisp. This is based on Fortran. And still people would be pretty excited because it isn't Objective C, you know? And that's pretty much enough for us Objective C developers. Give us anything that's better than Objective C and we're going to be happy with the result. But I contend that Swift is much better than Objective C and it's actually a pretty decent language to learn even as a first programming language. It's modern, it's elegant, so there's some pieces of syntax borrowed from here and from there which make it a really nice little language, elegant in a, you know, language formal kind of way. It's type safe, so there's much less opportunity for all those ugly downcasts succeeding and then failing at runtime. It's a generic language, so there's built-in support for generic types, collections, stuff like that, you know, arrays. It's a functional programming language with very strong roots and functional programming languages like, well, you know, Haskell, Schem, Lisp, whatever. So there's support for pattern matching, Algebraic data types, a bunch of other nice function language features. Another pretty important property which is shared with Objective C is that Swift compiles to native code. So there is no virtual machine, there is no byte code, there is no interpretation, there is no, you know, VM at runtime that does stuff with your code. It's compiled down to machine instructions, so you take Swift code, you compile it down to ARM, ARM64 and potentially in the, in the very near future to x86 on other operating systems as well. It also, it already supports x86 on the Mac and it will support Linux as well in the future. So it is a native programming language that can give you the performance of a native compiled language like C, C++, Objective C and so forth. But at the same time, it can't lose, you know, support for Objective C and so you can take Swift code and call Objective C methods and you can write a Swift class and call it from Objective C and you can do it from the same project. So you have a Swift file and an M file, Objective C code and they can call each other in the same project. And finally, that last point means all the iOS APIs, all the Mac APIs are accessible from Swift. And if, even if there is, you know, some low level C style API that you really have to call and you can't directly call it from Swift, you can wrap it with an Objective C layer and then call that Objective C code from Swift. So essentially, you can build iOS applications from scratch with Swift. You can mix and match, oh man, you can mix and match Objective C code and Swift code. You can take, you know, an existing library from GitHub and just use it in your Swift project. You can add Swift classes to your Objective C project. It all works, it all works by design. So here are a couple of ways, you know, to get started with Swift and if any of you have your Macs along, you can just sort of try and experiment a little as well. The first way I'm going to show you is the Swift REPL. So this is a little command line app called Swift. You run it and you start typing in Swift code, so 2 plus 2, you know, or hello world, great. And then, of course, you can define classes and functions. So for example, I can define a function called add which takes an int, x and int y and returns an int and here's the function and then I can call the function and it returns a value. So, you know, a REPL for using, for experimenting with Swift features. Now, here's the cool thing. Again, Swift can talk to all the iOS and OS X APIs, for example, foundation APIs. So suppose I want to use the NSDate class. Ooh. Unresolved identifier NSDate. Well, NSDate is part of a module called foundation. So in the REPL, I can import foundation and then here's an NSDate and sure enough, we can use a type which is definitely not a Swift class. It's a type from the foundation module but we can use it just fine and interact with it, of course. So let x equal NSDate, x, date by adding time interval 1.0 and so I've just added a second to that date and so on and so forth. So this is one way, you know, to get your feet wet with Swift. The other is called playgrounds and this is a really nice X code feature since X code 6 where you can basically, you know, play around, you know, on a playground with some Swift code of your own. So there's a couple of examples here for visualizations and added value that playgrounds give you which the REPL doesn't. So the first couple of lines here, for example, this is a loop which, you know, takes some initial value and then starts to apply some operations to it. I can visualize the execution of that loop by just clicking on this little thingy over here and expand it and I can see the progression of values in the loop. I can see the final value or I can see the succession of all the values as either a graph or a list. Another example is with colors and there's similar support for images as well. So if you have a color object, an image object, an animation, you can see what they look like in your app. And finally, you can do interactive programming as well. So the code there in the bottom, it creates a button, it gives the button a background color, it gives the button a frame, it gives the button an opacity, it sets the button's title and it sets the button's text color. And then it calls a method for playgrounds only called XCP show view and then here's the button, you know. And you can make this interactive actually, you can subscribe to events that this button would raise. Now, this is really, really nice for experimentation when learning a new API. This is also a great way to create interactive tutorials. So you can give your students, you can give your fellow developers a nice little playground with a bunch of already built features and you can tell them, okay, so here you should just write a line of code to make this example work a little different. So I really like playgrounds for training and for experimenting with new libraries. So that's just, you know, to give you a general idea of what Swift looks like and what ways you have of experimenting with it. Now, the fundamental language principles and obviously we're not going to have time to discuss them all are the following. Swift makes a really, really strong emphasis on immutability. And so you have variables which can vary and you have constants which cannot, which are set and immutable. And there are different keywords for those. You use var for variables and you use let for constants which you cannot modify. So again, if you're familiar with Objective C, there's no more NS array and NS mutable array, NS dictionary and NS mutable dictionary, NS string and NS mutable string. If you have a string, it could be either in a variable or it could be in a constant. The type is the same type, it's just the variable that matters, the type of the variable. The other important proposition is optional types and I'll come back to that a bit later. It has to do with nullability and so Swift does a way with nullability. Stuff cannot be null unless you explicitly say this variable here may be null and this is such a strong proposition especially compared to Objective C where everything pretty much can be null and when something's null, doesn't mean you can't call methods on it and get nonsensical values back. The other thing is first class handling for functions, for functional programming concepts like pattern matching, I'll show you a couple of examples and then of course again the full interrupt with Objective C. Anything pretty much you can do in Objective C, you can also do in Swift. So this, I have a couple of examples here. I'm not going to go into depth, it's just designed to show you in general how Swift is really a breath of fresh air in this whole ecosystem. So on top I have a class, an Objective C header file actually with a, well the class is called O-complex and it has a couple of properties, it has an initializer which is like a constructor, it has some methods as well and then on the bottom you have the Swift version of this, a struct complex with properties and with functions and with operators and operators actually overloading of operators is a really, really strong proposition in Swift. It makes, you know, working with strings, it makes working with integral and floating point types that much easier and you can overload operators for your own, for your own classes as well. And so even if I didn't put this white line over here, you'd be able to tell which is old and which is new, right? So there is the sense of elegance coming out of the Swift code at least for me. Here's another little example. It's not so much about length, you know, there's almost the same number of lines, it's about the elegance and so again just look at all the parents which are gone, look at the, you know, the rectangular braces here which are so typical of Objective C code, really borrowed from small talk syntax. These are gone, lots of, lots of things are automatic and just sort of flow from the screen. And finally here's the overloaded operator so z equals z times z plus c as opposed to z mult by z add to c which is what happens where you don't have overloaded operators. So again, even if I didn't put this line here, you'd be able to tell which is old, which is Objective C and which is Swift. So again, I'm not trying to teach the language here but I do want to show you a couple of representative examples before I just write a couple of classes and the little iOS application. So here's Exhibit D which shows you, well, the foundation of Swift's pattern matching around the switch statement. So the scenario here is that we have the fair class for someone's plane ticket, you know, and I want to calculate the mileage bonus they're going to get from that particular flight. So the switch statement can go over strings and that's already something Objective C cannot do and many other languages can't do either. But then a case statement can include multiple cases, okay? So f, a, j and c are all business or first class tickets and then y and b are full fair economy and m and h are discount but it's a high tier discount. And then I can even do conditional, complex conditional operations so I can assign that fair class to a temporary variable here and then ask questions of it. So if it has the r prefix, the whole string, then it's an upgrade ticket and it doesn't deserve any bonus. So that's a very basic example of Swift's switch syntax. And here's an even more powerful example which shows you a sum type, an enum, an enum called HTTP response. And enums in Swift, they have state. It's not just, you know, a couple of integers that vary. So for example here I have a success, I have a success case for HTTP response which has a body of that, you know, HTTP response and I have an error case which has a description and a status code for that error. And then I can pattern match on those in really, really clever, elegant ways. So assuming HTTP get request returns one of those enums, it can go two ways. It can go error or success. But even if it was an error, I can do stuff like error, description and status where the status was greater than or equal 500. And that's an internal server error as opposed to all the other cases and as opposed to the success case. And in all these cases you can see that there's pattern matching syntax that deconstructs the enum and puts it in nice little variables that you can use again. And there's very similar, there's very similar support for tuples as well. And so in functional programming languages this would typically be called a sum type and a tuple is essentially a product type. And in both cases you have this really nice language level support for deconstructing these algebraic types into their constituent variables. And this is really, really handy once you get used to it. And so here's, this is probably one of the examples most influenced by functional programming. Here's another nice feature of Swift, it's designed for extensibility. So it's really easy to take existing types and add features, add operations, extend them essentially. And so here's an extension of int. You know, it's not a very practical extension but it's one that you can actually write. And so here I'm extending the int type to have a method called repeat. And the repeat method takes a function. This thing over here, task is a function. And it's a function from ints to void, from int to nothing. And then what that repeat function does is just call that task as many times as the integer I'm holding in my hand. So you can do stuff like 3.repeat and pass in a function which will be invoked for, which will be invoked three times with the values 1, 2 and 3. And so there's a bunch of syntax on this slide which again shows the conciseness of Swift. First, you can see the range, the range syntax for loops, right? So you can do x in 0 to self. And you can see this conciseness here around the closure, the function that's being passed to the repeat function. There is no argument. That function takes an argument but it isn't there. You can just use $0 for the first argument and $1 for the second argument and so on. There is this conciseness in the syntax where you need it or you can spell it out if you really need this to be explicit. And there's a final exhibit again designed to convince you of the value of Swift. This is a little playground I used to solve a problem for Project Euler. Is anyone familiar with Project Euler? It's basically, yeah, okay. It's basically a website with like a hundred, no, maybe more, several hundred problems ranging from the very simple like printing numbers which are multiples of five to really, really hard math problems. And so the second one is really easy. It's basically enumerate all the terms of the Fibonacci sequence which are smaller than four million. Look for the even ones, the visible by two, and sum them all up. And so this is a classic thing to do with a playground. As you experiment with the code, you can really see the execution of it. You can see the progression of the X's which are part of the sequence itself. You can see the progression of the sum variable which sums up the even terms. It's really, playgrounds are really designed for this sort of experimentation. So let me just, before I write a little app with you, let me just focus on the one thing that maybe makes Swift unique in the mainstream programming languages, you know, C-sharp, C++, Java, Python, all that lot. This is a quote from Sir Charles Anthony Richard Hoare from 2009 when he was accepting some award or other 50 years of really extraordinary computer science work. And he said, I call it my billion-dollar mistake. It was the invention of the null reference. And there's a bunch of other texts here where he explains why he thinks it's such a horrible mistake and why it's a billion-dollar one. But Swift doesn't have nulls by default. And so here's a tiny little example which shows how this nullness and non-nullability still works with APIs that produce nulls occasionally. So for the Objective C developers, here's a method which you might be familiar with, TableView, the query usable cell with identifier. This is a method used in UI applications on iOS which gives you some object or other that you're supposed to use, a UI TableView cell. Now, this method is part of the UIKit framework and it's not a Swift method. So what it returns is not even a proper class. It's not a TableView cell. It returns something like object, you know, an arbitrary thing which can be anything. In Swift, the way to express an arbitrary object is using the any object type. But there's a bonus. That thing you're getting back could be null as well. Not only do you not know the type, it can also be null altogether. And the way to express that in Swift is by adding a question mark. So this is an any object question mark, a nullable any object. It can be any type and it could be null as well. But then you want to test if that arbitrary weird thing you got back is actually of a specific type and is actually not null. So you have this really nice as operator and some nice syntax around if statements. So this line over here says, well, see if that cell variable is actually of type UI TableView cell and if it's not actually null. If those two statements are true, then put the result of type UI TableView cell back in a temporary variable called cell. And then if I get into that if statement, I know for sure that cell is of type UI TableView cell and it isn't null. And again, the language guarantees that if you don't have a variable designed to contain nulls, it will not contain nulls. So you have to be explicit about nullability and in most cases you don't want nullability in the first place. And then inside that little if statement, there's another example which is now popular in some other languages as well, optional chaining. Optional chaining on nullable things. So what you can do, what you can see here is that the text label and detail text label properties of the cell are actually nullable objects. So these properties might be null. And so to avoid having to test and then use them, there is this chaining operator, question mark dot. And you have that for member access expressions, for array access expressions, for method calls. So you can say conditionally if that property isn't null, then I want to access it. If it is null, just do nothing. And that's a really handy way of working with existing code which already has nullable stuff built in. So that's another principle of Swift that you're going to see in your code. So let me show you a quick example of building a little iOS application with Swift. I already have the skeleton for the app itself. I didn't want to waste time, you know, creating a new project and putting UI controls on board. I just want to write a few classes, just show you a bit of Swift syntax. So the app itself is going to be extremely original. It's going to be a to-do app, right, with to-dos, tasks in this case. And the first thing we're going to need is a class task. And that class is going to need a text property with the title for that to-do item and a due date. So I'm going to make the text property a string and it's going to be immutable, a read-only property. On the other hand, the due date is something a user can change, so I'm going to make it a var. And that's a read-write property. Next, we're going to need an initializer which assigns those values. Particularly, I already have an error because my class doesn't have an initializer. And that tiny, teeny thing over here says the stored property text without initial value prevents synthesized initializers. In other words, you have a read-only property and you're not assigning to it in any of your initializers, so that's invalid. Okay, so we need an initializer. And that initializer is going to take a text which is a string and due date which is an NSDate and assign them, so self-due date is equal to due date. And I might also make an initializer, a convenience initializer which takes only the text and calls the other initializer. So the text is going to be text and the due date is going to be a new NSDate. Right. What does it want from me? Expected separator. What? Okay, come back to that. Next, we need is overdue, a Boolean property which says if the task is overdue. And that's going to be a computed property which is why I have it here even. So is overdue is a Boolean property. And what I'm going to do here is just check if the due date is before or after the current date. So NSDate is the current date and I'm going to do, what's the method called? I forget. Does anyone remember what the, there's a method that checks if, okay, time interval since date is one way of doing it. So time interval since date, due date returns, well, you know, the time interval since that date. So if NSDate, time interval since date is positive, then we are not overdue. Right. So actually less than zero. Right. Am I right in my calculations? We are overdue if the interval since the due date is negative. I think so. In any case, finally we have a snooze method which is supposed to snooze that task for a while. So here's snooze. And in snooze I'm going to say due date equals due date, date by adding time interval. And I already have a handy constant for it seconds in day, task that seconds in day. So whenever the snooze method is called, we just snooze that task for 24 hours. Okay, next up is a nice little extension. So, so far I just had the task class which is like my model class. But then I have an extension of it which I intend to use for the UI only. So this is my way of separating these concerns. I have the model class which is pretty clean and I have an extension for display purposes. So here I want a due date string computed property. Due date string of type string. And what I want to do over here is test. So if I'm overdue, I'm going to return past due. This is again for display purposes only. And then I'm going to switch on the due date. Actually I'm going to switch on the due date, due date, time interval since date and a state. And so I want to see how much time exactly I have until that, until that moment arrives. And actually the other way around, NSDate, time interval since date due date. Okay, so case 0 to anything less than an hour, I'm going to say very soon. Okay, and case an hour to a day, I'm going to say soon. And in all other cases, I'm just going to return a date. So I'm going to use a date formatter. And this again goes to illustrate that you can just use whatever APIs are available to you. You know, it's just another language. It doesn't mean the framework you have to use changes in any way. So I have a time style, non and a date style, medium. This is another interesting example. This is actually an enum. And so officially the type of that date style, the type of that time style and that date style is NSDate formatter style. And so it's not actually called non. It's called no style. But the type inference is powerful enough to know that if it's an NSDate formatter style, then I can just say dot no style. And similarly the date style will be medium style. And then I'm just going to return for matter, string from date due date. And just display the due date in my UI. Okay, so we have this extension built in. Last piece of code I want to write, which is really strongly integrated with the UI, is in my view controller over here. And so what I have over here is a place holder for a welcome message. And again, this is just to show you that you can really, really easily use Objective-C APIs, stuff from the framework in your Swift code. So here I'm going to use an alert, an UI alert controller for displaying a welcome message. UI alert controller with a title welcome, a message welcome to the tasks, to the NDC tasks app, and preferred style alert. And again, I'm going to remove the enum name from here. And then eventually I'm going to present that view controller using present view controller, oops, alert, animated true, completion nil. And I'm going to add a couple of buttons to that little alert view controller. So I'm going to do add action, UI alert action. These are just buttons. And so UI alert action has a title, which is going to be, let's say dismiss. Style, UI alert action style default. And the handler is going to be nil for this one. And I'm going to add another action, another UI alert action. And this one is going to be more info, UI alert action style default as well. But this one is going to have a handler. And this is just to show that you have closures in Swift as well. So this thing over here is a method that gets invoked when that action is clicked, when the user clicks more info. And what I'm going to do here is UI application, shared application, open URL, NSURL with the string, and the C osla.com. Okay. And I'm probably missing a couple of braces somewhere. Let's see. No, that's not right. Okay. So this is one. And this is two. And then I'm closing this one. And I'm closing that one. And the action is done. Well, I guess let's just build it. What? What's that? Open bracket, open bracket. This one fills the UI alert action. This closes the UI alert action. Oh, no, no, no. The initializer returns, no. The error makes no sense. It's ‑‑ let me just ‑‑ this is exactly why I already have the whole thing filled in. So here's the ‑‑ here's the view ‑‑ oh, I didn't wrap it. Well, yeah. Actually, it does make sense because it might fail if the URL is malformed. Good catch. Okay. Yeah, okay. Anyway, the rest of it is pretty much the same. So let's run this little application. It's a really rudimentary table view, basically. So this is the simulator. And by flowers and run this demo or do you soon ‑‑ let me create a new task here. Move on, add ‑‑ we have that as well. And I can snooze ‑‑ I can snooze them somehow. Maybe I forgot to add the code to actually snooze them. But I can delete them. That works. Anyway, very well. We have this little iOS application that's using Swift from all directions. And next thing I want to talk about, which I want to actually show you a demo of, but I do want to just give you a brief look of what it feels like, is adding Objective C code to a Swift application. So let me just walk you through the experience in Xcode itself. So say I want to create a new file in that project. And the file I want is an Objective C class. There is a template for this, actually, somewhere or other. Let's create an Objective C file. I'm going to call it just, you know, obj class.m. Next, I'm going to tell Xcode where to put it. And then here's what I wanted to show you here, essentially. You get prompted to create an Objective C bridging header. Xcode says by adding an Objective C file to this previously Swift only project, you will create a mixed target. And would you like Xcode to make it possible for both languages to talk to each other inside the same project? So obviously, if you have, say, a framework and you want to access it from your application, they don't have to be in the same language. But within the same project, this is pretty impressive. And it's not something you often see when interrupting between languages. And so if I do hit yes, what basically happens is that Xcode creates for me this file over here called ndc tasks bridging header.h. And here I import, I include any header files which contain declarations I want accessible to Swift. So this direction is explicit. I have to tell my compiler which Objective C classes I want to make visible to Swift. But that's the only thing I have to do. So I just put import statements in here for my Objective C classes and they are available to Swift. There is an automatic mapping layer which maps everything. In the other direction, it's even easier. If you write a Swift class, it is automatically by default visible to your Objective C code. So it's really seamless to make this bidirectional interrupt between Objective C and Swift in the same project. And again, I wish we had a little more time to expand on this, but I'll just leave it at that for now. So just going back to the slides, there's a couple of final points I want to make before I leave some time for questions as well. So first of all, the whole interrupt story which I was just hinting at and showing you an Xcode, there's two directions, essentially like I said, Swift code can access Objective C code through those generated header files, the bridging headers, and Objective C code can access Swift classes automatically just by magic that the compiler provides. Last thing I want to talk about is the Swift 2.0 beta. And this was announced just at WWDC 2015 which was a few weeks ago. And Apple is taking Swift to a slightly different level than previously. There's been a few minor releases since last June, since June 2014, but this is going to be a major one which is probably due, you know, this fall or so, maybe along with the new iOS and new sex release. And the major announcement about Swift 2.0 is that it's going to be open source. The compiler itself and the libraries, the Swift runtime, the Swift libraries are going to be open sourced with a permissive license that you can actually contribute to and reuse. And there will be a Linux port for Swift. And because the Swift compiler is based on LLVM, it's probably going to be fairly easy to port it to other platforms as well. So if you want to use Swift on Windows, for example, that's definitely going to be possible at some point. Now by making this step, not the open sourcing step, the porting to Linux step, Apple is saying that Swift isn't just a language for building iOS applications and OSX applications. From Apple's perspective, Swift is a systems programming language. You can use it to build anything. You can use it to build operating systems for all day care. And again, it started as a totally proprietary thing that Apple built as they always do, you know, in a cavern somewhere, floor minus 33 in California. But it ends up as an open source project that will actually be able to use freely and possibly port to other platforms, creating cross-platform apps that compile down to native code. No performance, no performance hit, no runtime, no translation layer. There are also some pretty considerable language features in Swift 2.0. Notably, there's error handling support, exception handling essentially with a few statements designed for exception handling. There's something called defer, which means you can, it's kind of like C++ destructors. You can declare a piece of code to run at the end of the scope. And this helps with, it's kind of like tri-finally in other languages. There's a feature called protocol extensions, which means basically you can take a class that conforms to an interface and extend the interface. So basically adding extensions to all classes that support a particular interface. And Apple is also working, and this is really a crazy proposition. Apple is working on changing Objective C so that it is more friendly to Swift code. So Apple is adding to Objective C, for example, generics support. To Objective C, which didn't have generics since 1983, when it was first, first announced. And this is only for making Swift code more readable, comfortable when working with Objective C APIs. So that, again, instead of any object, you'd get specific types. Similarly, Apple is adding nullability annotations to Objective C so that methods can specify if they return a nullable or non-nullable entity. Again, just to make these things more consumable from Swift. So I think Apple is indirectly making it pretty clear that it considers Swift the future of mobile app development for iOS, of app development for OS X, and also probably of app development in general from Apple's perspective anyway. And of course, needless to say, there's been many, many apps submitted to the App Store using Swift in the past year, and I expect these numbers to grow. So this is great. We have about 13 minutes for questions. I'll be very happy to take them. Another thing I was asked to remind you of is that you should vote when going out. The voting thingies over there, just vote. It's extremely important for me and for the conference as well to know how this went. If you have any extra questions later which you don't get a chance to ask right now, then please be in touch on Twitter or try to catch me later after my second talk today. So we're going to have some time for questions. I think they have mics somewhere over here, or I can just repeat questions if you'd like. And in any case, I really appreciate you coming, and I hope you enjoy the rest of NBC. So thank you very, very much. So, yeah. Thank you. Questions, please. Yes? Okay, yes. So you're not asking a question. You're basically adding a vital piece of information. In the next version of OSX, Apple is making a Swift available for as part of the operating system so you can start writing scripts, for example, such as build scripts in Swift. And indeed, Swift, because it doesn't really require any structure from your application, is really suitable for scripting tasks as well. For example, print hello world is a valid Swift application. You don't need main methods or classes or all that fluff around. And it's really pretty suitable for scripts. That's a great comment. Yep. Yes? Okay, so the question is if there's support for two-way data binding. Like you're probably coming from Angular or WPF or Xamela. Well, this is not a Swift question. It's actually a Cocoa and Cocoa Touch question, which are the frameworks used for UI development. Currently, there is no two-way binding support built in. There are some frameworks that are trying to make this a little easier. But built in, you do not have bidirectional binding support for primitive variables. And so, you know, all the sample code you see in any case would bind to a UI object, like a label, and then ask that label what the text is. So, you know, the way we used to do it in the 1990s. That's not a Swift thing, though, unfortunately. Okay. I bet if we wait long enough, someone will have a question eventually. It always works this way. Yes, yes. But you'll have to raise your voice, like really raise it. I can hear you. I'm sorry. Are there problems with switching? Obvious performance gains. Obvious performance gains. Well, theoretically speaking, yes, because the Swift compiler, as of generosity, type safety, non-nullability, and other traits of the Swift language, the Swift compiler has access to more information than the Objective-C compiler. On the other hand, the Swift compiler is a tad a little bit newer than the Objective-C compiler. And so, you can absolutely find on Stack Overflow these pathological cases where someone goes and implements a sort algorithm in Swift and in Objective-C, and it's 28 times slower, and that means Swift sucks and there's no hope. There is a switch that you can turn on in the Swift compiler, which essentially includes unsafe optimizations. For example, around accessing arrays. So you can go outside the bounds of arrays, which adds performance at the expense of safety. So you can choose to go that route. But looking forward, absolutely, yes. I mean, the Swift compiler from a compiler perspective has more information, and so it is capable of producing higher quality code. I'd say for, I mean, I obviously haven't ported, like, you know, every single iOS application to Swift, but it's, I find it unlikely that you'd hit, like, a serious performance issue not in a benchmark. Okay. Just remember there's projectors, and so I can just barely see silhouettes, like, you know, ghosts in the audience. So if you have a, if you still have a question that try to make it obvious, oh, yeah, okay. Can you explain what you did with the explanation or the wrapping? Yeah. So this probably is going to be the last thing we do, but yes. So basically, where is that other project here? The, can you switch back the screen? Thank you. Right. So we had this call here to open URL, and I'm not connected to the Internet, but open URL is a method that takes a non-nullable URL. You have to give it a real URL, it doesn't accept null. Now NSURL, what I'm doing here is basically constructing an object of type NSURL. The NSURL constructor that we're calling here, which takes a string and, you know, converts it to a URL, that constructor might fail by returning null. This particular constructor might be other constructors which can't fail, but this constructor is designated to return a nullable NSURL. So the constructor returns a nullable thing, and the open URL method takes a non-nullable thing. And this is actually a good example of how the type system protects you. So in Objective C, you would call open URL if NSURL, if the NSURL constructor returned null. Now here, I have to tell the compiler my intent. I can either test, you know, construct an NSURL object, take this thing out, and say if let URL equal this whole thing, then open that URL. So I can either be explicit about my test, or, and that's the thing I did in this other project over here, or I could use the unwrapping syntax. And this tells the compiler I know what I'm doing. So I'm guaranteeing it's not going to be null, and so this converts the type of this expression from a nullable expression to a non-nullable expression, and if that thing ends up null at runtime, it will crash. But since, you know, I see the shape of the URL, I'm just assuming it's going to be okay. So either way, you have both ways, right? You can unwrap by telling the compiler I know what I'm doing, or you can test explicitly. So that's actually a good illustration of the whole optionality thing. Yeah. How is it to work with REST services? How, how what? How easy it is to work with REST services? How easy it is to work with REST services? Again, unfortunately, a question not about Swift, but about the, the whole iOS ecosystem. It is pretty easy. There's some really great libraries. Apple has a really nice library called NSURL Session, which is pretty easy to use, but there's great, there's other great framers for this as well. Well, if anyone has any extra questions, would like to discuss with a little more, again, please feel free to approach and ask. And I have another talk on dotnet application performance actually, if you'd like to come, it's going to be in room three in 25 minutes. So thank you again for coming. Enjoy the rest of NDC. Thanks. And don't forget to vote.
 Alright. Hello everyone. Thank you for coming and I hope you're enjoying NDC so far. I've  got to say I've been to a lot of conferences but never did I have a stage suspended between  heaven and earth. You just got to look, I mean, it's not quite stable this whole construction.  Just look at my water bottle and I hope I don't fall anyway. So the other thing on behalf  of all speakers, you know, in this particular slot after lunch, I have just one piece of  feedback for NDC organizers. The food is way too good and there's way too much of it.  And so I hope you'll be able to stay awake for this talk on Swift. If you have any questions  throughout then please do raise your hand or shout out and I'll try to make this interactive  and then at the end I'm going to, we're probably going to have some time for questions. I do  have another talk back to back 20 minutes later so if you don't catch me immediately  after this one please feel free to stay on touch on Twitter otherwise just meet me and  I'll be happy to talk. So how many of you, just to get a general feeling, how many of  you are iOS developers? Okay, so not a whole lot but there are some. And how many of you  are using Objective C today? Maybe Billy Mac apps, iOS, well everything, okay. So basically  I wrote down in the abstract that there is no prerequisite here to know iOS or Objective  C. This is just an introduction talk to Swift and it's actually been pretty successful,  this idea of mine to do a general introduction talk to Swift because Apple has just announced  a few weeks ago that they're planning to make Swift a programming language for things other  than just iOS and OS X. Generally it's a pretty good systems programming language which can  be pretty successful in spaces where people are using Rust and Go and C++ of course and  Objective C. So here's a graph, here's a picture and that's some pretty biased statistics  based, it's language popularity based on Stack Overflow searches and GitHub repos and a bunch  of other informal sources like that. And so what would you say happened to Objective  C popularity around 2009, the end of 2008, what happened? What? The iPhone and more specifically  the release of the App Store, right? If we just had an iPhone but we couldn't build apps  for the iPhone, I don't think Objective C would have been that popular outside of Apple.  But in late 2008, Apple released, well announced the Apple Store, App Store and people were  able to submit applications to run on iPhones and it's been pretty popular since and what  happened, what happened to Objective C popularity somewhere around this peak in 2014? Swift  happened, yeah. And again this is an informal survey of developers but it does look like  iOS developers and Mac developers are slowly moving to Swift, actually not so slowly, it's  just been a year since Swift has been released and it's gaining really nice popularity. It's  still not one of the top ten programming languages but it is extremely popular and I'd like to  show you why in this talk. So basically what we're going to do, I'm going to give you a  couple of reasons why Objective C is a horrible, horrible language and then I'll give you a  few reasons why Swift is an elegant, beautiful, incredibly concise language to use and then  I'll build a little app with you, just you know, completing pieces of code here and there  to show you what Swift is capable of and then we'll have some time for reflection questions,  future directions, stuff like that. By the way, I'm not affiliated with Apple in any  way so all the stuff I'm going to say is just based on public information. So here's, you  know, exhibit A of how Objective C is a horrible, horrible programming language. If you, for  the Objective C developers in the audience, this is going to look familiar but otherwise,  I just want to point out this is a simple method that takes an array and a string and  it tries to see if that array contains that string and it's supposed to return the index  of the object of that string in the array and it turns out if you pass in a string which  is null, then you get back a value called NSNotFound which is basically the maximum unsigned  integer value and that says no. There is no null in that array because arrays cannot contain  nulls. That's the way the Objective C runtime works but if you pass in a null array, then  the Objective C behavior is that you get zero as the result of this function and there are  some good reasons for this but for me it's just another proof that Objective C is a horrible,  horrible programming language. Here's another example, exhibit B. So here you can see on  the left hand side the variable type is NSMutableArray. On the right hand side, the type is NSArray  and actually NSMutableArray is a subclass of NSArray but this code still compiles. There  is a sort of a downcast there and the interesting thing, the cast succeeds at runtime. It is  only after the cast that when you try to use an NSArray as if it were mutable, so for example  if you try to add an object to an array which isn't mutable, then you get an exception at  runtime. What are you talking about? Of course there is no selector called add object on  the NSArray class. What are you talking about? Exhibit C. For those of you who are still  unconvinced, here we have an NSMutableArray. This is a mutable array. That's all right.  And then it doesn't really quite have a type for the elements. So I can add a string, I  can add a number. Okay, fine. That's fine. Many languages are dynamic with types, you  know, kind of loose with types but then you can take out that int and put it in a variable  of type NSString. That compiles just fine as well and that line runs as well. And you  can even take that string which isn't a string and print it out and it prints 17. That works  all right. It's only when you try to treat it as a string by for example calling a method  which only strings have, then you get a crash at runtime. I bow my head in shame at this  point. I've been writing some Objective C for a while for several years and this is not  the kind of stuff that makes you proud as an Objective C developer, I think. Right? Objective  C guys and girls, right? Okay. So enter Swift and Swift has been announced in just June  2014 and one of the, I mean, they could pretty much announce anything, I think. They could  say this is, you know, based on Haskell. This is based on Lisp. This is based on Fortran.  And still people would be pretty excited because it isn't Objective C, you know? And that's  pretty much enough for us Objective C developers. Give us anything that's better than Objective  C and we're going to be happy with the result. But I contend that Swift is much better than  Objective C and it's actually a pretty decent language to learn even as a first programming  language. It's modern, it's elegant, so there's some pieces of syntax borrowed from here and  from there which make it a really nice little language, elegant in a, you know, language  formal kind of way. It's type safe, so there's much less opportunity for all those ugly downcasts  succeeding and then failing at runtime. It's a generic language, so there's built-in support  for generic types, collections, stuff like that, you know, arrays. It's a functional  programming language with very strong roots and functional programming languages like,  well, you know, Haskell, Schem, Lisp, whatever. So there's support for pattern matching, Algebraic  data types, a bunch of other nice function language features. Another pretty important  property which is shared with Objective C is that Swift compiles to native code. So there  is no virtual machine, there is no byte code, there is no interpretation, there is no, you  know, VM at runtime that does stuff with your code. It's compiled down to machine instructions,  so you take Swift code, you compile it down to ARM, ARM64 and potentially in the, in  the very near future to x86 on other operating systems as well. It also, it already supports  x86 on the Mac and it will support Linux as well in the future. So it is a native programming  language that can give you the performance of a native compiled language like C, C++,  Objective C and so forth. But at the same time, it can't lose, you know, support for  Objective C and so you can take Swift code and call Objective C methods and you can write  a Swift class and call it from Objective C and you can do it from the same project.  So you have a Swift file and an M file, Objective C code and they can call each other in the  same project. And finally, that last point means all the iOS APIs, all the Mac APIs are  accessible from Swift. And if, even if there is, you know, some low level C style API that  you really have to call and you can't directly call it from Swift, you can wrap it with an  Objective C layer and then call that Objective C code from Swift. So essentially, you can  build iOS applications from scratch with Swift. You can mix and match, oh man, you can mix  and match Objective C code and Swift code. You can take, you know, an existing library  from GitHub and just use it in your Swift project. You can add Swift classes to your  Objective C project. It all works, it all works by design.  So here are a couple of ways, you know, to get started with Swift and if any of you have  your Macs along, you can just sort of try and experiment a little as well. The first  way I'm going to show you is the Swift REPL. So this is a little command line app called  Swift. You run it and you start typing in Swift code, so 2 plus 2, you know, or hello  world, great. And then, of course, you can define classes and functions. So for example,  I can define a function called add which takes an int, x and int y and returns an int and  here's the function and then I can call the function and it returns a value. So, you know,  a REPL for using, for experimenting with Swift features. Now, here's the cool thing.  Again, Swift can talk to all the iOS and OS X APIs, for example, foundation APIs. So suppose  I want to use the NSDate class. Ooh. Unresolved identifier NSDate. Well, NSDate is part of  a module called foundation. So in the REPL, I can import foundation and then here's an  NSDate and sure enough, we can use a type which is definitely not a Swift class. It's  a type from the foundation module but we can use it just fine and interact with it, of  course. So let x equal NSDate, x, date by adding time interval 1.0 and so I've just  added a second to that date and so on and so forth. So this is one way, you know, to  get your feet wet with Swift. The other is called playgrounds and this is a really nice  X code feature since X code 6 where you can basically, you know, play around, you know,  on a playground with some Swift code of your own. So there's a couple of examples here  for visualizations and added value that playgrounds give you which the REPL doesn't. So the first  couple of lines here, for example, this is a loop which, you know, takes some initial  value and then starts to apply some operations to it. I can visualize the execution of that  loop by just clicking on this little thingy over here and expand it and I can see the  progression of values in the loop. I can see the final value or I can see the succession  of all the values as either a graph or a list. Another example is with colors and there's  similar support for images as well. So if you have a color object, an image object, an  animation, you can see what they look like in your app. And finally, you can do interactive  programming as well. So the code there in the bottom, it creates a button, it gives  the button a background color, it gives the button a frame, it gives the button an opacity,  it sets the button's title and it sets the button's text color. And then it calls a  method for playgrounds only called XCP show view and then here's the button, you know.  And you can make this interactive actually, you can subscribe to events that this button  would raise. Now, this is really, really nice for experimentation when learning a new API.  This is also a great way to create interactive tutorials. So you can give your students,  you can give your fellow developers a nice little playground with a bunch of already  built features and you can tell them, okay, so here you should just write a line of code  to make this example work a little different. So I really like playgrounds for training  and for experimenting with new libraries. So that's just, you know, to give you a general  idea of what Swift looks like and what ways you have of experimenting with it. Now, the  fundamental language principles and obviously we're not going to have time to discuss them  all are the following. Swift makes a really, really strong emphasis on immutability. And  so you have variables which can vary and you have constants which cannot, which are set  and immutable. And there are different keywords for those. You use var for variables and you  use let for constants which you cannot modify. So again, if you're familiar with Objective  C, there's no more NS array and NS mutable array, NS dictionary and NS mutable dictionary,  NS string and NS mutable string. If you have a string, it could be either in a variable  or it could be in a constant. The type is the same type, it's just the variable that matters,  the type of the variable. The other important proposition is optional types and I'll come  back to that a bit later. It has to do with nullability and so Swift does a way with nullability.  Stuff cannot be null unless you explicitly say this variable here may be null and this  is such a strong proposition especially compared to Objective C where everything pretty much  can be null and when something's null, doesn't mean you can't call methods on it and get  nonsensical values back. The other thing is first class handling for functions, for functional  programming concepts like pattern matching, I'll show you a couple of examples and then  of course again the full interrupt with Objective C. Anything pretty much you can do in Objective  C, you can also do in Swift. So this, I have a couple of examples here. I'm not going to  go into depth, it's just designed to show you in general how Swift is really a breath  of fresh air in this whole ecosystem. So on top I have a class, an Objective C header  file actually with a, well the class is called O-complex and it has a couple of properties,  it has an initializer which is like a constructor, it has some methods as well and then on the  bottom you have the Swift version of this, a struct complex with properties and with  functions and with operators and operators actually overloading of operators is a really,  really strong proposition in Swift. It makes, you know, working with strings, it makes working  with integral and floating point types that much easier and you can overload operators  for your own, for your own classes as well. And so even if I didn't put this white line  over here, you'd be able to tell which is old and which is new, right? So there is the  sense of elegance coming out of the Swift code at least for me. Here's another little  example. It's not so much about length, you know, there's almost the same number of lines,  it's about the elegance and so again just look at all the parents which are gone, look  at the, you know, the rectangular braces here which are so typical of Objective C code,  really borrowed from small talk syntax. These are gone, lots of, lots of things are automatic  and just sort of flow from the screen. And finally here's the overloaded operator so  z equals z times z plus c as opposed to z mult by z add to c which is what happens where  you don't have overloaded operators. So again, even if I didn't put this line here, you'd  be able to tell which is old, which is Objective C and which is Swift. So again, I'm not trying  to teach the language here but I do want to show you a couple of representative examples  before I just write a couple of classes and the little iOS application. So here's Exhibit  D which shows you, well, the foundation of Swift's pattern matching around the switch  statement. So the scenario here is that we have the fair class for someone's plane ticket,  you know, and I want to calculate the mileage bonus they're going to get from that particular  flight. So the switch statement can go over strings and that's already something Objective  C cannot do and many other languages can't do either. But then a case statement can include  multiple cases, okay? So f, a, j and c are all business or first class tickets and then  y and b are full fair economy and m and h are discount but it's a high tier discount.  And then I can even do conditional, complex conditional operations so I can assign that  fair class to a temporary variable here and then ask questions of it. So if it has the  r prefix, the whole string, then it's an upgrade ticket and it doesn't deserve any bonus. So  that's a very basic example of Swift's switch syntax. And here's an even more powerful example  which shows you a sum type, an enum, an enum called HTTP response. And enums in Swift,  they have state. It's not just, you know, a couple of integers that vary. So for example  here I have a success, I have a success case for HTTP response which has a body of that,  you know, HTTP response and I have an error case which has a description and a status  code for that error. And then I can pattern match on those in really, really clever, elegant  ways. So assuming HTTP get request returns one of those enums, it can go two ways. It  can go error or success. But even if it was an error, I can do stuff like error, description  and status where the status was greater than or equal 500. And that's an internal server  error as opposed to all the other cases and as opposed to the success case. And in all  these cases you can see that there's pattern matching syntax that deconstructs the enum  and puts it in nice little variables that you can use again. And there's very similar,  there's very similar support for tuples as well. And so in functional programming languages  this would typically be called a sum type and a tuple is essentially a product type.  And in both cases you have this really nice language level support for deconstructing  these algebraic types into their constituent variables. And this is really, really handy  once you get used to it. And so here's, this is probably one of the examples most influenced  by functional programming. Here's another nice feature of Swift, it's designed for extensibility.  So it's really easy to take existing types and add features, add operations, extend them  essentially. And so here's an extension of int. You know, it's not a very practical extension  but it's one that you can actually write. And so here I'm extending the int type to  have a method called repeat. And the repeat method takes a function. This thing over here,  task is a function. And it's a function from ints to void, from int to nothing. And then  what that repeat function does is just call that task as many times as the integer I'm  holding in my hand. So you can do stuff like 3.repeat and pass in a function which will  be invoked for, which will be invoked three times with the values 1, 2 and 3. And so there's  a bunch of syntax on this slide which again shows the conciseness of Swift. First, you  can see the range, the range syntax for loops, right? So you can do x in 0 to self. And you  can see this conciseness here around the closure, the function that's being passed to the repeat  function. There is no argument. That function takes an argument but it isn't there. You  can just use $0 for the first argument and $1 for the second argument and so on. There  is this conciseness in the syntax where you need it or you can spell it out if you really  need this to be explicit. And there's a final exhibit again designed to convince you of  the value of Swift. This is a little playground I used to solve a problem for Project Euler.  Is anyone familiar with Project Euler? It's basically, yeah, okay. It's basically a website  with like a hundred, no, maybe more, several hundred problems ranging from the very simple  like printing numbers which are multiples of five to really, really hard math problems.  And so the second one is really easy. It's basically enumerate all the terms of the  Fibonacci sequence which are smaller than four million. Look for the even ones, the  visible by two, and sum them all up. And so this is a classic thing to do with a playground.  As you experiment with the code, you can really see the execution of it. You can see the progression  of the X's which are part of the sequence itself. You can see the progression of the  sum variable which sums up the even terms. It's really, playgrounds are really designed  for this sort of experimentation. So let me just, before I write a little  app with you, let me just focus on the one thing that maybe makes Swift unique in the  mainstream programming languages, you know, C-sharp, C++, Java, Python, all that lot.  This is a quote from Sir Charles Anthony Richard Hoare from 2009 when he was accepting some  award or other 50 years of really extraordinary computer science work. And he said, I call  it my billion-dollar mistake. It was the invention of the null reference.  And there's a bunch of other texts here where he explains why he thinks it's such a horrible  mistake and why it's a billion-dollar one. But Swift doesn't have nulls by default. And  so here's a tiny little example which shows how this nullness and non-nullability still  works with APIs that produce nulls occasionally. So for the Objective C developers, here's  a method which you might be familiar with, TableView, the query usable cell with identifier.  This is a method used in UI applications on iOS which gives you some object or other that  you're supposed to use, a UI TableView cell. Now, this method is part of the UIKit framework  and it's not a Swift method. So what it returns is not even a proper class. It's not a TableView  cell. It returns something like object, you know, an arbitrary thing which can be anything.  In Swift, the way to express an arbitrary object is using the any object type. But there's  a bonus. That thing you're getting back could be null as well. Not only do you not know  the type, it can also be null altogether. And the way to express that in Swift is by  adding a question mark. So this is an any object question mark, a nullable any object.  It can be any type and it could be null as well. But then you want to test if that arbitrary  weird thing you got back is actually of a specific type and is actually not null. So  you have this really nice as operator and some nice syntax around if statements. So  this line over here says, well, see if that cell variable is actually of type UI TableView  cell and if it's not actually null. If those two statements are true, then put the result  of type UI TableView cell back in a temporary variable called cell. And then if I get into  that if statement, I know for sure that cell is of type UI TableView cell and it isn't  null. And again, the language guarantees that if you don't have a variable designed  to contain nulls, it will not contain nulls. So you have to be explicit about nullability  and in most cases you don't want nullability in the first place. And then inside that little  if statement, there's another example which is now popular in some other languages as  well, optional chaining. Optional chaining on nullable things. So what you can do, what  you can see here is that the text label and detail text label properties of the cell are  actually nullable objects. So these properties might be null. And so to avoid having to test  and then use them, there is this chaining operator, question mark dot. And you have that for member  access expressions, for array access expressions, for method calls. So you can say conditionally  if that property isn't null, then I want to access it. If it is null, just do nothing.  And that's a really handy way of working with existing code which already has nullable stuff  built in. So that's another principle of Swift that you're going to see in your code.  So let me show you a quick example of building a little iOS application with Swift. I already  have the skeleton for the app itself. I didn't want to waste time, you know, creating a new  project and putting UI controls on board. I just want to write a few classes, just show  you a bit of Swift syntax. So the app itself is going to be extremely original. It's going  to be a to-do app, right, with to-dos, tasks in this case. And the first thing we're going  to need is a class task. And that class is going to need a text property with the title  for that to-do item and a due date. So I'm going to make the text property a string and  it's going to be immutable, a read-only property. On the other hand, the due date is something  a user can change, so I'm going to make it a var. And that's a read-write property. Next,  we're going to need an initializer which assigns those values. Particularly, I already have  an error because my class doesn't have an initializer. And that tiny, teeny thing over  here says the stored property text without initial value prevents synthesized initializers.  In other words, you have a read-only property and you're not assigning to it in any of your  initializers, so that's invalid. Okay, so we need an initializer. And that initializer  is going to take a text which is a string and due date which is an NSDate and assign  them, so self-due date is equal to due date. And I might also make an initializer, a convenience  initializer which takes only the text and calls the other initializer. So the text is  going to be text and the due date is going to be a new NSDate. Right. What does it want  from me? Expected separator. What? Okay, come back to that. Next, we need is overdue, a Boolean  property which says if the task is overdue. And that's going to be a computed property  which is why I have it here even. So is overdue is a Boolean property. And what I'm going  to do here is just check if the due date is before or after the current date. So NSDate  is the current date and I'm going to do, what's the method called? I forget. Does anyone remember  what the, there's a method that checks if, okay, time interval since date is one way  of doing it. So time interval since date, due date returns, well, you know, the time  interval since that date. So if NSDate, time interval since date is positive, then we are  not overdue. Right. So actually less than zero. Right. Am I right in my calculations?  We are overdue if the interval since the due date is negative. I think so. In any case,  finally we have a snooze method which is supposed to snooze that task for a while. So here's  snooze. And in snooze I'm going to say due date equals due date, date by adding time  interval. And I already have a handy constant for it seconds in day, task that seconds in  day. So whenever the snooze method is called, we just snooze that task for 24 hours. Okay,  next up is a nice little extension. So, so far I just had the task class which is like  my model class. But then I have an extension of it which I intend to use for the UI only.  So this is my way of separating these concerns. I have the model class which is pretty clean  and I have an extension for display purposes. So here I want a due date string computed  property. Due date string of type string. And what I want to do over here is test. So  if I'm overdue, I'm going to return past due. This is again for display purposes only.  And then I'm going to switch on the due date. Actually I'm going to switch on the due date,  due date, time interval since date and a state. And so I want to see how much time exactly  I have until that, until that moment arrives. And actually the other way around, NSDate,  time interval since date due date. Okay, so case 0 to anything less than an hour, I'm  going to say very soon. Okay, and case an hour to a day, I'm going to say soon. And  in all other cases, I'm just going to return a date. So I'm going to use a date formatter.  And this again goes to illustrate that you can just use whatever APIs are available to  you. You know, it's just another language. It doesn't mean the framework you have to  use changes in any way. So I have a time style, non and a date style, medium. This is another  interesting example. This is actually an enum. And so officially the type of that date style,  the type of that time style and that date style is NSDate formatter style. And so it's  not actually called non. It's called no style. But the type inference is powerful enough  to know that if it's an NSDate formatter style, then I can just say dot no style. And similarly  the date style will be medium style. And then I'm just going to return for matter, string  from date due date. And just display the due date in my UI. Okay, so we have this extension  built in. Last piece of code I want to write, which is really strongly integrated with the  UI, is in my view controller over here. And so what I have over here is a place holder  for a welcome message. And again, this is just to show you that you can really, really  easily use Objective-C APIs, stuff from the framework in your Swift code. So here I'm  going to use an alert, an UI alert controller for displaying a welcome message. UI alert  controller with a title welcome, a message welcome to the tasks, to the NDC tasks app,  and preferred style alert. And again, I'm going to remove the enum name from here. And  then eventually I'm going to present that view controller using present view controller,  oops, alert, animated true, completion nil. And I'm going to add a couple of buttons to  that little alert view controller. So I'm going to do add action, UI alert action. These  are just buttons. And so UI alert action has a title, which is going to be, let's say dismiss.  Style, UI alert action style default. And the handler is going to be nil for this one.  And I'm going to add another action, another UI alert action. And this one is going to  be more info, UI alert action style default as well. But this one is going to have a handler.  And this is just to show that you have closures in Swift as well. So this thing over here  is a method that gets invoked when that action is clicked, when the user clicks more info.  And what I'm going to do here is UI application, shared application, open URL, NSURL with the  string, and the C osla.com. Okay. And I'm probably missing a couple of braces somewhere. Let's  see. No, that's not right. Okay. So this is one. And this is two. And then I'm closing  this one. And I'm closing that one. And the action is done. Well, I guess let's just build  it. What? What's that? Open bracket, open bracket. This one fills the UI alert action.  This closes the UI alert action. Oh, no, no, no. The initializer returns, no. The error  makes no sense. It's ‑‑ let me just ‑‑ this is exactly why I already have the whole  thing filled in. So here's the ‑‑ here's the view ‑‑ oh, I didn't wrap it. Well,  yeah. Actually, it does make sense because it might fail if the URL is malformed. Good  catch. Okay. Yeah, okay. Anyway, the rest of it is pretty much the same. So let's run  this little application. It's a really rudimentary table view, basically. So this is the simulator.  And by flowers and run this demo or do you soon ‑‑ let me create a new task here.  Move on, add ‑‑ we have that as well. And I can snooze ‑‑ I can snooze them somehow.  Maybe I forgot to add the code to actually snooze them. But I can delete them. That  works. Anyway, very well. We have this little iOS application that's using Swift from all  directions. And next thing I want to talk about, which I want to actually show you a  demo of, but I do want to just give you a brief look of what it feels like, is adding  Objective C code to a Swift application. So let me just walk you through the experience  in Xcode itself. So say I want to create a new file in that project. And the file I want  is an Objective C class. There is a template for this, actually, somewhere or other. Let's  create an Objective C file. I'm going to call it just, you know, obj class.m. Next, I'm  going to tell Xcode where to put it. And then here's what I wanted to show you here, essentially.  You get prompted to create an Objective C bridging header. Xcode says by adding an Objective  C file to this previously Swift only project, you will create a mixed target. And would  you like Xcode to make it possible for both languages to talk to each other inside the  same project? So obviously, if you have, say, a framework and you want to access it from  your application, they don't have to be in the same language. But within the same project,  this is pretty impressive. And it's not something you often see when interrupting between languages.  And so if I do hit yes, what basically happens is that Xcode creates for me this file over  here called ndc tasks bridging header.h. And here I import, I include any header files  which contain declarations I want accessible to Swift. So this direction is explicit. I  have to tell my compiler which Objective C classes I want to make visible to Swift. But  that's the only thing I have to do. So I just put import statements in here for my Objective  C classes and they are available to Swift. There is an automatic mapping layer which  maps everything. In the other direction, it's even easier. If you write a Swift class, it  is automatically by default visible to your Objective C code. So it's really seamless  to make this bidirectional interrupt between Objective C and Swift in the same project.  And again, I wish we had a little more time to expand on this, but I'll just leave it  at that for now. So just going back to the slides, there's a couple of final points I  want to make before I leave some time for questions as well. So first of all, the whole  interrupt story which I was just hinting at and showing you an Xcode, there's two directions,  essentially like I said, Swift code can access Objective C code through those generated header  files, the bridging headers, and Objective C code can access Swift classes automatically  just by magic that the compiler provides. Last thing I want to talk about is the Swift  2.0 beta. And this was announced just at WWDC 2015 which was a few weeks ago. And Apple  is taking Swift to a slightly different level than previously. There's been a few minor  releases since last June, since June 2014, but this is going to be a major one which  is probably due, you know, this fall or so, maybe along with the new iOS and new sex release.  And the major announcement about Swift 2.0 is that it's going to be open source. The  compiler itself and the libraries, the Swift runtime, the Swift libraries are going to  be open sourced with a permissive license that you can actually contribute to and reuse.  And there will be a Linux port for Swift. And because the Swift compiler is based on  LLVM, it's probably going to be fairly easy to port it to other platforms as well. So  if you want to use Swift on Windows, for example, that's definitely going to be possible at  some point. Now by making this step, not the open sourcing step, the porting to Linux step,  Apple is saying that Swift isn't just a language for building iOS applications and OSX applications.  From Apple's perspective, Swift is a systems programming language. You can use it to build  anything. You can use it to build operating systems for all day care. And again, it started  as a totally proprietary thing that Apple built as they always do, you know, in a cavern  somewhere, floor minus 33 in California. But it ends up as an open source project that  will actually be able to use freely and possibly port to other platforms, creating cross-platform  apps that compile down to native code. No performance, no performance hit, no runtime,  no translation layer. There are also some pretty considerable language features in Swift  2.0. Notably, there's error handling support, exception handling essentially with a few  statements designed for exception handling. There's something called defer, which means  you can, it's kind of like C++ destructors. You can declare a piece of code to run at  the end of the scope. And this helps with, it's kind of like tri-finally in other languages.  There's a feature called protocol extensions, which means basically you can take a class  that conforms to an interface and extend the interface. So basically adding extensions  to all classes that support a particular interface. And Apple is also working, and this is really  a crazy proposition. Apple is working on changing Objective C so that it is more friendly to  Swift code. So Apple is adding to Objective C, for example, generics support. To Objective  C, which didn't have generics since 1983, when it was first, first announced. And this  is only for making Swift code more readable, comfortable when working with Objective C  APIs. So that, again, instead of any object, you'd get specific types. Similarly, Apple  is adding nullability annotations to Objective C so that methods can specify if they return  a nullable or non-nullable entity. Again, just to make these things more consumable  from Swift. So I think Apple is indirectly making it pretty clear that it considers Swift  the future of mobile app development for iOS, of app development for OS X, and also probably  of app development in general from Apple's perspective anyway. And of course, needless  to say, there's been many, many apps submitted to the App Store using Swift in the past year,  and I expect these numbers to grow. So this is great. We have about 13 minutes for questions.  I'll be very happy to take them. Another thing I was asked to remind you of is that  you should vote when going out. The voting thingies over there, just vote. It's extremely  important for me and for the conference as well to know how this went. If you have any  extra questions later which you don't get a chance to ask right now, then please be  in touch on Twitter or try to catch me later after my second talk today. So we're going  to have some time for questions. I think they have mics somewhere over here, or I can just  repeat questions if you'd like. And in any case, I really appreciate you coming, and I  hope you enjoy the rest of NBC. So thank you very, very much. So, yeah. Thank you. Questions,  please. Yes?  Okay, yes. So you're not asking a question. You're basically adding a vital piece of information.  In the next version of OSX, Apple is making a Swift available for as part of the operating  system so you can start writing scripts, for example, such as build scripts in Swift. And  indeed, Swift, because it doesn't really require any structure from your application, is really  suitable for scripting tasks as well. For example, print hello world is a valid Swift  application. You don't need main methods or classes or all that fluff around. And it's  really pretty suitable for scripts. That's a great comment. Yep. Yes?  Okay, so the question is if there's support for two-way data binding. Like you're probably  coming from Angular or WPF or Xamela. Well, this is not a Swift question. It's actually  a Cocoa and Cocoa Touch question, which are the frameworks used for UI development. Currently,  there is no two-way binding support built in. There are some frameworks that are trying  to make this a little easier. But built in, you do not have bidirectional binding support  for primitive variables. And so, you know, all the sample code you see in any case would  bind to a UI object, like a label, and then ask that label what the text is. So, you know,  the way we used to do it in the 1990s. That's not a Swift thing, though, unfortunately.  Okay. I bet if we wait long enough, someone will have a question eventually. It always  works this way. Yes, yes. But you'll have to raise your voice, like really raise it.  I can hear you. I'm sorry. Are there problems with switching? Obvious performance gains.  Obvious performance gains. Well, theoretically speaking, yes, because the Swift compiler,  as of generosity, type safety, non-nullability, and other traits of the Swift language, the  Swift compiler has access to more information than the Objective-C compiler. On the other  hand, the Swift compiler is a tad a little bit newer than the Objective-C compiler. And  so, you can absolutely find on Stack Overflow these pathological cases where someone goes  and implements a sort algorithm in Swift and in Objective-C, and it's 28 times slower,  and that means Swift sucks and there's no hope. There is a switch that you can turn  on in the Swift compiler, which essentially includes unsafe optimizations. For example,  around accessing arrays. So you can go outside the bounds of arrays, which adds performance  at the expense of safety. So you can choose to go that route. But looking forward, absolutely,  yes. I mean, the Swift compiler from a compiler perspective has more information, and so it  is capable of producing higher quality code. I'd say for, I mean, I obviously haven't  ported, like, you know, every single iOS application to Swift, but it's, I find it unlikely that  you'd hit, like, a serious performance issue not in a benchmark. Okay. Just remember there's  projectors, and so I can just barely see silhouettes, like, you know, ghosts in the audience.  So if you have a, if you still have a question that try to make it obvious, oh, yeah, okay.  Can you explain what you did with the explanation or the wrapping?  Yeah. So this probably is going to be the last thing we do, but yes. So basically, where  is that other project here? The, can you switch back the screen? Thank you. Right. So we had  this call here to open URL, and I'm not connected to the Internet, but open URL is a method  that takes a non-nullable URL. You have to give it a real URL, it doesn't accept null.  Now NSURL, what I'm doing here is basically constructing an object of type NSURL. The  NSURL constructor that we're calling here, which takes a string and, you know, converts  it to a URL, that constructor might fail by returning null. This particular constructor  might be other constructors which can't fail, but this constructor is designated to return  a nullable NSURL. So the constructor returns a nullable thing, and the open URL method  takes a non-nullable thing. And this is actually a good example of how the type system protects  you. So in Objective C, you would call open URL if NSURL, if the NSURL constructor returned  null. Now here, I have to tell the compiler my intent. I can either test, you know, construct  an NSURL object, take this thing out, and say if let URL equal this whole thing, then  open that URL. So I can either be explicit about my test, or, and that's the thing I  did in this other project over here, or I could use the unwrapping syntax. And this  tells the compiler I know what I'm doing. So I'm guaranteeing it's not going to be null,  and so this converts the type of this expression from a nullable expression to a non-nullable  expression, and if that thing ends up null at runtime, it will crash. But since, you  know, I see the shape of the URL, I'm just assuming it's going to be okay. So either  way, you have both ways, right? You can unwrap by telling the compiler I know what I'm doing,  or you can test explicitly. So that's actually a good illustration of the whole optionality  thing. Yeah.  How is it to work with REST services?  How, how what?  How easy it is to work with REST services?  How easy it is to work with REST services? Again, unfortunately, a question not about  Swift, but about the, the whole iOS ecosystem. It is pretty easy. There's some really great  libraries. Apple has a really nice library called NSURL Session, which is pretty easy  to use, but there's great, there's other great framers for this as well.  Well, if anyone has any extra questions, would like to discuss with a little more, again,  please feel free to approach and ask. And I have another talk on dotnet application performance  actually, if you'd like to come, it's going to be in room three in 25 minutes. So thank  you again for coming. Enjoy the rest of NDC. Thanks.  And don't forget to vote.
Swift__Apple___s_New_Programming_Language_for_iOS_and_OS_X_-_Sasha_Goldshtein_0_3119.png Swift__Apple___s_New_Programming_Language_for_iOS_and_OS_X_-_Sasha_Goldshtein_3120_6035.png Swift__Apple___s_New_Programming_Language_for_iOS_and_OS_X_-_Sasha_Goldshtein_6036_10295.png Swift__Apple___s_New_Programming_Language_for_iOS_and_OS_X_-_Sasha_Goldshtein_10296_15167.png Swift__Apple___s_New_Programming_Language_for_iOS_and_OS_X_-_Sasha_Goldshtein_15168_15515.png Swift__Apple___s_New_Programming_Language_for_iOS_and_OS_X_-_Sasha_Goldshtein_15516_17051.png Swift__Apple___s_New_Programming_Language_for_iOS_and_OS_X_-_Sasha_Goldshtein_17052_17375.png Swift__Apple___s_New_Programming_Language_for_iOS_and_OS_X_-_Sasha_Goldshtein_17376_17891.png Swift__Apple___s_New_Programming_Language_for_iOS_and_OS_X_-_Sasha_Goldshtein_17892_19883.png Swift__Apple___s_New_Programming_Language_for_iOS_and_OS_X_-_Sasha_Goldshtein_19884_19967.png Swift__Apple___s_New_Programming_Language_for_iOS_and_OS_X_-_Sasha_Goldshtein_19968_20819.png Swift__Apple___s_New_Programming_Language_for_iOS_and_OS_X_-_Sasha_Goldshtein_20820_20879.png Swift__Apple___s_New_Programming_Language_for_iOS_and_OS_X_-_Sasha_Goldshtein_20880_20927.png Swift__Apple___s_New_Programming_Language_for_iOS_and_OS_X_-_Sasha_Goldshtein_20928_23303.png Swift__Apple___s_New_Programming_Language_for_iOS_and_OS_X_-_Sasha_Goldshtein_23304_26651.png Swift__Apple___s_New_Programming_Language_for_iOS_and_OS_X_-_Sasha_Goldshtein_26652_28379.png Swift__Apple___s_New_Programming_Language_for_iOS_and_OS_X_-_Sasha_Goldshtein_28380_30755.png Swift__Apple___s_New_Programming_Language_for_iOS_and_OS_X_-_Sasha_Goldshtein_30756_33155.png Swift__Apple___s_New_Programming_Language_for_iOS_and_OS_X_-_Sasha_Goldshtein_33156_34679.png Swift__Apple___s_New_Programming_Language_for_iOS_and_OS_X_-_Sasha_Goldshtein_34680_35783.png Swift__Apple___s_New_Programming_Language_for_iOS_and_OS_X_-_Sasha_Goldshtein_35784_40607.png Swift__Apple___s_New_Programming_Language_for_iOS_and_OS_X_-_Sasha_Goldshtein_40608_40667.png Swift__Apple___s_New_Programming_Language_for_iOS_and_OS_X_-_Sasha_Goldshtein_40668_40727.png Swift__Apple___s_New_Programming_Language_for_iOS_and_OS_X_-_Sasha_Goldshtein_40728_42311.png Swift__Apple___s_New_Programming_Language_for_iOS_and_OS_X_-_Sasha_Goldshtein_42312_42359.png Swift__Apple___s_New_Programming_Language_for_iOS_and_OS_X_-_Sasha_Goldshtein_42360_42491.png Swift__Apple___s_New_Programming_Language_for_iOS_and_OS_X_-_Sasha_Goldshtein_42492_42947.png Swift__Apple___s_New_Programming_Language_for_iOS_and_OS_X_-_Sasha_Goldshtein_42948_43571.png Swift__Apple___s_New_Programming_Language_for_iOS_and_OS_X_-_Sasha_Goldshtein_43572_43967.png Swift__Apple___s_New_Programming_Language_for_iOS_and_OS_X_-_Sasha_Goldshtein_43968_44171.png Swift__Apple___s_New_Programming_Language_for_iOS_and_OS_X_-_Sasha_Goldshtein_44172_45947.png Swift__Apple___s_New_Programming_Language_for_iOS_and_OS_X_-_Sasha_Goldshtein_45948_46055.png Swift__Apple___s_New_Programming_Language_for_iOS_and_OS_X_-_Sasha_Goldshtein_46056_46559.png Swift__Apple___s_New_Programming_Language_for_iOS_and_OS_X_-_Sasha_Goldshtein_46560_50687.png Swift__Apple___s_New_Programming_Language_for_iOS_and_OS_X_-_Sasha_Goldshtein_50688_55427.png Swift__Apple___s_New_Programming_Language_for_iOS_and_OS_X_-_Sasha_Goldshtein_55428_55475.png Swift__Apple___s_New_Programming_Language_for_iOS_and_OS_X_-_Sasha_Goldshtein_55476_55583.png Swift__Apple___s_New_Programming_Language_for_iOS_and_OS_X_-_Sasha_Goldshtein_55584_56111.png Swift__Apple___s_New_Programming_Language_for_iOS_and_OS_X_-_Sasha_Goldshtein_56112_56951.png Swift__Apple___s_New_Programming_Language_for_iOS_and_OS_X_-_Sasha_Goldshtein_56952_57491.png Swift__Apple___s_New_Programming_Language_for_iOS_and_OS_X_-_Sasha_Goldshtein_57492_57599.png Swift__Apple___s_New_Programming_Language_for_iOS_and_OS_X_-_Sasha_Goldshtein_57600_57791.png Swift__Apple___s_New_Programming_Language_for_iOS_and_OS_X_-_Sasha_Goldshtein_57792_57899.png Swift__Apple___s_New_Programming_Language_for_iOS_and_OS_X_-_Sasha_Goldshtein_57900_58127.png Swift__Apple___s_New_Programming_Language_for_iOS_and_OS_X_-_Sasha_Goldshtein_58128_58175.png Swift__Apple___s_New_Programming_Language_for_iOS_and_OS_X_-_Sasha_Goldshtein_58176_58223.png Swift__Apple___s_New_Programming_Language_for_iOS_and_OS_X_-_Sasha_Goldshtein_58224_58271.png Swift__Apple___s_New_Programming_Language_for_iOS_and_OS_X_-_Sasha_Goldshtein_58272_58667.png Swift__Apple___s_New_Programming_Language_for_iOS_and_OS_X_-_Sasha_Goldshtein_58668_59207.png Swift__Apple___s_New_Programming_Language_for_iOS_and_OS_X_-_Sasha_Goldshtein_59208_59267.png Swift__Apple___s_New_Programming_Language_for_iOS_and_OS_X_-_Sasha_Goldshtein_59268_59327.png Swift__Apple___s_New_Programming_Language_for_iOS_and_OS_X_-_Sasha_Goldshtein_59328_59399.png Swift__Apple___s_New_Programming_Language_for_iOS_and_OS_X_-_Sasha_Goldshtein_59400_59459.png Swift__Apple___s_New_Programming_Language_for_iOS_and_OS_X_-_Sasha_Goldshtein_59460_60755.png Swift__Apple___s_New_Programming_Language_for_iOS_and_OS_X_-_Sasha_Goldshtein_60756_60815.png Swift__Apple___s_New_Programming_Language_for_iOS_and_OS_X_-_Sasha_Goldshtein_60816_60911.png Swift__Apple___s_New_Programming_Language_for_iOS_and_OS_X_-_Sasha_Goldshtein_60912_61511.png Swift__Apple___s_New_Programming_Language_for_iOS_and_OS_X_-_Sasha_Goldshtein_61512_67451.png Swift__Apple___s_New_Programming_Language_for_iOS_and_OS_X_-_Sasha_Goldshtein_67452_68615.png Swift__Apple___s_New_Programming_Language_for_iOS_and_OS_X_-_Sasha_Goldshtein_68616_69575.png Swift__Apple___s_New_Programming_Language_for_iOS_and_OS_X_-_Sasha_Goldshtein_69576_75215.png Swift__Apple___s_New_Programming_Language_for_iOS_and_OS_X_-_Sasha_Goldshtein_75216_75275.png Swift__Apple___s_New_Programming_Language_for_iOS_and_OS_X_-_Sasha_Goldshtein_75276_75347.png Swift__Apple___s_New_Programming_Language_for_iOS_and_OS_X_-_Sasha_Goldshtein_75348_75395.png Swift__Apple___s_New_Programming_Language_for_iOS_and_OS_X_-_Sasha_Goldshtein_75396_77423.png Swift__Apple___s_New_Programming_Language_for_iOS_and_OS_X_-_Sasha_Goldshtein_77424_77759.png Swift__Apple___s_New_Programming_Language_for_iOS_and_OS_X_-_Sasha_Goldshtein_77760_77843.png Swift__Apple___s_New_Programming_Language_for_iOS_and_OS_X_-_Sasha_Goldshtein_77844_77903.png Swift__Apple___s_New_Programming_Language_for_iOS_and_OS_X_-_Sasha_Goldshtein_77904_78647.png Swift__Apple___s_New_Programming_Language_for_iOS_and_OS_X_-_Sasha_Goldshtein_78648_78719.png Swift__Apple___s_New_Programming_Language_for_iOS_and_OS_X_-_Sasha_Goldshtein_78720_80123.png Swift__Apple___s_New_Programming_Language_for_iOS_and_OS_X_-_Sasha_Goldshtein_80124_80842.png