Now, let's pay a visit to our view controller class.

Which if we were to pop into the story board in either the Swift or

Objective C version, we would see it's the only class shown there.

This is a very simple app after all.

In the Objective C version, in our .m.

We see that up top, we've imported the classes that we created and

will wanna use.

In the swift version, we don't need to do that because, as we mentioned before,

we're using structs rather than classes.

Below that, we see how we're declaring our IB outlets.

They're similar in the two languages, though in Objective C you would often find

these over here, declared in the header file.

A couple notable differences are that here in Swift,

we can use the syntactic sugar for an implicitly unwrapped optional.

That's this little exclamation point right here.

By the way, the term syntactic sugar means a sweeter or

simpler way of writing code that is shorter or more pleasant for

the dev, but doesn't actually alter the functionality of a code.

If you need a refresher on implicitly unwrapped optionals and

what they're used for, check the link below.

Another effect of using structs instead of classes is that in the swift version,

we don't have to call alloc and init like we see over here.

Instead, we can just use a call like that.

It's also worth noting,

that in our functions in Swift, we can end with an empty set of parenthesis.

This is shown here and in the viewDidLoad method, and down here as well.

If you aren't used to seeing those, they're common to lots of C-base languages

like C# or Java, but they're not seen in Objective-C methods.

By the way, they look a little more useful and appropriate when they have parameters

inside, but these functions don't require them.

If you're making the switch from Objective-C to Swift,

chances are you may forget these at the beginning.

I know I did when I was learning C# and it caused a gray hair or maybe three.

More substantial than this syntactical difference I just mentioned

is that in Swift, functions are first class types.

That means that they can be passed as parameters, used as return types and

assigned to variables.

If you'd like a refresher on that, check the links below.

We have touched on some of these already but let's cruise through the rest of

the files and point out some of the other little differences that can get you

tripped up when moving from one language to the other.

For one thing, Swift is gonna save you just a little bit of time with no

semi-colons at the end of every line.

On the flip side, you will be expending a few key strokes specifying override,

like we do here and here.

And we do that when we're overriding a method found in the super class.

But before you get too upset about those wasted keystrokes,

it's actually a good trade for the safety it provides.

If you have a subclass in Swift, and you give it a method with a same name as one

found in the parent class, like for example, with viewDidLoad.

The check for

the override keyword at compile time will ensure that it was intentional.

Perhaps, it wouldn't happen with a famous function like viewDidLoad.

But it is easy to create duplicate function names in different classes

once you start naming them after logical functional parts of your code.

We can call the overridden versions found in the class like we see up here for

fact model, or we can call the super classes versions, like we see here,

and here by using super and then dot.

showFunFact is actually just an IB action hooked up to a button, so

we don't actually call it anywhere in our code.

In our objective C version,

we use the self keyword to access the properties we've declared in our class.

But we don't need to do that in Swift.

You will see self sometimes in Swift, especially in relation to closures, but

you wouldn't need to do it here just to get at the properties.

If we hop over to our app delegate,

we can see a couple more differences worth pointing out.

In the did finish launching with options method,

we see how what we declare a return type differently in the two languages.

In Swift, we use an arrow and then the return type, and

over here in Objective C, we do it at the beginning inside a set of parens.

We also see the declaration of an optional here in window.

We also see a declaration of an optional here for window.

An optional being a Swift variable that explicitly may or

may not have a nil value.

This question mark here denotes a vanilla optional,

as opposed to the implicitly unwrapped optionals we saw a moment ago,

which was declared with the exclamation point.

I hope this little side by side comparison was helpful in highlighting some

of the common differences you'll need to be comfortable with

when switching between Swift and Objective C.

Now when I say differences, I do mean the little things like semi-colons, or arrows

for return types, but much more important are the architectural and fundamental

differences, which really should drive how you craft your code in projects.

It's important to get comfortable with those larger concepts and

principals in each language so you don't find yourself trying to

translate your syntax without really picking the appropriate tool for the job.

Since we know that tool boxes are different between the two languages and

we wanna put those tools to use correctly.

Depending on how much exposure you've had to each language,

you might wanna spend some additional time boning up on one or the other.

Subsequent courses will draw on both and reviewing legacy code,

hacking on your own or reading other developer's perspectives or

just the Apple docs will be time well spent.

Having a firm grasp on both Swift and Objective C

will position you very well to work on a wide array of projects, both old and new.

You'll probably also find that the work you do in one,

will actually improve your understanding of the other as you internalize

the important feature differences.

Until next time, happy coding.