Good afternoon, everyone! Welcome to the new UIKit support for international user interfaces session, my name is Sara Radi I'm a international utilization software engineer, and I'm one of those people who would really love to use your amazing app in my native language, but I just can't find great apps in the App Store localized.

My native language is Arabic. And I grew up in a country, where we didn't write right from right to left. And before Smart Phones became so popular, we didn't have to think about layout in right to left. So basically just supporting the text rendering and the font was enough.

However, today, with all of these electronic devices, people are using more and more eBooks, and they are interacting more and more with their devices. So supporting just the text in your apps is not enough and it becomes very important to think about the layout and the flow of your app when supporting these localizations.

And just like me, there are a million of users who wants to use their apps in their native language. This is a huge opportunity for you to grow your markets in these areas of the world. This is an example of an Apple ad in Dubai in one of the largest buildings in the world, and this gives you an idea of Apple's presence in the Middle East.

So what are we going to talk about today? So mainly we are going to focus -- I'm sorry. Mainly we are going to focus on right-to-left user interface challenges, and then we are going to introduce the new UIKit support. We added the native UIKit support for right-to-left languages so we made it seize easy for you to support right-to-left with no effort.

And then we are going to talk about your custom layout and how can you add right-to-left support in your custom layout with auto layout, and then we are going to introduce new APIs that we just added on iOS 9 and talk about exception cases and hopefully by the end of the session, I want to see more apps localized in Arabic in the App Store, and Hebrew. I'm sorry. So let's get started with an overview. So when you are designing your app in left-to-right languages or in English, for example, you always start by placing the most important elements on the left side of the screen.

And then you if have, like other elements, so they would flow naturally left to right. And the reason why we do that, is because the layout itself it starts to, [follow] the reading and the writing direction of the script. So it makes total sense if you are designing your app in right to left, to flip the layout and this is because the scripts read and write from right to left.

And the UI mirroring concept does not only apply to static UI. It also applies to dynamic UI. For example, in your app, if you have navigation gestures and animations. For example, so here the back button is always on the left side of the screen. So when writing in a right-to-left environment not only the back button should be on the right side, but also the gesture and the animation that comes with it.

So what's new in UIKit. So on iOS 9 UIKit sender controls fully support user interface mirroring. Which means when your apps are running in right-to-left localizations they will flip automatically for you. Also the whole system and all our native apps fully support right-to-left UI so your apps should be consistent.

So let's go through some standard controls in our native apps. Let's start with UI table view. So this is an example from the Settings app, where we are using a stock UI table view. As you can see here we are running the device in English, so the icons are on the left side of the screen, the labels are left aligned, and the table view accessories are on the right side, so changing my language to Hebrew, for example, will flip the table view cells automatically for me so all of the icons now are on the right side. The text labels are right aligned on left of the icons, and the table accessories are on the left side.

Next navigation controller. And this is an example from the phone app where you can see the back button now is on the right side of the screen and also the navigation gesture and animation comes from the right edge of the screen. If you look closely, also the UI table, the UI tab at the bottom also flips so now favorite is on the right side.

Next, tracking gestures, this is another example of a UI table view in the clock app where you can see the slide, the swipe to the lead gesture is coming from the left edge of the screen. If you use a stock UI table view and enable the swipe to the lead gesture -- that comes for free.

So, how can you enable right-to-left support in your apps? If you already have this localizations in your app, all you need to do is link against iOS 9 and test your apps, make sure that your custom layout works as expected. However, if you are adding this localizations for the first time, so we recommend that you move your storyboards to base approach with auto layout and when you add the localizations, XCode with create basically strings fast for you so you can export them, send them to translations. When you get them back, you can import them via XCode again and when you run your app at run time, you will see that your translation is integrated automatically as well as your layout is flipped.

So now let's talk about testing. So XCode makes it so easy for you to test right-to-left layout without even having the localizations or integrating the translations. So if you go to XCode scheme and you change your application language from system language to right-to-left to do language, that will simulate a right-to-left environment for you and you will have an idea if your app is ready to ship or not with right to left. And to show you, all what we just talked about now. I am going to call my colleague Aaltan Ahmad on stage to give you a demo.

Great, thank you, Sara. I am going to show you an example of an app that I wrote, a simple recipes app that I wrote that I want to add a right-to-left localization for and I will show you how easy that can be with the new stuff we have added to iOS 9. Here is the app. It's pretty straight forward. There is a table view, a tab bar at the bottom.

