Software Dev

Mobile Native Foundation: Developing Large-Scale Apps

Writing apps for a large organization has its own unique challenges.

Large teams require that you collaborate in complex ways while keeping quality and delivery speed high. It’s not straightforward, and it makes the days of knocking out an app on your own look fun and easy, if somewhat solitary.

@MobileNativeFoundation

It’s not just about “data structures and algorithms” or any of that Computer Science 101 stuff at this level.

The Mobile Native Foundation is a new organization that focuses on large-scale app development issues for iOS and Android.

It’s mostly just discussion groups right now, but they have contributions from people at large companies with apps you know and respect such as Lyft and Spotify.

The discussions cover relevant topics ranging from organizational (such as Encouraging and enforcing testing), to design (Building Modern UI), to technical (Splitting an app into modules).

๐Ÿ‘‰ This site also reminds me of a book on large-scale app development that I’m currently working through: Building Mobile Apps at Scale.

Via iOS Dev Weekly.

Software Dev

The Singleton Pattern – When There Can Only Be One โ˜๏ธ

Like so many smart and courageous people, the Singleton design pattern is often misunderstood.

Whether it is attacked as an anti-pattern, maligned as untestable, or misused as a global convenience, singletons take a lot of ๐Ÿ’ฉ for just being what they are: a way to enforce that there is only ever one of something. I think they should call this pattern “The One”.

A real life example of a singleton is The President of the United States. We only ever have one president at a time. That’s a key part of the concept. It’s not just a convenience.

In software terms, singletons make sense in many cases such as the one and only instance of the current app running on the current iPhone.

With all this in mind, this quick post provides some nice context about singletons (aka the President) versus just a shared instance (hey, let’s all share this one bike) in Swift.

๐Ÿ‘‰ Whatโ€™s the difference between a singleton and a shared instance in Swift?

Thanks to iOS Dev Weekly for calling out the ongoing confusion on this topic. ๐Ÿ™

Software Dev

Learn to Love Throwing in Swift

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.

Software Dev

What Adding Dependencies Will Do To Your App in 2020

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.

Software Dev

Reducing Your Appโ€™s Memory Footprint

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

Software Dev

We All Hate Error Handling. Here Are Some Tips.

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.

Software Dev

Point-Free Composable Architecture

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.