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.
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. ๐คท๐ปโโ๏ธ
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. ๐
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.
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.
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).
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.
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. ๐ฅ
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.