TIANYU LIU: Hey, how's it going everyone? And this is the iOS App programming of objective c seminar. And my name is Tianyu Liu. I'm a Lowell junior right now, concentrating in computer science. So in this seminar I'm going to teach you guys a little bit about how to make an app. Yay, get excited for it. 

So before we even start diving into the actual programming side, let's just really quickly talk about why might you want to build an iOS app? Why is iOS so awesome? So the first problem, the first thing that is pretty awesome for us, especially as a CS50 student, is that iOS uses Objective C. Well, there's a new language called Swift, but we're not going to use that in this seminar. If you're interested in Swift, there is an independent seminar about that. But Objective C is basically a superset of C. Meaning that everything you use in C can be translated into Objective C very easily. 

As you might see later, that indeed there are some very basic syntax, are basically exactly the same, C and Objective C. So, since you have taken CS50 up this far, you already know Objective C, at least 40%. Also, Apple has a really robust API for iOS. There are a lot of really crazy things you can do with it. One of which is someone actually created an iOS app for controlling cars, which is pretty interesting. Probably a helicopter is more exciting. But that's how powerful the iOS API can be. 

And as you might have figured out right now, the stack overflow is probably one of the most important online resources available to you. And good news, for every single problem you can possibly think of while building your final project in Objective C, there is likely a stack overflow answer. It's just awesome. In addition to that, iOS is really a platform where you can reach a huge audience with little effort. It's not like Android, where everything's pretty fragmented. 

Everything iOS is unified. And as long as you create an app for an iPhone, you can very easily port that to iPad, iPad mini, or different iPhone sizes. These are all really convenient. And it's just really good for impressing your friends. You can just hold an iPhone and tell your friend hey, this is the app I make. You can do that for any desktop apps, which is nice. 

All right, now let's actually get into the language Objective C. So why don't we start with some really basic syntax. As I mentioned before Objective C It's basically a superset of C. So a lot of basic syntax are actually exactly the same. Declaring a variable and adding two variables together is exactly as we have done in Mario. Nothing new here. 

Similarly, the lodger for loop and condition is also the same. You can do a for loop just as you have did in a Mario [INAUDIBLE]. And you can do conditions just as what you have been doing in your previous p sets. However, Objective C is not completely C, and there is something that is kind of weird about it. 

The first one being that when you are doing C programming, you typically call include and then a library name. But in Objective C you call that import. Basically saying functionality, just different names. And the strings are actually a little bit weird. You can see that the first thing that is kind of weird is that you have a pretty weird-- sorry-- you have a pretty weird NS sign over here. And the second thing that's kind of weird is you have an at sign before actually declaring the string. So the at sign basically signifies that a string is not only a string, it is actually an object. We're going to explain that later so don't panic if you don't understand what that means. And printing to console is a little bit different because in C we call printf, but in Objective C we call [INAUDIBLE]. 

You might be wondering what is that. That is basically printf, just a different language. Exactly the same usage, exactly the same functionality. Well it turns out that Objective C actually has an ns prefix in almost everything, every basic data type, nsstring, nsarray, nsdictionary. The reason being that ns actually stands for Next Step, which is a company that Steve Jobs has founded, which is a company where the language Objective C is born. So this is basically tradition. I know it's a little bit weird, but it's Apple. 

So something that is even weirder than that is a function declaration. This is very different from what we see in C, because here it actually doesn't look like C anymore. What you have here-- by the way this is not a bullet point, this is a minus sign. You have a minus sign parenthesis void and then the function name. Let's just say if we have hello world, then the return type would be void because we return nothing. 

What gets really weird is that when you're having more than one parameter passing into a same function that will be really weird as shown here. We have a method name, called addInt to [INAUDIBLE] and we're passing one parameter. But after that, we have more method name call with. And after with we're passing the second parameter. This is actually a little bit weird, but all these function declarations follow the same pattern as this. 

We have a minus sign to begin with. The minus sign could be a plus sign sometimes based on what kind of method is it. Method is basically another name for function. And we're going to explain that later when we're talking about object oriented programming. You first specify the return type inside parentheses, after which comes the method name. You're passing one parameter. And if you have more parameters you need to extend the method name and basically write something more here. 

It could be anything you want. In our case it's with. But you could say end, or or, or abc full bar, whatever you want. And then after that you're passing parameter b. This is a really weird convention but we are going to see why Apple wanted to do that very quickly. So how do you call function? Calling a function in Objective C is also different from C. 

