thegoodalright.dev

Exploring Default Argument Values

2023-02-03T00:00:00Z

It's 2023 and I'm not sure that comparing Objective-C with Swift is still relevant, but I'll go with it anyway. Unlike Objective-C, Swift is blessed with a handy feature of default argument values. The feature is quite a life improvement and it feels awkward when a programming language does't support it.

Nevertheless, there are times when default argument values can get in the way. Alas, in a rather mischievous manner. Changing a default argument value is a subtle enterprise. Especially so in libraries and frameworks, e.g. when you aren't the library's interface consumer and can't be sure how it's used.

There are multiple occasions when changing default argument values can bite you. The first occasion is function overloads. Swift supports similar function signatures, but with tweaked arguments or a return value:

func render(_ content: String, newlineStyle: LineEndingStyle = .linux) -> Markdown {
  // ...
}

func render(_ content: String, newlineStyle: LineEndingStyle = .linux) -> HTML {
  // ...
}

The second occasion is wrapping a function with default arguments, but leaving a way to pass the argument down to the function:

func prettify(_ content: String, newlineStyle: LineEndingStyle = .linux) -> Markdown {
  // ...
  render(prettyContent, newlineStyle: newlineStyle)
}

In both cases it seems reasonable to provide a default value for the newlineStyle argument. What's more, the default value is visible in autocompletion. In other words, it works great... unless we need to change the default value.

As you might have noticed, we would need to change the default value in multiple places. Some can be colocated in the same source file, whole others might reside in neighbor files or in different projects. And it might happen that one such place could be overlooked.

Optional Default Values

Well, that's awkward, but what can be done about it? I would argue that optional nil default arguments might be a solution we are after:

// Instead of this:
func render(_ content: String, newlineStyle: LineEndingStyle = .linux) -> HTML {
  // ...
}

// One would do this:
func render(_ content: String, newlineStyle: LineEndingStyle? = nil) -> Markdown {
  let newlineStyle = newlineStyle ?? .linux
  // ...
}

There are certainly downsides. For example, the default value won't longer show up in code completion and probably would need a mention in a function's documentation. Oof, that sounds like another can of worms and I agree.

But at least it removes the burden of tracking down changed default values from code consumers. So, technically it adds a bit more longevity to consumers' code.

One more thing that this approach doesn't tackle is... we might forget to pass the default argument down from a wrapper function to an actual function. E.g. forget to pass the prettify's newlineStyle argument to the render function. That's especially true when there are more than one such arguments.

Structured Default Arguments

So, is there anything we can do to help with trickling down default arguments? One way to mitigate it is by composing arguments in a struct. UIButton.Configuration is a good example of the said technique. Returning to our samples this might look like this:

// Instead of this:
func render(_ content: String, newlineStyle: LineEndingStyle = .linux) -> HTML {
  // ...
}

// One would do this:
struct Configuration {
  var newlineStyle: LineEndingStyle = .newlineStyle
}

func render(_ content: String, configuration: Configuration = .init()) -> Markdown {
  // ...
}

Even tho it stands as not the most revered UIKit's API, but it does the job. On the other hand, there's so much more to the struct technique that it unavoidably feels cumbersome for tiny interfaces. What's more, it still doesn't solve the trickling down arguments problem.

Warnings to the rescue

This section is somewhat dragged by the ears and doesn't strictly relate to the default arguments discussion. Nevertheless, I would argue that it's a good tool to have in any codebase.

I'm speaking about unused function arguments warning. I can't recall how many times I was saved by this warning. Unfortunately, it doesn't work out-of-box in Swift. There are some discussions around adding it to Swift Add warnings for unused function arguments by default - Evolution / Discussion - Swift Forums, but it feels like it won't happen.

For now we can use tools like peripheryapp/periphery: A tool to identify unused code in Swift projects to help us track down unused arguments. It might sound somewhat as an overkill just for that warning and I agree.

But my favorite is nicklockwood/SwiftFormat: A command-line tool and Xcode Extension for formatting Swift code. SwiftFormatter has a linter mode, that would warn about unused variables instead of replacing them with underscores. Just be certain to --disable unusedArguments in automatic formatting. This way unused arguments would stay in the code and the linter mode would have a chance to surface them

Unconclusion

I can't say any the mentioned method is particularly elegant. Personally, the one with optional default values has the most favorable set of tradeoffs. Tho, it's subjective and not universally applicable.

On the other hand, I find it fascinating how such tiny things can impact code longevity. I wonder how many steps language designers need to foresee to come up with a well rounded solution?

Anyway, please let me know if there's have a better option on the table.

You can make anything, till next time :)

Combine Rate Limiting

2021-06-17T00:00:00Z

Combine, Apple's take on the reactive programming paradigm. Despite that AsyncSequence is a new kid in town reactive town, it's safe to say that Combine is here to stay. Ah, I already can see how the said is aging like milk 🥲

