Any time a ScrollView scrolls, it calculates where it’s going to finish. You can “sneakily” steal those calculations, modify them, replace the originals, and see scrolling finish where you just told it to. Super secret subversion stuff. 🥷

This gets done by supplying the ScrollView with a ScrollTargetBehavior.
That’s going to be a struct adhering to the ScrollTargetBehavior protocol, implementing only one method:
func updateTarget(_ target: inout ScrollTarget, context: TargetContext)

In that method, ScrollTarget is a struct representing where the scrolling will finish. TargetContext will give you various info on the ScrollView - where it was when the gesture began, which way it’s scrolling, with what velocity, what the total scrolling content size is, and what the container size (visible view) is.

Because ScrollTarget is an inout parameter, we can modify it and make the ScrollView land somewhere else than originally intended.

Here’s what I did to make it center on each view (follow code in gist below, lines 49-53):

• took the top left coordinate where the scrolling was supposed to land and figured out which view that would be

• calculated the top left coordinate of that view

• figured out how much remaining space there is when the view’s width is deducted from ScrollView’s width on screen

• made scrollView land not on the top left coordinate of the view, but “half the remaining space” before it

Here’s the code:

Let Xcode extract all the phrases for you

Xcode has a menu command Product > Export Localizations… that leverages the compiler to find translatable text and to produce a .xcloc file.
Opening that file will launch a nice table-based Xcode editor for translations.

Translating is easier when the keys are English phrases

Text(“Workouts”) is better than Text(workoutsTitleTranslation) because it’s in place, it’s less code to write/maintain, and makes the .xcloc editor much more usable. Translators will always prefer reading English to processing abstractions.

Translating is more efficient in an organized workspace

When you make the effort to organize phrases by tables, work in the .xcloc editor becomes more compartmentalized, focused and efficient. What you group up by is up to you: It can be phrases within a tab, a screen, a module, a feature... whatever makes sense: Text(“Select all”, tableName: “Workouts tab”)

However, organizing into tables in code comes with a gotcha: the parameter for String(localized: table:) is called table, but the SwiftUI team decided to call it tableName in Text(_: tableName). It will be annoying throughout the process of updating your code, so you might want to extend one of those to match the signature of the other -- to your preference.

Add translation comments for every phrase

Text(“This year”, comment: “Button; sets dates…”)
Writing "descriptions" for every translatable phrase might seem unnecessary and tedious, especially if you're the only person working on the codebase, but nothing could be further from the truth. These comments are not for you (although they might help future you). The comments give context to translators, both human and AI. They help translations make sense to users. And if you want to excel in these, learn best practices from this WWDC21 video: https://developer.apple.com/videos/play/wwdc2021/10221/

Don't forget the "numbers"

Users expect to see dates and numbers appropriate for the language they are using the app in, so don't forget to set up formatters to render them. The Foundation framework already does so much of the heavy lifting for us, we pretty much just have to set up the templates.

Localizing apps is much more than just topics mentioned in this article but I am hoping that these tips will help you hit the ground running. And if your main obstacle is finding the translators, I have another tip for you: check out Strings.dev (I am not affiliated in any way).

Just copy the file to some other folder (which is not synced to iCloud Drive 😁) and add the media from there.

which I would use like:

• label.textColor = GlobalSettings.darkRed

• directionalLayoutMargins = GlobalSettings.defaultMargins

But there is a better way.

Extending individual types:

This makes coding so much easier and less verbose at the point of assigning - just start typing with a dot and rely on autocomplete to get to:

• label.textColor = .darkRed

• directionalLayoutMargins = .defaultMargins

And as a bonus, keeping these extensions in individual files reduces compile time. Remember GlobalSettings? Changing a single parameter in there would require every source file that references GlobalSettings to get recompiled.

--

Images above were generated with Snippet built by Seb Vidal.

It offers various levels of logging — info, warning, error, and more — which you sprinkle around your code so that you can monitor the flow in the console.

As your app grows, so does the volume of messages in the console.

Instead of filtering Xcode’s console by keywords or updating search parameters in the Console app, here’s how I keep my console de-cluttered:

• Have a Logger instance for each “subsystem” of the app

• Explicitly define (and use it) as an optional

• Manage which of them are active in a single place - a file that extends Logger

My code here shows that I want to keep seeing health and shoes messages, but CoreData and onboarding are not needed at this time -- I just set them to nil, and comment out the original code.

--

The image above was generated with Snippet built by Seb Vidal and uses a background by the wonderfully creative Meng To.