Actually, calling a function in Objective C is more like you're talking to someone. Here we have self, which is called an object. You're basically telling the object self to say "Hello World!" That is how to call the function. An object and a method name combined with each other. And this is where the weird extension for method name really comes into play. 

Let's look at the second example. We just defined a method called addInt with blah blah blah. So in this case when you are calling that specific [? message ?] it's going to look like self addInt:10 with:2. It sounds like English. Although the function function declaration is weird, the point of Objective C's method declaration pattern, is that when you are calling the function or method it will sound like actual English. So it's very intuitive once you get into it. 

Especially in this case, where you can basically see that the function name is sort of documenting itself. You don't need any more explanation to see what exactly is happening, what exactly one parameter doing. Going beyond that, let's talk a little bit about object oriented programming. Object oriented programming is one of the fundamental programming techniques or patterns that is used by Objective C. Objective C is called Objective C, not C, for a really good reason. 

So before we get into Objective C syntax, Let's really quickly look at what exactly is an object. We've probably done something like object before, which is called the struct when you are implementing a tree or a linked list or [? try. ?] So, it's basically like a struct, but it's much more powerful than that. An object has methods and properties. Methods are basically functions. Basically functions that a specific to a certain object. 

And properties are basically the field you specify in the struct. So for every single object we have some property that has some variables which are specific to the object. And we have some functions which are also specific to the object. And the functions are called methods and the variables are called properties. It's just a fancy name. While you fact, every single view you see while you open an iOS app, let's just say Twitter or Facebook, every single view you see is an object. And even the entire app is an object to start with. Very interesting concept. 

And why do we want object oriented programming? So you can imagine that when you program it gets pretty complicated. Let's just say when you're implementing chessboard, the logic is going to be really complicated. You have 36 different pieces, so that if you want to write logic for all 36 different pieces in chess, that's going to be a lot of different functions and variables. It's a lot of trouble. And probably you're going to write a different method or different function for each of the piece to exactly control what they do. 

But if you do object oriented programming, all of these pieces can be abstracted into one single object. And the object will have some common properties, like what kind of piece is it? What color is it? How can it move? And in that way you have greatly simplified the logic of it. So it's just a really good way to make complicated programs, and hierarchical relationship within the program, very simple. As we're going to see why very quickly when we're actually doing programming-- when we're actually doing an S code programming session later. 

Well in addition to that, object oriented programming is just a lot of fun. You got to design your own object. You got to design what does it look like by yourself. There is no right answer to it. And it's totally interesting. So in object oriented programming, two fundamental concepts will be class and instance. A class is basically a template for object. And an instance is basically one specific object. 

Let's just say you're making a cookie. In this case, every single cookie you actually end up with is going to be an object. But the cookie plate you use to bake all the cookies will be a class. A class is basically a template. And the instance will be one specific object created out of that class. 

And an instance will be created based on class declaration, as we will see in later slides. So let's actually do a really quick example [INAUDIBLE]. Let's say we're declaring an object for a cat. The object should have-- the cat class should have some properties and methods. What kind of properties should the class have-- should the cat have? 

For instance, color, age and breed, those will be variables that are specific to each cat. And those are some things that we use to describe a cat. What kind of method, or what can a cat do? Some quick examples would be chase mouse, eat fish or just meow. This is a really quick example of cat class. And a really specific cat object will be a cat where we specify the color, the age and breed. 

In that case, our object is no longer a class anymore. We copy the template from the class and we specify each specific information to that specific object to make it independent. And when you are calling a method inside an object, you just call meow on the object, which is the cat you just created. 

Probably you will print out something like "Hello World! Meow." Pretty cute. All right, let's just get into some details and see what exactly does that translate into being iOS programming. So in iOS programming every single class will be implemented in two files. One file is here, which is called the interface. Another file is here, which is called implementation. 

Typically the interface will have extension.h as we have seen in C libraries. And implementation file is going to have extension.n. It's kind of weird. But .n means actually .c, there is no fundamental difference between those two. So in this case, we can see that we're declaring interface, Cat : object. That is called inheritance. We're basically inheriting the cat class from the object class. So every property and method that was previously defined in the object class will be automatically defined in a cat class as well. 

