New UIKit Support for International User Interfaces
iOS 9 brings complete right-to-left support for Arabic, Hebrew, and other languages. Going beyond basic text, your app's entire interface can now flip to provide a native right-to-left experience. Learn what behavior you get for free from UIKit, and hear details about adding right-to-left support in custom interfaces. Hear from experts about how to evaluate the readiness of your app for these languages. Understand best practices to avoid common pitfalls and to create a seamless bi-directional app.
SARA RADI: 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.
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
Which means when your apps are running
in right-to-left localizations they will flip automatically
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.
AALTAN AHMAD: 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.
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.
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.
PAUL BOROKHOV: 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
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.
AALTAN AHMAD: 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
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
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.
PAUL BOROKHOV: 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
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
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
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,
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.
AALTAN AHMAD: Last demo, I promise.
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.
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.
So our Chevron is flipped [applause].
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.
SARA RADI: 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!
Looking for something specific? Enter a topic above and jump straight to the good stuff.
An error occurred when submitting your query. Please check your Internet connection and try again.