Let me suggest a quick stroll through Combine's avenues. Behind well-polished facades, right to the shady custom publishers' back alleys. To places which decent youtuber-traveler would visit straightway.

Though, you might as well check out the end implementation elfenlaid/rate-limiter

Under Pressure

Reactive programming is one of those well-brewed paradigms that outgrew initial hype and became classics. Heck, Rx specification will celebrate its 10th birthday this year.

The Apple platform is not an exception here. There're tons and tons of reactive and reactive-like frameworks available for it. Here are the honorable mentions: ReactiveCocoa/ReactiveSwift has been here since 2012, ReactiveSwift's initial release dates to 2015.

But in 2019, Apple comes off with Combine. It will take another 20 years and a retired Apple veteran to spin a tale of Combine's origins and why 2019 was the year.

For now, let's distract ourselves by scrutinizing the framework. By mere coincidence, Combine looks suspiciously Rx-like. The good ol' asynchronous stream of values over time concept. Though, with one, and significant, distinction. Combine included the backpressure mechanism.

The backpressure concept coordinates a consumer's demand (values processing) and a producer's supply (values generating). Thus, you can't send more events than consumers can, well, consume.

From the UI standpoint, backpressure doesn't seem like a groundbreaking concept. UI is rarely demand-bounded and generally concerned only about the latest values. However, your best friends - throttle and debounce, are here to carry the weight when it comes to that.

And indeed, all shipped Combine consumers (sink and assign) are rolling with unlimited demand. That's somewhat ironic and also makes backpressure a bit underrepresented citizen.

But don't forget that Combine is a general framework. Aside from User Interface, there are a lot of cases where you'll find backpressure useful. In system design, backpressure is a well-known and honored concept. Take for example Fred Hebert's classics Queues Don't Fix Overload and Handling Overload. Frameworks like GenStage are purely demand-driven.

Though, the before-mentioned examples are mostly from the backend side of things. But backpressure is not only a safeguard from overflow but also introduces the point of concurrency and parallelization. Imagine an intelligent Combine's map that would parallelize workload if given 20 or more items (like AsyncSequence 🙈).

Behind the Facades

So, Combine not only helps to build message pipelines. Combine goes even further and orchestrates the data flow itself, twirls a pipeline's valves, keeps the system safe from overflows.

If the orchestration process sounds like an intimidating chore, well, it is. It's much more pleasant to interact with a well-polished facade and never dig to the pipeline's internals for sure:

First of all, there are so many moving parts: Publisher, Publishers, Subscriber, Subscription, Cancellable, Scheduler.
Secondly, Combine is (surprise-surprise) a closed-source project. Only a handful of people know its internals. The rest are left to speculations. For example, we still don't know how to build thread-safe Publishers 🙈

It would be a minefield walk if not for OpenCombine and CombineExt. Don't get me wrong, it still is a minefield walk, with explosion leftovers, body parts scattered here and there, smokes from the production builds. But this time, a smiling sergeant is marching ahead of you. Which is nothing but relieving, I guess.

To the limit

Okay-okay, back to the business. Let's actually build the rate limiter :) By the way, what the heck is a rate limiter, and where can it be used? Say that you are ingesting large portions of data. It might be for the sake of data scrapping or a part of Extract, transform, load process. Whatever it is, you certainly want to keep your appetites in check and don't accidentally DDoS your data sources.

That's why most public APIs are often rate-limited. So, rate limiting is an omnipresent system design pattern that keeps clients' traffic at bay. By the way, let's check out some real-world limit examples:

The API is limited to 5 requests per second per base
– Airtable API

and

You can make up to 5,000 requests per hour.
– Github API

How about expressing the limits in Combine's pipeline terms. We are dealing with a request count per a given time unit metric. Let's plan the rate limiter interface accordingly:

//Airtable's constraint
publisher.rateLimited(by: 5, per: .second(1))

// Github's constraint
publisher.rateLimited(by: 5000, per: .hour(1))

// Oh, let's drop a `scheduler` to count the passing time
publisher.rateLimited(by: 100, per: .second(30), scheduler: .main)

By the way, limits won't be limits if they never hit. So the next step of designing the rate limiter's interface is to know how to handle the limit hit. The plan is to queue the client's demand while the rate limit is on cooldown:

publisher.rateLimited(by: 5000, per: .hour(1), queue: .fifo)

A sound solution, though, something is not quite right here. I think that the .fifo is an acceptable strategy for most cases. But at the same time, it's a too opinionated solution. Perhaps .filo is a more appropriate strategy, what about timeout, oh, and don't forget queue priorities... 🥲 It's a tough choice to make, so let's work around it by providing the library's first extension point!

One can summarize a rate limiter as middleware between Upstream and Downstream that controls the pipeline's throughput. And we're looking for means to abstract the control behavior. And what can abstract concepts better than protocols? The end protocol might look like this:

protocol ThroughputStrategy {
    typealias Action = () -> Void
    func requestThroughput(_ action: @escaping Action)
}

