Xavier Lowmiller’s Blog

Implementing the Slide to Unlock Animation in SwiftUI

2020-10-14T00:00:00+00:00

Everybody remembers the original iPhone’s solution to avoid pocket calling people:

This venerable UI pattern has disappeared a while ago from our lock screens, but many apps implement it, perhaps most prominently in Amazon’s 1-click buy.

I recently implemented such an animation at work in UIKit. The StackOverflow answers typically reach for CoreAnimation on layers, and I was wondering how this would go in SwiftUI. Animations are one of the things in SwiftUI that don’t come easy to me, so it’s the perfect exercise!

AnimatableModifier

I chose to implement the effect as an AnimatableModifier. This protocol inherits from both Animatable and ViewModifier, so we implement both animatableData and func body(content: Content) -> some View.

My idea here is to take whatever view we are given inside the ViewModifier’s body function, overlay it with a gradient, and constrain it to the contents using mask():

LinearGradient(/* ... */).mask(content)

The animation then is done via animatableData: It exposes data that should be animated over. Since our animation is an endless one, I chose a simple CGFloat that grows from 0 to 1 over and over again. This float represents the horizontal percentage-based position of the gradient that is moved from left to right.

Getting the layout right

Let’s start by implementing the body function:

import SwiftUI

struct Shimmer: AnimatableModifier {

    private let gradient: Gradient

    init(sideColor: Color = Color(white: 0.25), 
        middleColor: Color = .white) {
        gradient = Gradient(colors: [sideColor, middleColor, sideColor])
    }

    func body(content: Content) -> some View {
        content
            .overlay(LinearGradient(
                        gradient: gradient,
                        startPoint: .leading,
                        endPoint: .trailing))
            .mask(content)
    }
}

There’s an overlay over the content, that is again masked by the content. This way, we don’t need a GeometryReader because the overlay will exactly match the frame of content. We use a LinearGradient that currently spans the entire available space. This gradient is then masked by the content again, which stamps out the alpha channel of the content. This works nicely with text:

Moving the gradient

Currently, the gradient goes from .leading to .trailing. Let’s fix that with a position variable that we can later animate:

struct Shimmer: AnimatableModifier {

    // ...

    @State private var position: CGFloat = 0.25

    func body(content: Content) -> some View {
        content
            .overlay(LinearGradient(
                        gradient: gradient,
                        startPoint: .init(x: position - 0.2, y: 0.5),
                        endPoint: .init(x: position + 0.2, y: 0.5)))
	// ...
    }
}

This now displays the animation at 25% of its run:

Pretty nice! The gradient now covers 40% of the area (20% to the left side and 20% to the right side of the position). Unfortunately, there are some artefacts at 0% and a 100%, where half of the gradient is still shown:

We can fix this by removing the ±0.2 at the edges of the animation:

At 0%, we want to hide the right side of the gradient

At 100%, we want to hide the right side of the gradient This is a simple linear equation:

startPoint: .init(x: position - 0.2 * (1 - position), y: 0.5),
endPoint: .init(x: position + 0.2 * position, y: 0.5)))

Animating the position

To conform to the Animatable part of AnimatableModifier, we need to expose the position as animatableData:

struct Shimmer: AnimatableModifier {

    // ...

    @State private var position: CGFloat = 0
    var animatableData: CGFloat {
        get { position }
        set { position = newValue }
    }

	// ...
}

If we animate from 0 to 1, SwiftUI will be call this with values ranging from 0 to 1 for every frame. It’s like a stream of numbers: During the animation it will assume the values 0.1, 0.2, 0.3, …

The actual animation needs to be triggered in an .onAppear closure:

func body(content: Content) -> some View {
    content
        .overlay(/* ... */)
        .mask(content)
        .onAppear {
            withAnimation(Animation
                            .linear(duration: 2)
                            .delay(1)
                            .repeatForever(autoreverses: false)) {
                position = 1
            }
        }
}

Let’s dissect this:

In .onAppear, we set the position to 1
This is wrapped in a .withAnimation
We have a 2-second linear animation that is delayed by 1 second
This 3-second animation is repeated forever

It’s important to use a .withAnimation here because this only animates the changes that happen inside the closure. If we opted for a .animation modifier on the view, all other changes (like frame change on device rotation) will be animated as well.

This is what the result looks like:

Final Thoughts

It’s really nice to animate things in SwiftUI. The previews help a lot: while developing this, I had multiple previews showing the animation’s progress at various stages.

But the main reason I liked it is that SwiftUI doesn’t mix metaphors: In UIKit, you could always reach down to the layer API when something (such as masking) isn’t exposed. Nothing stops you from doing that from a UIView, or a UIViewController, or another UIViewController. SwiftUI severely limits these interactions: It’s a fresh start with consistent APIs that are properly contained.

You can find the final code in this gist.

Porting @AppStorage to iOS 13

2020-09-04T00:00:00+00:00

A couple of weeks ago, a few friends and I were out having beers. We told the barman to make sure our glasses are filled, and we’d figure the tap out later. After a while, somebody said “you know, I’d love an app for my watch to keep track of how many I’ve had”. My answer was that for watchOS 7, that app would probably fit in a tweet, including persistence and all (it didn’t, but it’s not so far off). When porting it back to watchOS 6, I noticed that the thing I missed most was the @AppStorage property wrapper.

While there’s a lot of UserDefaults wrappers out there, I couldn’t find one that had a 100% identical API to the “real” SwiftUI thing. So of course, I had to write one.

This post collects some of the obstacles and surprises I faced implementing it. While it’s specifically about @AppStorage, any property wrapper that implements a simple side effect can probably be implemented in a similar manner.

Starting out

Since I had a specific target in mind, I started by copying the exact signature:

@frozen @propertyWrapper public struct AppStorage<Value> : DynamicProperty {
  public var wrappedValue: Value { get nonmutating set }
  public var projectedValue: Binding<Value> { get }
}

The thing that immediately caught my eye was the nonmutating set. It’s a modifier that is used very rarely in day-to-day Swift, but makes total sense: In SwiftUI, views are value types, and mutating them doesn’t make much sense. They just get copied on mutation, and nothing happens in the SwiftUI update engine since the original is just the same. First I’ve tried wrapping an @State property, but that had some issues later. The trick here is to borrow from Swift’s Copy-on-Write types and make the backing storage a reference type:

private class Storage<Value>: ObservableObject {
  @Published var value: Value

  init(value: Value) {
    self.value = value
  }
}

struct AppStorage<Value> : DynamicProperty {
  @ObservedObject private var _value: Storage<Value>
  public var wrappedValue: Value { 
    get { _value.value }
    nonmutating set { _value.value = newValue }
  }
}

This way, the compiler is happy since mutations to the reference type don’t cause the struct itself to mutate, and SwiftUI will know to update views because of the ObservedObject. I image that @State is implemented similarly.

Actually saving values

SwiftUI’s @AppStorage takes two arguments: A key (a simple String), and a store (an optional UserDefaults instance).

There are multiple initializers for all the types that are supported, such as:

extension AppStorage where Value == Int {