In addition to that, we define color, breed, and age, three variables. That actually looks like something you have done before. It looks like struct. That is basically the syntax for struct declaration, and that is totally correct. And since I mentioned before, the difference a struct and an object, one of the fundamental differences is that an object has method, while a struct only has variables. So in addition to the properties or variables we've created for the object, we specify some method. 

Let's just say here we have two methods, one is meow, another one is chase mouse. We probably want to be passing a parameter based on our previous method declaration pattern. You probably want to be passing a mouse. And you'll probably want to return a bool signifying if your cat has successfully caught the mouse or not. 

This is the interface, but we can see that the interface actually doesn't do anything. It just tells a program what exists-- what exists in the cat class. So in order for the program to do something, we need to have implementation files. So here, the first thing we do is obviously we import the interface. After we import the interface, we define the method. 

Let's just say here meow would just print out "Hello World!" to the console. And after the implementation file, we're pretty much done. This is basically a class declaration for one class. So now the question becomes, how do you declare a variable? The way you use a class to create an object in Objective C is written here. 

You first specify that this is a cat pointer, because every object in Objective C is finally implemented as a pointer. And you call the class, call them as alloc, which is basically malloc, telling the operating system that you need some memory space for this object. After that you have an object already and you just initialize it. This is just convention. I know it's is a little bit weird, but this is actually how Apple does stuff. 

Assigning properties is actually pretty straightforward. It's very similar to what you're doing when you're assigning some specific field inside of struct. You just have the variable name, the property name, and assign a specific value to it. And calling a method is very similar. The calling a method is basically what I talk about for calling any method in Objective C. 

You're passing an object, in this case it's going to be myCat, and you're passing the method name. As if you're talking to the object, myCat, that you should meow. It's pretty interesting. After that, there is one more essential design pattern that we need to talk about before getting to actual S code. That design pattern is called event driven programming. This is also probably one of the most fundamental ideas in iOS programming. 

So you probably don't know what exactly is the event driven programming, but it's not really that scary. Well in fact, you have already done that before. This is one of the lines you've probably already written in the last [INAUDIBLE] of CS50, google.maps.event.addListener(marker, "click", function(){}):. By calling this line you are essentially telling the computer that whenever the event called "click" happens on the marker, use that function. 

This is very different from what you do in mario.c. In mario.c you just run the program once, it gives you an output, and you're done. These are sort of like one shot programs. Event driven programs are very, very different. Let's imagine, if Facebook is a one shot program it's not really good. You just go to Facebook once and it's done. It gives you some output and you never got it back. You never got anything more. 

So here, especially the pattern we use is event driven, so that every function will be caught based on what event has happened. For instance, if we have a button and we specify that whenever that button is clicked, call the function called "Hello World!" In that way we can really manage the function logic flow in a highly flexible way. The user can do or call a function that has already been called. It's completely based on what users do. 

So we can see that this is actually much better than mario.c. And good news is that it's actually not a new concept. You guys have already done that in the last problem set. So in Objective C there are three different diagrams for event driven programming. The first diagram is called target action, where you bind a button press with some function. Let's just say, whenever you click some button, you call some function. This is very simple target action. 

The second one is actually the hardest one, it's called delegation on protocol. We're going to explain that in great detail later. And the third way is notification. This is actually not very important as far as we're concerned, because the chance that you're going to use notification in your final project is pretty low. So we're going to skip that part. 

And we're going to dive into delegation on protocol. So what exactly is a protocol? Or what exactly is a delegation? Let's talk about protocol to start with. Protocols are nothing but events. But these events are given to you by Apple to start with. For instance, I'm not completely sure how many of you guys use Apple's original app mail or contact, but every time you scroll the table and press the specific cell on the table, that is an event. 

And if you want to do that event by yourself, it's actually a little bit hard. So Apple has given that even to you so that you can just directly use the event to do something on your own. Protocols are actually really, really widely used in Objective C. Well in fact, every single app has something caught app delegate. Inside of delicate is all of the protocols for loading the app. 

Let's just say there is an event for app did load. So what should happen after you've created an app, after you open the app, after you close the app, or after you put the iPhone to sleep. These are all events that has already been given to you. And originally inside these particles there will be no implementation. Apple just told you that this function will happen when some event happens, but what you do with that function is completely up to you. 