I've decided to implicitly constraint the throughput rate by one value per action. I.e., Downstream can't demand 10 values in one go. It certainly reduces the interface's generality but drastically simplifies its implementation. As a side note, CombineExt has a superb example of a demand buffer handling that can help us in the future.

Let's take the new protocol for a spin:

final class QueueStrategy: ThroughputStrategy { }

let strategy = QueueStrategy(rate: 2, interval: .seconds(1), scheduler: scheduler)

publisher.rateLimited(by: strategy)

Explicitly defined strategies are also sharable. The previous interface .rateLimited(by:_ per:_ scheduler:_) served as a single API's entry point. That might do for a globally constrained API (like Airtable API). But for complex APIs with different sets of constraints, the single API entry point won't do. Check out the complete limits set of limits for the Github API 🤯

final class GithubClient {
    private lazy var unauthenticatedLimiter = QueueThroughputStrategy(
        rate: 60, interval: .minute(1), scheduler: scheduler
    )

    private lazy var authenticatedLimiter = QueueThroughputStrategy(
        rate: 5000, interval: .hour(1), scheduler: scheduler
    )

    private lazy var tokenApiLimiter = QueueThroughputStrategy(
        rate: 1000, interval: .hour(1), scheduler: scheduler
    )

    private lazy var searchAuthenticatedLimiter = QueueThroughputStrategy(
        rate: 30, interval: .minute(1), scheduler: scheduler
    )

    private lazy var searchUnauthenticatedLimiter = QueueThroughputStrategy(
        rate: 10, interval: .minute(1), scheduler: scheduler
    )

    // ...
}

The Implementation

I'll spare you from the implementation details as you might check them here. Though, I should brag that at last I've used Swift Collections's Deque! Also big shot-out to Point Free with combine-schedulers package. Life would be much more difficult without the TestScheduler (yet another missed standard Combine class 🙈):

(1...5).publisher
    .rateLimited(by: strategy)
    .sink(receiveValue: { values.append($0) })
    .store(in: &cancellables)

(1...5).publisher
    .rateLimited(by: strategy)
    .sink(receiveValue: { values.append($0) })
    .store(in: &cancellables)

scheduler.advance(by: .seconds(0))

// Rate limiter starts immediately, and throughputs events up to the initial capacity:
print(values) // [1,1]

// Now the limiter waits for its interval to pass...
scheduler.advance(by: .seconds(1))

// ... to get another round of values
print(values) // [1,1, 2,2]

Also, times it's hard to wrap your head around custom publishers due to hairy implementation details. Sincerely speaking, I failed to come up with a better custom publisher's guide than "follow the example and see what happens." AnyPublisher.create is a decent reference source.

Here be Dragons

A word of warning, though. The current implementation is quite naive. It doesn't account for Upstream's shenanigans. For example, the rate limiter assumes that an Upstream issues only one request per demand unit. But it might be not true, say a network retry gets in a way, or DNS resolution took way too long and throttled the issued requests, or the Upstream might issue multiple requests by design.

Whatever it is, make sure that you've planned the limit hit scenario. Never mind the pattern (circuit breaker, delayed retry, etc.), make sure that it's there and, if possible, in the Downstream.

It's also hard to say whether the implementation is thread-safe. I've used it in my personal projects without noticeable issues. Though it might not be the case for you.

Conclusion

That concludes the rate limiter showcase. As you can see, Combine's backpressure mechanics is quite a peculiar thing. It's a pity that most of the built-in publishers sorta ignore it and start with unlimited demand right off the bat.

Overall, if you think that Rx is an excellent reactive interface specification, you would also like Combine. But, unfortunately, it's not exactly my case. Don't get me wrong, Combine is a decent framework and certainly does its job. But, alas, it's a so PITA to work with. Not only due to custom publishers state, but even simple operations like retry can be deceptively tricky to implement.

It's ridiculous how many pain points a single decent official custom publisher example can help with. But we are not there yet. To be honest, WWDC 2021 wasn't a great year for Combine. High hopes for WWDC 2022, I guess 🤞

You can make anything, till next time :)

Swift String Showcase: Privacy Logs

2021-05-21T00:00:00Z

Here I'm (a year late to the party 🥲) explaining what Swift String Interpolations is all about and showcasing a custom string interpolation type.

Here's the full implementation and bits of context to follow along.

Introduction to String Interpolation

According to Rich Hickey's vibes, we're up to look for interpolation's definition. Without further ado:

the insertion of something of a different nature into something else

"the interpolation of songs into the piece"

a remark interjected in a conversation

"as the evening progressed their interpolations became more ridiculous"

A remark interjected in a conversation 🧐? Voila, a thing to interpolate in the everyday dandy dictionary.

Anyway, talking about the definitions, we're going to concern ourselves with the first one. Most modern programming languages support string interpolation in some way:

Rust println!("The {species}'s name is {name}.");
JS console.log(`The ${species}'s name is {name}.`);
Elixir IO.puts("The #{species}'s name is #{name}.")
Swift print("The \(species)'s name is \(name).")
You have the idea...