  public init(wrappedValue: Value, _ key: String, store: UserDefaults? = nil) {
    let store = (store ?? .standard)
    let value = store.value(forKey: key) as? Value ?? wrappedValue
    self.init(_value: Storage(value: value), store: store, key: key)
  }
}

We can forward this store to the property wrapper so we can persistently store values as a side effect when setting new values:

struct AppStorage<Value> : DynamicProperty {

  @ObservedObject private var _value: Storage<Value>
  private let store: UserDefaults
  private let key: String

  public var wrappedValue: Value { 
    get { _value.value }
    nonmutating set {
      store.set(newValue, forKey: key)
      _value.value = newValue
    }
  }
}

This works quite nicely for simple types like Int, String, and Bool, that can be stored and retrieved from UserDefaults directly. In addition to those types, SwiftUI supports RawRepresentables, such as enums and URLs. Since I was going for a 100% compatible API, I wanted to do this as well.

A little type erasure

I was stuck at this point for a couple of days. There are two failures:

In the initializer, a cast from Int to an enum with RawValue Int fails: store.value(forKey: key) as? Value just never works.
There’s a crash when trying to set an enum in UserDefaults.

After some research, I found that this is a case for type erasure: Instead of directly casting to Value and writing that to UserDefaults, the property wrapper gets two closures: One for saving to and one for reading from UserDefaults. This way, there’s no need to know how to (de-)serialize arbitrary types: this information can be captured in the initializer, where we know which concrete type we’re dealing with:

extension AppStorage where Value : RawRepresentable, Value.RawValue == String {

  public init(wrappedValue: Value, _ key: String, store: UserDefaults? = nil) {
    let store = (store ?? .standard)
    let rawValue = store.value(forKey: key) as? String
    let initialValue = rawValue.flatMap(Value.init) ?? wrappedValue

    self.init(_value: Storage(value: initialValue), saveValue: { newValue in
      store.setValue(newValue.rawValue, forKey: key)
    })
  }
}

This way, the property wrapper itself is becoming really simple, since it doesn’t even have to know about stores and keys anymore: All it needs is a way to somehow save new values:

public struct AppStorage<Value> : DynamicProperty {

  @ObservedObject private var _value: Storage<Value>
  private let saveValue: (Value) -> Void

  public var wrappedValue: Value {
    get { _value.value }
    nonmutating set {
      saveValue(newValue)
      _value.value = newValue
    }
  }
}

It would be easy to extend this idea to more types, such as all Codable types. Since the SwiftUI version doesn’t do this, I decided to leave it out (for now).

At this point I thought I was finished: I wrote some tests that ensured I have an identical API, and thought of wrapping up. Then I thought of the possibility of somebody changing UserDefaults without letting the property wrapper know (cruel, I know). SwiftUI’s property wrapper still works in this case, so I had to address it, too.

Key-Value Observing the Store

Luckily, UserDefaults is compatible with KVO. It’s easy enough to work with in this case, but requires some things:

The observer must subclass NSObject
The observer must override observeValue(forKeyPath:of:change:context)
We must be careful to add and remove the observer correctly. Since we’re already dealing with a reference type as our private backing storage, it can be used to support KVO here:

private class Storage<Value>: NSObject, ObservableObject {
  @Published var value: Value
  private let defaultValue: Value
  private let store: UserDefaults
  private let keyPath: String
  private let transform: (Any?) -> Value?

  init(value: Value, store: UserDefaults, key: String, transform: @escaping (Any?) -> Value?) {
    self.value = value
    self.defaultValue = value
    self.store = store
    self.keyPath = key
    self.transform = transform
    super.init()

    store.addObserver(self, forKeyPath: key, options: [.new], context: nil)
  }

  deinit {
    store.removeObserver(self, forKeyPath: keyPath)
  }

  override func observeValue(forKeyPath keyPath: String?,
                             of object: Any?,
                             change: [NSKeyValueChangeKey : Any]?,
                             context: UnsafeMutableRawPointer?) {

    value = change?[.newKey].flatMap(transform) ?? defaultValue
  }
}

Unfortunately, we have to pass the UserDefaults instance which we want to observe, the key we wish to observe on, and the type eraser closures to the backing storage, ruining much of the simplicity of before. I omitted the logistics here, but you can take a look in the final implementation: Most of the information that Storage requires is handed through AppStorage’s private initializer.

The upside is that the property wrapper now instantly updates SwiftUI views that depend on it, even if somebody sneakily changes (or deletes) things in the UserDefaults instance.

Naming

Now, since the name @AppStorage clashes with SwiftUI’s own property wrapper, I had to change this property wrapper’s name: It’s called @Persistence, and I’m not really happy about that.

What I’d really like is some way to make the custom property wrapper go away in iOS 14, watchOS 7, and the likes:

@unavailable(iOS 14, watchOS 7, macOS 11, tvOS 14, *)
@propertyWrapper public struct AppStorage<Value>

…but this only works the other way around. You can make more types available for newer operating systems, but not remove them.

Another thing that would be cool would be a typealias based on operating system availability:

if #available(iOS 14, watchOS 7, macOS 11, tvOS 14, *) {
  typealias AppStorage = SwiftUI.AppStorage
} else {
  typealias AppStorage = Persistence
}

…but Swift doesn’t allow top-level statements like this.

If you have any idea about this, please reach out to me!

Recap

I learned a couple of things while building my own version of SwiftUI’s @AppStorage property wrapper:

A simple struct wrapper around a reference type is a pattern Swift really likes, even beyond Copy-on-Write types.
Initializer overloads in combination with type erasure enables powerful generic patterns.
KVO is very useful, especially when contained in a private type.
Swift’s support for type-level programming can be improved.

That’s it for today! Please check out the final implementation, especially when you can’t drop iOS 13 yet but want the goodness of @AppStorage.

What Adding Dependencies Will Do To Your App in 2020

2020-06-04T00:00:00+00:00

With Xcode 11’s support for Swift Package Manager and the coming changes in Swift 5.3, there’s a lot of discussion on what dependency manager to use. I’d like to take you on a tour to see what happens to an app when dependencies are managed using the various tools.

To do this, I measured various metrics around dependencies to see what adding dependencies looks like in the various options in 2020.

Dependency Management has come a long way on iOS. In the early days, it was expected to manually add libraries and frameworks, and update them by hand. Git Submodules can be of some help here, but integrating them into Xcode projects is still tedious.

The managers

CocoaPods

As the community grew and more libraries were written, discoverability was another concern. Enter CocoaPods, which fixed all these problems: There’s a central index where pods can be discovered, and the integration into projects is now a breeze. The value of CocoaPods to the iOS community cannot be described by words. It’s such a great example of what a community can do, and has been the de facto default package manager for iOS projects for years. Its impact on the whole iOS ecosystem can’t be overstated. The website is the go-to place for discovering iOS dependencies. Publishing a library or framework for iOS without CocoaPods support is barely imaginable.

This is the Podfile used for the experiments can be found here.

Carthage

