3 min read

Issue #42

Hi there,
Welcome to the 42nd issue, the answer to life and everything! This time, among other topics, there's a couple of tips about code and project setup improvements that facilitate speed - faster app launch, execution speed, and build times. Enjoy!

By the way, next issue will arrive on Tuesday, February 14th 💌

💎 Supporter of the week - Paste 💎

Paste is like a time machine for your clipboard. It brings all your copied items together in one place and makes it super easy to find your snippets with visual previews and powerful search.

It’s a go-to tool for thousands of developers who aim to speed up their daily workflow on the Mac.

Try Paste for free at 👉 pasteapp.io
they’re also hiring macOS/iOS developers ☺️

Speeding app launch by improving code

A story about DoorDash improving their app launch time by auditing and improving code that's run during startup. Among other things, I was surprised how small changes make a big difference. For example, shifting from using String(describing:) to ObjectIdentifier boosted their launch time by 11%!

How We Reduced Our iOS App Launch Time by 60%
Learn how DoorDash went about optimizing our customers’ experience and making continuous improvements in app launch times

Optimizing code performance

In this article you'll learn about even more small tweaks you can make to Swift code that would optimize for performance. I love how Avi includes the "price table" - the tradeoffs for each of the suggestions 👍

9 Ways to Boost Your Swift Code Performance
Some tips on squeezing Swift for speed

Improving linting speed

Many of us use SwiftLint, and if you don't - it's a good idea to add it to the project.
Xcode 14 introduced a new warning, notifying us of a previously non-obvious fact - with the default setup, SwiftLint is ran on all source files in the project, even for incremental builds, when only one file was changed, for example.
So the incremental builds are slower than they could be - and on large projects this could be a noticeable difference.

So what can we do? If we just accept Xcode's suggestion, it will just silence the warning. Gladly the warning is useful here - it hints that we can configure it to work together with incremental builds, so it would only run on files that changed.  

Steven here made a detailed write-up on how to configure this in Xcode, so you get faster incremental builds:

GitHub - steven851007/SwiftLint_build_phase_example
Contribute to steven851007/SwiftLint_build_phase_example development by creating an account on GitHub.

Formatting JSON strings

A small reminder that we can write JSON strings rich with quotation marks without escaping them - keeping the readability of the JSON.

On testing

It's not the first time I share one of Jason's thoughts. I find most of what he writes extremely insightful. If you're still on Twitter, make sure to give him a follow!

Alright, that's it for today! Thank you to Paste for sponsoring this issue (and here's their iOS/macOS developer job posting).
I'm curious if you found one of the tips particularly interesting - let me know by replying to this email!