앱의 다국어 경험 개선하기

مرحبا! (Marhaba) My name is Omar and I’m very excited to talk to you today about how to enhance your app’s multilingual experience. We live in a deeply multilingual world. You're no longer just building apps. You’re building experiences that need to work anywhere for anyone. Whether you’re designing a social app for people in Singapore and Southeast Asia, or a productivity tool for remote teams in London and the rest of Europe, or building apps for Beirut and the Arab world, language is never just text on a screen. It's culture. It's identity. And for millions of people, it’s also the difference between feeling included or feeling left out.

In iOS 26, we’re introducing many new features that make the multilingual experience even better.

And as developers, you can tap into these improvements to build more accessible, globally friendly apps. Let’s walk through some of these new features.

In iOS 26, Arabic speakers can use the new Arabizi transliteration keyboard. This means that they can now type Arabic words in Latin script, and then the keyboard automatically enters Arabic script for them. If you’re used to typing on the English or the French keyboard, this makes it very easy for you to type in Arabic. We’ve also added the ability for the transliteration keyboard to offer bilingual suggestions. This means that when you type an English word on this Hindi keyboard, iOS 26 automatically suggests the translation for it. We’re also introducing a new multi-script bilingual Arabic and English keyboard. If you speak both Arabic and English, it will now auto detect the language as you type, which simplifies the experience of typing in both languages.

Finally, we have a new Thai keyboard with a 24-key layout that makes the experience much easier for Thai speakers.

Internationalization is a fundamental first step in building apps for a global audience. With Apple’s powerful tools and technologies, including Xcode, Foundation APIs, and Unicode support, it's easy to prepare your apps to support multiple languages, even before you know which languages you’d like to add.

Before I get into our new tools and APIs for internationalization, I’d like to share some fundamental best practices on how to make your app multilingual ready.

TextKit2 makes it easy to support multiple languages in your app. It handles complex scripts like Korean or Hindi and gives you more control over layout and styling so that your text looks just right no matter the language. TextKit2 seamlessly manages bidirectional text. Later, my colleague Danny will introduce you to the latest advances for bidirectional text.

Formatters in Swift help you display dates, numbers, and text in a way that automatically adapts to each person’s language and region.

With just a few lines of code, you can localize everything from currency to date formats without writing custom logic for each locale.

There are many APIs in Swift that simplify the experience for managing different input modes like software and even hardware keyboards.

For example, you can use inputAccessoryView to place a view directly above the keyboard, or set textInputContextIdentifier to help the keyboard automatically remember its last used language and layout. For more details on TextKit, formatters, and text input, watch the video from last year linked below. You can also check out the associated sample code. Now, let’s get into some new APIs that enhance your app’s multilingual experience. We’ll introduce a new feature, Language discovery. Learn how to support Alternate calendars in your app and explore advances in handling bidirectional text. Let’s start with Language discovery.

Billions of people around the world are multilingual. In many regions, the majority of people use more than one language in their everyday lives. We believe that great apps need to consider the full range of the human experience. It’s crucial for people to be able to interact with them in their own languages. Before iOS 26, the only way for people to choose their languages was by manually adding them in the Settings app. We understand how challenging it is to do that. For example, my own iPhone is set to English, but my native language is Arabic. I listen to music and podcasts in Arabic. I read the news and send messages in both English and Arabic. So even though I’d like to have my iPhone’s user interface in English, I would love to get news, music, and podcast recommendations in Arabic.

In iOS 26, Siri is personal, proactive, and can offer intelligent suggestions to help set up my device in my own languages. Using on-device intelligence, Siri can recognize that even though I set up my iPhone in English, I text, listen, and browse in Arabic as well. So when I tap on Siri’s suggestion, I can choose to switch my iPhone language to Arabic, add an Arabic-English bilingual keyboard, and ask to get content recommendations such as news, music, and podcasts in my language. This experience applies to millions of users around the world who are multilingual and would love to get recommended content in their own languages.

Thanks to the Foundation framework, you can use Locale.preferredLanguages to get the list of the user’s languages and personalize your app’s multilingual experience. If you’re familiar with Locale.preferredLanguages, you will know that it returns an array of language identifiers as Strings. These String values conform to BCP-47 language tag.

However, it can be daunting and complex to handle and manipulate these String-based identifiers.

