 iOS Code Review - Issue #31 | Curated code improvement tips

#31・
1.41K

subscribers

32

issues

Subscribe to our newsletter

By subscribing, you agree with Revue’s Terms of Service and Privacy Policy and understand that  iOS Code Review | Curated code improvement tips will receive your email address.

 iOS Code Review
 iOS Code Review
Hi there,
Did you enjoy the Apple event yesterday? Whether you’re into the latest tech, or in the camp of anti-consumerism, hope you had a nice day 🙂
On Twitter it might seem that everyone is so excited about the new phones/watches/etc. But that’s just the bubble. I, for one, will not be buying a new iPhone or watch any time soon - will keep enjoying my 2-year-old XS and series 5. To whomever needs to hear this, it’s totally ok not to jump on buying the newest thing, but also it’s ok to do so.
Now let’s dive in, hope you learn something new today

On [weak] self (again)
The weak self subject is a bit worn, but check this out. Steve has a good general point that such everyday things should be as ergonomic and effortless as possible in a language.
Here Steve also shared an article on the topic of self in closures. It’s sort-of-a-reply to another opinionated piece, but I really like it on its own. If you were looking for once-and-for-all answer to the question of when to use weak and when not, this might be it.
I promise no more weak-self related tips 😀
Steve Troughton-Smith
I feel like if you have a convention in your language & APIs that everybody gets wrong, few people know how to do right, and can lead to all kinds of strange bugs, maybe you should provide a more-structured fix at language level? Swift’s [self] in closures https://t.co/rKsb49Ay25
Thoughts on massive observable objects
Having granular ObservableObject‘s is a good way to go. To avoid unnecessary re-renders, give the high-level views only the dependencies they need.
Chris Wagner
In UIKit development we have the non-ideal MVC ("Massive" View Controller) ... I am starting to see something emerge with SwiftUI development... non-ideal Massive ObservableObjects (MOOs) with too many Published properties. I'm going to refer to these as "cows" 🐄
Harlan Haskins
In my experience, "too many views observing the same observable object" coupled with "one observable object that holds the state for a bunch of unrelated views" are the majority of SwiftUI perf issues I've seen.
Actions in @Environment
Very important TIL-moment if you’re embracing @Environment-based action closures such as OpenURLAction. They should be callable types, not closures - otherwise views that use this variable will re-render unnecessarily whenever the environment could change - for example, on rotation or going to foreground.
Callable structs look like functions to the user of the api, as if you used a typealias for the closure type. If you define a type (struct, enum or class) and add a function named func callAsFuntion() , you’ll then be able to invoke it by using () - x() is equivalent to x.callAsFunction(). This supports custom parameters too. It’s a pretty cool feature in Swift!
Luke Redpath
TIL - if you’re creating your own SwiftUI environment keys where the value is some kind of “action”, modelled as a closure (e.g. `() -> Void) you might see unexpected re-renderings of views that use that @Environment property.
Luke Redpath
In our case, we had a custom void closure environment value that we only set once in the whole app (and I confirmed it was only set once), yet a child view was re-rendering and using the new .printChanges() API it was because it thinks the custom environment value changed.
Luke Redpath
My hunch - which turned out to be correct - was that closures in Swift are reference types and SwiftUI gets confused when its environment holds reference types. As a clue - note that similar built-in values in SwiftUI are actually structs with callAsFunction() methods.
Xavier Jurado
@lukeredpath @tclementdev @environment Interesting! It could be because closures are difficult to compare in Swift so SwiftUI assumes they are always different and thus triggers a render.
Slack's legacy codebase improvement story
Recently Slack shared how they improve their legacy mobile codebase in a 3-article series. Here’s an 8-minute summary, in case you don’t have 30+ minutes to read the original, which is also linked there.
Mobile App Refactoring Initiative by Slack | by Elye
🤘
Alright, that’s it for today. 
Did you enjoy this issue? Let me know by pressing the buttons below. If you enjoyed it, you can help grow the newsletter by spreading the word ☺️
Got feedback? Want to see more, or less of certain kinds of tips? I’d love to hear from you. Reply to this email or reach out on Twitter via @ios_code_review 🙌
Did you enjoy this issue? Yes No
 iOS Code Review
 iOS Code Review @ios_code_review

Bi-weekly newsletter amplifying code improvement tips from the Apple developer community in a bite-sized format. Swift, Objective-C, iOS, macOS, SwiftUI, UIKit and more. Curated by Marina Gornostaeva and published every other Thursday.

For feedback or sponsorship ->> [email protected]

In order to unsubscribe, click here.
If you were forwarded this newsletter and you like it, you can subscribe here.
Created with Revue by Twitter.