Delegation is basically telling the class that you should handle these protocols. It's a little bit confusing, but it will be much clearer when we do the s codes in action. Delegation on protocol is actually a highly robust mechanism in the sense that if we do delegation to a specific class, we can essentially handle all kinds of events using any class we have, very convenient tool. 

So one quick example for delegation on protocol will be what I just talked about. This protocol specifically is called tableview [INAUDIBLE] select role at [? index ?] [? past. ?] So this an event that would be caught when you actually tap on a specific cell in your tableview, let's just say in your mail or in your contacts app. 

Inside a function there was originally doing nothing. The function doesn't do anything by default. But you can specify what the function does, given what you want out of your app. Very convenient tool. And with all that being said, I basically cover some very basic syntax and fundamental concept for Objective C programming, and we can do some s code. Much more exciting. So s code is actually a little bit overwhelming when you open it for the first time. 

One quick note, so if you want to do iOS development, I highly recommend you have a Mac. Because doing iOS development on Windows is really, really hard. It's doable, but it's really hard. And you definitely do not want to use g edit. So in s code we have several different areas. When you first open up s code you will see a navigation area, which basically shows you all the files that is in your current project. 

You have a toolbar area, which is basically managing views, or some little quick tools about s code itself. And this is the actual editor area. This area is very similar g edit, but much better than g edit. And in this right area, is called the utility area. The area becomes really handy when you're creating interface or specifying some quick setups for your app. 

And the final area is the debugging. This area contains the console. So whenever you say printf, or nslog in our case, all your results are going to be printed here. All right? I guess we can really quickly do an example for iOS programming. And let's actually open up s code. So every time you open up s code, it's going to show up something like that. It's going to ask you what do you want to do? Do you want to start something random, a playground, basically you can just test code without actually committing to any app. 

Do you want to create a new project? Or do you want to continue working on the existing project? In our case we're going to create a new project. So it's really nice, s code actually has already given you some templates for creating objects. If you want to do a game, s code actually has a game template for you, has page based applications, tab based application. In this case, we're going to do something very simple, and we're going to use a single view application. 

After that just what you want to call your product, and what's your name, what's your identifier, and what language do you use. Here we do not want to check using Core Data. Core Data is basically a databasing iOS. If you do Core Data, s code is going to define a lot more complicated classes for you. So to keep everything simple, we're just going to do without Core Data right now. 

The problem we're going to be using is that-- the problem we're going to be creating is that we basically want to import Mario from C to an iOS app. So let's call that Mario-iOS. Of course you specify what you want to put in your project. And there we go. 

So this is a little bit overwhelming, but this is actually what we just saw on the slides. And the first area we see right now is basically project configuration. So everything you want to do project, what kind of device, let's just say what kind of device do you want your app to appear on? Is it iPhone, iPad or universal? So device orientation, all this stuff. Not very important, but could be, but this is a place where you set up your project if you actually want to deploy to the Apple store. 

All right, let's look at something that is inside our code. Let's go through the file navigator. And these are all the files that already came with the template, very nice. So when we click one of them this is what it looks like. Very similar to g edit. But you can see that the syntax highlighting is probably a little bit nicer. And it's actually much more powerful than g editing. And you can auto complete a lot of things for you, as we will see very quickly. 

Let's open the debugging area as well. All right, as we can see, the console is right here. This is what you're going to see where you're in printf or nsloging something. So without further ado, let's actually compile the app and see what happens. One essential feature for s code, is that s code comes with an iPhone simulator. So you don't need to have an iPhone to try your project, s code can simulate that for you, as we can see right now. 

It's pretty nice. It's taking a little bit of time to compile and basically we have an empty application, which actually does nothing. But it compiles. It's pretty awesome. It's much better than C, huh? All right, then let's try to add something. One file that is a little bit weird here is called storyboard. This is actually a great, awesome feature for s code. Because in s code, you can actually drag and drop elements onto the interface and it will directly show up. Let's try that. 

We drop a label here, "Hello World!!!" We can center that. Pretty cool. Now let's run this stop simulation. Here we have "Hello World!!!" We didn't even do any coding yet. What the heck is happening? This is how powerful Interface Builder can be. Somebody even said that you can probably just complete an app without writing probably a thousand lines of code just by using the Interface Builder. But it's probably not the best way to do it. 