Nothing particularly new here, right? Except here is Swift 5's custom string interpolations SE-0228 proposal. In case you've missed it completely, it gives control over the default string interpolation. Here are the proposed potential uses:

// Use printf-style format strings:
"The price is $\(cost, format: "%.2f")"

// Use UTS #35 number formats:
"The price is \(cost, format: "¤###,##0.00")"

// Use Foundation.NumberFormatter, or a new type-safe native formatter:
"The price is \(cost, format: moneyFormatter)"

// Mimic String.init(_:radix:uppercase:)
"The checksum is 0x\(checksum, radix: 16)"

What I did a year ago - I've checked said uses, which are totally rad, thought, "yeah, that's cool," and was off with it. But I've entirely missed the way of said proposal to land - custom interpolation types.

Don't be me, read to the end, or review or revise the proposal, or some other explanation.

Extend String Interpolation

Before we talk about custom interpolation types, I want to mention that types are not the only available extension point. Most of the time, it's much quicker to drop a String.StringInterpolation extension.

Let's have a look at what it takes to implement the purposed use cases:

let 🇺🇸 = Locale(identifier: "en_US")

extension String.StringInterpolation {
    // Use printf-style format strings:
    mutating func appendInterpolation(_ value: Double, format: String) {
        appendInterpolation(String(format: format, value))
    }

    // Use UTS #35 number formats: http://www.unicode.org/reports/tr35/tr35-numbers.html#Number_Format_Patterns
    mutating func appendInterpolation(_ value: NSNumber, format: String) {
        let formatter = NumberFormatter()
        formatter.locale = 🇺🇸
        formatter.format = format // .format @available(macOS 10.0, *)
        appendInterpolation(formatter.string(from: value)!)
    }

    // Use Foundation.NumberFormatter, or a new type-safe native formatter:
    mutating func appendInterpolation(_ value: Double, format: NumberFormatter) {
        appendInterpolation(format.string(from: value as NSNumber)!)
    }

    // Mimic String.init(_:radix:uppercase:)
    mutating func appendInterpolation<Value: BinaryInteger>(_ value: Value, radix: Int, uppercase: Bool = false) {
        appendInterpolation(String(value, radix: radix, uppercase: uppercase))
    }
}

let moneyFormatter = NumberFormatter()
moneyFormatter.locale = 🇺🇸
moneyFormatter.numberStyle = .currency
moneyFormatter.maximumFractionDigits = 2

let cost = 12.8
"The price is $\(cost, format: "%.2f")" // The price is $12.80
"The price is \(cost as NSNumber, format: "¤###,##0.00")" // The price is $12.80
"The price is \(cost, format: moneyFormatter)" // The price is $12.80

let checksum = 123123123
"The checksum is 0x\(checksum, radix: 16)" // The checksum is 0x756b5b3

Well, it wasn't that complicated or horrible (aside from emoji locales). Oh, you can find more examples of StringInterpolation extensions here.

If you follow along with the implementation, you may notice that things kind of become messy with every override of appendInterpolation. We were forced to juggle with types (NSNumber/Double) and compromise on APIs, far from optimal. That's where custom string interpolation types come into play.

Custom String Interpolation Type

Aside from reducing String type clutter, custom string interpolation types rein how and what is out to be interpolated. But to think about it, where can it be useful?

Well... How about logs? Logging is a pain point on iOS (and we're clearly not there yet). The post's idea emerged while I was lurking around Peter's post and stumbled upon the next lines:

let logger = Logger(subsystem: "com.steipete.LoggingTest", category: "main")
logger.info("Logging \(obj.description, privacy: .public)")

Aha (obj.description, privacy: .public)! Clearly, a custom string interpolation is in play. I immediately went off to check its implementation at Apples' Swift Log repo. Alas, this is not a complete os.Logger implementation, and it misses interpolation details.

I guess we have no choice but to try and implement our own logs privacy policy :) Let's define an API surface:

func log(_ message: Message) { print(message) }

log("Hello, \("World!", privacy: .public)")   // Hello, world!
log("Hello, \("Secret!", privacy: .private)") // Hello, ******!
log("Static strings say whatever they want") // Static strings say whatever they want

By the way, Logger's 'privacy: is set to .auto. All of that without saying that OSLogPrivacy is way more intricate than our example implementation:

struct Message {
    enum Privacy {
        case `public`
        case `private`
    }

    var value: String
}

So, we already can log Message instances:

log(Message(value: "Hello, World!")) // Message(value: "Hello, World!")

But they aren't looking pretty, are they? Thankfully we are one protocol conformance away from fixing the situation:

extension Message: CustomStringConvertible {
    var description: String { value }
}

log(Message(value: "Hello, World!")) // Hello, World!

How about dealing with static strings or string literals before tackling interpolations? Plus ExpressibleByStringLiteral conformance is a requirement for ExpressibleByStringInterpolation anyway.