Shortly after Swift came around, Carthage was born. It’s written in Swift itself, and has some different opinions than CocoaPods. It focuses on simplicity and ease of understanding how it works. This means there’s less magic, both in the good and in the bad sense. It’s the simple (not easy) dependency manager for Swift projects. There’s some beautiful ideas behind Carthage, like being decentralized and imposing as few changes to your Xcode project as possible. There’s a great writeup on their GitHub page that I don’t need to repeat here. The bottom line is that it’s simpler than CocoaPods but doesn’t have (and won’t ever have) as many features. This makes the setup a little more work, but once it’s done it’s unlikely to need adjustments in the future.

This is the Cartfile used for the experiments can be found here.

Swift Package Manager

The new kid on the block for dependency management on iOS. At WWDC 2019, Apple announced that the Swift Package Manager (which has been around since late 2015) would be fully integrated in Xcode and could manage iOS projects. This is big news for a platform that never had a truly official package manager! A lot of popular libraries have since adopted SPM and it’s only going to grow bigger as important features land in SPM in Swift 5.3, such as support for assets.

Alternatives Considered

In this post, I drilled down the most popular ways to manage dependencies using their most basic configurations. But of course, there’s many more ways to manage dependencies.

Manual Dependency Management

A.k.a. just adding files to your project. It would have been nice to do this so I could have a baseline without any kind of module/framework/Swift Package for the measurements. This probably works nicely with single-file dependencies (RNCryptor even recommends this technique), but managing more complex dependencies is tedious, especially since there’s not way to easily update things. I tried this, but it’s just not feasible with so many dependencies, I had too many name clashes and other issues, like libraries expecting to be embedded in modules.

Git Submodules

The dependency manager when there is no dependency manager. The idea here is to add projects as git submodules and integrate their .xcodeproj files into your project’s project file or workspace. This is a lot of setup work, and should have similar results as CocoaPods.

CocoaPods with static libraries

In the early days of Swift, it was only possible to package Swift Modules as dynamic frameworks. This is still the default for most CocoaPods, so I used that in my measurements.

The dependencies

To do my measurements, I chose 10 dependencies that should be a somewhat realistic mix of popular libraries. They must be compatible with all dependency managers and for simplicity’s sake should be on GitHub. Some of them have dependencies themselves. They range from small (Reachability.swift, 1 file, 275 LoC) to large (RxSwift, 141 files, 10330 LoC).

Here’s the list:

All measurements were done on my developer machine, a MacBook Pro (15-inch, 2017), using Xcode 11.5 and iOS 13.5. If you’d like to follow along, all of my experiments are on GitHub.

Round 1: App Launch Times

Historically, app launch speed has been negatively impacted, especially if you have a lot of libraries. With the arrival of dyld 3, a lot has changed here. Let’s see if launch times are still an issue for todays iOS dependency setups.

I tested this using the new default launch test on both a physical iPhone 11 Pro as well as the iOS Simulator.

This is the test case:

func testLaunchPerformance() throws {
  measure(metrics: [XCTOSSignpostMetric.applicationLaunch]) {
    XCUIApplication().launch()
  }
}

The hypothesis is that an app with 10 dependencies launches slower than an app that has no dependencies at all. The results, however, show that there is no longer much of a measurable impact:

	No dependencies	CocoaPods	Carthage	SPM
iPhone 11 Pro	1.009s	1.021s	1.105s	1.032s
Simulator	1.056s	1.105s	1.118s	1.080s

There’s still a little difference between the different methods, but that can very well be a measurement error. All setups that use dependencies launch a little slower than the “No dependencies” setup, but it’s not any serious amount of time. At 10 dependencies, it’s probably not worth optimizing for.

Winner: Tie!

Round 2: App Size

App download size has always been an important metric, especially before Apple effectively dropped the mobile app download size limit.

Let’s find out how integrating dependencies will affect your app’s size!

Round 2a: xcodebuild build

Running xcodebuild will create a build product in the DerivedData directory that basically is a runnable app. We use this command to generate it:

xcodebuild build \
  -quiet \
  -scheme Dependencies \
  -configuration Release \
  -derivedDataPath DerivedData

We can measure the file size of the artifact using du:

du -sh DerivedData/Build/Products/Release-iphoneos/Dependencies.app

Here are the results:

	No dependencies	CocoaPods	Carthage	SPM
Total Size	140 KB	14 MB	84 MB	12 MB
Executable Size	104 KB	104 KB	104 KB	12 MB
Frameworks Folder Size	No Frameworks	14 MB	84 MB	No Frameworks

84 Megabytes! Yikes!

I measured the binary executable size separately from the Frameworks folder, which are the two places where compiled code lives. It looks like SPM wins this round, but apps are normally not distributed in a universal, uncompressed way. Let’s see what a thinned app looks like!

Round 2b: App Thinning

iOS 9 introduced App Thinning, which is a technique to reduce .ipa file sizes: By default, the App Store will generate specialized versions for each kind of device, stripping away unneeded assets and executable code. Let’s see how using App Thinning changes the numbers!

First, we build and export an archive so we can export thinned apps locally:

xcodebuild archive \
  -quiet \
  -scheme Dependencies \
  -configuration Release \
  -archivePath 'DerivedData/archive.xcarchive' \
  -derivedDataPath DerivedData

Then, we can build thinned versions for specific devices:

xcodebuild build \
  -quiet \
  -configuration Release \
  -exportArchive \
  -archivePath 'DerivedData/archive.xcarchive' \
  -exportPath 'DerivedData/thinned-ipa' \
  -exportOptionsPlist ../exportOptions.plist

The exportOptions.plist contains the device identifier of the model we’d like to thin for, in this case it’s an iPhone 11 Pro:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
        <key>thinning</key>
        <string>iPhone12,3</string>
</dict>
</plist>

This will create a thinned, zipped .ipa file that we can measure again:

	No dependencies	CocoaPods	Carthage	SPM
Total Size	24 KB	2.1 MB	2.2 MB	1.7 MB
Total Size (unzipped)	136 KB	6.2 MB	6.5 MB	5.0 MB
Executable Size	88 KB	88 KB	88 KB	5.0 MB
Frameworks Folder Size	No Frameworks	6.4 MB	6.0 MB	No Frameworks

This is a pretty neat result! Carthage still produces the largest artifacts, but it’s nowhere near the difference as in the un-thinned test. SPM is definitely a good option when in comes to size, as it produces the smallest files. The ipa produced here is around 20% smaller than the others. This might be due to embedding dependencies statically, so a similar result can might be achieved using CocoaPods in the static library mode.

Winner: Swift Package Manager!

Round 3: Build Times

Having fast feedback from CI and quick builds on developer machines is always a goal worth spending time on. Let’s see how the different package managers perform!

I measured the following things:

Dependency Resolution
Clean Build
Incremental Build
Dependency Resolution + Build (a.k.a. What you’d do in CI)

	No dependencies	CocoaPods	Carthage	SPM
Dependency Resolution	-	1m 38s	13m 25s	2m 23s
Clean Build	3s	1m 10s	5s	1m 20s
Incremental Build	2s	3s	2s	3s
DR + Build	3s	2m 32s	12m 39s	2m 31s

The clear outlier here is Carthage. With it building all the frameworks during the dependency resolution phase (which is far slower than the others), it wins at clean builds.

During day-to-day development (where you’re mostly doing incremental builds), there’s almost no difference, at least in this rather artificial project.

