Translation API in iOS 18 and macOS Sequoia
In a WWDC 2024 coding video last week, Apple highlighted a recently-introduced API that allows developers to offer built-in Translate app capabilities in their own apps on iOS 17.4, iPadOS 17.4, macOS Sonoma, and later.
Discover how you can translate text across different languages in your app using the new Translation framework. We’ll show you how to quickly display translations in the system UI, and how to translate larger batches of text for your app’s UI.
Sequoia still doesn’t bring the Translate app to the Mac, so I’m hoping someone will use this to make a standalone app so that I don’t need to read translations within a tiny popover.
The new Translation API is such a massive disappointment.
It’s a purely SwiftUI API.
Even the programatic API to get back Strings from Strings (no UI) requires you to get a session object via SwiftUI to do so.
[…]
Really hope this isn’t a pattern Apple is going to use going forward in the future.
You don’t instantiate this class directly. Instead, you obtain an instance of it by adding a
translationTask(_:action:)ortranslationTask(source:target:action:)function to the SwiftUI view containing the content you want to translate, such as aTextview. When you do, the function passes you an instance of a translation session in itsactionclosure which triggers as soon as the view appears. After you receive this instance, use one of the translate functions to translate one or more strings of text.
I wonder if these sort of horrible API designs are a consequence of Apple building features with SwiftUI natively now?
UIKit allows UI to be presented fairly freely from around your code, due to the view controller hierarchy being easily accessed.
SwiftUI needs an element anchored to a View to do anything.
If that’s true, eventually virtually all APIs will need to be invoked via a method on View and I’m going to really hate the next few years of Apple API releases.
Previously:
Update (2024-10-07): Danny Bolella:
Curiously, the manner in which Apple forces developers to use Translation is strikingly passive aggressive: it can be accessed by SwiftUI only. This has been confirmed by an Apple Engineer who suggests UIKit apps would need to host a SwiftUI View if it would like to access Translation.
[…]
There are strong implications and signals to take from all this, even if a translation feature doesn’t apply to you. In fact, it has some of the strongest messaging regarding Apple’s recent stance on UIKit and SwiftUI.
[…]
There’s no doubt that UIKit and AppKit are not to be deprecated any time soon (or ever). But Apple has made it abundantly clear the tide will eventually turn towards SwiftUI, and they will make it so.
[…]
Translation also offers a glimpse into how Apple wants developers to view the relationship between concurrency and SwiftUI. When we obtain a TranslationSession through the programmatic route, it’s done so through a translationTask and offers function calls that are all async.
8 Comments RSS · Twitter · Mastodon
It's not great (consistent/intuitive) developer UI (API) if you consider the new Genmoji APIs rely on NS/UITextView/NSAttributedString (not AttributedString) and SwiftUI lacks an editable multiline textView except for TextEditor which does not support AttributedString or NSAttributedString (oh well, hands up in the air!).
Just another pathetic attempt to try to force SwiftUI on developers just short of doing so by gunpoint. It’s pathetic really. Don’t use it.
Requiring a UI framework to transform a string? This belongs in Foundation or another framework that anyone can call from whatever UI framework they want (or common line tool).
Anyone wondering how Safari uses the translation service: Soft linking to private framework TranslationUIServices. Looking for OBJC classes LTUISourceMeta, LTUITranslationViewController
> another framework that anyone can call from whatever UI framework they want (or common line tool).
***Or Command line tool*** Sorry I really need to stop writing these comments on my iPhone SE (too many typos on this little keyboard).
Apple has started integrating Swift into UIKit, and it’s terrible. First, the code is stripped, resulting in undebuggable mess. UIKit is crashing? Good luck figuring out why, because Apple decided to save 3MB of disk space. Clowns.
Next, the API design is absolutely abhorrent and completely alien to UIKit. Take a look at the new transition APIs:
https://developer.apple.com/documentation/uikit/uiviewcontroller/transition/4448132-zoom
This is what happens when you give a bunch of kiddies unfamiliar with now “oldschool” frameworks, such as UIKit, carte blanche to push whatever, because who cares right? Old UIKit developers will be so happy we threw them a bone this year!
To be fair, TipKit was announced at WWDC 2023 as SwiftUI only, but UIKit and AppKit support was added soon afterwards.
And just as I was reaching for Xcode to add the facility to Keyboard Maestro I read “It’s a purely SwiftUI API”. Say what now?!
I don't even have any Swift code, but I could probably manage a little wrapper function or something, but what?
Sigh.
I know I should expect no more from Apple, they stopped being “API-first, then UI on top” long long ago, but this is taking it to extremes.
