Now, let's pay a visit to our view controller class. 0:00 Which if we were to pop into the story board in either the Swift or 0:03 Objective C version, we would see it's the only class shown there. 0:06 This is a very simple app after all. 0:10 In the Objective C version, in our .m. 0:14 We see that up top, we've imported the classes that we created and 0:17 will wanna use. 0:21 In the swift version, we don't need to do that because, as we mentioned before, 0:23 we're using structs rather than classes. 0:26 Below that, we see how we're declaring our IB outlets. 0:29 They're similar in the two languages, though in Objective C you would often find 0:32 these over here, declared in the header file. 0:37 A couple notable differences are that here in Swift, 0:39 we can use the syntactic sugar for an implicitly unwrapped optional. 0:43 That's this little exclamation point right here. 0:48 By the way, the term syntactic sugar means a sweeter or 0:51 simpler way of writing code that is shorter or more pleasant for 0:54 the dev, but doesn't actually alter the functionality of a code. 0:57 If you need a refresher on implicitly unwrapped optionals and 1:01 what they're used for, check the link below. 1:04 Another effect of using structs instead of classes is that in the swift version, 1:07 we don't have to call alloc and init like we see over here. 1:12 Instead, we can just use a call like that. 1:17 It's also worth noting, 1:22 that in our functions in Swift, we can end with an empty set of parenthesis. 1:23 This is shown here and in the viewDidLoad method, and down here as well. 1:30 If you aren't used to seeing those, they're common to lots of C-base languages 1:35 like C# or Java, but they're not seen in Objective-C methods. 1:39 By the way, they look a little more useful and appropriate when they have parameters 1:43 inside, but these functions don't require them. 1:46 If you're making the switch from Objective-C to Swift, 1:49 chances are you may forget these at the beginning. 1:52 I know I did when I was learning C# and it caused a gray hair or maybe three. 1:54 More substantial than this syntactical difference I just mentioned 1:59 is that in Swift, functions are first class types. 2:02 That means that they can be passed as parameters, used as return types and 2:06 assigned to variables. 2:09 If you'd like a refresher on that, check the links below. 2:11 We have touched on some of these already but let's cruise through the rest of 2:14 the files and point out some of the other little differences that can get you 2:18 tripped up when moving from one language to the other. 2:22 For one thing, Swift is gonna save you just a little bit of time with no 2:24 semi-colons at the end of every line. 2:29 On the flip side, you will be expending a few key strokes specifying override, 2:32 like we do here and here. 2:37 And we do that when we're overriding a method found in the super class. 2:40 But before you get too upset about those wasted keystrokes, 2:44 it's actually a good trade for the safety it provides. 2:47 If you have a subclass in Swift, and you give it a method with a same name as one 2:50 found in the parent class, like for example, with viewDidLoad. 2:54 The check for 2:58 the override keyword at compile time will ensure that it was intentional. 2:59 Perhaps, it wouldn't happen with a famous function like viewDidLoad. 3:04 But it is easy to create duplicate function names in different classes 3:07 once you start naming them after logical functional parts of your code. 3:11 We can call the overridden versions found in the class like we see up here for 3:16 fact model, or we can call the super classes versions, like we see here, 3:21 and here by using super and then dot. 3:26 showFunFact is actually just an IB action hooked up to a button, so 3:32 we don't actually call it anywhere in our code. 3:36 In our objective C version, 3:40 we use the self keyword to access the properties we've declared in our class. 3:42 But we don't need to do that in Swift. 3:47 You will see self sometimes in Swift, especially in relation to closures, but 3:49 you wouldn't need to do it here just to get at the properties. 3:54 If we hop over to our app delegate, 3:58 we can see a couple more differences worth pointing out. 4:00 In the did finish launching with options method, 4:05 we see how what we declare a return type differently in the two languages. 4:08 In Swift, we use an arrow and then the return type, and 4:12 over here in Objective C, we do it at the beginning inside a set of parens. 4:16 We also see the declaration of an optional here in window. 4:21 We also see a declaration of an optional here for window. 4:27 An optional being a Swift variable that explicitly may or 4:31 may not have a nil value. 4:35 This question mark here denotes a vanilla optional, 4:37 as opposed to the implicitly unwrapped optionals we saw a moment ago, 4:40 which was declared with the exclamation point. 4:43 I hope this little side by side comparison was helpful in highlighting some 4:47 of the common differences you'll need to be comfortable with 4:50 when switching between Swift and Objective C. 4:53 Now when I say differences, I do mean the little things like semi-colons, or arrows 4:55 for return types, but much more important are the architectural and fundamental 4:59 differences, which really should drive how you craft your code in projects. 5:03 It's important to get comfortable with those larger concepts and 5:07 principals in each language so you don't find yourself trying to 5:10 translate your syntax without really picking the appropriate tool for the job. 5:13 Since we know that tool boxes are different between the two languages and 5:17 we wanna put those tools to use correctly. 5:20 Depending on how much exposure you've had to each language, 5:23 you might wanna spend some additional time boning up on one or the other. 5:26 Subsequent courses will draw on both and reviewing legacy code, 5:30 hacking on your own or reading other developer's perspectives or 5:33 just the Apple docs will be time well spent. 5:36 Having a firm grasp on both Swift and Objective C 5:39 will position you very well to work on a wide array of projects, both old and new. 5:42 You'll probably also find that the work you do in one, 5:47 will actually improve your understanding of the other as you internalize 5:49 the important feature differences. 5:53 Until next time, happy coding. 5:55