Please take these results with a grain of salt. There’s no caching involved, so especially the CI use case is probably not a realistic scenario.

Winner: Hard to say, but probably Cocoapods with Swift Package Manager as a close second.

Conclusion

Things are looking pretty good for Swift Package Manager. It produces small binaries and builds as fast as Cocoapods. Once all your dependencies are available on SPM, there’s no reason not to switch to it. That said, all three dependency managers I compared are definitely viable in 2020, so there’s also no compelling reason to change dependency managers.

I think it ultimately comes down to team preference or some nuances from the random tidbits section which one they should use, with Swift Package Manager being my recommendation if you can get away with it.

Random Tidbits

XcodeGen can make the initial Carthage setup a breeze
When running on CI such as GitHub Actions, strongly consider caching your dependencies
Many people have been bitten by CocoaPods when merging branches or updating pod versions
Both Carthage and SPM don’t require any ruby setup on the build machines
In fact, SPM works with Xcode out of the box! If CI simplicity is a concern, consider using SPM
SPM doesn’t give you the option to check in dependencies out of the box
Some “important” dependencies like Firebase don’t support all package managers (yet)
SPM is pretty GUI-heavy, there’s no straightforward way to use CLI to manage dependencies

365 Days of Exercise

2020-03-08T00:00:00+00:00

20 minutes. Every day.

I don’t remember exactly when or how I decided this, but according to my records it must have been some time in December of 2018. I read about habit-forming and decided that it would be healthy to devote some time to working out every day.

In my first attempt, I hit a streak of about 50 days but illness required me to take antibiotics in late February 2019, so I paused until March and got started again.

My current streak just hit 365 days.

Benefits

There’s some obvious upside to exercising your body. Working in an office, I started having some pain in my back, shoulder and neck, but this is completely gone. I also used to suffer from pretty tough headaches that completely shut me down about every month or two. This isn’t completely gone, but it’s getting very infrequent: I can remember only a single incident in the last year. Also, it’s not like I’m totally ripped or anything. I’m happy about my looks, but the same was true a year ago. My flexibility and posture have improved considerably, though.

But there’s also some unexpected effects on my life.

Improved Planning

Usually, I don’t plan ahead a lot. This lead me to some missed appointments and a bunch of stress to make up for lost time. Now, since I schedule my exercises, I have a pretty good idea what my next 3-5 days will look like. Since I’m serious about doing sports everyday, bad planning just has to go. This also makes most of my other scheduling more realistic.

Overall Health

Being ready to do sports everyday requires more than just having time to do it. Sickness that keeps me from doing exercise has to be avoided at all costs. Obviously, nobody wants to be sick, but I used to not care as much. Being ill was just a fact of life sometimes. Now, I do more for my health.

Sleep is important.
I drink far less alcohol.
I eat healthier food. Thinking about this, I should find a way to better check my nutrition and cook more.

Willpower

There’s little that makes me get up from the couch at 11pm and exercise, but apparently that annoying little red badge on iPhone apps is one of those things. The app I use, Streaks, has this badge and won’t stop displaying it until I check off the exercise.

After about 20 days, losing my streak became something I dreaded. This feeling becomes stronger after 68 days. And after 125. There’s just no way you’re going to stop at 197 days. I use this sensation for more things now (like flossing, or making photos for 1SE). Perhaps surprisingly, I haven’t worked up the courage to “cheat”, and check off the day even if I haven’t exercised yet (Yes, my girlfriend did this once for me, but I did two sets the next day, I swear!).

A lot of people ask me if it’s not unhealthy to work out every day. I certainly agree that not all exercise is good when done every day, I don’t notice any issues after one year. Also, I’m doing 20+ minutes, it’s not like I’m working on the same muscle group for hours each day.

What I do

The Happy Body

The Happy Body is the bread and butter of this project. The exercises were designed to be done every day in 30 minutes to improve flexibility, strength, speed, posture, leanness, and ideal body weight. After seeing the author doing this at 59 years old, I bought the book. The exercises are easily learned and can be remembered well. There’s no baseline fitness required, and you ease into doing them perfectly over time.

This program goes beyond just exercise and includes a comprehensive diet plan. I believe that it works and used to eat accordingly for a while, but I never really had an issue with my weight, so I don’t follow this as religiously anymore.

On the road

It’s also quite portable. The book suggests using water bottles as weights when on the road, but I usually do it without any weights and go for speed instead. Many hotels have a fitness lounge, but I’ve also done it just on the floor when there’s a carpet. Wooden floors are usually too tough for me.

How much is it?

The book and the weights cost me some money, but it’s a one time thing.

Bouldering

Now, this is something I really enjoy. I can hang around with friends, and it’s giving me a nice sense of achievement every time I conquer a new route. Most of the time, I go for an hour or two with friends, but it can also be fun to go alone for just 30-45 minutes and really hit the limits. I’d love to do more rope climbing as well, but it’s not nearly as convenient as bouldering. It requires a partner and a lot more equipment, and gyms aren’t as widespread as Bouldering. It’s very nice to do this outside, but this typically is an all-day affair which is easily ruined by bad weather.

On the road

I went to bouldering gyms while traveling to Berlin, Vienna and Mainz. They always have shoes for rent, so there’s no need to plan for taking your equipment. The chalk bag is another thing, since many places don’t have bags for rent, but it’s not as essential as one might think.

How much is it?