If we tap one of the cells we get taken to the details view for the recipe. Here we have some custom labels and stuff like that laid out using auto layout and a collection view to show off some pictures of the recipe that the user is about to make hopefully.

So now that we are ready to add a right-to-left localization to our app we actually want to see what it looks like first, before even integrating any of the translations, or doing any of that work, we want to see what our app looks like with the new changes we have added. To do that as Sara mentioned I will go to the edit screen menu in XCode and from the application language drop-down, will select right-to-left pseudolanguage.

This basically has the effect of bringing in those UI changes without loading any of the translations. And it has the added bonus of if I'm not a native right-to-left language speaker I can see my app in English with the right-to-left UI and not need to learn those languages or have a native review before I do any translations. So I'm going to close that and I will run the app again.

That's it. So without writing a single line of code, I have introduced all of these changes into my app and I can see that things look great. So let's go through our app and see what changes we got. So because I was using a standard table view cell type, I, the text label is over on the right side. The Chevron is on the left side and points to the left. Even the tab bar at the bottom is flipped. So the first tab is now on the right-most side as a right-to-left user would expect.

If you look at the navigation bar, the navigation button that was on the right side is it now flipped over. And if I tap on one of the cells, I can see that because I was using auto layout, with leading-to-trailing constraints, that entire UI is flipped along with the text alignments.

The cool thing here to notice is that the collection view -- because I was using a stock collection view with the default collection view flow layout -- has also flipped. So the first picture is now on the right side and the subsequent items follow to the left. As Sara pointed out, the navigation is also reversed. If I click this back button, you can see it takes me, the navigation comes over from the right edge, and in fact, if we try to swipe, we see the same effect.

So, great. I have checked out my app with these new right-to-left changes and I have seen it looks great and I'm ready to add the translations. So let's add the translations and see what the process looks like. So, I am going to select my project, in the project navigator, I will head to the editor men, and here you can see there is a few localization-related options, so I will go to add localization and I will pick Arabic. So XCode presents me with a dialogue and it does its thing. This basically creates the localizable resource files that I need to have translated.

The next step is to actually export the strings from my project, so we go back to the editor menu and hit export for localization. XCode asks me where I want to do that. I select the desk top, and hit save. XCode has now taken the all of the strings from my project, packaged them up into an XLIFF file which is a common file format for software translations, and put that file on my desktop. I can take that file and send it to a translator, who will go and make the correct translations for me and send me back a translated XLIFF file.

So very sweet, the translator, they do the work. I'm ready to import the localizations, I go back to editor, import localizations, go to my translated XLIFF folder, and here is my Arabic or XLIFF with the translations, hit Enter. XCode goes and takes all of those translations and integrates them into my project.

And now we have both the UI, and the translations ready to go. So final step, I'm going to go back to the edit scheme menu, and this time instead of right-to-left pseudolanguage I will select Arabic, which shows up because I wrote the localization. Close. Run the app again.

So there you have it. Now, I have my translated strings, my navigation controller title is translated. My tab bar items are also translated into Arabic as the user would expect, and I'm able to offer a complete right-to-left user experience for my Arabic-speaking customers, and in fact the bonus item here is because I was using date component formatters to format my prep time and cook time durations, I actually get localized versions of those as well.

So shameless plug for using number and date formatters. And that's it. That's how easy it can be to bring your app, your existing right-to-left-- , existing left-to-right apps over to right-to-left. To talk to you a little bit more about how you can bring your custom UI over, I will hand it over to Paul.

So as you just saw from Sara and Aaltan, if you are using stock UIKit controls it is very easy for you to add a right-to-left localization to your application. But what if you have something a little bit more complex? First, before we jump in, I just want to go over some API changes that we have made, if you are customizing UI controls, that make it easier for you to support right-to-left localizations.

If you are using UI text fields, left view, right view, left view mode and left view mode are automatically mirrored for you in right to left, so you don't need to do anything else. The only thing to be aware of is that rect for bounds methods, they'll stay unchanged. For table views if you are setting separatorInsets, the left and right measurements will automatically be flipped for you, with no additional work on your part.

If you are using a slider, the minimum and maximum value images are automatically flipped for you, because in a right-to-left context, the minimum of a slider is on the right. The only thing you need to be aware of is that the rect for bounds methods, while they are flipped, if you are customizing the offsets on the x-axis, you'll need to make sure those are properly accounting for right to left, if you are running in that context.