This year, we’re introducing Locale.preferredLocales, which returns an array of Locales instead that contains a superset of information compared to Locale.preferredLanguages. A locale represents both the language and the region, like English UK or English Canada. In my iPhone's use case, for example, the locale would be Arabic Lebanon. Using Locales is crucial for your apps to adapt to the right spellings, date formats, and currencies to better match your users’ preferences and better personalize their experience.

With Locale, you can still access the String-based identifier if desired, and even choose the precise format of the identifier, such as BCP-47, ICU, or CLDR.

You also gain access to a rich array of properties about the Locale. For example, you can get the numberingSystem or use the localizedString APIs to get access to localized names for languages and regions.

Locale.preferredLanguages may be deprecated in the future, so we would encourage you to switch over to Locale.preferredLocales instead. In iOS 26, we’re using preferredLocales extensively.

For example, the Translate app can now show people’s languages at the top instead of showing a long list of languages to select from. In Calendar, when an alternate calendar is set, the app can now show UI elements such as days and months in their languages. And lastly, Apple Music uses preferredLocales to recommend and offer translations for lyrics. This makes the multilingual experience even more personalized. This experience in the Translate app applies to many apps where people have to pick their languages from a long list of languages.

You can personalize the experience in your app by using the preferredLocales API and Foundation.

Let's get into the Translate app and build this experience together. Let’s consider availableLocales as the array of your app’s available locale objects. We will use matchedLocales as the array that matches people’s preferredLocales with your app’s availableLocales. You can then loop through the Translate app’s availableLocales. For every available locale, you can then check if that locale is in their preferredLocales. Once a match is found, you can add it to matchLocales and break. matchLocales can then be used to prioritize the languages and place them at the top of the list for easy access. To your preference, you can choose here to use isEquivalent or hasCommonParent.

Language discovery helps your app feel more personal, natural, and takes away the step of asking people for their languages. The use cases are endless, and we’re excited to see how you will use preferredLocales in your app. Now, let’s talk about the new alternate calendar APIs available in Foundation. With iOS 26, you can select from many new alternative calendars. For example, we now have alternate calendar options for Gujarati, Marathi, and Korean. These new calendars are available on all platforms. Now, in addition to the existing 16 calendar identifiers, we’ve added 11 new calendars that you can access using Calendar.Identifier in the Foundation framework.

We have exciting new updates on internationalization today. We've discussed language discovery and our new calendar identifiers. Now, I’d like to hand off to my colleague, Danny, to walk you through exciting new updates on bidirectional text.

Thanks, Omar. Xin chào. My name is Danny, and I am excited to discuss advancements in bidirectional text on iOS and iPadOS. These innovations have the potential to significantly enhance the multilingual experience in your app.

For a comprehensive understanding of bidirectional text, refer to the “Get it right (to left)” session. To begin, let’s review the definition of bidirectional text. When English is written, text flows from the left and concludes on the right. This writing direction is referred to as left-to-right or LTR.

When a language such as Hebrew is written, text flows from the right and concludes on the left. This writing direction is known as right-to-left or RTL.

When LTR and RTL texts are combined, the written text becomes bidirectional, which has significant implications for text selection.

To understand how text selection works in bidirectional text, we must first consider the order of the text that is displayed versus the order of the text that is stored. In this LTR example, the characters are stored in the order that they are written.

The characters in RTL text are also stored in the order that they are written, just like LTR text. However, the difference lies in how the text is displayed, which is right to left. This doesn’t pose any immediate issues because text can still be selected by simply flipping the selection method to select in descending order in storage as the selection is dragged to the right.

This will still result in a single contiguous range of text in storage that corresponds to what is visually selected.

The issue arises when we combine LTR and RTL text. The text is still stored in the same order that it is written, but it must now accommodate multiple directions when it is displayed.

If we restrict the selection to a single range of text in storage, text selection will no longer behave naturally.

For instance, if we initiate text selection by dragging the selection from the left to the right, the selection will no longer align with the cursor as it crosses the LTR and RTL boundary. Instead, it will begin selecting the text on the right side first, leaving an awkward gap in the middle of the selection. This occurs because despite our intention to select text that is displayed, the selection behaves as if it’s happening in storage. Since the text flow on the screen doesn’t match the text flow in storage, it’s impossible for the selection to be contiguous on screen and in storage at the same time.