extension Message: ExpressibleByStringLiteral {
    init(stringLiteral value: StringLiteralType) {
        self.init(value: value)
    }
}

log("Hello, World!") // Hello, World!

Now we're ready to deal with the whole interpolation thing:

extension Message: ExpressibleByStringInterpolation {
    init(stringInterpolation: StringInterpolation) {
        self.init(value: stringInterpolation.string)
    }

    struct StringInterpolation: StringInterpolationProtocol {
        var string = ""

        init(literalCapacity: Int, interpolationCount: Int) {
            string.reserveCapacity(literalCapacity)
        }

        mutating func appendLiteral(_ literal: String) {
            string.append(literal)
        }

        mutating func appendInterpolation<T>(_ value: T, privacy: Privacy = .private) where T: CustomStringConvertible {
            switch privacy {
            case .public:
                string.append(value.description)
            case .private:
                string.append(
                    Array(repeating: "*", count: value.description.count).joined()
                )
            }
        }
    }
}

The main workhorse of ExpressibleByStringInterpolation is Message.StringInterpolation type and its appendInterpolation implementation. You can check out full implementation here.

`Logger` Nuances

As I've mentioned before, an actual Logger implementation is way more intricate. We can get some insights into how things work by checking the os interface:

public struct Logger {
  public func log(_ message: OSLogMessage)
}

public struct OSLogMessage : ExpressibleByStringInterpolation, ExpressibleByStringLiteral {
    public init(stringInterpolation: OSLogInterpolation)
}

So, OSLogInterpolation is an analogue to our Message.StringInterpolation type. By digging further, we can see tons of overrides of appendInterpolation:

//..
public mutating func appendInterpolation(
  _ argumentString: @autoclosure @escaping () -> String,
  align: OSLogStringAlignment = .none,
  privacy: OSLogPrivacy = .auto
)

logger.info(
  "Hello, \("World!",
  align: OSLogStringAlignment.right(columns: 20))"
)
// > Hello,               World!

public func appendInterpolation(
  _ number: @autoclosure @escaping () -> Double,
  format: OSLogFloatFormatting = .fixed,
  align: OSLogStringAlignment = .none,
  privacy: OSLogPrivacy = .auto
)

logger.info("\(123.123, format: .exponential)")
// > 1.231230e+02

First of all, arguments are following @autoclosure @escaping () -> T signature. In that way, some arguments won't be computed when logs are switched off (either overall or reduced by a log level).

Secondly, formatting parameters like .format and .align to tune output meessages. The official OSLogInterpolation's documentation covers more of them.

Thirdly, there are many overrides for concrete types like UInt8/UInt16/UInt32/UInt64/etc.. I presume it speeds up either compilation or method resolution for specified types 🤔

Conclusion

As you can see, Swift String Interpolation is a hilarious feature that might be easily overlooked, as it feels so at home with the current implementation.

You may find a much more detailed explanation of ExpressibleByStringInterpolation at NSHipster, which covers yet another custom interpolation type example.

Know more cases of ExpressibleByStringInterpolation? Don't hesitate to hit me up on Mastodon!

You can make anything, till next time :)

CocoaPods Setup ft. Apple Silicon

2021-04-14T00:00:00Z

The article describes CocoaPods setup for Apple Silicon (arch64) machines. We're going to skim over possible Ruby Environment setups, discuss why and how pin gems versions, and how to resolve common issues.

Ruby Management

tl;dr:

If you can roll with old Ruby (~2.6.3) - checkout System Ruby solution
Otherwise, I recommend to use asdf or rbenv

CocoaPods is a Ruby gem or package. Therefore we can't get much done without a proper Ruby setup. We'll kick off the tutorial by discussing our Ruby environment options.

System Ruby

tl;dr:

Set GEM_HOME
Set PATH

Fortunately for us, macOS has Ruby on board. It's a 2.6.3 version on Big Sur 11.2.3 at the time of writing. It's an outdated version and all, but let's be honest here, for most iOS projects, it might be enough 😬

Just imagine for a second, no Ruby environment juggling, and you are ready to roll from the start with a minimal setup. I assure you, it's nothing wrong with using the system Ruby. Especially so with arm-based machines:

$ file /usr/bin/ruby

/usr/bin/ruby: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64e:Mach-O 64-bit executable arm64e]
/usr/bin/ruby (for architecture x86_64): Mach-O 64-bit executable x86_64
/usr/bin/ruby (for architecture arm64e): Mach-O 64-bit executable arm64e

See that file output with 2 architectures? It means that the binary can run either natively or under Rosetta (arch -x86_64 ruby) emulation.

Does it matter? Well, sometimes Rosetta fails. For example, launching arch -x86_64 scripts under arch -x86_64 mode will fail with arch: posix_spawnp: ruby: Bad CPU type in executable. You might think that the example is a bit contrived. Alas, libraries' support for M1 is a mess at the time of writing. So you happen to find a strange workaround here and there.