And finally for a navigation bar like you saw in the demo, we are flipping left bar button items and right bar button items for you automatically, but if you are adding subviews outside of those APIs, you will want to make sure that those are properly positioned, as otherwise you are going to have overlapping content.

So let's talk about some different types of custom UI that you might have on your application and how to handle those correctly. So like you saw earlier, standard cell types will flip for you automatically with no additional work needed. What that means is that, if you have custom layouts, you will want to make sure those are flipped as well, to be consistent with the rest of the OS, as well as potentially, other table view cell types in your own application.

You can of course do this by simply mirroring the frames in your layout, but the recommendation that we give is that you simply use auto layout with leading and trailing constraints because this requires no additional work on your part, and you can have the exact same interface and code handling both left to right and right to left.

The story is quite similar for collection views. So, like we saw in the demo, collection vew flow layout automatically supports right to left and just reorders the items to flow from right to left. What that means if that if you are doing a custom collection view layout you will want to make sure it's properly flipped on the x-axis as well.

Generally, what we recommend today is you subclass collection view flow layout instead of writing your own layout code from scratch. And there is actually a session that will happen tomorrow in the afternoon that talks about how to do this well, as well as other customizations you may want to do in Cocoa Touch.

Now, we have said the word auto layout a lot of times already throughout this presentation, but maybe you are not familiar with this technology. So Auto Layout is a way to position elements in your UI, instead of using frames, using a set of constraints. It's been available since iOS 6 it makes it much easier for you to support different screen sizes both iPhone and iPad, as well as different size classes. With the new split-view multitasking, it makes it that much easier to make your application compatible with this new technology.

Finally, even before right to left, Auto Layout makes it easier for you to support additional localizations because once you have a good set of constraints, adding a new localization is just a matter of translating strings, and you don't need to write any special code to properly handle the layout. If these are the constraints that I have in XCode, it looks exactly the same in English, of course.

When I'm running in Russian is might look like this, and if I go and decide to add a localization for a language that's double the length of the English one, I don't need to do anything extra, because the constraints are handling all of the positioning of the UI for me. Today there is one more reason for right to left.

Now, your layout will also just automatically flip, and you don't need to do anything extra. Now, you can use auto layout both in storyboards, as well as in code, as well as a combination of the two. So you can have outlets to your constraints and storyboard, and then manipulate them programmatically when you need to change your UI for some reason.

So we have talked about leading and trailing. Again, maybe this is something you are not familiar with. Basically if you have two labels side by side and you have horizontal constrains between them you can specify them either as left to right or leading to trailing. The difference is that left to right stays left to right all of the time.

Leading to trailing on the other hand, looks like left to right in a left to right localization, but it will actually mirror your UI and layout in a right-to-left localization. If you are creating constraints in storyboards, when you create horizontal constraints by the default, they will already be leading to trailing so you don't need to do anything else.

Similarly if you are creating constraints in code and you are using the visual format language, there again the default for horizontal constraints is going to be leading to trailing. However, if you are creating constraints explicitly, or using the new layout anchors API in iOS 9, there you will want to make sure that you are selecting the correct attribute when you are creating your constraints.

Animations, as you saw in the demos, are flipped for all of the stock controls. What that means is that if you have custom animation in your UI, you will want to make sure that's properly flipped as well. Again, of course, you can use frames if you want, but the recommendation that we have is that you use Auto Layout with leading and trailing constraints instead, and simply change the constant value of those constraints, which will automatically do the right thing for both left to right and right to left without requiring any additional code. Here is an example of how this would look.

Let's say I want to change the constant value of one of my constraints. I have a duration here. I will change the offset to a different value. Before doing the animation, I call layoutIfNeeded, to make sure that the frames are in the correct position to begin with. Then I call an implicit animation block, inside which I change the actual constant value of the constraint, and call layoutIfNeeded again. This will update the frames and because it's inside the implicit animation block, it will also animate that change.

You will notice here that there is no special casing for right to left, or left to right, it's just a single set of code that works perfectly in both contexts. Now, let's talk about gestures. Now, like you saw again for table views and for navigation, we flip the standard gestures.

However, the gesture recognizer API itself remains unchanged. The reason for that is because gesture recognizers on their own are fairly abstract, and at the framework level, we have no way of knowing what your using the gesture recognizer for. So what that means for you as a developer, is that you just need to be aware of when you are using gesture recognizers, and when you are responding to gesture events, what you are actually using them for.

