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:
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.