Now let's actually get down to coding. So the structure for the file is actually really interesting because, as you may see, there is no main function anywhere. See? As we mentioned before, you can see that this is an implementation file for a specific class. But there is no main anywhere. So where is main? Actually, there is a main, but the main is actually hidden from you. The main is here. That looks familiar. 

So basically what iOS is doing inside main is that whenever main is called, which is basically whenever the app is executed, it creates a object called AppDelegate. As I mentioned before, the entire app is actually an object by itself. So in this way, basically the iOS app is telling the compiler that OK, I'm going to create a product called AppDelegate, and that is going to be my app. So you need to go through that AppDelegate and see what that guy's doing. My job is done for me. 

And in AppDelegate you can see that there are some really weird functions, well actually methods, that Apple has already given you. What are these? These are actually just protocols that I was talking about. So these are events that Apple has given you to start with. There is nothing in some of the functions right now, but if we want to initialize something for our app before getting into displaying any view, we do that here. 

You can just read the name and I guess the event is actually really clear. So now main has created an object for AppDelegate. And what AppDelegate is going to do is actually also hidden from you. The AppDelegate is going to start loading the ViewController stock. So it's basically going to start loading up all the views that you have and just render the view based on the hierarchy. 

So in this case we only have one view, which is here. So that is the only view that's going to be called. The ViewController logic is right here. This is the code that actually controls the view we just saw. All right, let's do something here. So viewDidLoad sounds like an event, when in fact this is also a delegate, this is also a protocol. 

So whatever the view is loaded, everything inside the function will be called. In this case we should see "Hello Tianyu!" if we run the program. It's getting a little bit slow compiling storyboard files. Well indeed, we do see an output for it. It's pretty cool. Now let's actually do Mario. I'm going to define the function very quickly. marioWithLevels: (int)level results. 

All right, this is actually the awesome feature of s code auto completion. So when you write for and type enter, it has already given up the template for you, which is pretty cool. That should look really familiar to you guys. Sorry, that's my fault. All right, cool. That logic should look really familiar to you guys, especially just Mario. 

But we will now print out to the console every single time, because we want to somehow keep track of what we are printing. We're going to use the results somehow later, to display the print out result to the user. So instead we're just nslogging everything, which we're storing everything into a function call result, but the logic is exactly the same. After we finish it, we just print our results. 

And here instead of printing out my name, we're going to call a function. Let's see what happens. Oops, obviously. We do have a nice little pyramid out here. This is basically C, we're just manipulating where you call a function and how does a function look like. There's nothing different. But this is actually not very exciting here, because we're not seeing anything from the iPhone app. 

So if you actually have an iPhone app-- if you actually have Mario iOS right now, you're not going to see anything that has anything to do with Mario because all those outputs into a console are hidden from a user. This is what you see, which is "Hello World!!!" Not good. Now let's try to make the user see what exactly we're printing out. So we don't need to label anymore. Let's try and figure out something else that could be useful. 

There is actually one element that is called text field, which could be very helpful to us. It basically displays a region of text that can be edited. So that looks really helpful. Now let's drag it and drop it. Wow, we have a text view in our view, really fancy. That's a little bit too big. Let's make it smaller. Put it into center. Make it smaller as well. 

Now we have a text view, which we could be used to display our final result. But right now it's definitely not going to work because there is no-- the ViewController we just defined doesn't know that there is a text view out there. So we need to somehow link the text view we just created with the class that has already come with us. 

The way we do that is actually really magical. So open up storyboard. There is a special [INAUDIBLE] called [? assistant ?] [INAUDIBLE]. When you click that, it's going to open two files. One is a class and the other one is a corresponding view for it. It's very, very helpful. And let's just goes through the .h file. Control, this is [INAUDIBLE] logic. Press Control and drag the text view into the declaration. We're going to call that outputView. Connect. So here we have declared a new property for our ViewController class. And the new property is just the text view we've created in the interface building. So in that way we could access all the data and manipulate everything that is inside the output view, which is awesome. 

So in our actual code, let's do something with it. So this time when we are like printing out the final result for Mario, we're in not logging anything. I mean we could keep the logging statement. In addition to that, we send the readout we just created to the output view, which is a UI textview we just created. Now let's see what happens. Wow. We have a pyramid in the app right now. 