So, for example, if you are using your gesture recognizer to draw on the screen, you will want to keep that as is because speakers of right-to-left languages don't draw backwards. However, if you have a custom gesture recognizer for your table view cells, for example, you will want to make sure you flip that because the layout of the table view style has been flipped as well.

Similarly if you are using navigation gestures, you will want to flip those, since like we saw earlier, back and forward are actually reversed. The main thing to remember here is that no matter what you are doing you will want to make sure that the gesture tracks the UI that's under it appropriately, and you don't get a situation where you are swiping from left to right but the UI moves from right to left, because that would be very confusing. If you use Auto Layout this will make your job much easier. I would like now to invite Aaltan back up on stage to give you a demo of the stuff that we just talked about.

Thanks, Paul. So while Paul was talking, I thought a little bit about my app and I decided that I wanted to add some more custom UI. So I went ahead and created a cool custom table view cell subclass that I laid out using Auto Layout.

It's pretty straight forward. There is some more informative text labels in the row and there's a nice image so the user can see a picture of what they are about to cook. There is also this cool little favorites view on the left side that the user can drag out by swiping across the cell, similar to the stock swipeToDelete gesture that we have on table view cells right now. If they pull far enough, a little star appears on top of the image in order to show them that they favorited this recipe. So let's look at what this looks like in left to right, in English.

So, great, my app looks like lot more vibrant and inviting right now, so there is a picture, there's some more text labels, and in fact, if I pull the cell out far enough, the favorite view is revealed, and if I complete the gesture, the little star shows up.

Great. And while Paul was also talking I had a chance to learn the entire Hebrew language and add a Hebrew localization to my app as well, so for this demo we are going to be running in Hebrew as our right-to-left language. So I will go back to the edit scheme menu, and this time select Hebrew, hit enter and run the app.

Wow! It's because I was using auto layout with leading and trailing constraints, everything just flips. The image is now over on the right side. The text labels are all right-aligned in the correct position. The Chevron, of course, is stock so that stays where it is, and again, formatters plug, my durations and numbers are correctly localized for Hebrew.

But we didn't look at the custom gesture yet so let's check that out. Because the entire cell is laid out from right to left, the user is also expecting that the swipe for favorites will be in that direction as well, and more so because the swipe to delete gesture system-wide, is flipped. So they are going to know that that comes over from the left edge and whatever your custom gesture was they are going to be expecting it from the right.

So let's swipe in that direction and see what happens for a right-to-left user in that case. And you can see that things don't work as expected. I swiped, but instead of revealing that view, the table view cell thought I was tapping on it, and instead presented the details view. It doesn't make too much sense.

And the reason this is happening is because there is an implicit assumption in my code, off the directionality of that swipe. I'm expecting the swipe to go from left to right. Or, in other words, in a positive X direction. In fact, if I go and swipe in that direction, you can see that the view does reveal itself. However, it reveals itself in the direction opposite to the direction that I'm dragging my finger, and that doesn't really make any sense to the user. And you really want to avoid situations like this.

So let's jump into the table view cell subclass and see if we can figure out what's going on here. So here you can see I have two gesture recognizer-related methods. So the first is this gesture recognizer should begin method. And the reason I have to implement this is because like I said, I want to support both that custom gesture, as well as a stock table view gesture. What goes on here if the user swipes in the direction of my gesture, I allow my gesture recognizer to begin, and if they swipe in the direction of the swipeToDelete, I don't do anything and I let table view handle that stuff.

So right here you can see I have the X translation of the gesture recognizer and if that translation is greater than zero, or left to right, I go ahead and begin my gesture recognizer. So what we really need to do here, is check if we are running in a right-to-left localization, and if we are, we need to look for translation in the opposite direction.

In order to figure out whether I'm running in a localization in a right-to-left localization or not, I will use new API that we added in iOS that Paul is actually going to talk about shortly, but since it's exactly what we need right now, I will go ahead and use it. So I will declare a new constant called isLeftToRightLayout And I'm going to use a new user interface layout direction for semantic content attribute, API, that we added in iOS 9 and I am going to parse in my view semantic content attribute.

This returns the resolved layout direction, left to right or right to left for this view, and if that direction comes back as left to right, I know I'm running in a left-to-right localization. So next step before checking that translation, I will look at my isLeftToRight variable. If it's left to right, we continue as usual. If it's right to left, we look for a translation for less than zero or in the negative X.