Universal binaries don't matter much in terms of local Ruby setup, but I guess it's fewer things to worry about.

System Ruby: GEM_HOME

Probably the main issue you'll encounter with the system Ruby is that gem install requires sudo by default.

But we can easily fix this by providing GEM_HOME environment variable:

# ~/.bash_profile or ~/.zshrc
export GEM_HOME="~/.gem/ruby/2.6.3/"

# fish shell
set -x GEM_HOME "~/.gem/ruby/2.6.3/"

After sourcing the config (or opening a new terminal tab), gem install no longer needs sudo. Try it by installing bundler (gem install bundler). You'll probably need it later :)

System Ruby: PATH

By the way, you'll also need to add ~/.gem/ruby/2.6.3/bin to your $PATH. It's the home of gem executables (bundler, pods, fastlane):

# ~/.bash_profile or ~/.zshrc
export PATH="~/.gem/ruby/2.6.3/bin${PATH:+:${PATH}}"

# fish shell
set -U fish_user_paths "~/.gem/ruby/2.6.3/bin" $fish_user_paths

Fishshell users, please checkout path.fish function to simplify $PATH handling.

Homebrew

tl;dr:

Install Homebrew
brew install ruby@3 and follow the provided instructions

If you don't swap Ruby versions, but need something other than the system Ruby version, then Homebrew is here for you.

Homebrew has a collection of precompiled Ruby versions. The group included 2.4, 2.5, 2.6, 2.7, 3.0 versions at the time of writing. You can specify version via:

$ brew install ruby@3.0

If you need to have ruby first in your PATH, run:
  echo 'export PATH="/opt/homebrew/opt/ruby/bin:$PATH"' >> ~/.zshrc
...

I'll leave you in the good hands of Homebrew for the subsequent setup. All you need to do is to follow the provided instructions.

Mind that you can install as many versions as you need. Though the swapping between them is passable at best. Another downside of Homebrew is its precompiled versions range. If your version is not on the list, well, brew won't help you here.

Also, specific Ruby versions are drift with time. For example, ruby@3 installs 3.0.1 today, but tomorrow's ruby@3 will install 3.0.2 or something entirely different.

Despite all the downsides and inconveniences, it's a sensible path to take to avert Ruby compilation (some RVM hacks use this Homebrew feature).

RVM

tl;dr:

Follow the official RVM instructions
Also, mind I interest you in switching to something else 🤔

RVM stands for Ruby Version Manager and is considered a classical approach to managing the Ruby environment.

There're already tons of guides on installing RVM. Therefore I leave you here.

As far as Apple Silicon is concerned, you might find the RVM ride to be a bit bumpy: Unable to install any version of ruby on macOS Big Sur · Issue #5047 · rvm/rvm. Some workarounds, including installing Homebrew versions, are specified in the discussion.

RVM is more than capable of providing a decent Ruby environment. Nevertheless, my take is RVM feels too hacky. It loads in the shell, overrides cd, or requires additional prompt mockery. I often find the rbenv or asdf to be a better choice.

rbenv

tl;dr:

brew install rbenv and follow instructions
Custom installation instructions

rbenv is yet Ruby environment manager. Alas, a less popular one. It works via PATH directories prioritization trick (How rbenv works it details). So, no side scripts and other shell override shenanigans in the background (RVM 👀)

It also has a dedicated page for rbenv vs RVM comparison if you are into it.

The main rbenv's' drawback for arm64 architecture is that some Ruby versions require unconventional installation approach. Nevertheless, rbenv is genuinely good. It was my Ruby environment manager before asdf.

asdf

tl;dr:

follow the official install instructions
install Ruby plugin asdf plugin-add ruby https://github.com/asdf-vm/asdf-ruby.git
install required version asdf install ruby 3.0.0 && asdf ruby global 3.0.0

asdf is an extendable version manager with support for Ruby, Node.js, Elixir, Erlang, and more. The principle behind asdf is similar to rbenv, both use PATH directories prioritization.

Official documentation is genuinely good. Alas, an installation process might turn a bit cryptic, especially considering Common Homebrew issues 🍻 · Issue #785. I'm personally using the plain git clone method here (don't forget to subscribe to asdf releases on GitHub)

asdf Ruby plugin aside from managing Ruby environments, also can:

Install default gems right after installing a Ruby versions. Presumably, you want bundler, pry, or gems of your choice to be available on each and every installed Ruby version.
Help with migrating from other Ruby version managers. Meaning it supports .ruby-version configuration file

asdf seems to go well along M1 and builds most Ruby versions just fine. Alas, there are nuances

If you got tired of a never-ending stream of language managers, check out asdf. Despite a bit messy setup, it's dope!

Gems Management

tl;dr: use bundler

At this point, I presume you have a working Ruby setup. Check out the Ruby management chapter if it's not the case.

It's a great temptation to globally install CocoaPods(gem install cocoapods) and jump straight into the project. But hear me out, knowing (version control) the exact gem version we work with is always a good idea.