So the user can see our output because we have copied the output from our code to our interface. It's pretty good. It's actually not that exciting because we can-- All the app is doing is showing a pyramid to you, and there's nothing you can do about it. It's not particularly exciting. So now let's make a button that will clear the views. Seems that a button will be helpful. Drag and drop. Button one. Button two. 

So when we click the left button, the view should clear. There should be nothing on the screen. And when we click the right button, Mario, the view is going to appear again. So this way we also do the magic stuff, control and drag to the class declaration in the assistant director-- in the assistant viewer. In this case we are specifying that that should be an action. clearMario. 

So here we have already created an action called clearMario, which is the method that would be called whenever we press the button clear. So in our actually code, let's just put the output text and the output view into nothing, and that way it will appear to be clear. In addition to that, let's create another method called runMario. Oh sorry, that should not be a property. All right, that should be an action as well. 

And when that function is called, we just run Mario ten. Hopefully that will be fine. Does it compile? Yes. Now we have a view. We have an output. And let's just see what happens. That's gone. It's back again. So here we have specified what kind of function will be called when we type in something, when we press a specific button. This is basically the target action scheme for event driven programming in Objective C. 

In addition to that, it's not very exciting because we can't really change how high the pyramid will be, so we probably want to somehow get an input from the user and change the height of the pyramid based on what they output. So we're going to do that. So this time when we call runMario, we do not just call Mario directly. This one's title. 

Delegate. This is very interesting. What is a delegate? I'm going to put self here. And we're going to see what that means later. So here we have basically created a specific instance called a UI alert view. A UI alert view is basically what you will see every time something pops up and asks you for input, like what will happen when you're trying to purchase something on an app store. 

In addition to that, after you create it, we just show the alert. All right, let's just quickly test will that work or not. That's very cool. Now let's actually create an input field for the UI alert. This is how we do that. And we should have an input view for the alert. Very cool. Let's just say 10. 

It's not doing anything right now because the call actually didn't change for executing mario. So this has become a little bit weird because whenever we press a button down, whenever we press a button in the alert view, something should happen, but it doesn't happen. How do we catch that? How do we know that a user has dismissed an alert view and already entered a number, because right now nothing's actually happening. 

Well, you might have guessed it right, delegation. So in addition to all these declarations, we need to add a new delegation to it called UI alert view delegate. So that every single interaction or event that we're going to have with the UI alert view is going to be handled by our class as well. 

So in addition to that, will be alert view click button at index. This is reached. So in that case we have already-- so we have found out a protocol that will handle the event when we click the Done button on the alert view. So every time we dismiss the alert view, this should happen. Let me just test it very quickly. Well indeed, we have reached here. 

So here, what we won't actually get is actually get the-- So we want to get out the text that we have previously entered in the alert view. And based on text, we're going to display Mario. This very quickly turns out if it actually works or not. So in that case, if we input, let's say, 10, we should see 10. 

Very good, we do have a number here. It's pretty good. Now the last step will be-- So the last step we need to do right now is just a call Mario with level based on the input that we have put into alert view. So we need to convert this string into iOS. Static overflow is very awesome. And then we just call self marioWithLevels value. Let's see will that actually work or not. 

We're already given a pyramid. Let's try to change the height. That actually works. It's pretty cool. So that now you can just input any value you want. Let's just say four. That's pretty awesome. So this is basically a really quick example for how to create a project in s code and how to really quickly wire up some really simple events and functions. 

So the source is going to be put online later. So if you're interested in how iOS Mario works, I'm going to put exactly the same projects onto the CS50 website later. We're basically done with the summer, and before we finish I just want to point you guys to some really awesome resources that are available online. 

Obviously the Apple documentation is going to be very helpful. But in addition to that, I especially recommend four sources, code school, tree house, AppCoda and WWDC videos. Code school and tree house are two online educating websites, which specifically focus on software engineering. Especially for code school, they have really good tutorial on iOS. 

That is a really quick example for it. They actually create a really cute-- look at that little cute iPhone dude over there, it's pretty awesome. And the way they explain Objective C syntax is perfectly clear. Tree house is the same. And AppCoda is a forum. It's actually a blog that was run by a really experienced Objective C programmer. And all those tutorials in AppCoda are pretty short and easy to implement, highly recommended. 

And if you're a developer, definitely go check how the WWDC videos where you can learn about the latest iOS programming techniques, APIs and libraries. So that is pretty much it for the seminar. Thank you so much. And I hope you have fun creating your own iOS app.