 So, for today I am going to talk about universal links, how many of you have used it or how many of you have heard about it. So, Apple announced this last year at WWDC and they supported actually it can still be supported by USA, but they announced it last year prior to universal links your skills were the only way you can communicate with another app. For example, if you have your application where you needed to let us say let you use it to login to Facebook, you install the Facebook stick and sometimes what happen when you just tap on the connect button or the login to Facebook button, it goes to the Facebook app, it checks whether the user has logged in to Facebook or not and then comes back with some token that you handle on the application. And now those kind of things were being done prior to universal links using custom URL schemes and slowly the custom URL schemes will be depicted and universal links will be the only way to go forward and I will tell you what are the reasons. But I will show you a quick demo again from the WWDC session. So here I have a WhatsApp application and I have the WWDC app installed as well. So I go to WhatsApp, I tap on the link and it directly comes to that WWDC app and goes to that particular screen. Let's do it again and see what happens. And if I let's say delete the application, what is going to the behavior? You still go to any third party application or any other application, you tap on the link, it opens in Safari. Now that kind of behavior is not possible just by using custom URL schemes. You need to really write a log code, let's say to handle within your application if a URL scheme is present. First of all you need to check whether an application with the URL scheme is present or not within the system and if it's present then what you need to do, if it's not present what you need to do. You still need to do some kind of, some of this determination with universal links. But the main advantage of this is, is a HTTP or HTTPS, it's using HTTP or HTTPS scheme. That means you can potentially open a web page or you can direct user to your website if that application is not installed. Another thing is you can do is you can use smart banners. I'll show you a couple of examples, smart banners. But let's say you have, you have been browsing to certain websites and you see on top that install this application and sometimes let's say you are, you have that application installed and you see that open, let's say you go to m.youtube.com which suggests you, they open the YouTube app because I know that you have already the YouTube app installed on your application. So that you can do using smart banners. But just for universal links, there is very few steps that you need to do on the server side and client side. I'll walk through those steps and a link will look like something like this is normally like how your typical URL will look like. The first part is scheme, it can be HTTPS or HTTP, then then the next part is domain. This is your own domain. Then the last part is a path, it can be a direct path or a path prefix with certain parameter. You need to do something on the server side to make your app compatible with universal links. First of all you are trying to hit a URL and you are redirecting that URL to your app if the app can handle that URL. So there is this file that you need to create and the file name needs to exactly match this name apple dash app site association. The second part is, let's see what this file looks like. This is an Asian file basically, you have the apps links dictionary, then you have the apps array. Now this is quite interesting, the second parameter it needs to be there, the array and it needs to be blank and apple needs it, it can't remove that parameter. I tried to find what is the reason behind it, I really couldn't get a proper answer but what I think is, let's say you have multiple apps that you need to support and apple probably initially thought of using that array for that but then no longer needed. So it happens all the time in software development that you need to create something and it became an integral part of your API that you can't remove it anymore. But anyway, the most interesting part is the details, where you, the first parameter is the app ID. You can find it from your developer portal, you can, when you create an app, it's just the app ID with a bundle identifier. Then you specify the paths, paths, recognition array. You can specify a wildcard path so that it can handle every path. Or you can specify certain URLs, specific URLs that your app is going to handle. The second part is generate and SSL certificate. This is not something that you can generate from Apple portal. This needs to be from a trusted authority, you need to generate an SSL certificate. Usually, if your domain provider provides HTTPS and they have the way to generate SSL certificate, you can do that. Once you have the SSL cert, you sign your file like this. And the output is always going to be that Apple App Site Association. Then you have this, the cert keys that you need to use to sign it. Now, the good thing is that you do not need this step if you are targeting only iOS 9. So if you have, if you're only targeting iOS 9, you can upload the unsigned file directly to your server. But if you need backward compatibility like iOS 8 and, I don't think it supports iOS 7, but I'm not too sure. But for iOS 9, you don't need to sign. If you're trying for backward compatibility, you need to use the SSL cert to sign. Then you just upload to your, the root of your domain and it needs to be HTTP or HTTPS. On the App Site, there are very few setups as well as like, literally you can get it running in few minutes. This is the method that will get triggered on the application delegate. The main interesting part is the user activity. If you have used or heard about Handoff, which was, I think you introduced in iOS 8 if I'm not wrong. So Handoff is a feature where you can, let's say your application, your user is using one device and he's using this application. And suddenly he uses another device, then he can resume the app from where he left. For example, Mac and iPhone, they're missing with each other. Similarly, Apple Watch and iPhone, they can sync with each other. You're doing certain tasks and then you want user to resume from wherever he has left. So that is about Handoff. And Handoff uses this delegate method as well. And these are the two domains, you need to have associated domains and this needs to be like app, links, colon, and your domain name. And you need to have an entry for every domain that you support. So let's say you support your domain name, then you need to have an entry separately for that and if you support a domain without the, then you need to have an entry for that as well. For the demo, what I did is I have an app, I'll walk you through the app. But I was running the sample today and I was unable to upload the file to my server because I do not have a private key on this Mac. So I can't show the complete demo on this Mac, but I'll walk you through the steps on the client side. The server side piece is also, I'll show you, but the demo will not work. Maybe I'll send a video later on, meet a problem or something. Best practices, again, we'll come to this in a while after the demo. Again, it's a swift best practice to do new things in an extension of your class. So if you're doing, I'll give you an example. Let's say your view controller confirms to a certain protocol or two different type of protocol or three different type of protocol. You need to kind of make a practice that you confirm to these protocols individually in a separate extension. First, for this one, all this part of application delegate on this, I want to kind of keep this code separately in an extension so that, first of all, you can read this extension individual and see what individual extension are doing. So it's extension is meant to do one specific task. For example, here, I'm just going to handle all the code that is related to universal links. First, so you basically have this delegate method, as I was saying. And the parameter that I'm interested in is this user activity. And user activity has a property called activity type. And if you're coming from a wave, you can have, again, specify the activity type. But let's say you're coming from a handoff, then you need to kind of handle that separately as well. So if you're coming from wave, user activity will have a web page URL. So again, I think this is kind of a bad practice in Swift to force downcast and optional. Although here, I know for sure that because it's coming from wave, I can force downcast. But what do you need to probably do is you can use a guard statement. So that's going to check if this value is nil or not. And if it's not nil, it's going to unwrap and I'll have the value in URL. Then I'm going to call this presentCustomViewController with URL. Now with URL, there is this thing called NSURLComponents, using which you can find different parts of the URL. You can find what is the host, what is the path. So here I'm just taking, I'm just getting the host. I'm also getting the path components. And you can even, let's say you have a path component, so your path might be multiple strings separated by slas. Then you can do additional splitting logic here and then you can handle that. But at the end, you can have this parameter. You need to check, okay, what is my host? If it's coming from a trusted host or not, it's coming from a trusted host. Then handle this URL, otherwise just let user know that you're not supporting this host or you can redirect your host for you or whatever. And for my sample code what I'm doing is, okay, let me show you that. It's a very simple app. I could have probably spent a little bit more time to make it look interesting, which probably I'm going to do after this meetup and sample sample. But just for the understanding, what I was trying to do is I have a, this view controller where I have three items. Let's imagine this is a table view and you have three cells. And you tap on one cell and you get the detail of that cell. What I was trying to achieve with the sample app is, if I have a direct URL for a particular item, I directly go to the details of the page. And imagine you're trying to sell something on Corroso, right? And you want to give that universal link to your friends on Facebook or WhatsApp or whatever messaging platform, right? The moment they tap on the link, it directly takes user to Corroso app, to that particular page, right? That's the idea behind it. And if Corroso today doesn't accept payment, but let's say there is an app which accepts payment, your friends can pay there and purchase that item directly from the page. On the back end side, on the server side, let me see. It's going to look something very simple like this. As I mentioned, you have the same JSON format. You specify your app ID along with the bundle identifier. And for paths, for here, I was just using the wildcard path, but you can specify the individual path that your app is going to handle. There are a few refactoring we can do in this code. First of all, wherever there's a Boolean value, there's a straightening fault. We're not handling anything. That's a really, really bad user experience. If you are not handling something, either you need to take user to Safari, and open Safari, or you need to present an alert to user that you're not handling this particular URL. Otherwise, your user will be presented a blank view controller with no content in it, right? So on the main app here, I think this method itself is returning a Boolean value. And I'll see if it's false, then I can do something like this, which is going to open the app in Safari. I think it's going to. This is going to open that URL in Safari. You can present an URL at view or whatever. The best practices, as I mentioned, is you need to validate the input because not necessarily, let's say, the user can create a custom URL or it can come from an untrusted source or whatever. So you need to validate whatever you're expecting. First of all, you need to validate whether it's coming from the right host or not. Then whether it has the proper path that your application is handling or not. If there are certain paths that your app is unable to handle or you do not have the provision to handle, then you need to sue an alert to user. And as I mentioned, failed graceful agent, you open either in Safari or so on. And although the universal link can support both HTTP and HTTPS, but let's say you have certain data that you're sending from app to the browser or browser to app, then you probably should use HTTPS instead of HTTP. These are the smart banners that I talked about and these are fairly simple to add to your web mobile app. The only thing you need to do is you just need to add this meta tag to your header of the page. The first part, the name needs to be exactly the same Apple iTunes app. The content part that needs to be the app ID, this is the iTunes ID or App Store ID. Then app argument is something that again the page is going to say with your app if you need a user. And this is mostly useful. The first part is okay, if user hasn't installed your application, then it will present, okay, install this app or you haven't installed. But if user has installed the application and he's on a particular page of your website and you want to take user to certain page within the app, then the app argument comes into picture so that you can just redirect user to app. These are the two resources that you can refer to. I mostly covered topics from 5.9, but there's another thing which is really really interesting and which goes well with the universal link which is the search APIs, how deep linking works when you search certain things on the spotlight of iOS 9 and how Siri basically looks for things. And then it can, Search API also can redirect user to certain section of your apps. As well as if your app is not installed by the users, they can still provide search APIs or they can index your different pages of your app. So that when user searches certain things on the spotlight, they can get to know about your app. Another thing which I did not cover in the material is, let's say your user is going to your website and the user has logged into your website. And you have the login credentials for the user, then he's visiting certain things, then you're redirecting the user back to the app. And if user comes back to the app and he has to login again, that kind of sucks, right? So there is a way using universal links where you can save the credentials, basically Safari credentials or credentials saved in Keychain to the app. Let me see. So it's going to look like this. So when user comes to your app, it's going to present, are you going to use the credentials from this? It has to be already in the device credentials. If you have shared Keychain for example on Safari, right? It has to be already there. So you already have shared? No, so if you're using the same Apple ID for your Mac and your iPhone, then obviously the username and password is there. So either it needs to be within the Keychain or you need to be using an Apple ID. So where you have the username and password saved within the Safari cookies. Any questions? This is for Safari. But there are a lot of new things that every year because with every OS launch, you have like thousands of new APIs that Apple announced and we do not cover all of it in our session. So again, it depends on the speaker's preference or whatever. But another thing I thought might be interesting if some of you want to cover yourself in some of the feature meters is the force touch. You have a 3D touch which is available on iPhone 6 and 6s Plus which will allow you just to force touch and go to certain sections of the app. I haven't looked into that API myself but I would imagine they would be using some form of universal links there or you will also get there as well. Any questions? Then our next speaker is Isaac who is going to talk about WebKit. Thank you.