I'm sure you want to get the same result from running pod install on your machine and on a college's machine or a build server. Even if you an indie developer, there's a notion of time. Your future self will have a different setup. Imagine how happy you'll be after enumerating CocoaPods and Ruby versions for the whole day just to reproduce a particular build. The pinned or at least known version of tooling never harms.

With that out of the way, let's discuss how we can pin gem versions in the Ruby environment.

Bundler

bundler is sort of CocoaPods but for Ruby gems. From the side, bundler looks like a complete Xzibit thing: installing package manage to manage package manager while managing packages.

Alas, while sounding like insanity, it's a surprisingly reoccurring theme. For example, Python with easy_install, pip, and pipenv or Haskell and its slack + cabal pairing.

CocoaPods is heavily inspired by bundler, and indeed we can draw a lot of parallels between them:

Gemfile is analog to Podfile
Gemfile.lock is analog to Podfile.lock

By the way, CocoaPods themselves use bundler. And as you can see, bundler doesn't take much to setup:

Create a Gemfile (or use bundle init) and specify required dependencies. A typical iOS project Gemfile:

# frozen_string_literal: true

source 'https://rubygems.org'

gem 'cocoapods'
gem 'fastlane'

Install specified dependencies with bundle install. At this stage bundler generates dependency tree in Gemfile.lock file:

GEM
  remote: https://rubygems.org/
  specs:
    CFPropertyList (3.0.3)
    activesupport (5.2.4.5)
      concurrent-ruby (~> 1.0, >= 1.0.2)
      i18n (>= 0.7, < 2)
      minitest (~> 5.1)
...

Don't forget to check in Gemfile.lock to the source control or pin the exact gem versions in the Gemfile.

Run commands with bundle exec prefix:

$ bundle exec pod install

You might add an alias alias be="bundle exec" to avoid typing bundle exec over and over again:

$ be pod install

Also, most of the shells have a dedicated bundler plugin with completions:

(Optional) bundler can pin Ruby version as well:

ruby '~> 2.6.0'
# or
ruby '3.0.1'

You might consider using this method, but it depends on your Ruby environment manager of choice. Some managers use .ruby-version or .tool-versions file mechanisms.

Gemset

A lesser-known option of handling gem versions is a gemset. Gemset is a snapshot of globally installed gems. Both RVM and rbenv support a gemset-like notion. Alas, asdf Ruby plugin don't and won't have it

From the first take, gemsets won't work well in "long-term" projects. Yet, it can be helpful in one-shot scripts or library tryouts. Nevertheless, I wholeheartedly recommend sticking to bundler. But if you have a bundler reckoning, I guess gemsets are better than nothing :)

Pods Management

Hey, we're getting closer! At this point, I presume you have a working Ruby setup and installed CocoaPods (either via bundler or globally). It it's not the case, consider skimming through Ruby environment management and gems management parts.

Aside from few quirks, there's nothing new to running CocoaPods under Apple Silicon. Alas, CocoaPods doesn't officially support Apple Silicon at the moment of writing. With that said, CocoaPods run perfectly fine under Rosetta and times even natively.

Our end goal is a project setup that runs on both arm64 and x86 simulators. Such configuration allows a graceful migration without sacrificing simulator performance.

Firstly, we'll see that pod install works as expected. Secondly, we'll build a project and discuss possible build issues.

Pod Install Quirks

If you are lucky enough, pod install or bundle exec pod install won't cause any issues on your machine. If that's the case, move along to the project setup chapter.

If not, well, here's the most common issue with CocoaPods out there:

`ffi` error

pod install exists with a ffi-related exception:

$ bundle exec pod install
...
LoadError - dlsym(0x7fc182ca67b0, Init_ffi_c): symbol not found - /Library/Ruby/Gems/2.6.0/gems/ffi-1.14.2/lib/ffi_c.bundle
...

Turns out, ffi is also waiting for M1 adoption and probably will get one in 3.4 version.

Depending on your setup, try the following steps if you're using bundler:

Pin ffi in Gemfile: gem 'ffi', '1.14.2'
Run bundler install (You'll probably need to delete Gemfile.lock beforehand)
Run pod install under Rosetta: arch -x86_64 bundle exec pod install

If you have a global CocoaPods pod installed, the steps are mostly the same, but instead, you'll need to pin ffi globally: gem install ffi -v 1.14.2

Project Setup

At last, it's time to build and run the project! Select iOS simulator target and launch the build process. Take my congratulations 🎉 if everything works fine. It was a long way. I wasn't that lucky and faced another bunch of issues.

First of all, if the project was create in Xcode 11 or older, make sure to get rid of VALID_ARCHS build setting:

VALID_ARCHS is no longer a thing in Xcode 12
- Remove it from build settings (in user-defined variables) and config files
VALID_ARCHS setting was replaced by EXCLUDED_ARCHS. Update it accordingly or leave empty
Optionally (but highly recommended) to have ONLY_ACTIVE_ARCH = YES for Debug builds
- Make sure that it's set to ONLY_ACTIVE_ARCH = NO for Release. Xcode doesn't care about ONLY_ACTIVE_ARCH when assembling the Release for a general device. Yet, let's keep things explicit, shall we?

`EXCLUDED_ARCHS` shenanigans

You've built the project only to face the following error:

Showing Recent Errors Only
~/Work/quotes/Quotes/Sources/Scenes/Premium/PremiumScene.swift:5:8: Could not find module 'Analytics' for target 'arm64-apple-ios-simulator'; found: x86_64-apple-ios-simulator, x86_64

Some CocoaPods vendors add a nasty quick-fix to work around Xcode 12 VALID_ARCHS deprecation:

Pod::Spec.new do |s|
  # ...
  s.user_target_xcconfig = { 'EXCLUDED_ARCHS[sdk=iphonesimulator*]' => 'arm64' }
  s.pod_target_xcconfig = { 'EXCLUDED_ARCHS[sdk=iphonesimulator*]' => 'arm64' }
  # ...
end

These two lines force Xcode to skip assembling the arm64 simulator slice and failing the build.

Tweaking user_target_xcconfig in a Podspec is a big NO-NO. Please, consider other methods.

To fix the issues we're going to patch the project and libraries .xcconfig files:

post_install do |pi|
  pi.target_installation_results.each do |result|
    result.each do |name, installation_result|
      target = installation_result.target
      installation_result.native_target.build_configurations.each do |config|
        config_path = target.xcconfig_path(config.name)
        next unless config_path.exist?

        config_data = config_path.read
        config_data.gsub!("EXCLUDED_ARCHS[sdk=iphonesimulator*] = arm64", "")
        File.write(config_path, config_data)
      end
    end
  end
end

I find it as a rather dirty solution, but that's the reality we live in. Also, keep in mind that tweaking build_settings alone won't cut here.

Missing `arm64` Simulator Slice

pod install runs just fine, but the project won't build with the following error:

ld: in ../../SpotifyiOS.framework/SpotifyiOS(MPMessagePackReader.o), building for iOS Simulator, but linking in object file built for iOS, file '../../SpotifyiOS.framework/SpotifyiOS' for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

We've encountered a close-sourced (framework or library) dependency that doesn't have an arm64 Simulator slice. Alas, we can't do much here unless you're brave enough 🙈

The thing is, classic fat Mach-O libraries can't have two slices of arm64 architecture. The trick works only with the new [XCFramework](Distributing Binary Frameworks as Swift Packages | Apple Developer Documentation). You can find more about XCFrameworks here:

The quick fix is to launch Xcode under Rosetta (arch -x86_64 xed .) and notify a third-party vendor.

Conclusion (or Rant)

iOS package management is living through its wild west. The advent of new architecture surely doesn't make things easier either. For now, I hope that you found the guide helpful.

Despite all the rough edges, I can't thank the iOS community enough. CocoaPods team delivers the best experience possible and even more. I only wish for Apple to stop pretending CocoaPods doesn't exist in the first place.

It's hard to make any calls but just imagine a graceful Swift Package Manager migration or proactively making CocoaPods support a new Xcode change. How cool would that be, huh? 🤔

You can make anything, till next time :)

thegoodalright.dev

Exploring Default Argument Values

Optional Default Values #

Structured Default Arguments #

Warnings to the rescue #

Unconclusion #

Combine Rate Limiting

Under Pressure #

Behind the Facades #

To the limit #

The Implementation #

Here be Dragons #

Conclusion #

Swift String Showcase: Privacy Logs

Introduction to String Interpolation #

Extend String Interpolation #

Custom String Interpolation Type #

Logger Nuances #

Conclusion #

CocoaPods Setup ft. Apple Silicon

Ruby Management #

System Ruby #

System Ruby: GEM_HOME #

System Ruby: PATH #

Homebrew #

RVM #

rbenv #

asdf #

Gems Management #

Bundler #

Gemset #

Pods Management #

Pod Install Quirks #

ffi error #

Project Setup #

EXCLUDED_ARCHS shenanigans #

Missing arm64 Simulator Slice #

Conclusion (or Rant) #

Optional Default Values

Structured Default Arguments

Warnings to the rescue

Unconclusion

Under Pressure

Behind the Facades

To the limit

The Implementation

Here be Dragons

Conclusion

Introduction to String Interpolation

Extend String Interpolation

Custom String Interpolation Type

`Logger` Nuances

Conclusion

Ruby Management

System Ruby

System Ruby: GEM_HOME

System Ruby: PATH

Homebrew

RVM

rbenv

asdf

Gems Management

Bundler

Gemset

Pods Management

Pod Install Quirks

`ffi` error

Project Setup

`EXCLUDED_ARCHS` shenanigans

Missing `arm64` Simulator Slice

Conclusion (or Rant)