The second method here, is this updateFavoriteButtonPosition method. So here is where we actually manipulate the constants of the constraints and show that view on screen. Here you can see against I have should allow dragging favorite button constant that allows-- that tells the following code whether it should start revealing that view, and, again, similar thing, we are checking for a positive X translation. Solution is also similar, we can just pick up this check, bring it over here, and check for the left to right layout, and check for translation in the opposite direction, and right to left.

The last bit over here is this distancePulled variable. So the distancePulled variable, or constant, is telling the following code how far the user has dragged their finger across the cell. Now that we can accept a negative translation it doesn't really make sense for the distancePulled variable to also be negative because it's conveying sort of an absolute value, so to rectify that, we are going to just take the absolute value of the translation as well. That solved that problem for us. With those few changes let's run the app again. And see where that got us.

Okay. Things look good here still. Now, if I drag my finger over, things work as a right to left user would expect. So really that's it, you really just need to make sure you are watching out for these kinds of assumptions in your code, and really just accommodating for the right-to-left keys, which oftentimes turns out to be something that's really just that simple. And that's all it takes to bring your custom gestures and UI over to right to left. To talk to you a little bit more about some exceptions and best practices, back over to Paul.

Alright, Thanks Aaltan. So let's talk about some exceptions and some of the new API that we have introduced in iOS 9. One of the things we saw in Aaltan's demo was the semantic content attribute API so before we get into that let's talk about what semantic content attributes are.

The semantic content attribute is a new property on UI view, and it's there to make sure that all UI looks correct in right to left and left to right because in some cases not all of the UI flips and we need to make sure that we have a way to specify that. Now, the default semantic content attribute is unspecified.

This will flip in a right-to-left localization and stay as is in a left to right localization. But we have some additional attribute types that you can set, that will prevent the flipping from happening, for a number of historical and other reasons, but they manage the expectations of right-to-left users.

Finally, the resolution of leading and trailing constraints is actually based on the semantic content attribute. So that's just something to keep in mind. So the first one is playback. The idea here is if you have some sort of playback control, you sub the semantic content attribute of that control, or that group of controls, to be playback, and that will keep them left to right. So you can see here in the new music app, we have the progress bar as well as the playback controls, they stay left to right. They do not flip.

The next one is spatial. This is for annotating controls that correspond to some sort of direct UI manipulation where maybe you have a D pad in your game and you press up and it goes up. You press left, it goes left, or similarly for text alignment. So here we have on the pages app, a segmental control that lets you set the alignment of your text. Left-aligned text will still stay on the left side, even when running in a right-to-left localization, so we keep that as is.

Finally, for those of you who want to be more explicit, we have these forceLeftToRight and -RightToLeftand right-to-left attribute types, and they just do what you would expect from the name. The forceRighToLeft one will actually affect layout in a left-to-right localization. All the others only have an impact when you are running in right to left.

And the only thing that I will say about these is if you feel like you want to use them, please come talk to us on the lab or post on the dev forums to just make sure you are doing the right thing and that the existing API doesn't quite satisfy your needs. or maybe we are missing API, there is another type we need to add, and you can tell us that.

I want to talk about some best practices for UI and text when you are supporting right to left. One of the things you want to make sure you are doing all of the time (and like we saw in the demos) is to use formatters. For Arabic this is particularly important because different Arabic speaking countries will use actually use different words for the months of the year.

So you will want to make sure that you display those correctly to all of your users, no matter what region or language they are using. In fact, there is a What's New in Internationalization talk tomorrow, bright and early at 9:00 in the morning, where they will talk about all of the existing formatters as well as some of the new formatter APIs that are available in iOS 9.

However, you will want to make sure that if you have some sort of layout or logic branching like we saw for the gesture recognizer, you never want to use NSLocale or NSbundle or NSFormatter for determining that. So perhaps you have seen code like this. You want to figure out if you are running in a right-to-left localization.

You look up the preferred languages, you pick the top one and if its writing direction is right to left, boom! This is something that you literally never want to do. There is many ways that this can break. It's just not what you want to be doing. If you want to find out that your application is running right to left.

Instead, you'll want to use this new API we saw in the demo. User interface layout direction for semantic content attribute, and pass in the semantic content attribute of the view that you are interested in figuring out how it's being laid out. And that will give you either left to right or right to left as the UI layout direction.

Of course, the converse is that you shouldn't be using this for regional or format settings. Now, here is a sample that matches sort of the intent of the previous slide but is actually correct. We get the semantic attribute of the view, we ask for the layout direction, and if that happens to be right to left, we do custom logic, perhaps.

