Here’s a great article on the surprising news that the next version of MacOS is going to be more fun-looking.
👉 The Comeback of Fun in Visual Design
Or as Apple puts it:
Although the design language strongly encourages visual consistency, it doesn’t preclude judicious expressiveness.
That’s Apple’s way of saying you can be more fun now. 😆
Via iOS Dev Weekly.
I really like the points made in this article about Swift error handling: using throw/try/catch is actually much better than returning optionals or the new Result type.
👉Benefits of using throwing functions (try) – Swift’s most underrated feature?
Throwing errors, when used throughout your codebase, helps you reduce and simplify code. It makes your unit testing easier too.
As a former Java programmer, I have to admit some hesitance to throw anything. Java error handling can turn into a nightmare of its own.
But the author makes some compelling arguments why throwing might make sense in Swift. Error handling is never fun; let’s do it the easy way. 🤷🏻♂️
In a related note, Re: Making Wrong Code Look Wrong also talks about the benefits of throwing in Swift, in particular with relation to local reasoning. 👍
Via iOS Dev Weekly.
I like the title of this article because it recognizes that pulling third-party dependencies into your app has a cost.
👉 What Adding Dependencies Will Do To Your App in 2020
And yet we all do it because it also has its benefits. 🤦🏻♂️😂
That article is a realistic and practical look how the dependencies affect your app in terms of app launch times, app size, and build times. It compares Swift Package Manager 🤓, Carthage 🤷🏻♂️, CocoaPods 😬, manual dependency management 🥺, and Git Submodules 🤮.
I still have a dream of zero dependencies 🤩, but I know it’s not realistic in a complex app. 😑
Via iOS Dev Weekly.
Retain cycles, timers, big images, caching. These are a few reasons why your app might be using more memory than it should.
It might be a good time to audit your app and see how much memory it’s really using.
Lazy loading, implementing memory warning methods, using NSCache, autorelease pools. These are a few ways to deal with it.
Also, let’s say, just make a clean, focused software design. 🤷🏻♂️
👉 How To Reduce Your App’s Memory Footprint
A great article via iOS Dev Weekly on defining a design system for your app. A design system ensures consistency, efficiency, accessibility, and reusability.
A design system defines the visual language of a product’s design.
👉 Building a Design System for iOS – Part 1 – Introduction
Error handling makes everything more complicated. Ugh! What do you do if a network call times out (pretty common)? Or you’re trying to save an image and there is no disk space (less common but can happen)? Or that thing that’s never supposed to happen happens (occasionally happens)?
I mean, you have to do something, right? Ugh. 🤦🏻♂️
Here are some tips. Thanks to Swift By Sundell for giving this topic some attention.
👉 Propagating user-facing errors in Swift
Via iOS Dev Weekly.
A new software architecture! Hurray! 🙌🤷🏻♂️
I’m filing this away as an idea to try on my next app because all other architectures are still just annoying in some way, and this one has a good name. 😆
This architecture is designed to work with SwiftUI and UIKit on any Apple platform (iOS, macOS, tvOS, and watchOS).
👉Composable Architecture, the library
Via iOS Dev Weekly.
App users may not be aware — and app developers often forget — that favorite app of yours might be running native code from a third party such as Facebook. Besides making your app potentially way bigger to download, it can also cause instability. When Facebook screws up, suddenly you can’t run TikTok, Spotify, and countless others apps.
This actually happened recently. 💥
👉 The big Facebook crash of 2020 and the problem of third-party SDK creep
It was as if Facebook had an “app kill switch” that they activated, and it brought down many of people’s favorite iOS apps.
For this and other reasons such as added integration complexity, when I’m making my next app, I am going to try to minimize third-party libraries.
It seems like software architecture often focuses on theoretical concepts and cool ideas, but we should look at things like this that can impact millions of real users. IMHO we developers need to consider third-party libraries as a liability to be weighed against the vulnerabilities they open up. 💥
Also, a shout out to the “App-ocalypse” video from this article. 😆
I’m filing this away as an architecture guide for SwiftUI because it’s recommended by iOS Dev Weekly. 👍
👉 MVP + Coordinators in SwiftUI (part 1)
This is part 1 of a 3-part series and has a supporting GitHub repo.
Are you wondering how to get some information from one component to another in SwiftUI? Too many options to consider? This helpful post walks you through all the scenarios.
👉 View Communication Patterns in SwiftUI
Cheat sheet:
Via iOS Dev Weekly.
