 You are following iOS 9 updates and how many of you watched WWDC videos? I know he went all the way to California to watch the video in person. So anyone else? I mean not in person. Did you watch the video, WWDC video? The keynote? Okay, one. Did you watch the State of the Union? No. Any other tech videos that Apple posted on their website? Just one. No worries. I've summarized three or four of the most important videos that explain the new features of three things. The platform, which is, sorry, the language, which is Swift 2, the development environment that you use, which is Xcode 7, and the operating system, which is iOS 9. So I've been doing a similar talk every single year. I did one for iOS 6, iOS 7, iOS 8, and now iOS 9. So that's probably some of you know me. What is it called? Okay, we'll skip that slide for now. iOS 9. What's new in iOS 9? First and for biggest update in iOS 9 is split screen multitasking. iPads now support something called split screen multitasking. How is it going to affect developers like you is what I'm going to talk in the next few slides. Next important update in iOS 9 is search and deep linking. So far you know that App Store search is shitty as hell, right? Whenever you want to download an app, say for example you want to download Airbnb, you probably go to Google search Airbnb and then download their app, right? That's what most people do, including me, right? Apple is trying to solve this problem by integrating App Store search within Spotlight. And not just that. They don't just stop there. App Store now, sorry, search APIs are now public through a framework called Core Spotlight, which means if your app is a content app, for example, if you are making Airbnb, you can index your content with Apple. So when someone search for properties in rental properties in Singapore, your app can, Spotlight can suggest your app to be downloaded and installed, which means more visibility for your app, just from Spotlight. You don't have to go to a search engine to do all those. But how to do SEO within the system is not clear as of now. It's too early. It's remote, it's not working and this uses app thinning. The third major update for iOS 9 is app thinning. App thinning means with more and more devices, more and more platforms, you've been bundling .onex file, add to x file and now add 3x files and so much of resources are getting bundled in your app these days, especially if you're a game developer, you'll be bundling like tons and tons of resources, right? And this easily increases the download size of your app, right? As on date, App Store lets you download any app that is less than 100MB over your wireless network. If your app is more than 100MB, users have to wait till they connect to a Wi-Fi, right? So developers like us, we use to optimize so that the complete payload is within 100MB, right? Well, no longer the case. With app thinning, you can mark certain resources as dynamic and you can download things on demand when users go to that part of the screen. It's very useful for level-based games. For example, I have a game from level 1 to level 50. I can just bundle level 1 inside the game and mark level 2 to level 50 as dynamic through resource tags and download level 2 only after the user has completed level 1. This means you can kind of reduce your app initial download size, okay? There's more to app thinning, we'll talk about it later. Cloudkit, iCloud sync was kind of broken, right? So Apple introduced Cloudkit in iOS 8 and they had an easy way to migrate from iCloud sync to Cloudkit, right? How many of you have used Cloudkit in your app? Probably no one, okay? How many of you have used PaaS? Some of you? No one? Yeah, one. PaaS had an advantage over Cloudkit in a way that the data you store in PaaS can be used and accessed from other application, sorry, other platforms like Android, web, right? Cloudkit was almost locked into Apple platform, right? With iOS 9, Apple is opening up and you have a Cloudkit.js JavaScript library that lets you access your Cloudkit data store from a web application. There is also a Cloudkit web service API, a HTTP API with which you can write your own Cloudkit client for Android or Windows Phone or whatever, okay? So data you store in Cloudkit is no longer locked into one single platform. News publisher, another thing that is new, how many of you are content producers? How many of you write blogs, maintain blogs, no one? Or is it like no one or is it like no one wants to raise their hands? I'm not going to ask you questions over there. So news publisher is very, very similar to Flipboard. The advantage, it's baked right into your operating system and you can sign up as a publisher with Apple by just providing your RSS feed as of now. Apple is coming up with something called Apple Format News with which you can change the layout, change the way the news articles get animated and so on. Not much information is available as on date when a couple of months pass by, you'll probably have more info here. Lastly and most interesting one is content blocker extension. Most of the content blocker extension, even ad block, ad block plus, they all work not by blocking loads but by removing divs after they load. Very few, unless you install a VPN based extension, they don't block loading. They only remove your divs so that you don't see them. Okay, that's how ad block work for the most part. But with content blocking extensions in Safari, you can prevent certain URLs from certain domains and subdomains from loading completely. Which means you can have an ad-free experience, not just in Safari but also in Facebook, Twitter and every other app that uses Safari to display webpages. Okay, and writing a content blocker extension is fairly straightforward. You know why? Xcode has a built-in template. Click content blocker extension, next, next, next, you get a template. Just provide what all needs to be done. You get it, okay? So, a brief history about iOS. Apple usually alternates between a user-focused release and a developer-focused release. This has been happening since iOS 1. iOS 1, we didn't have access to an SDK, right? It was purely a user-focused release. iOS 2, not much on the UI side, mostly a developer release. They released an SDK, they had an app store, they let developers submit apps and get paid for their work, so on. iOS 3, user-focused release, cut copy paste. Most important feature of iOS 4, right? Sorry, iOS 3. iOS 4, again, developer-focused release, not much on UI. I forgot what was introduced. iOS 5 was user-focused release. I think push notification was introduced in iOS 5. They targeted iOS 4 and then released it in iOS 5, if I'm not wrong. iOS 6 was, again, developer-focused release. iOS 7 was mixed. It was both for users and developers. Users got a fairly new UI and developers had tons and tons of work just to get your app look nice on the iOS 7 new user interface. iOS 8 was a user-focused release, not much changes. iOS 9 is performance-related tweaks and it's developer-focused release, which means you have a lot of work to do for migrating your app to support iOS 9. We have a whole new font called San Francisco. This slide uses San Francisco, so that's how you know that we have a new font. There are two variants, San Francisco Display and San Francisco Text. The display one is used for text sizes above 20, 20 points. You don't have to change your fonts. It automatically happens. If you create a font that is less than 20 pixels, sorry, 20 points, it automatically changes to San Francisco Text. If it is more than 20, it changes to San Francisco Display. For watch, you have an equivalent set called San Francisco Compact Display and Text. I don't know the point size when it changes from text to display. This is the cool thing about it. The difference between display and text is it makes text readable at any point size. This is a feature that jailbroken iPads were having since iOS 4 or 5. How many of you have jailbroken your iPads? Some of you might have done. Again, you don't want to show your hands. What is so special about split-screen multitasking is after a very long time, Apple allows two applications to run simultaneously on one single screen. What implication that has on you as a developer is what we are going to see. There are three kinds of multitasking that is supported on iOS 9. One is called a slide-over, the other is called a split-view. The last one is picture-in-picture, also known as PIP. Slide-over multitasking. What is slide-over? Slide-over is when I have an iPad, of course, this is not running iOS 7. I have an app like this, when I slide my finger over from the left, I see a task picker from which I can select the second app that I want to run. Split-view is an extension of slide-over. You can make that single app run simultaneously using a split-screen. What is the difference between slide-over and split-view? In slide-over, your main app just becomes inactive. It doesn't run. You see what is happening on the screen, but it doesn't run. You can quickly open Twitter, send a tweet, and then go back to your parent app. Say, for example, you are browsing something on Safari. Just want to send a quick tweet. You don't have to close your application, open Twitter, send a tweet, and then come back to Safari. You can just pick an app, slide it over, and then work on it, and then just close it. With split-view, you can have two apps running at the same time. Picture-in-picture is mostly for applications that display videos like YouTube, Daily Motion kind of apps. What happens when a user slides over your application in iOS 9? Even if your application is an iPad-designed application, when your application is slide-over on iOS 9, what happens is your application is executed as if it's an iPhone application within the right edges of the screen. Unfortunately, I don't have screenshots because I'm not allowed to post screenshots. I can show you some from the internet, go and search. It's too early, and no one is allowed to post screenshots. My slides are going to be boring because of that. What you as a developer should understand is, many of us have written code by checking the device orientation. If device orientation is landscape, do something. If device orientation is portrait, do something. How many of you have done that? I've done it. No one? Okay. Right? This kind of code is going to break. Why? Because even if my iPad is in landscape, when the user slides over another application, that app takes a portrait orientation on the right edge of the screen. The layout of that app is portrait, though your device orientation is landscape, which means whatever you do, whatever code you write within if condition that says if device orientation is something, do something, it's all going to break. You shouldn't use device orientation anymore. What should you use instead? Size classes. Size classes was introduced in iOS 8 last year, which provides a more elegant way to do what you have to do. How many of you use UI window, main window, bounds? Right? Again, we all assumed that your app is going to be always full screen and my app's main window size is what my view controller, my parent view controller size, right? Not anymore. With split screen multitasking, your application's main window might be considerably smaller than the device's main window. It could run on a smaller window. So code that uses window size to position things, the position your subviews are going to break. Again, use size classes. This has been, Apple has been recommending us to use interface idioms since I was 3.2, right? When Apple introduced iPad, they said, okay, you can use a macro called UI interface idiom. It returns iPad on an iPad, it returns iPhone on an iPhone, right? So we had code that said, if UI interface idiom equal to iPad, do something. If it is iPhone, do something. Not going to work. Because I can slide over Twitter as an iPhone app inside my iPad. So all those kind of code is going to break. Again, Apple's recommendation, use size classes. Size classes is completely new. It came just last year. You will have to migrate your code to use auto layout and size classes. No other option. And memory. Most of the old devices will come back to consideration. There's one slide just dedicated for consideration. You will have to consider about memory usage within your app, CPU cycles used within your app and the frame rate that you aim for in your app. We all know that 60 frames offer the butter smooth scrolling, right? 60 frames boils down to 16.66 milliseconds per frame, right? That's all going to break because you know how two or three applications at the same time on the screen. So all these three apps together should render everything in 16.66 milliseconds, which means what you have is less than 16.66 milliseconds. We'll come back to the consideration in a short while. Split view is enabled only on powerful devices. All devices will support slide over, but to make it a split view application with both apps running, you need iPad Air 2 and higher devices. Higher, we don't know what's new, right? The size can vary based on the divider's position. No arbitrary sizing. You cannot size your divider anywhere you want. Three-fourths, half and one-fourth are the three possible sizes. And size glass will let you know what exactly is the size chosen by the user. Regular, compact, or what is the other one, full, something. Picture in picture, probably the easiest multitasking enhancement that you can adopt. As long as you're not using MP movie player controller, you're good, okay? Apple introduced something called AV player controller or something similar to something that starts with AV, AV player controller or something like that in iOS 7 or iOS 8. If you use that to playback video, enabling PIP is just saying allow picture in picture, something like that. Yes, that's all. And it just works. But if you're using MP movie player controller, you'll have to change your code to use AV player controller because MP movie player controller is deprecated in iOS 9. Okay? They're going to remove this probably soon and force you to support picture in picture, okay? The other important consideration that you have to understand when you use picture in picture is when an external screen is connected to a device when your application is displaying a PIP. So what happens is when external device is connected, if your application supports secondary screen, your PIP photo video is going to automatically move to another screen and users will not know what is happening. This happens when users toggle the airplay from the control center. So there are some notifications and delegate methods that are called back on your view controller that which you have to handle, okay? Yeah, it's called as AV player view controller. If your application is displaying a full screen video using AV player controller, you don't have to do anything. When the user closes the app by pressing the home button or when he launches another app, PIP automatically kicks in. If it is not full screen, it doesn't. And you should not, as a developer, you should not automatically display a PIP when you're playing back a video in a subview without user explicitly asking you to display it. If you do so, your app will be rejected, okay? So, so far for the last seven, eight years, this has been the motto of good iOS applications. Use as much memory as you can when you are in the foreground and use as much CPU cycles you can when you are in the foreground and relinquish everything when you go back. You can, you are free to use, like on a one GB iPad, you are free to use up to like 700 or 750 MB in working memory just for your application. But with iOS 9, it all boils down, boils back to how Windows and Macintosh managed memory. Be a good citizen on an operating system that you're running on. Use as little memory as possible. So, this is going to considerably change how you cache things, how you store certain things within your application, okay? This doesn't stand true anymore. Why? Because if your application takes up all the, all available memory when a secondary app is opened inside of a split view, it will not have enough memory. And to allow that app to run, your app might get killed. And that's a bad user experience, right? So, you don't have the liberty to use as much memory as possible anymore on iOS 9. Profile your application. So far, this wasn't that important. Only when you're scrolling table views, only when you're scrolling the most important table view in your class, you used to use instruments to profile your application, right? But not true anymore. Again, what we normally do is we aim for 60 frames per second when user scrolls through their application, right? When the user scrolls table view in your application, right? And that boils down to a render time of 16.66 millisecond per frame. So, if you have a table view that is displaying, say, 10 or 15 cells at one go, you have about 1.2, 1.3 milliseconds to render one single cell, right? This is no longer true with the new multitasking. Because I can have two different apps scrolling at the same time with another app displaying a PIP video screen. And all these have to render within the 16.66 milliseconds, which means you are now left with less than a millisecond to display, sorry, less than probably half of it, like six or seven milliseconds to display your frame. That means your job is going to be even more complicated. Getting the right kind of performance is going to be even more complicated with the new multitasking in iOS 9. Lastly, again, as I said, use size classes instead of device orientation or instead of using main vendor bounds. This code will not work anymore. I mean, it still works. But your layout is going to look messy. Again, this is another one. A easy way to get rid of this situation is by just opting out of multitasking. At least for the first three months, you can do this. That is done by using a key called UI needs full screen equal to yes in your Infoplist. It's just a checkbox that you have to check. It automatically adds that key. But don't do it. Apple's recommended list of applications that can opt out of multitasking is games that use full screen sensors, full screen games that use iPad sensors, like if I'm using the accelerometer of the iPad to play my game. It doesn't make sense when another application sits halfway onto the screen. So if your game is like that, then yes, it makes sense. You can opt out of multitasking. Camera applications, anything that triggers the iPad's camera obviously have to be in full screen. Kiosk mode applications like point of sale apps or ATM machines, for those kind of kiosks, yes, you can opt out from multitasking. That's it about multitasking. It's easily one of the biggest update in iOS 9. And it's easy for the user. Super difficult for us. Next one is search and deep linking. Apps can be discovered with the spotlight. I can just pull spotlight, start searching for something like a bruised knee. My knee is bruised. I want to know what apps will offer me suggestions. So App Store or Spotlight automatically recommends that I download WebMD so that I can know what I should do for if my knee is bruised. If I'm searching something for a spare part for my car, whatever, App Store will ask you to download an app that can help you do something. All this without opening your browser. And that means your application should very similar to what we did with metatags in HTML. Your application should hint Apple that you can do this, you can do this, et cetera. And what keywords you submit to Apple is a complete black box. And there are going to be SEO guys who can help you with this in the future. At least for the first six months, we probably won't understand how Apple is indexing, how Apple is doing all this search and deep linking stuff. But yeah, someone will figure it out. It's a very great technique for content apps. Right now, we have for searching for any content, you open your browser, go to Google, search for something, and then download the app. And then again, search for the same stuff inside the app. And mostly no one does that. If this works as advertised, it's going to be very, very useful for content producers. The framework that you have to look for is CoreSpotlight. CoreSpotlight was a Mac framework that lets you index so that Spotlight search on Mac can index your files within your application. But it's now expanded to iOS. And if you are a content app, if you are like a reminder app, you can use the same CoreSpotlight so that Spotlight search knows about the reminders created instead of your app. Or if you're a node supplication, you can use CoreSpotlight to say that these are all the nodes I have. And so when the user searches for something, you can show a result. When the user taps on that result, your app opens with that reminder. Right now, when you search for something in Spotlight, you are able to launch messages, calendar, and Apple's reminder. Because the API is public now, you can index your own data inside of CoreSpotlight. It's used in conjunction with something called Linux user activity that was launched last year for something called continuity. Apptaining, as I explained before with multiple devices, multiple screen resolutions, and multiple densities of screens like Retina, Retina 2, At1X, At2X. And now we have At3X with iPhone 6 Plus. It's getting complex to create all these assets. And it's getting, your application bundle is getting heavier and heavier. With apptaining, you can significantly make the app smaller, at least the initial download smaller. And the best part is if you ship At1X, 2X, and 3X images, App Store will take care of downloading just the 3X images if your app is being downloaded on iPhone 6 Plus. If your app is being downloaded on iPhone 4 or iPhone or maybe iPad 2, App Store downloads just the 1X images, which means your initial app download is going to be significantly lower. You can also mark certain assets as on-demand resources. As I explained before, if you are a level-based game, I can mark level 2 to level 50 as on-demand resource and download these resources on-demand whenever I want. As soon as the user finishes level 1, I can initiate a download to download all the assets for level 2. This way, you can reduce the initial download size of your application. And when I say resource, it doesn't have to be PNG files. It can be anything. It can be a storybook. It can be the fifth chapter inside a storybook, anything. Anything that you put inside the resource bundle, that's all. And when I say download from App Store, you are going to download it from App Store programmatically, not the user. The main reason is it significantly reduces the initial download size of your application. A very interesting stuff is app transport security, which mandates that every URL connection you make is a HTTPS connection. So if you don't add an exclusion and try to call HTTP colon slash slash google.com using an NSURL session or something, iOS 9 will automatically redirect that request to HTTPS colon slash slash. All requests are now converted automatically to HTTPS, even if you make a mistake. But if your server doesn't support HTTPS, you can create an exception inside the Infoplist. And that exception is NS temporary third party exception allow insecure HTTP loads. If you set this to yes for a given domain, that domain HTTP calls will go through. But I believe that in future, this will probably be deprecated, and Apple is going to force you to use HTTPS for everything. Because packet sniffing, privacy is getting common these days, right? Privacy issues, and Apple want to thwart all those problems that users are facing. So everything will automatically be translated to HTTPS. If you have the control over your back end server, implement SSL now. At least start planning to implement SSL now. If you don't have control over your back end server, you can use an exception for the time being, OK? Yeah, exception can be on a per domain basis or can be pervasive. I'm expecting more changes to app transport security with iOS 10 and what the future holds. CloudKit, this is interesting. Apple has opened up the data you store in CloudKit, and you can now access those data using CloudKit.js. It's JavaScript library. So if you're writing a web application, you can display the same data that your users store from your application. Like, for example, if I am making a reminder application, I can have a website that displays the same reminders. Previously, this was not possible with iCloud stored data. You were using parse or third party data storage, all those stuff. You don't have to do it anymore. So CloudKit.js, you also have a web service API based on HTTP so that you can access the same data that you store from your iPhone to CloudKit on another device running on a completely different platform, like, say, Android or Windows phone, whatever. News publisher, as of now, not many information is available. But any website that supports RSS feeds can be added right away. And there is something new called Apple News Format. It's still unknown. No documentation is available from Apple, as of now. They're still working on it, probably. Content blocker extension, interesting stuff. You can now write a Safari extension right from Xcode with a default template and create an ad block. OK. Most ad blocks work by just hiding divs. So your bandwidth is actually wasted to download your advertisements, not anymore with Safari, this thing. It just passes you the URL of a subdomain and asks you, should I load, should I load, should I load, and I delegate this all. Works not only in Safari, but also in SF Safari view controller, which is a new replacement for UI WebView or WK WebView. And even that will not display contents blocked by your extension. OK. So that's all the most important new features in iOS 9. Any questions so far? I'm going to move to the next important part of the discussion is Swift 2. What is new in Swift 2? How many of you have used Swift before? I know that the presenter was presenting everything in Swift. So apart from that, OK, one, two, OK, not bad. At least some hands go up. I did not use Swift 1. The reason is when Swift 1 was announced, Apple said we are not going to have a backward compatibility when Swift 2 is released. That pissed me off. Why should I invest time today, learn something new, only for Apple to change it next year? Like, for example, if you have written some application in Swift 1, if you compile it today with Xcode 7, it's not going to work. You'll not get one or two errors. You'll get tons and tons of errors, like hundreds of errors. And there is no easy way to migrate your application from Swift 1 to Swift 2. But if you have written applications using Swift 1.2, which was released in March or April this year, three, four months ago, there is a migrator that can convert 1.2 to Swift 2, OK? Even today, Apple stands as like, when Swift 3 is released, it will not be backward compatible with your Swift 2 code. It's code-wise backward compatibility, OK? There's no code-wise backward compatibility, but there is binary backward compatibility, which means if you release an app that was written using Swift 1, it continues to run even on iOS 21, because Swift actually ships a small Swift runtime along with the application. So your app will continue to run, but your code will not run. And you will not have Xcode 5 that can interpret your code so that you can submit your app again, OK? So your app will run. It's binary backward compatible but not code compatible, OK? But with Xcode, with Swift 2, Apple has released a migrator, which means they are going to release a migrator when Swift 3 is launched as well, OK? There's a migrator now for that migrates your code from Swift 1.2 to 2. I think the code that was used in one of your, where is the presenter? The previous presenter was using Swift 1.2, right? Yeah, there is a migrator that lets you migrate your code from Swift 1.2 to 2 easily, OK? There's a new statement called God, quite difficult to explain God. Let me try to explain what God's statement is. God is a way to use, to return from a function earlier. Like for example, let's say that you are writing a function that does something. And this function expects two or three mandatory parameters. And if these parameters are missing, you cannot function anymore. So what you normally do, if username equal to equal to nil, return. If password equal to equal to nil, return. Else do something, right? God is a new keyword that lets you bail out of a function earlier without using a if statement, OK? Because Swift adopts all this functional programming paradigm, they hate looping and if conditions, right? So God is one that lets you avoid using if when you are not really checking for a condition. Error handling with Swift uses a new syntax, slightly different from Java or any other error handling that you have seen. It's do, try, catch. It's not try, catch, finally. It's do, try, catch, OK? And because error handling now uses a keyword called do, the previously used do keyword, the do while loop, has now changed to repeat while, OK? Testability annotations. You can now mark this very important. How many of you write unit test cases? I don't. OK, one, two, OK. When you write unit test cases, you will have a problem where, like in Java probably, if you have written unit test cases in Java, you will probably mark every single function as public so that your unit test case suite can access those methods, right? But with Swift 2, you have a class called at testable. So you can import a package. You can import a namespace or you can import a complete class using at testable keyword that converts all internal classes to public, just for the testing suite. So your testing suite can see all your private methods and you can write test cases for all your private methods without exposing them to public, OK? Availability checking is a new API which will look at it in a short while. And then finally, protocol extensions. Protocol extensions, previously, when you had to add features to one of your classes, you used categories in Objective C, right? Protocol extensions let you create protocols that extend functionality of a given struct or a class, OK? First thing, migrator. Because there is a migrator, you can now use Swift 2 in your production code. How many of you have used Swift in your production code? Have you used it? No. I'm going to tell your boss, OK? Swift 2 is not like that. Swift 2, you can use it in production because there is a migrator, which means when next year when Apple releases Swift 3, your code is not completely lost. You can still migrate it to Swift 3. That's not like you have to rewrite everything from scratch, like what happened with Swift 1, OK? Error handling. Very interesting pattern, a quick and dirty code that illustrates this is this. There are some differences between try catch used in traditional programming languages like Java or C-sharp versus Swift. You start handling this by using a loop called do try catch, OK? Do, within a loop, say try a function. Any function that has the throws clause annotated in the function declaration has to be written with a try condition, try clause, OK? This syntax, do try something, catch error, that's all. In this case, NSJS1 serialization, when it encounters an error, it previously returned NSError pointer, right? It doesn't anymore. With Swift 2, it just throws an error, OK? The defer statement is very similar to finally, which means this statement will be executed regardless of whether this function throws an error or not. It's usually used for closing resources or if you're listening to a NS notification, you want to stop listening. Doing all the stuff, you do the cleanup stuff in defer, OK? So because now do keyword is used for try catch, the do while is changed to repeat while, OK? So what is the difference? There is no matching. You have to handle every error case. Like in Java, exception handling is kind of abused by most developers. They just do try catch exception e.printstacktrace, right? This is a very common pattern you see in most Java code. Try catch exception, the whole of any exception. And then just print e.printstacktrace, right? You cannot do that with Swift because there is no matching. You cannot do a global match for any condition. You'll have to catch one by one. And if you're catching one, you'll have to catch everything, OK? Also, I don't know why this is the case. There's no way to specify what kind of errors a function throws. There's only one clause called throws, that's all. You cannot specify what it throws. Something is missing, OK? I don't know if it is by design or if this might change in future. It's still new. You might see some changes here in Swift 2.1 or something. Testability, as I explained, there's a new annotation. If you use this annotation and import a class, you can start testing all the internal and private methods of that class. Availability checking, yeah? This is a code that you can use to see if a particular div, like previously, availability checking was complicated. You do something like if a particular function was available, then call that function, right? That's all fine. The problem with that technique is the function names are all written in strings. And because of that, you were able to call private APIs. We used to do that name mangling just so that I can use a private API, right? This new availability checking, you cannot call a private API anyway. You cannot create selectors from strings, arbitrary selectors from strings and call it, OK? This is actually a bad way to do availability checking, but I don't know why Apple is recommending this over the previous selector way or previously checking if a class is present and then instantiating or something like that. You might expect changes. You can expect changes in this, OK? You can also use, instead of if available, you can use God-available-else-return. So if it is not iOS 9, you can just do an early return using the God statement, OK? That's a brief introduction to what is new in Swift. The most important take back is start using Swift, OK? Because Swift 2 is much more stable. Xcode 6 crashes a lot when you're writing a Swift application. The most common crash was source kit service terminated, and your code becomes black and white. You'll not see any source code formatting. You cannot compile anymore. You won't get auto-complete suggestions, anything, till you restart Xcode. This was super painful when we started learning Swift last year, OK? With the latest release of Xcode 6, which is Xcode 6 point, I don't know the number, it was released in April, along with Swift 1.2. That fixed most of these problems. And with Swift 2, I still get crashes, but very, very rarely, OK? And because now you have a migrator, you can be assured that your code is not going to be wasted when Apple releases a new Swift compiler and Swift language feature. There will always be a migrator that helps migrate your application to the latest one. The reason why I'm asking you to adopt Swift is next year, you will have features that can be used only through Swift, maybe, OK? Maybe when Apple releases a TV, they'll say, only Swift or binaries can be deployed to an Apple TV. They can do it. So you will be like, what? That's all, OK? That also means if your company you're working for is using Objective C and have no plans to adopt Swift, you're going to be out of job in a couple of years. So you know what to do now, right? Start learning Swift and start using Swift at least by December this year, OK? And when I say December, it's already going to be like I was 9.1, 9.2, and above. Many open source libraries will be available for Swift by then, OK? And if you're still using Objective C, it's like going to be dated, OK? I was actually expecting a slower adoption curve for Swift. Back in 2000s, when Microsoft was still using VB and C++ and all this stuff, they migrated to C-Sharp, right? And that adoption curve was like since 2001, they started. And then by around 2007, almost everyone was using C-Sharp. It took six, seven years for Microsoft to move all developers over to the new programming language. But for Apple, it seems like it's going to take three to four years, and this is the second year. So by next year, almost like 50%, 60% of developers will be using Swift. In fact, this year's WWDC, almost every single source code demo that Apple has uploaded are all in Swift, 90%. But previous year, WWDC 2014, when Swift was introduced, not even one single application, one single demo app was in Swift, because Apple know that they are going to change. So they did not invest time creating those applications that are going to be wasted, right? But not anymore. It's becoming a very important language, and Swift is getting open sourced soon, not yet, but soon. When it is open sourced, you will even see Swift being used on servers, just like Golang or something. There will be new runtime interpreters and compilers target that lets you use Swift in other completely different platforms, including Android. All these cross-platform tool developers, like those who've been using cross-platform tools to make applications that run on iOS, and all these guys will start making tools that let you compile Swift code for Android and Swift code for Windows Phone. I mean, this can happen probably in a couple of years time. But yeah, it's eventually going to happen, which means you cannot ignore Swift anymore. It's a very important language. Start learning it. The advantage of being an early mover is that you have much better understanding with Swift five years from now, if you start learning now, learning today. Questions on Swift? Nothing? The last part of the topic is Xcode 7. Not that important. Not so many changes in Xcode 7, per se. The most important change with Xcode 7 is the way it does app thinning. App thinning is not just for images. It's for binary as well. When you compile an app today, you have something called valid architectures. You select something called valid architecture and say, I want to support ARM V7, ARM V7S, and ARM64. But with app thinning enabled in Xcode 7, you don't have to choose an architecture. What instead happens is Xcode 7 compiles your application into intermediate code, very similar to Java byte code or C-sharp's common language runtime code, CLR. And this code gets uploaded to iTunes Connect. The App Store application downloads this, compiles it into the native binary of that phone, which means your application, you don't have to resubmit your application whenever Apple releases a new device. Your app will just work. Like for example, when Apple introduced 64-bit iPhone, almost 90% of the apps on App Store, on day one of their launch, 90% of the apps were not running on 64-bit processes. They were running on downgraded 32-bit equivalents. This problem will not happen with the new app thinning. You upload a byte code, you upload a bit code, the App Store compiles it to assembly, to a binary that runs the most fastest on that particular device that downloads your app. Bitcode is going to be, yeah, with more and more processes, like watchovers has a different processor from my iPhone. So if my app supports iPhone, iPad, and Apple Watch, I'll be shipping a fat, fat, fat binary with all these three architectures. Arm V7, Arm V7s, Arm 64, I know what architecture Watch uses. So with bitcode, you just submit one bitcode to App Store, to iTunes Connect. iTunes Connect automatically compiles it for you to the respective platform. Important thing, for watchovers, you can no longer submit Arm V7s, Arm 64 binaries. You will have to compile it using Xcode 7 to submit it to App Store. If you want to run your application on your watch, traditionally till watchovers 1.0, your applications were not running on the watch, right? Your applications were running on the phone, used watch as an external screen, right? That's how your watch was. But with watchovers 2, you can run applications right on your watch using the watch's GPU and CPU. And that requires that you submit your applications as bitcode. On iOS, bitcode is optional. You don't have to submit it. But it is selected by default for all new projects created on Xcode 7. And eventually, Apple is going to say, all applications submitted to App Store from so-and-so date has to be compiled using, compiled to bitcode. And then you'll have to do it. You don't have a choice. So bitcode is very important. It's one of the major tweaks that made your code platform independent. You can write your code today that works on any platform of Apples, including any upcoming new platforms that they create. It could be TV. It could be a new Mac that runs iOS applications or whatever. So what is there in future? 10, Swift 3, and Xcode 8. I'm expecting some new things to happen around ATS, App Transport Security, because HTTP 2.0 or HTTP 2, they don't want to call it as 2.0. They just want to call it as 2, because it's not a version number. HTTP 2 mandates that every website uses secure transport layer SSL by default. And that means ATS will have some changes, possibly mandating that you can no longer create an NSURL session with HTTP colon slash slash protocol at all. Appthenning, you will see a lot and a lot more changes to appthenning because there's going to be new devices, new platforms, stuff like that. Again, bitcode, same thing. Swift 3 will become super popular by next year. And the usage of Objective-C will go down. That doesn't mean Objective-C is going to be dead. We still use C in our iOS applications. How many of you have done core text before iOS 7? You use C. How many of you have done TCP-based networking? FTP, clients, or something like that. Core foundation, core network. Uses C. So you will still be using Objective-C. But the amount of Objective-C code that you write in your application will drastically come down. Today, it's 100%. This year, probably, you will be using 30% Swift and 70% Objective-C. But by next year, around this time, you will probably all be using Swift. And two years from now, people will not even know Objective-C to that extent. Like today, if you ask anyone if they have written C, C++ code in their iOS applications, almost 99% of developers will say, no, you probably did it, right? No? You will see better availability checking in future. Newer devices and how Swift lets you adapt your code on all these devices. So watch out for all this over the next few months or years. That's it. Questions? Yeah. Storyboard merge conflict, OK. With Xcode 6, you probably will not end up with a conflicted storyboard as it used to be. The most common conflict happens when two developers are using different versions of Xcode. So when they open your storyboard file, the storyboard file has something called version number that gets changed every time someone even looks at your storyboard file. That is fixed with the latest release of Xcode 7, OK? The next important stuff that you have to understand is, don't create one single storyboard for your entire application. If you do that, then I cannot help you. No one can help you, OK? I've seen storyboard with like 70 view controllers. Imagine, 70 view controllers. There isn't even a search function. You cannot even go to a single view controller. And on the other end of the spectrum, there are developers who create one storyboard for every single view controller they use. So don't be like that, OK? Storyboards are like this. For one given use case, you should use one storyboard. For example, an app that shows a splash screen, a landing screen, login, sign up, forgot password. All these screens can be combined together into one storyboard, OK? Your main screen settings and all those stuff that you navigate from your first screen can be in another storyboard, OK? Any activity that the user performs, like for example, if I'm making Instagram kind of application, the camera flow can be on a different storyboard. It makes sense in two ways. One, less emerge conflicts because someone who is taking care of login-related issues or enhancement features will not be working on your storyboards. You probably will be working on, like, assume that there are two developers, one developer is working on camera, the other one is working on login. So if he modifies and commits his login storyboard, you will not be affected. But if all of them are merged into one single storyboard, you are going to be in hot soup. It's going to be problematic, OK? So break your storyboards into multiple smaller storyboards. Identify use cases, identify the boundaries, and then do it, OK? The best part, Xcode 7 doesn't alter your version number inside your storyboard anymore. So you can, you know, previously I used to recommend that all developers should use the same Xcode version, including the minor version. If it is 6.3.2, everyone should be on 6.3.2, otherwise it's going to be messy. This guy opens it in 6.3.1, commits his storyboard, and then the other one cannot open it anymore. Like, there will be much conflicts inside it, right? This problem will not happen anymore with Xcode 7. It's fixed. Yeah. The only way to avoid storyboard conflicts is by making sure that your storyboards are broken down into multiple different storyboards in a way that different developers will be working on different storyboards, that's all. Does it answer your question? Yeah. Any other? Anyone else? Yeah. Yes. Yes. You can still target iOS 8 and iOS 7 with Xcode 7. The adoption rate for iOS 8 was not significant, like the previous releases, because iOS 8 was slow. iOS 7 and iOS 8 was slow to run on all devices. But iOS 9, because of the refactoring and performance improvement they did, Apple claims that it can run even on iPad 2 that was released in what, 2011? That was a four-year-old device, which can still run iOS 9. And what Apple claims is that it's going to be faster than iOS 8. So if it is really faster, people will start upgrading their application. Start upgrading to iOS 9. And that also means you don't have to target iOS 9, 8, 7, and so on. It's actually very, very hard to support more than two versions of operating systems on iOS. Because they keep adding too many new features, and all those fancy applications start adopting those features, and your boss wants those features. So it becomes harder. Questions? That's all. And just on time, 8.55, last one. Thanks.