For equipment, I need new shoes about once a year (50-100€), some chalk (I use liquid chalk, which costs 10-15€ and lasts about half a year. The gym costs around 10€ per visit, but I’m with Urban Sports Club, where I pay around 50-60€ each month and can enter most places for free.

Running

If all else fails, I go out for a run. I used to be more serious about running (in 2008, I ran five days a week), but nowadays I find it quite boring. There’s some situations where it’s just perfect: It’s nice when on holiday and you want to get to know the surroundings a bit. Running with colleagues after work or with conference attendees is also very good.

What’s cool is that I’m pretty fast even if it’s what I do the least. I couldn’t find records of my pace ten years ago, but if I remember correctly, I’m pretty much as fast. Having great flexibility really pays off. I can run a pace of 5 minutes per Kilometer pretty easily. The only thing that isn’t as great is my stamina: Usually I want to stop after 40-45 minutes, when I used to run for 90 minutes without an issue a couple of years ago.

On the road

Running is the ultimate portable sport. I usually pack my 2012 Nike Airs when I spend the weekend at my girlfriend’s, and on vacation it’s usually not a problem to take the running shoes with me. I think I could run in my regular shoes pretty well, too.

How much is it?

Aside from the shoes, which I’ve had for a really long time, it’s completely free! I’m thinking of getting an Apple Watch to monitor my vitals better, but this wouldn’t just be for running.

Other stuff

When I’m on vacation, I often make it about some sport. Surfing counts. Hiking in the mountains counts.

Today, I’m snowboarding in the mountains with my family.

The future

Exercising is never something I liked. To this day, the hardest minute is the first (after that, my body goes into autopilot mode and just does the routine). After a year, I still wouldn’t say that I enjoy most physical activity. But I deeply enjoy having done it. The shower after is great. Checking off the exercise in Streaks is great.

Having done at least 20 minutes of exercise every day for the past year is a tremendous achievement to me. I’m really proud. Next, I want to reevaluate the motivations behind it. Maybe I’ll make it more about nutrition and health. Maybe I’ll get more serious about bouldering. Maybe I’ll find another sport I really like.

I don’t know when I’m stopping my streak. Like I said, the dread of breaking it is now far greater than my laziness. I’ve shown myself I can do it for a year straight, and now I can focus on something else.

Maybe I’ll make it to 500. Maybe 1000. Maybe I won’t stop ever.

Deploying a Vapor App Using Docker: The Missing Manual

2020-02-06T00:00:00+00:00

One of the the things that made Vapor awesome was the ability to easily deploy to Vapor Cloud in a couple of seconds. The service took care of certificate generation and subdomains, which made it perfect for prototyping backends used in iOS apps, which require TLS. Bringing you backend online was always just a vapor cloud deploy away. Unfortunately, it’s shutting down February 29th, 2020, so we have to use another way to deploy our Vapor apps. I recently migrated my PassKit business cards to my company’s OpenShift platform, so I want to share my experiences working with Swift and Docker.

This article is aimed at developers who aren’t experts with Docker, such as iOS developers playing around with Swift on the server (like me). If you have never used Docker before, this guide should help you!

Required software

Docker for Mac
The docker CLI, which is available on homebrew:
```
  brew install docker
```

The Dockerfile

Every Vapor application that is created using vapor new comes with a fully configured Dockerfile (called web.Dockerfile) that works out of the box.

In it, two containers are created:

The builder image:

This uses the official Swift image and contains all the tools necessary to build (and test) your app.

The production image:

This is standard Ubuntu LTS image that copies the build artifacts from the builder, but has none of the build tools, so it will be lighter.

Building an image

To create the container, run the following command:

docker build -t app:latest --build-arg env=production -f web.Dockerfile .

This is what the arguments do:

-t app:latest: It’s customary to name a container, and this is the command to do so. Usually, the scheme <name>:<version> is used, for example app:1.0, app:latest, etc. If this option is omitted, a hash for the container is generated.
--build-arg env=production: Vapor apps have a few default environments (production, development, and testing) which can be checked for. It’s important to set this value, otherwise your app will crash on startup. You could also hardcode this value in the Dockerfile, or set the ENVIRONMENT env value when you run the image later.
-f web.Dockerfile: By default, the Dockerfile is just called Dockerfile. If that’s the case, this argument can be omitted, so you could rename web.Dockerfile and not pass the argument.

If everything works as planned, the terminal will report success:

Successfully built 4cb90e95b339
Successfully tagged ledger:latest

Let’s take the image for a spin!

Running the image locally

docker run -p 8080:80 app:latest

You can now hit localhost:8080 and see your app!

In the Dockerfile, the Vapor app is started on port 80 by default, but that only concerns the container. The -p 8080:80 argument is necessary to access the port from the outside.

You’ll notice that cmd+. and ctrl+C won’t stop the Docker process. You can list all containers and use a separate command to stop it again.

docker container ls
docker stop 00ec27eaafa0

Note that this doesn’t remove the container, but only stops it. Remember to run docker system prune from time to time to clean up dead containers.

Deploying

After your image is built, you can publish it to a cloud provider using docker push <url>. You probably need to follow some sort of authentication, but that process typically is well documented (at least OpenShift is).

Choosing a provider is really up to you, and most (all?) of them support Docker in this day and age. Many of them have a free tier available.

More thoughts

Here’s some things that helped me get started:

The Docker Dashboard and Kitematic are great GUI tools to see what Docker is up to. It’s also good for setting environment variables and exposing ports.
Restarting a container wipes data unless storage is configured. This, however, is another blog post.
Docker is a power tool. It might seem hard to get started, but people who are more experienced are usually willing to help with the basics. Almost none of this is Swift-specific after all.

Conclusion

Having Swift and Docker play nicely is an important step on the road to ubiquitous Swift. Having an environment like Docker that is completely agnostic of the language and processes running in them enables developers to use their favorite language anywhere. This article is meant as a Getting Started guide that takes you from knowing nothing about Docker to successfully deploying to a cloud provider.

iOS 13 Modal Presentation Styles

2019-09-12T00:00:00+00:00

As the release of iOS 13 draws near, it’s high time to update your apps to the latest SDK. One thing you will notice immediately (besides the new dark mode) is that all the modals are different.

There’s a great WWDC video that covers the design update. This post is meant to be a TLDR overview of the new modal styles.

By default, a UIViewController will have a modalPresentationStyle of .automatic. On iOS and iPadOS, this will mostly behave like .pageSheet.

What’s actually happening here?

iOS 13 brings the .pageSheet style to modals on all iPhones in portrait orientation and makes it the new default. On earlier versions, .pageSheet only worked on some iPhones in landscape, such as on an iPhone 8 Plus:

There are four common use cases for modals in iOS 13:

iOS 12 Style:

To get back the iOS 12 style, just set the modalPresentationStyle back to .fullScreen, which used to be the default.

You can do this in a storyboard:

Or programmatically:

let viewController = UIViewController()
viewController.modalPresentationStyle = .fullScreen
present(viewController, animated: true)

If you are using segues, it’s also possible to set this property in prepare(for:sender):

override func prepare(for segue: UIStoryboardSegue, sender: Any?) {
    segue.destination.modalPresentationStyle = .fullScreen
}

Using this style is a great idea for views that should take up the whole screen, for example when showing an image or reading modes.

iOS 13 Page Sheet styles

The new iOS 13 only styles are more interesting, as they can be dismissed by pull down out of the box. There are different use cases that you might want to support:

Pull To Dismiss

Great news: Since this is the new default (.automatic), you don’t have to implement anything! The same effect can be achieved when you set the modalPresentationStyle to .pageSheet.

Prevent Pull To Dismiss

In cases where the user should not be able to dismiss the modal just by swiping, but you still want the new page sheet style, dismissal can be prevented.

The simplest way to implement this style is to set the UIViewController’s isModalInPresentation flag to true:

final class NonDismissableViewController: UIViewController {
    override func viewDidLoad() {
        super.viewDidLoad()
        isModalInPresentation = true
    }
}

It’s also possible to set the delegate of the UIViewController’s presentationController and forbid the dismissal there:

final class NonDismissableViewController: UIViewController, UIAdaptivePresentationControllerDelegate {
    override func viewDidLoad() {
        super.viewDidLoad()
        presentationController?.delegate = self
    }

    func presentationControllerShouldDismiss(_ presentationController: UIPresentationController) -> Bool {
        return false
    }
}

Pull To Dismiss with Action Sheet Confirmation

If you want to support the user pulling to dismiss, but need to perform an action (such as ask for confirmation), you can hook into the dismissal attempt.

There is a new method in UIAdaptivePresentationControllerDelegate that will inform you that the user attempted to dismiss the modal by pulling down:

final class ActionDismissableViewController: UIViewController, UIAdaptivePresentationControllerDelegate {
    override func viewDidLoad() {
        super.viewDidLoad()
        presentationController?.delegate = self
    }

    func presentationControllerShouldDismiss(_ presentationController: UIPresentationController) -> Bool {
        return false
    }

    func presentationControllerDidAttemptToDismiss(_ presentationController: UIPresentationController) {
        present(actionSheet, animated: true)
    }

    private var actionSheet: UIAlertController {
        let actionSheet = UIAlertController(
            title: "",
            message: "Discard Changes?",
            preferredStyle: .actionSheet
        )
        actionSheet.addAction(.init(
            title: "Yes", 
            style: .destructive, 
            handler: { _ in self.dismiss(animated: true) }
        ))
        actionSheet.addAction(.init(
            title: "No", 
            style: .default
        ))
        return actionSheet
    }
}

Note that presentationControllerDidAttemptToDismiss will only be called if presentationControllerShouldDismiss returns false.

Working with `UINavigationController`

A common use case is to wrap view controllers inside of a navigation controller and present the navigation controller modally.

If you do that, be careful to set the navigation controller’s delegate (and not the delegate of the view controller contained inside.

Note that this only applies to the delegate, setting the isModalInPresentation property to true on the contained works 🤷‍♀️.

Conclusion

It’s really simple to adopt the new modal styles once you know where to look. At first, it might seem confusing what properties to set, but this overview should help you.

As a user, I’m looking forward to having these in many apps!

Five Years of Swift: A Love Letter

2019-06-02T00:00:00+00:00

“The language is called Swift, and it totally rules.”

Craig Federighi on June 2, 2014

Swift’s announcement came as a total surprise to me and everybody watching the WWDC keynote. Somehow, everyone at Apple managed to keep this language that Chris Lattner and others worked on since 2010 a total secret (to me, it’s almost an even greater achievement to patiently go through 100 minutes of keynote speech before telling the world about it).

It has been quite a ride, and I have some words for its fifth birthday.

The first taste

In the winter semester of 2013, there wasn’t a lot of programming in the curriculum of my computer science studies, so I decided to take the Stanford iOS course. Before learning about iOS, I had done some C# and Java during the first two semesters, so Objective-C was a bit foreign to me. It was, however, the perfect language for me to learn at the time. I had never really worked with pointers before, Foundation and UIKit have a lot of nice examples of software architecture that came in handy in later classes, and there was a plethora of material for me to read and learn from. At the end of the semester, I finished the course and decided to apply for an internship in iOS at a local company.

The phone interview was to take place on June 3rd. By this time, I was down with nil messaging. I started to grasp the big ideas behind the distinction of NSString and NSMutableString. I had even typed out my first valueForKey: calls.

And then came Swift.

After the keynote, the idea of learning a new language in preparation of the interview seemed a little … distressing. Immediately after the download of the Xcode 6 beta (which took hours on my home internet connection), I opened a Playground and started playing: There’s let. Xcode wants me to put exclamation marks everywhere. All the method names are strange all of a sudden. SourceKitService Crashed. Before I got the map function working, I went to bed.

(Of course, everyone on the interview had yet to try Swift. I got the job.)

During the internship, I got the chance to build a whole app in Swift 1.0. We never shipped this one before rewriting it in Objective-C, because of some code signing issues that I don’t quite remember. But by then, it was already a burden to go back to the old ways. I replaced let with * const, tuples became NSDictionary, and map on arrays turned into valueForKey:.

We didn’t really have a Swift project for a while, but on the side we played around with it a lot. Also in my studies, the Programming Languages class featured Swift: At the beginning of the course, the professor unveiled the languages we’d be working with: C/C++ (to learn about pointers and low-level stuff), JavaScript (to learn about interpretation and scripting languages), C# and Java (mainly for the JIT compilation), and Swift: To learn how C# and Java should be implemented, were they designed in 2015, and to see what the future will look like.

Naturally, I liked this class quite a lot, even though a lot of the Swift features we learned about (like tuples and value semantics on arrays) were controversial with my peers. I smiled when tuples, local functions, and pattern matching were touted as a big feature of C# 7.0.

Swift 2 and opening up

At WWDC 2015, I was surprised to see the announcement of Swift 2.0. Nobody I knew really used Swift in production code, so seeing a major version bump on the language that still felt a little beta was strange to me.

The big features were protocol extensions (which I soon loved), and try/catch based error handling, which I had mixed feelings about. I had previously learned about the Result type and the error handling it enables, and discussed with many of my peers why Swift doesn’t need try/catch and why it’s a stupid idea in other languages.

Still the biggest announcement for Swift at WWDC was that it’s going to be open source. This enabled me to write my bachelor’s thesis on Swift (which is in German, sorry). It focuses on Swift’s memory management (ARC) and the Copy-on-Write implementations, which heavily use the reference counting mechanism to do its tricks. Writing it was one of the best times in my life, and I got through it pretty well. It was a lot of fun to dig through the source files and find out how everything works under the hood.

While I got an A on the thesis (yay!), the best thing about open source Swift is the discussion about new features. Imagine the incredible amount of change that Swift 3 brought without understanding the reasoning! I can now fully support many decisions (like the removal of C-style for loops), and accept others (like the removal of currying) because I see what made the team arrive at these decisions. This transparency is an invaluable asset that open source and especially the open discussion has brought to the Swift community.

An example of this is the try/catch error handling: After learning how it’s implemented in Swift, I now love it. I still despise the stack-unwinding madness and ‘anything can throw’ mentality of Java (much like I dislike the ‘anything can be null’ mentality).

Swift 3 and becoming mainstream

During the Swift 3 era, we fully switched to using it over Objective-C. New projects were already started in Swift 2, but we had some legacy projects that we inherited at the agency I’m working at. In early 2017, we made the decision to port over all of them, which works quite well due to the incredible interoperability between Objective-C and Swift, especially when going from the former to the latter.

The impact this decision had on our work was profound. I don’t have a lot of data on bugs, issues, performance, etc., but a big plus was that our internal discussions shifted: Before, we were talking about peculiarities of Objective-C, and all its little gotchas. After making the switch to Swift, it was more about features and architecture.

This seems to also reflect in the broader Swift community: Swift was more and more adopted as the darling of the iOS community and posts that featured Objective-C were getting rarer as time went on. I’m not sure if books like Advanced Objective-C would ever have happened. Many blog posts talk about features that plainly weren’t available in the old world. Most of the issues that the Clang Analyzer is great at finding are simply impossible to write in Swift.

I sometimes jest that I learned everything I need to know about my job on Twitter. While I can’t really say how the community changed with the advent of Swift (because I wasn’t around to see much of it in the Objective-C days), I have never seen such a plethora of high-quality content to learn from. We are truly blessed to have such cool people publishing awesome stuff.

Another big thing that happened in the Swift 3 era is the release of Vapor. I love using Swift for iOS, and hope it has a place other realms in the future, like on the server. Using Vapor 1.0, we deployed a couple of smallish web apps to try it out a bit.

True to Swift’s nature, Vapor has had a lot of API and conceptual changes between its major versions, especially going from 2 to 3. Now that it’s based on SwiftNIO and lots of cool Swift 4 features like Codable and Key Paths, I think they have found their rhythm and the changes are going to be smoother in the future.

Swift 4, 5, and the crazy and brilliant future

Speaking of smoother migrations, the Swift 4 migration across all our projects took less than an afternoon (yes, without migrating JSON parsing to use Codable). Lots of really cool stuff was introduced that we now take for granted (hello conditional conformance 👋), but it was still a much smoother upgrade than going from 2 to 3. By now I feel like Swift is the mainstream language for iOS apps, and it is stable enough to explore other realms.

I’m not quite sure it’s ready for world domination, but we’ve come a long way. Now that there’s support for Linux, Android, Windows, and many more, it’s time to spread the wings and set for new horizons.

In the future, I’m looking forward to an improved editing experience outside of Xcode, and the shiny proposal for asynchronous/concurrent programming 🤩.

To five years

Nothing seems to have had a bigger impact on my career so far (and my whole life, really) than Swift and its community and ecosystem. I couldn’t have imagined a better tool to work with these past years.

So cheers, cheers to five years! Thank you for making it great.

On to the next five!

Configure Apps at Build Time

2018-11-18T00:00:00+00:00

In many modern, networked apps, dealing with multiple configurations is a fact of life. Many backends in development have multiple stages with different versions of the code or feature flags that all need to be supported by clients. All of these stages have different URLs that need to be accsible by the iOS app. This extends to API keys, private oauth keys, etc.

Xcode’s Configurations seem like a natural fit for this:

There are, however, a couple of problems with this:

Private information is now part of the repo. You might not want to share all secrets with everybody who has access to the code base (especially if it is open source)
Changing data in a config is a nontrivial task for developers not familiar with Xcode
Mixing of orthogonal concepts: What stages should be addressed with apps that have the #DEBUG flag on?
It gets confusing: What is the difference between Release and Production?
You have to re-run cocoapods each time you add, remove, or rename a config

To avoid these issues, sites like iOS-factor recommend separating the config from the code. Unfortunately, they don’t provide an example on how to inject configs at build time. This blog post does just that.

There will be multiple parts to this. Part one (this post) will detail how to factor out configs from code and inject it during CI. Part two will show how configurations can be changed at run time. In the third and final part, we will implement a solution for over-the-air (OTA) updates.

Step one: Extract all configs to a separate file

Extract all the things that can change between stages to a single file. I chose JSON here because pretty much any build system can manipulate it easily, (and it’s much easier to feature in a blog post) but a property list can do the job as well.

{
    "backendUrl": "https://dev.example.com",
    "analyticsKey": "s3cr3t-k3y",
    "redesignedLoginEnabled": false
}

Step two: Load the file and use the configs in the app:

Load the file and parse its data. I chose to include it using NSDataAsset because it loads trivially and applies a minimal layer of obfuscation to the contents:

enum Configuration {
    private static let json: NSDictionary = {
        guard let data = NSDataAsset(name: "Config")?.data,
            let json = (try? JSONSerialization.jsonObject(with: data)) as? NSDictionary
            else { fatalError("Malformed config.json file") }

        return json
    }()
}

Notice that the actual dictionary is marked private. Since JSONs and property lists don’t have strong typing, I like to write accessors for the keys expected in the config files:

extension Configuration {
    static var backendUrl: URL {
        guard let urlString = json["backendUrl"] as? String,
            let url = URL(string: urlString)
            else { fatalError("Invalid/missing backend URL") }

        return url
    }

    static var analyticsKey: String {
        guard let analyticsKey = json["analyticsKey"] as? String
            else { fatalError("Invalid/missing analytics key") }

        return analyticsKey
    }

    static var redesignedLoginEnabled: Bool {
        guard let redesignedLoginEnabled = json["redesignedLoginEnabled"] as? Bool
            else { return false }

        return redesignedLoginEnabled
    }
}

There’s a lot of fatalError going on here. That’s because I consider errors in the config file programmer errors and there’s no sensible way an app can recover from a missing URL or key. The exception here is the feature toggle, where you can easily provide a good fallback value.

Once these accessors are in place, using the data from the config file is a piece of cake:

Configuration.backendUrl // https://dev.example.com
Configuration.analyticsKey // s3cr3t-k3y
Configuration.redesignedLoginEnabled // true

Step three: Modify the config file from CI

The idea here is to modify the JSON file before building the app. How you do this really depends on what CI system is in place. We use fastlane, so here’s how you modify JSON in Ruby:

path = '/path/to/app/Assets.xcassets/Config.dataset/config.json'
file = File.read(path)
json = JSON.parse file
json['backendURL'] = 'https://test.example.com'
json['analyticsKey'] = 'k3y-for-t3st1ng-3nv'
File.open(path, 'w') { |file| file.write(JSON.pretty_generate json) }

This example sets the values in code, but you might as well read them from an ENV or pass it to the build script some other way.

Recap

In today’s article, we learned how to extract app configurations from the code. Once all the configurations are isolated to the config.json file, there’s no more need to include URLs or secrets in the repository.

If you’re worried that you might forget to set a required value in the file when running the code locally, you can generate Xcode warnings in a build script to inform you about the missing keys.

Just Do Blocks

2018-10-24T00:00:00+00:00

Swift’s error handling system relies on do blocks to wrap throwing statements and handle those errors:

do {
    try FileManager.default.write(file, to: url)
} catch {
    print("An error has occurred trying to write the file")
}

While this is obviously the most common use case, there’s nothing stopping you from writing a do block without any try statements

do {
    print("I won't throw an error")
}

Why would you do this, you might ask?

Variable Names

Well, do blocks have their own variable scope. Consider the following code:

func persist(image: UIImage, named name: String) {
    // Save full size image
    let fullSizeData = image.jpegData(compressionQuality: 1)
    let fullSizeUrl = fullImageUrl(for: name)
    persist(fullSizeData, at: fullSizeUrl)

    // Save thumbnail
    let thumbnailData = image.resizedToThumbnailSize.jpegData(compressionQuality: 1)
    let thumbnailUrl = thumbnailUrl(for: name)
    persist(thumbnailData, at: thumbnailUrl)
}

All that awkward naming can be avoided using do blocks:

func persist(image: UIImage, named name: String) {
    // Save full size image
    do {
        let data = image.jpegData(compressionQuality: 1)
        let url = fullImageUrl(for: name)
        persist(data, at: url)
    }

    // Save Thumbnail
    do {
        let data = image.resizedToThumbnailSize.jpegData(compressionQuality: 1)
        let url = thumbnailUrl(for: name)
        persist(data, at: url)
    }
}

It’s not a problem to use the same name in different do blocks.

I find this particularly useful with XCTestExpectations in unit tests:

do {
    let exp = XCTestExpectation(description: "Wait for async dispatch")
    loadUserData() { _ in exp.fulfill() }
    wait(for: [exp], timeout: 1)
}

do {
    let exp = XCTestExpectation(description: "Wait for async dispatch")
    loadPhotosMetadata() { _ in exp.fulfill() }
    wait(for: [exp], timeout: 1)
}

do {
    let exp = XCTestExpectation(description: "Wait for async dispatch")
    loadPhotos() { _ in exp.fulfill() }
    wait(for: [exp], timeout: 1)
}

XCTAssert(...)

No more exp1, exp2, exp3, …!

Memory Management

Furthermore, as variables go out of scope their memory can be reclaimed. You can use this like the using statement in C#.

func postProcessFrameOfMovie(at url: URL, at scrubbingPosition: TimeInterval) -> UIImage {
    let frame: UIImage
    do {
        // Load the movie, which fills up a lot of memory
        let movie = Movie(at: url)
        frame = moview.frame(at: scrubbingPosition)
    }
    // The movie is out of scope now, its memory can be reclaimed

    frame.postProcess()

    return frame
}

This is also useful for nasty stuff like locks, which should be kept around as short as possible.

SwiftLint For Teams

2018-07-09T00:00:00+00:00

SwiftLint is an indispensible tool in the arsenal of the modern iOS developer. If you have more than a single iOS developer on the team, chances are you are already using it to enforce style guides and perform linting. Our iOS Team discusses new rules on a regular basis and decides which ones make sense for our style guide.

However, if you are working on multiple projects at the same time, updating the .swiftlint.yml files can become a hassle. Luckily, there’s a way out of this repetitive task.

Hosting and loading the shared config

We use a dedicated repository to host our coding guidelines and best practices. Part of that repo is our default .swiftlint.yml file that we keep updated.

Luckily, most git providers make it easy to download files via an API: Here’s how to get a file from GitHub:

SWIFTLINT_CONFIG_PATH="/tmp/.swiftlint.yml"

curl -s https://raw.github.com/realm/SwiftLint/.swiftlint.yml -o $SWIFTLINT_CONFIG_PATH

(Notice the raw.github.com)

GitLab provides a similar API. If your provider does not have an API, you can use the git-archive command:

git archive --remote=git://yourGitRepo.com/<user>/<repo> .swiftlint.yml | tar -x -C /tmp

Using the shared file for linting

Using the file is a trivial matter:

/usr/local/bin/swiftlint autocorrect --config ${SWIFTLINT_CONFIG_PATH}
/usr/local/bin/swiftlint lint --config ${SWIFTLINT_CONFIG_PATH}

You can extract all of this into a script (say, run-swiftlint.sh) and replace your SwiftLint build phase with an invocation of this script (or just paste it in the Run Script phase).

Be aware that this will download the .swiftlint.yml on every single build. Since this will slow local builds and rate limiting is a thing with most git providers, this is a bad idea.

In production, we use a more sophisticated script. It will try to download the file at most every 24 hours, or if it was deleted. Furthermore, it employs caching because If-Modified-Since requests do not count against the rate limit.

Overriding rules locally

So what do you do when the new shared configuration introduces a lot of errors to a project so that it isn’t feasible to fix them right now? Since the new config is shared, you can’t just disable the rules temporarily. Luckily, SwiftLint has a feature that makes this easy:
nested configurations.

Consider the following project setup:

Let’s say your style guide forbids force unwrapping because you never ever want the app to crash in production. Your .swiftlint.yml file then might contain a rule that forbids them and produces errors:

opt_in_rules:
  - force_unwrapping

Now, how do you allow force unwrapping in tests? You could use a //swiftlint:disable force_unwrapping every time you want to use a !, but this gets boring quickly. Leveraging SwiftLint’s nested configurations, this is as easy as adding another .swiftlint.yml file to your Tests folder that disables the force_unwrapping rule again for this subfolder:

disabled_rules:
  - force_unwrapping

You can now force unwrap in your test files like there’s no tomorrow!

This feature can be used to disable rules that are new to the shared config but break the local project. Unfortunately, I haven’t found a way to put a .swiftlint.yml file in the root folder of the project since that one is overridden by the --config parameter in the script, so you have to create separate ones for the Sources and Tests directories.

⚠️ Limitations

include and exclude will be ignored in nested configurations, so you probably should have folders like Pods or Carthage in the shared configuration.

Recap

Use a shared .swiftlint.yml that is hosted somewhere on your git
Download the file before linting using a script
Replace your SwiftLint build phase with the script
Override shared rules with specific ones using Nested Configurations

This is the script we currently use across our team:

#!/bin/bash

SWIFTLINT_CONFIG_PATH=".swiftlint.yml"
TEMP_FILE=".temp.yml"

# If the file does not exist or is older than 1 day, download it
if [[ ! -f $SWIFTLINT_CONFIG_PATH ]] || [[ $(find "$SWIFTLINT_CONFIG_PATH" -mtime +1 -print) ]]; then
    last_modified=$(date -u -r $SWIFTLINT_CONFIG_PATH "+%a, %d %b %Y %H:%M:%S GMT" 2>/dev/null || true)
    http_code=$(curl \
        -H 'Accept: application/vnd.github.v4.raw' \
        -H "If-Modified-Since: $last_modified" \
        -w "%{http_code}" \
        -o $TEMP_FILE \
        https://api.github.com/repos/adorsys/csi-coding-guidelines/contents/iOS/.swiftlint.default.yml)

    if [[ 200 == "$http_code" ]]; then
        mv $TEMP_FILE $SWIFTLINT_CONFIG_PATH
    else
        rm -f $TEMP_FILE
    fi
fi

if [[ -e $SWIFTLINT_CONFIG_PATH ]]; then
    "${PODS_ROOT}/SwiftLint/swiftlint" autocorrect --config ${SWIFTLINT_CONFIG_PATH}
    "${PODS_ROOT}/SwiftLint/swiftlint" lint --config ${SWIFTLINT_CONFIG_PATH}
fi

You can also find the current version on our GitHub.

Xavier Lowmiller’s Blog

Implementing the Slide to Unlock Animation in SwiftUI

AnimatableModifier

Getting the layout right

Moving the gradient

Animating the position

Final Thoughts

Porting @AppStorage to iOS 13

Starting out

Actually saving values

A little type erasure

Key-Value Observing the Store

Naming

Recap

What Adding Dependencies Will Do To Your App in 2020

The managers

CocoaPods

Carthage

Swift Package Manager

Alternatives Considered

Manual Dependency Management

Git Submodules

CocoaPods with static libraries

The dependencies

Round 1: App Launch Times

Round 2: App Size

Round 2a: xcodebuild build

Round 2b: App Thinning

Round 3: Build Times

Conclusion

Random Tidbits

365 Days of Exercise

Benefits

Improved Planning

Overall Health

Willpower

What I do

The Happy Body

On the road

How much is it?

Bouldering

On the road

How much is it?

Running

On the road

How much is it?

Other stuff

The future

Deploying a Vapor App Using Docker: The Missing Manual

Required software

The Dockerfile

The builder image:

The production image:

Building an image

Running the image locally

Deploying

More thoughts

Conclusion

iOS 13 Modal Presentation Styles

What’s actually happening here?

iOS 12 Style:

iOS 13 Page Sheet styles

Pull To Dismiss

Prevent Pull To Dismiss

Pull To Dismiss with Action Sheet Confirmation

Working with UINavigationController

Conclusion

Five Years of Swift: A Love Letter

The first taste

Swift 2 and opening up

Swift 3 and becoming mainstream

Swift 4, 5, and the crazy and brilliant future

To five years

Configure Apps at Build Time

Step one: Extract all configs to a separate file

Step two: Load the file and use the configs in the app:

Step three: Modify the config file from CI

Recap

Just Do Blocks

Variable Names

Working with `UINavigationController`