In iOS 26, instead of forcing the selection to follow the storage order, we now allow the selection to naturally follow the cursor instead. Consequently, as the selection point is dragged, the selection closely follows behind it. We call this Natural Selection. Natural Selection ensures a seamless and consistent text selection experience, regardless of whether you’re selecting single directional text or bidirectional text.

With Natural Selection, the selection gap is no longer visible but is now concealed within the text storage. So instead of a single selectedRange, multiple selectedRanges are now required.

On macOS, NSTextView already supports Natural Selection by representing the selection as an array of values that are NSRanges. In iOS 18, UITextView has a single selectedRange property to represent the selection which can only express a single contiguous range. That means that in iOS 18, bidirectional text cannot be naturally selected without any visible gaps because the selectedRange will mistakenly encompass the range that wasn’t actually selected. In iOS 26, we have a new property called selectedRanges to represent an array of non-contiguous NSRanges, while the single selectedRange property will be deprecated in a future release.

The new SwiftUI Rich Text Editor also supports Natural Selection, where the ranges are represented as a range set of type attributed string index.

For more details, please see the “Cook up a rich text experience in SwiftUI with AttributedString” talk. Now as we had previously selected the bidirectional text, the selectedRanges will now accurately represent the text that was chosen. If your app has been performing an action that relies on the selectedRange, like deleting text from the TextView storage, it could inadvertently delete the incorrect range of text. Instead, you should use selectedRanges to ensure that only the text that was actually selected is deleted. In addition, we’ve updated the UITextViewDelegate and UITextViewDelegate protocols to accept an array of values that are NSRanges instead of a single range.

These methods are triggered whenever the text input system needs to modify the text within the specified ranges in response to text input. For instance, if you select text and then paste in a text view, the shouldChangeTextInRanges method will be called to confirm with the delegate that the text can be changed within the specified ranges before the deleted text is replaced with the pasted text.

Since the ranges are non-contiguous, there are multiple potential insertion locations. The text input system determines the appropriate location within the deleted ranges to insert the new text based on various factors, including the currently used keyboard. If the text should not be inserted into any of these locations, the delegate should return false.

Additionally, there are new versions of the editMenuForTextInRange method that now accept an array of ranges instead of a single range to more accurately represent the ranges of text for which the returned edit menu should correspond. By switching to using selectedRanges and implementing the new delegate methods, you can ensure that your apps work seamlessly with Natural Selection, enhancing the bidirectional text experience. To maximize the benefits of Natural Selection, your apps must utilize TextKit2. UITextView and UITextField already employ TextKit2 as their text engine, and now support Natural Selection by default in iOS 26.

However, if your app accesses textView.layoutManager, it will revert the text engine to TextKit1, disabling Natural Selection and other features. If you need to use layoutManager, please use textView.textLayoutManager, which is the layout manager for TextKit2.

Next, we will discuss the concept of writing direction.

To understand writing direction, we first need to understand text direction. Text direction refers to the direction of character flow within a continuous single span of text, while writing direction refers to the direction of flow of those texts within a paragraph.

The writing direction is determined by the direction of the first span of text.

For example, when LTR text is written first, the writing direction will be left-to-right. If RTL text like Urdu is subsequently typed, the text will be displayed on the right side of the LTR text because the writing direction is still left-to-right. Even as more Urdu text is typed, forming an Urdu sentence, the writing direction remains the same. This year, when left-to-right text is written first, the writing direction also remains left-to-right after right-to-left text is typed because it’s still considered an English sentence.

However, writing direction will now be dynamically determined based on the content of the text.

Which means that this year, as more Urdu text is typed to form an Urdu sentence, the writing direction will change to right-to-left. This automatic adjustment will occur within your app if it utilizes Apple provided text views and text fields on all platforms.

But maybe your app doesn’t use the Apple provided text views, but instead uses its own custom text engine.

If so, refer to the Language Introspector sample code to learn how to use new APIs to determine the writing direction based on the content of the text within your app.

We hope this new way of determining writing direction for bidirectional text will help to further elevate your app’s multilingual experience.

In this session, we’ve talked about some exciting new features that help to enhance your apps for a multilingual audience. Language discovery automatically detects preferred languages, making your app feel more personal and natural. Additional alternate calendars offer even more customization options to enhance the multilingual experience. And with the introduction of Natural Selection support on iOS and iPadOS, your apps now function seamlessly and consistently across a wider range of devices, catering to your multilingual audience.

I’m really looking forward to you creating opportunities to chat with your friends and family from around the world using bidirectional text. Thanks for watching.