Now, when dealing with text, what you will want to do is just leave alignment and directionalty at their default values most of the time. So, new in iOS 9, natural alignment is now the default so you don't need to do anything to have text that is left-aligned in left-to-right languages, and right-aligned, in right-to-left languages.

Similarly the base writing direction is something you should never have to touch unless you are writing a text editor. That has been the default since iOS 7. For probably 99% of applications there is no reason you should ever need to touch this value and change it from default. Again, you don't want to use these for layout code branching. Instead use the API that we saw in the previous slide.

Finally, I would like to talk about images so we have new API and UI image called imageflipped for right to left layout direction. What this will do is this will horizontally flip the image automatically for you when you are in a right-to-left context. So an image flipped for right-to-left layout direction will stay as is in left to right, and then flip in right to left.

This also based on the semantic content attribute of the image view that contains the image and generally speaking, you will want to use this only for directional images or something that conveys some sort of UI. So people who speak right-to-left languages they don't look at all their photos in the mirror. So if you see errors or Chevrons in your application, like for example, we have in the Safari toolbar, for the back and forward buttons, you want to make sure that those flip, because all of the directionality concepts have flipped from right to left.

Similarly, if you have some sort of icons that represent UI, for example, a list, so in the new maps app in the transit feature, we have this icon that lets you see the list of steps because that sort of represents the table view, and in the table view, the icons are on the right side.

You can see the icon has been flipped, and more subtly we have also flipped the person for the walking directions because if we didn't, it would look like the person was just walking off the edge of the screen, and it wouldn't really match the rest of the layout file. So I would like to invite Aaltan back up on stage to give you a quick demo of that.

Last demo, I promise. All right. So, great! I just learned a lot about the new, cool new APIs we added and I decided to take the customization of my custom table view cell to the next level, by adding a custom Chevron that is indeed a pizza slice, so the pizza slice will be directing our users to go on to the next screen. And since we are all really familiar with the right to left by now, let's run our app directly in Arabic without showing you what it looks like in English, since we are past that point.

Great. So because I put in that image view with the pizza slice, using auto layout and leading to trailing constraints, it actually is in the correct position. It's over on the left side of the cell, where a user on right to left would expect it. However, clearly you can see that the pizza slice is pointing in the wrong direction. And this is exactly the kind of directional image that Paul was talking about earlier, that we can use the image flipping API in order to rectify. So let's go back to that table view cell subclass.

And here you can see I have my [unintelligible] method where all of those outlets, all of my outlets will be loaded and ready to go, so the first thing I'm going to do is get a reference to my custom Chevron image. customChevronImageView.image. Now that I have that, I'm going to put it back in the image view, except with one small change, which is I'm going to call the image flip for right-to-left layout direction method on the UI image itself.

And this basically has the effect of leaving your image alone in a left to right localization, but flipping it horizontally in a right-to-left localization. And the important thing to note here, is that because the method does the right thing for you, you don't need to worry about gating it around, and is it left to right or is it right to left check, as I was doing earlier. So you can do call this method with confidence in any localization, and you can be sure that it will do the right thing. And that's it, that's all we need to do. With that change, let's run the app again.

Pizza perfection. So our Chevron is flipped [applause]. Thank you. Our Chevron is flipped, our app looks great, we have the translations, custom gesture looks beautiful, and we are ready to go. That's how easy it can be to localize your apps right to left and back to Sara to finish up the session for you guys.

Thank you Aaltan for the great demo. So just to let you know we will be posting the demo that Aaltan gave us today online soon, so if you missed anything during the session, please feel free to download the simple code and look at it. So to summarize before closing the session, keep in mind when you are designing your app for right-to-left languages that natives of these language expect right-to-left UI, and this is a perfect opportunity with the new native UIKit support that we add it on iOS 9, it's a great opportunity for you to add this localizations. It takes no effort, and we also added new APIs that will make it so easy not only for non-native- the native developers, but also for non-native developers. And also it's your opportunity to reach millions of users and new markets.

And for more information, please visit our documentation website at developer.Apple.com we have documentation for internationalization and also for localization and if you have questions, also post them in the Dev forums. We also recommend that you go and watch these relates sessions. I highly recommend the What's New in Internationalization tomorrow at 9:00 a.m. so thank you, thank you so much for coming and have a great afternoon! Thanks!