These owners always keep an eye on new updates and make it a task to go through them as soon as they can. But sometimes, life happens, and one is not able to keep up with it. More often than not, though, the reason why updates are not kept on top of is simply because people forget that it's part of their responsibilities. And I don't blame them. Right now, we just keep the list of owners in our documentation site, which is a very passive way of doing things.

Instead, we've now worked on upgrading our nightly notification system! This existing system not only runs a set of unit tests and sends a message with test results and code coverage to our Slack channel, but it also shows a list of outdated dependencies thanks to swift-outdated and some custom code on top that is part of our development tools.

So before, the message just included a table of dependencies to be updated:

| Package | swift-composable-architecture | 1.12.0 | 1.13.0 | ❗️

But now, we've added an @mention to the Slack user responsible for each outdated dependency.

In my experience, the reason updates often get neglected is simply because it can be easy to forget or overlook tasks that aren't constantly in front of you. That's why I think having a system for notes is so crucial - it helps keep important responsibilities top-of-mind. By providing a daily reminder of the pending updates they are responsible for, our new notification system has helped streamline things for the whole team.

Doing this is very simple since we already have the infrastructure in place. It was just a matter of having a mapping between dependencies and Slack users in our CLI. Something very low-tech that does the work 👌

But there was an extra requirement of mine: if there is a dependency we don't have an owner for, we send an error on the nightly message so we can assign one immediately. This is something not trivial with swift-outdated because that reads from the .resolved file, which has no information about what dependencies are transitive and which ones are directly yours. Since in our opinion, we don't want to be bothered with transitive dependencies, we don't assign owners to those.

To solve this, we read the Package.swift file in advance so we know what the direct dependencies are. This is quite simple, as SPM makes it very easy to get a JSON representation of a package: swift package dump-package.

So work done.

But you know me, I can't avoid getting excited with interesting ideas. So when discussing how to approach this with my team, I wondered... what if we could attach the owner to the dependency itself in the Package.swift file? Well, hold my glass of water.

Something I love about SPM is that the package definition file is actually a Swift file, which means you can run Swift code in it. Thanks to that, we can add an API to the PackageDescription that does what we want.

.package(url: "...", exact: "...", owner: "...")

To do this, we can extend the SPM types with our own method. Of course, we need to return what SPM expects.

extension PackageDescription.Package.Dependency {
    static func package(
        url: String,
        exact version: Version,
        owner: String
    ) -> PackageDescription.Package.Dependency {
        .package(url: url, exact: version)
    }
}

So what's the point of having the new parameter if it's not used? Well, that we have it in the same source, and we can extract it from it!

But if you're thinking SPM dump will include this data, well, of course, it won't, as SPM doesn't know anything about it. That doesn't mean we can't get it; it just means it's our work. For things like this, I always rely on swift-parsing, and it makes it quite easy to extract the dependency from the file.

This is the output of running a quick proof of concept command line:

▶ ./spm-owners Package.swift
┏━━━┳━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━┳━━━━━━━━━━┓
┃   ┃ Package                       ┃ Version  ┃ Owner    ┃
┃   ┃ <String>                      ┃ <String> ┃ <String> ┃
┡━━━╇━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━╇━━━━━━━━━━┩
│ 0 │ swift-parsing                 │ 0.13.0   │ Martin   │
│ 1 │ swift-argument-parser         │ 1.5.0    │ Martin   │
│ 2 │ swift-composable-architecture │ 1.13.0   │ Alex     │
└───┴───────────────────────────────┴──────────┴──────────┘

I love this! Having the ownership data as part of the Package.swift makes it so things are always in sync and up to date.

Of course, I'm not using this in our team's system because it's not production-ready; it's just a proof of concept. The big disadvantage is that although Package.swift can run Swift code, you can't just import a separate package, which means one would have to copy-paste the code above manually. Not a deal-breaker, but not nice enough for me to want to maintain 😂 If one could import in the package file, it would be another story.

So there you go, an interesting proof of concept that has kept me entertained for a couple of hours. I wish SPM would officially support a way to accomplish this, somehow to be able to add metadata and that it would be kept for other tools. And maybe there is, and I'm not aware?

You can check out the proof of concept on the spm-owners repo, if you are curious.

Or do we?

There are some APIs that are easy to backport if we disregard the old versions of the operative system. This may sound awful but is a valid option that is worth considering. If you know you have a very little percentage of users stuck in the old version but you can't get rid of it because of some policy, you know the impact is very minimal. And if time has already passed and dropping that version is on the horizon, you have more reason to plan for the future and not get stuck in the past. No matter what, we should make sure that users in the old version don't get a bad experience. It may be not perfect and modern, but they still should be able to use the app properly. It's a case-by-case decision that you have to take, but if you do, here is how to pull it off.

Porting SwiftUI modifiers

We will focus on SwiftUI modifiers. Other features can also be backported, but they will need slightly different techniques. The one for modifiers is actually quite simple, but it always depends on the functionality itself.

I've used this technique for a while, and it works very well. For example the scrollDismissesKeyboard(_:) modifier is a good candidate. It's a new functionality that users in old versions won't miss because they wouldn't have access to it before (well, unless your app was UIKit, again, case by case).

The first step is to copy the modifier function signature in your own View extension:

extension View {
    /// docs...
    @available(iOS 16.0, macOS 13.0, tvOS 16.0, watchOS 9.0, *)
    public func scrollDismissesKeyboard(_ mode: ScrollDismissesKeyboardMode) -> some View
}

I also recommend copying over the documentation so the users of this function will get all the info they need. Just as if it was the legitimate function from the framework.

Conceptually the implementation of the function is very simple: we check in which OS version we are and we call the SwiftUI function when available and fallback to something else when not. This applies to all modifiers you want to port, but there are two things to consider.

Fallback on old OS

What do you do as a fallback? That's the first question to consider and it will depend on the feature, its complexity, how much worth it is for you and a multitude of other aspects, technical and non-technical. This is the "case by case" part of this work.

In this example, the fallback is simply to do nothing. And that works for many cases, really. To implement this, we just need to return self in the old version so our modifier does nothing with the view.

if #available(iOS 16.0, *) {
    self
        .scrollDismissesKeyboard(mode)
} else {
    self
}

That's what we want, easy, right? Well, remember that for this to work, we need to opt in this function into the ViewBuilder DSL. Check out ViewBuilder vs. AnyView for more details about this.

If your modifier didn't take any parameters, that would be all you needed, but that's rarely the case.

Backport parameters

Most modifiers take some parameters to adjust its functionality. Those types are often new and thus not present in old versions, so we need to port those too.

The process for that is similar, just copy the existing types into your own file.

public struct ScrollDismissesKeyboardMode {
    public static var automatic: ScrollDismissesKeyboardMode { get }
    public static var immediately: ScrollDismissesKeyboardMode { get }
    public static var interactively: ScrollDismissesKeyboardMode { get }
    public static var never: ScrollDismissesKeyboardMode { get }
}

Now that's a fine way to start, but I find it significantly easier to work with an enum. That way, you don't have to worry about internal implementations or storing any data. Furthermore, I also recommend prefixing the name of the type so is distinct from the SwiftUI one. This is not strictly necessary, but I've found that makes the compiler way happier as it helps distinguish the functions easily. It's also a hint to the user of the function that there are some shenanigans going on.

So let's convert that type to an enum instead:

public enum MyScrollDismissesKeyboardMode {
    case automatic
    case immediately
    case interactively
    case never
}

This makes it so the usage side can use the same dot syntax and names as with the original function while using our custom types. But we still need to give SwiftUI its own types, so I always add a property to do the conversion.

// MyScrollDismissesKeyboardMode
    @available(iOS 16.0, *)
    var swiftUI: ScrollDismissesKeyboardMode {
        switch self {
        case .automatic: return .automatic
        case .immediately: return .immediately
        case .interactively: return .interactively
        case .never: return .never
        }
    }

This property is only available in the new OS since when we call it we will be in the correct version.

Now we can switch the function to use the new type.

   @ViewBuilder func scrollDismissesKeyboard(
      _ mode: MyScrollDismissesKeyboardMode
  ) -> some View {
      if #available(iOS 16.0, *) {
          self
              .scrollDismissesKeyboard(mode.swiftUI)
      } else {
          self
      }
  }

And that's the function fully back ported. We take our custom parameter, and if we are in the new version, convert it to the SwiftUI one and call the real modifier. Otherwise, we just return the view unmodified.

Using our function

With this, the usage side would look exactly as with the real code.

SomeView()
  .scrollDismissesKeyboard(.immediately)

For that to work you just need to make sure your function is in your module, or if it's in a separate package (which I always recommend) you need to import it in your file.

This works because your code always takes precedence over system frameworks. This means the compiler will pick your custom function and types before SwiftUI's.

Obsoleted

Another very useful tip is to use an availability annotation to ensure the compiler will remind you to remove this code when your minimum target matches the one that introduced the modifier. For this, we can add an @available with the obsoleted parameter.

@available(iOS, obsoleted: 16.0, message: "SwiftUI.View.scrollDismissesKeyboard is available on iOS 16.")

This is very helpful and makes the compiler work for you.

Pick your battles

Just like deciding what to do as a fallback based on tradeoffs, choosing which parameters and features to support is important too.

For example, if we want to port presentationDetents(_:) we will find out is a bit more complex. The custom detent needs some generic work that might not be trivial, so when you see that sort of complexity you can decide to just ignore it. Remember that this code is for you. It's likely that you are not trying to make a full featured framework for the entire world, so if you don't need some functionality right now, just skip it. By the time you need it, you will use the native solution already.

So in this case, you may decide to simplify the detents you offer:

public enum MyPresentationDetent: Hashable {
    case medium
    case large
    case fraction(_ fraction: CGFloat)
    case height(_ height: CGFloat)
    // no custom detent supported
}

More than back-porting

This technique is not only useful to back port functionality to older OSs but also to improve functionality and make it work the way you want. You can use the same technique, ignoring the version checks, and that will give you a way to offer more reusable parameters and options and to have a reusable place to include extra logic, all of that while keeping the same syntax as the system.

This is beneficial because it allows your code to be easily adjusted when Apple adds new options natively, saving you from having to completely refactor multiple views.

Conclusion

This technique is just another tool on your belt. It's up to you to decide when is appropriate to use it, but I recommend you to think about it. There are plenty of times when we could use modern APIs with little problem while keeping compatibility with older systems.

Just have it in mind, analyze the tradeoffs and decide.

Rating: 5/5

I haven't experienced many world-hopping narratives, so what might come across as a trope to some was very appealing to me. The execution of the plot is brilliant, especially the dynamic where the two main characters need to learn to live each other's life. It is fascinating how Painter, who comes from a modern world akin to ours, needs to understand and follow the constraints of a world made by doctrine. In contrast, we observe Yumi thrust into a more open-minded world as she navigates her inner suppression and confronts her fears.

The asymmetry goes further than that. Painter having to live in Yumi's body initiates a subtle, yet impactful, conversation about the experience of living in a body that doesn't align with one's identity, a conversation still too often silenced in our society. On the other hand, Yumi keeping her own body introduces a more conventional underpinning of deception to the plot. The contrast between these two representations of what is living in a foreign world operates on many levels that are fascinating to read. The origin of these differences and the magic behind them are a mystery that keeps you hooked until the end.

Setting aside the fantasy and magic of the story, which in typical Sanderson's fashion is one of the best ones I've experienced, what resonated deeply with me was the core theme of personal growth. The journey of self-improvement that forces the characters to open their mind and shift their perspective, dismantling their own dogmas and fears. Among the many narrative threads, a particular subplot I really liked was about meditation. What started as a push for the other character to do meditation in the only correct way evolved into the understanding that each person is different and has its own path to tranquility, of emptying their mind or even of not emptying it at all. Coming to terms with the difference between each individual was an enriching and fulfilling experience.

The other part I liked a lot was the intricacies of the love story. As I often tell my wife, love finds its way in every tale, even in those that don't exactly belong to the romance genre. I've never been captivated by the romance genre, but I still find myself seduced by the deep connections that love weaves into every story. With "Yumi and the Nightmare Painter", while the main plot is about figuring out what happened and how to fix it, through the course of the story we see how two strangers naturally bound thanks to mutual understanding and sharing their fears. This evolution culminates in a lovely relationship that plays an integral part of the climax. It's a delight to see the author be less shy with certain scenes and letting these human aspects arise n the story.

Now, the question that everybody asks: Is this book enjoyable if you haven't read the Cosmere? Well, I can't tell you for sure because for me the Cosmere is the main reason I love Sanderson's work. I'm a sucker for interconnected stories and worlds and is where a big part of my enjoyment comes from. Yet, I truly think that you can enjoy this, and all other stories, without being an expert in Realmatic Theory. The story stands on its own and is self-contained. You will miss on the occasional nod to the rest of the Cosmere but that is normal and expected. So don't ignore this book just because of this.

I want to conclude with the only point of critique I have about this book, a concern that involves none other than our beloved and mischievous Hoid. The voice of the book being narrated by Hoid is very interesting. It feels different from other occasions while still being clearly Hoid. This narrative choice worked really well. However, I have to admit that there are a couple of moments where the exposition runs for a bit too long, even for me. This was particularly notable towards the end of the story, when the prose stops showing the events and just lets the narrator tell us exactly what happens in what feels like an "info dump". Granted, it makes sense from the narration point of view, as Hoid is narrating the story to somebody in the Cosmere, but while I was immersed in the story this pulled me out of the fiction immediately and made me ask: am I accepting this because the author is Brandon Sanderson? Would I accept it from another author lacking the same level of reputation?

The immediate answer that came to mind was that I would have been more critical of another author. However, after some introspection, I realised how I ignored a critical factor: context. Brandon Sanderson has not only carved his reputation through the years, but directly made a tremendous impact on me. Of course I can accept a bit of whimsicalness from time to time if that's what he enjoys. I shouldn't forget that's precisely why I baked the secret projects and why I love them so much!

In summary, a resounding endorsement. Must read. Cosmere pinnacle, and top fantasy book.

I really like how we see the conclusion of some of the recurrent characters, some who I ended up despising and others that I felt close to. But the character that makes more progress is humanity itself. The challenges that face humanity in this story are eye opening. The author not only presents a sci-fi story to spark a wild imagination, but it also solidifies philosophical questions and shows the possible consequences of our naïve space exploration.

For years, we have been wondering if we are alone in the universe, if there is life beyond the heat of our sun. And assuming we are not as special as we usually pretend, why we haven't found it yet. Remembrance of Earth's Past puts us in a fictional result of those thoughts. It tells us what could happen if we keep asking those questions instead of asking if we should even look for other civilizations. Maybe we should do everything we can to make ourselves invisible in the vastness of the dark forest.

Seeing the consequences of the Dark Forest theory, introduced in the previous book, and put beyond what I could have imagined, is also great. The author keeps surprising me with additional levels of power and technology. I always wonder how much further can power go in a science-fiction scenario. I'm used to see fantasy grow the power to extremes, but how can you do that with hard science and technology? The technologies and fundamental theories explored by this series are mind blowing. From new forms of communication to technology to travel at light-speed, even higher dimensional physics, the series explores mind-blowing concepts that will make me read additional explanations and summaries to grasp fully.

As with everything I read, some details run wild in my imagination, morphing and growing to eventually settle in some part of the Pulubi. It's what I love the most about reading, how it fuels the infinite machine of imagination to bring into existence new forms.

One concept that fascinated me the most is to see how the author raises the question of what makes us humans. During the events of the book, we find on multiple occasions when humanity itself considers how some fellow humans have lost their humanity, how they are something else entirely. I often find thoughts like this come from brutal acts that dehumanize the characters in question or from a scientific long evolution that departs the physical form from the original. But in this case, the author makes us question how seemingly small acts and just a bit of time can come to question if those committing them are still one of us. Seeing how being isolated in a spaceship in an unreachable part of the universe makes one question their relation to humanity. Or how stuffing the entire human race in a confine space and make it fight for survival to the extreme would make us consider if those taking part in such survival game are still human.

Overall, I really liked the book and the series. Very thought provoking, with plenty of ideas that will keep echoing in the back of my mind for a long time.

Now let's see how the adaptations fare in comparison.

It's still not fully generic since macros don't give you all the type information you need for that yet, but they are functional and usable via ad hoc macros.

But also I don't think we have a big need for them anymore, the development landscape has changed a lot since those days.

Check out this video:

Previous conversations about traits and mixins:

• UIViewController extension for keyboard avoidance, and the missing features of Swift | Alexito's World
• I'm not the only one that wants traits in Swift | Alexito's World
• Jonathan Blow's libraries discussion | Alexito's World

This year has been quite entertaining as the main focus has been on the new platform, something that hasn't taken too much brain power of mine. visionOS is very cool, but it still feels like a very narrow and futuristic device. For what I care, the software and the engineering, there are two parts: apps as we know them, and new spatial design. For the first one there is not much difficult things to learn since is all based on all the farmeworks we know and love. For the spatial design it requires bringing 3Dc ontent into apps, which is a different discipline that although I've dabbled with, it's not in my priorities right now. The combination of that means all the visionOS talks have been a breeze to go trough, like watching a scifi show.

The rest of sessions have been on the usual topics and frameworks. In general I've found all of them quite straightforward, without anything new or revolutionary that would make by brain go boom. Most of this is thanks to Swift being open source, which removes the surprise factor of the things I'm interested in by a lot. I basically knew everything coming on that front already. So that leaves SwiftUI as the delightful surprise machine.

I'm not complaining, is good to have a year a bit more relaxed. Before WWDC started I already decided to take this year a bit calmed, for my own mental health. I could jump in the wagon of content generation but I prefer to enjoy it, treat it as entertainment and learn with it. It's way more fun!

Favorite sessions

After long nights and early mornings, I've watched more than 90 sessions. That's pretty much every single session that is not gaming, ML, web or business related 😂. It's not that much time when you watch it an higher speed ⏭️ I surprised even myself, but with all the sessions being quite low in new content time flew by, it was very enjoyable!

From all of those the ones I've kept bookmarket are:

• Explore SwiftUI animation
• Demystify SwiftUI performance
• Explore pie charts and interactivity in Swift Charts
• Beyond the basics of structured concurrency
• Analyze hangs with Instruments, probably the best session with hands-on explanations on how to solve performance issues, exploring all different situations and giving nuggets of knowledge along the way.

Even if this year the content was not super impactful for me, every single session and presenter is amazing. The quality is over the clouds. They all are interesting to watch and listen, and present the topics in a very entertaining and interesting manner. And I love how Apple, a huge coorporation, let's every presenter add a bit of their own personality to the videos. It makes them so much approachable. My congratulations to all the ones involved in making this sessions so enjoyable!

Raw Notes

This won't include every detail in all sessions. The notes reflect things that have caught my attention and that I want to remember their existence for later. Details are best obtained by going to the documentation when needed knowledge is up to date.

Keynote

• Stickers in third party apps like emojis?
• Journal! gratitude and memories with suggestions from photos, music, trips...
  • suggestions api
  • health mood tracking with state of mind, assessments
  • Craig: "multiple timers, we truly live in an age of wonders."
  • vision health, how much time spent outdoors in sunlight, screen distance

SotU

With WidgetKit, you can surface your content in many places across the system. With App Intents, your app's functionality is integrated into the system even more seamlessly. With TipKit, you can surface beautiful tips directly in your app. And with AirDrop, you can make it even more convenient for your users to share content with those nearby.

• WidgetKit
  • Available on StanBy mode, lockscreen on ipad, and mac desktop. with background removed.
  • Identify the background (.containerBackground modifier) and update its padding (remove it, it comes by default now).
  • Interactivity with buttons and toggles to trigger App Intents.
  • Transitions supported.
  • TipKit
  • Configure tooltips to be displayed to users with rules. Sync across devices.
  • Values:
  • Accessibility:
    • new pause animated images flag
    • avoid bright flashing lights in videos
  • Privacy
  • App Store
  • New swiftui api to make the subscribe screens following apple standards.
  • Xcode
  • 
  • Code generation for asset catalogs
  • Macro for swiftui previews (and for uikit and appkit!)
  • visionOS
  • Windows, Volumes and Spaces
  • Existing apps are just using Windows, but if you rebuild you get the proper look and feel with materials.
  • 
  • ZStacks can have depth.
  • Mix SwiftUI with RealityKit.
  • Ornaments fix UI elements to the side of the window, great for toolbars and menus.
  • Hover effects where the user looks.

SwiftUI

Charts

• Pie and Donut charts with new SectorMark
• Chart Selection that automatically handles the gesture recognitizers to allow selection along axis, ranges and angles. Allows to provide a custom gesture whilte still making it easy to select the value based on the gesture location.
• Scrollable with chartScrollableAxis and specify the visible domain. It also supports scroll target behaviours.

Inspectors

Views that show further detail of selected content. Is a right sidebar that adapts to a sheet on smaller sizes.

Presentation

New presentationBackground to change the background of the sheets overlays, the overlay that covers the entire screen.

presentationBackgroundInteraction let's you enable the interaction of the content behind even when a sheet is up.

presentationCornerRadius(_:)

presentationContentInteraction(_:)

presentationCompactAdaptation(_:) Some of these modifiers also work when Inspectors are presented as sheets.

Animations

Phases:

• loop between phases applying styles on each one.
• starts immediately on appearance
• or pass a trigger to animate when it changes

Keyframes:

• Run parallel animation tracks, inside each track is a sequence
• Refreshes the view on every frame
• MapKit has support to keyframe the camera
• KeyFrameTimeline allows you to evaluate an animation, and even display it in a chart.

UnitCurve and Spring contain the algorithms/curves that drive the change of values. You can use them directly to get a value at a specific point in time.

CustomAnimation protocol to write custom animation curves. Can impleemnt velocty and merge behaviour to mix with other animations that was triggered while another was running.

Transaction is now public. Is another implicit-data flow construct, a dictionary that is passed trough the view hierarchy on every update and discarded at the end. it's used for animatable views to know if they should animate on this update. It's what withAnimation does, and the animation modifier touches. Now you can add your own data to know if during a body update it was triggered programmatically or by the user for example. A new animation modifier with a closure let's you apply the animation just to specific effects instead of inserting it in the view hierarchy. the other children views are not affected by this animation, unlike the normal animation modifier that injects the animation to all children.

• transfer velocity auomatically, smooth spring by default
• sfsymbol animated
• contentTransition(.numericText(value: totalCaffeine.value))

Observable

macro, so we just need State te and Environment wrappers now.

Scroll effects

scrollTransition to modify the rows when the enter the visible area.

scrollTargetBehaviour(.paging) for full screen paging deceleration

scrollTargetBehaviour(.viewAligned) to decelerate targeting a view, to mark which views are targets use scrollTargetLayout for lazy stacks (important because not all views are created yet, but the stack knows and will tell the scroll) or scrollTarget for the individual views themselves. Can use custom behaviours with ScrollTargetBehaviour conformance.

safeAreaPadding modifier, so the scrollview still extends to the full screen but its views are padded (both your content and its scroll indicators).

contentMargin modifier to specify padding only to the content or to the scroll indicators.

containerRelativeFrame to let the view grow based on the container size. And can use parameters to let multiple views share the space, making grid like layouts.

scrollPosition(id: gives a binding to scroll to that view.

Visual Effects

It gets the content and a geometry proxy.

You can use a coordinate space outside of the view, and compute the distance of a point in the space to the view using the proxy, then use that distance to change the content with effects.

Vertical tabs in watchkit

Menu palette

Picker with the palette style

Performance

Make sure IDs are fast to compute. Just pass to views what they need, otherwise they depend on more. ForEach should just have 1 view so it can match the ID with it. It eagerly gets all IDs, but lazy the views. If there are more views it needs to easily get them too which is bad.

Focus

You can specify the interaction for when a view is focused. (edit or activate) Default focus to specify which element should be focused by default. New onKeyPress modifier. Focus values to tell menu commands which view is in focus. Focus sections to let directional focus (like in tvOS) fall into a non-adjacent view that otherwise wouldn't be elegible for focus.

Widgets

• Animations and transitions when the data of the widget changes
• Interactive
  • Can use buttons and toggles with new inits that trigger an app intent.
  • App intent interactions are ensured to trigger a reload immediatly, unlike tmieline changes.
  • Invalidate content modifier for specific views that should show interaction update to the user faster, specially when is on mac since it goes over wifi.
  • Toggle optimistically updates the state so appear faster
  • Widgets show in mac via continuity
  • Widgets for watch stack have design recommendations, instead of hardcoded layouts like in the original apis
  • 

CoreData

• Composite attributes, alternative to transformables
• Staged schema migrations
• Deferred migrations, to delay the cleanup of schema migrations (colum or table removals) for later to not block the user.

SwiftData

• Built on top of proven core data persistance layer (?what does this mean??)
• Schemas and definitions all in code, with macros. No external schema files.
• @Model gives you:
  • Persistence
  • Schema modeling
  • Lightweight migration
  • Relationship management
  • iCloud synchronization
  • Spotlight search
  • Undo/Redo
  • @Query to fetch and show results in SwiftUI.
  • Model container understands the relationships of the schema so even if you just give it 1 type it will infer the related types it needs to persist.
  • Advanced model configuration and schema can combine multiple different schemas with different stores into 1.
  • Get the model context trough the environment to operate with the database. It propagates changes to the model container.
  • It uses the undo manager from the environment to automatically support undo/redo.
  • Auto saves in sync with SwiftUI related events and system events. You can also save manually.
  • Fetch trough the context with fetch descriptor and the new predicate macros, which give compiler validated queries.
  • Use the context enumerate method to effeminately fetch lists of data, uses automatically batch processing under the hood, and safe mutation guards. It can be customized.
  • Document based apps by using a SwiftData model as a packaged file
  • But models are still classes... they haven't embraced an immutable model. Pretty weird. :(

CloudKit

CKSyncEngine. Between high level core data integration and low level operations.

TipKit

Looks very interesting, specially with the rules system that will prompt the tips at the appropiate moment and a consistent UI.

Foundation

• Improvements in gramatical agreement with other arguments and even concepts outside the string.
• New terms of address for pronouns
• Resumable upload url session tasks, and support in SwiftNIO

Swift

• if/switch expressions
• improved result builders
• type parameter packs
• macros
  • 
  • 
  • 
  • 
  • native swift foundation
  • ownership
  • c++ interoperatibility
  • discarding task group

Xcode

• Improved suggestions order
• New localization strings catalog format
  • Eventually will replace strings and stringdict.
  • Allows variant of strings based on platform (click vs tap)
  • Can make multiple catalogs to have different string tables
  • Xcode automatically extracts localizable strings from code. Use localised initialisers in strings and LocalizedStringResource.
  • In SwiftUI use LocalizedStringResource in your views to accept localizable strings
  • Code gen asset catalog and localisation access
  • Documentation preview in editor assistant
  • Preview macro and UIKit/appkit support
  • Bookmarks
  • Source control improvements
  • test results new design
  • oslog integration in Xcode output, with filters
  • Streamlined workflows for app distribution

UIKit

Custom traits let you bridge with swiftui environment Status bar changes color automatically Page control with progress and timer. Menu palette New text selection style. Comes from free with system text views. Now can also be used in custom text views together with the loupe. New UITextItemTagAttributeName to tag ranges in a text so we can get interactions, ideal for "See More" in text! And it has new APIs to change the default menu behaviour when interacting with them. List and bullets supported in attributed string.

AppKit

• Table column customizations for free
• NSProgress support in NSProgressIndicator
• Popover background can expand to the chevron
• NSBezier path, CGPath interoperability
• CADisplayLink!
• More Sendable everywhere!

App Intents

Improvements on app intents App shortcuts are now discoverable in Spotlight, design for it.

Accessibility

• isToggle trait
• AccessibilityNotification.{Anouncement}.post
• Anouncement priority to avoid interruptions
• Direct touch options
• Accessibility shape

App Clips

• new size limit 50mb for digital invocations
• Default app clips urls hosted by the app store
• launching app clips from apps

Privacy

• new calendar write only permission
• New embedded photos picker that is smaller, so users picks what they want without requiring to give gallery permissions.
  • Customizable: Hide accessory UI, buttons, specify frame and padding, get selections in real time.
  • Inline style, ideal to combine with hidden accessories.
  • Compact style that is just a row.
  • new macOS window picker to screen recording
  • support for OHTTP relay
  • Communication safety for apps with Sensitive Content Analysis framework to detect nudity. sensitive content warning to blur images.
  • Xcode privacy manifest generates privacy details from third party sdks.
  • Tracking domains help the system block calls to those domains until the user has agreed to be tracked.
  • New Instrument that displays requests to potentially tracking domains
  • Required reason APIs are apis that have potential to be misused for fingerprinting. apps and sdks must declare a reason to use them.
  • Signatures for third party sdks to validate the code comes from the correct authors.

Core Location

New Monitor API based on actors.

Other

• VisionKit to integrate photo subject lifting into our apps.
• Accessibility audits now can be automated in UI Tests
• SFSymbols components to mix in your custom ones.
• Push Notification Console website
  • Send push to specific device for testing and development
  • Delivery log to know what went wrong. Put device in low power mode to not receive them.
  • Debug tool to validate tokens.
  • Improved App Store Connect APIs and a swift server library
  • DockKit is pretty cool. I didn't know iOS had this functionality out of the box!
  • Keyboard is now out of process.
  • Remember to use the keyboard autolayout guide in UIKit. In SwiftUI the safe area includes the keyboard automatically. If you are still using the old notifications check out the session Keep up with the keyboard because with all the recent keyboard modes it doesn't behave as expected.

Rating: 3/5

But I had another motive to read Daniel's words: to convince myself that I could write too. As someone who has been grappling with self-doubt regarding the worthiness of putting my thoughts into words, I actively seek any fragment that can fuel the self-confidence required to embark on such an endeavor. Seeing what Daniel has accomplished is another stone in the unfinished building of trusting myself. With this, I don't mean to diminish his work. Quite the opposite. He has accomplished something many could only dream of. But it also helps me believe, and, as with many things in life, that's the first step towards going anywhere. The rest is time and dedication and, well, that will need other stones and bricks.

But let's talk about the series itself.

I'm very intrigued by all the possibilities of the world building. That is not something that happens often, but it's also not surprising seeing the amount of reading that Daniel has made and how much of it matches my taste. Watching the videos where he explains a bit of the world building and magic system also makes me desire to see even more stories based on this world. What I really liked the most in these first two novellas is how they are so character focused. The plot leaves the intriguing world-building as a backdrop for an emotionally intense story. It would have been very easy to focus on the interesting bits of the world and its magic, but that would have made for a poor story. Very well done and something to learn from.

The other aspect I liked is how the words are not shy about using swear words when necessary. I always find most prose to be severely censored when, in reality, most people swear from time to time. Used poorly can make the text become distasteful, but when used appropriately, it makes me feel closer to the characters and the reality they are living.

Another notable aspect of Daniel's words is their fearless embrace of horror and visceral scenes. They are far and between, but when they come, they pack a big punch. Others would have skimmed through the events in the scene without focusing on delivering the impact they needed. I really appreciate Daniel being bold delivering the perfect amount of explicitness in the moments where the story benefited from it. Touché.

Overall, I admire the smart move of starting with novellas. It brings the focus to a concise plot and lets us taste of this world while leaving us wanting more. I hope Daniel returns to this series soon because I want to see how things progress forward.

What truly adds to the allure of Dark One: Forgotten is the collaborative effort of Sanderson and Wells. Their partnership holds immense potential, evident through the subtle traces of their individual brilliance that I discovered within this production. This exciting glimpse into their combined creativity has left me eagerly anticipating what they have in store for us next.

Rating: 4/5

Rating: 3.5-4/5

The third act of The Sandman continues to follow its captivating path, although I must admit that I found myself longing for more moments with Dream, as he isn't the central figure in many of the episodes. Nonetheless, each episode remains very enjoyable thanks to the diverse range of characters whose individual storylines weave together seamlessly, adding depth and richness to the overall narrative.

Despite my initial yearning for the previous storylines, I found myself thoroughly engrossed in the captivating arc that followed Delirium, Dream's extraordinary younger sister, in her quest to find their lost brother, a pursuit dismissed by the rest of the familay. Her character is nothing short of fascinating, with her whimsical demeanor and unpredictable nature adding a unique layer of intrigue to the narrative. This arc not only deepens our understanding of the Endless family but also grants us the opportunity to delve deeper into the intricate tapestry of the Sandman universe, introducing characters from other times.

Undoubtedly, the most captivating arc is the one set in the inn at the end of all worlds. The disconnected short stories, narrated by an intriguing ensemble of characters, are all fascinating. What adds to its allure is the intriguing framing narrative, which builds anticipation and culminates in a impactful and mysterious ending. While the concept of such a place is a common fantasy trope, the masterful execution by Gaiman makes it work exceptionally well within the story, providing valuable lessons to learn from.

I eagerly await the culmination of this extraordinary journey in The Sandman, I hope Act four is not too far away.

But then I started The Frugal Wizard’s Handbook for Surviving Medieval England, what a title!, and remembered how curious I got when Sanderson read the first chapters on his promotional videos last year. That excitement got the best of me. That was three days ago.

Rating: 4/5. Four of five stars. The author keeps delivering. Interesting premise, world and characters. Funny and mysterious in equal parts. Would recommend.

Like Tress, the Frugal Wizard is a different beast from what I'm used to with Sanderson, something that definitely will give him critical reviews again, from those that prefer their favorite authors to stay monotone. For me? I loved it. The way Sanderson mixes the seriousness of the mystery with the lightheartedness of the premise and the marketing materials of the Guide is nothing short of brilliant. It's a testament to his talent that he can balance all of it so effectively, and it's one of the many things I'm really enjoying about his more recent work.

The world-building in this book is so clever. For those who have followed Sanderson outside of his books, you may know that he has two unbreakable rules that he follows on the Cosmere: no time travel and no multiverse. I love those rules, and they are ones I've followed on my amateur fiction creation too. They are very important to keep the stakes of a story. As soon as time travel or multiple versions of the same characters are introduced, consequences lose their impact.

But in the Frugal world, he doesn't have to follow Cosmere rules, and he has broken them, not to the detriment of the story, but quite the opposite. The "Medieval England" of the story is not our Medieval England, the main character hasn't travelled to the past; instead, he has travelled to an alternate dimension that is similar but not exactly like ours. This is brilliant because it keeps the consequences of time travel away from the plot, and still it gives a chance to develop stories with what feels like time travellers. At the same time is not a multiverse of clones, but one where each dimension is slightly different, which means those are different and real people that the characters, and the reader, can care about. Brilliant!

In the same vein, I loved the main character. That he starts without memory in a strange land and starts remembering things of his past that may or not be correct is great. It's so relatable, not the loss of memory, but how our present mind can wrongly interpret old memories. The character is very flawed and we can feel the roller coaster of emotions and realisations that he's going through the entire book.

And finally, the setting of medieval England is very nice. I'm not a historical fiction reader but this was very interesting, mainly because one knows Sanderson style and you know he can't resist giving a twist to any world he builds. The mystery of knowing where things may differ from our history kept me on my toes, not at the level of the Cosmere, but enough to keep me going.

Rating: 3/5

I really liked how the present of the story is mixed with flashbacks of their past. Knowing the characters from the show, it felt like I was getting a view of multiple moments of their life, all in one book. The best thing was how the ends and beginning of the chapters segued so well into and from the flashbacks. It was very enjoyable.

The story's narrow focus was appropriate to highlighting the characters instead of the world of Exandria. By splitting them up, readers were given a chance to learn more about each character individually, which was particularly rewarding given how much of their plotline is about sticking together.

Overall, quite happy with the book. It is what it is without pretensions of trying to be what is not. Very enjoyable, would recommend for any fan of the show.

Back to campaign 2

That allied with other things that were going on in my life and Critical Role crossed my YouTube suggestions again. I stopped watching Campaign 2 a while ago and a thought came to me, "what if I watch it again". I needed to put something that could stay in the background and didn't require me to focus on all the characters in the world, something to pull my mind away from the shitty reality I was living in.

And those I was hooked to Critical Role, yet again ^^

Although I had paused the show during what seemed like a quiet period, a few episodes later, the story took shape. The mysteries grew more complex, and the tension escalated, leading up to what I can confidently say was one of the most unforgettable moments I've ever seen:

What Laura did in #CriticalRoleSpoilers episode 93 of campaign 2 with the cupcakes 🧁 represents the things you only get in roleplay based storytelling. (Yes I’ve been catching up a bit 😂) Mastodon post

After that, the party got involved in plots that would endanger Exandria, magic from ancient civilizations and political intrigue; all of that made me pause book reading for a bit and instead focus my fiction consumption on Critical Role.

That's how after so many hours I finished watching campaign two, with an epic final battle that just kept getting better and better. With moments that got me on the edge of my sit, and where tears peaked from my eyes.

Those moments made me remember why I love watching Critical Role. As I quickly posted, this is just another form of storytelling, but one that can make you feel more than any other. I truly believe this cast makes the most epic fiction there is to be, not because of the story, but because of the impact that it has on you. The passion, the emerging plot, the jokes and fun they have, the tears... Other mediums can hardly achieve this high emotional mix.

I really wish more people could enjoy this, but as with many good things it has, the over five-hundred hours one needs to enjoy it means this is not something for everybody. Even for me, somebody that watches at 2x (or more) it's a big time investment.

Totally worth it for something that no other form of storytelling can offer.

Can't replicate

After campaign two, I was so hooked that entered a completionist mode where I just went and watched every video in Critical Role's YouTube channel. Including one-shots and the short alternative campaign of Exandria Unlimited.

Watching this other show made me remember why Critical Role is the only live-play I keep coming back to. Everything I've said about emerging story telling is true, but the reality is that Critical Role hooks because of its cast. Not only because they are great voice actors and know how to make you forget it's just a story, but because they are all super nice to spend hours with and the chemistry they have between themselves is gorgeous. Basically, Critical Role is its cast. The story and events are the epic parts, but none of that works without the people.

I've watched my fair share of role-play shows, but none of them have managed to capture my attention and keep me invested like Critical Role. Even though I finished Exandria Unlimited, I realized that it was the cast that made the first two campaigns truly memorable. While I appreciate that Critical Role has grown into a major production house, is expanding into new territories and including other voices that deserve to be heard, I fear that this might dilute the essence of what made the show so special for me.

To Campaign 3!

At the moment of writing, I've made it through the first 10 episodes of campaign three, and it's been a bit of a strange beginning with mixed emotions about carrying over some characters from Exandria Unlimited. However, I was pleasantly surprised to find that my apprehension about a different cast affecting my enjoyment is not an absolute. Robbie's delightful presence in campaign three has erased any doubts I had and made the experience all the more enjoyable! And of course, my positive feelings about Robbie's presence in campaign three are not meant to be a critique of anyone else who participated in Exandria Unlimited or any other guests. It's simply a personal sentiment that's difficult to articulate, based on the social dynamics and human interactions that make the show so special.

For now, Campaign 3 hasn't hooked me completely yet, although it has a few things going for it; in-world and external.

The weird set of character choices is very interesting and is already showing many interesting interactions. It's interesting how fresh it seems to have a robot and undead in the main cast, interesting because this is fantasy after all!

The chance to explore a new continent of Exandria is always exciting as it engages my world-building brain to its max. I'm interested to see more places besides the city where the characters started, because in my mind Marquet was mainly a dessert, but hearing things about jungles and other populated areas piques my interest.

But the thing that really makes me curious about where the campaign is going is what's been happening in the real world with WotC. I've heard rumblings of God level events in this campaign, which makes me excited to see Matthew get rid of the last bit of ties that Exandria has with D&D lore. This idea just got more exciting a few days ago when they confirmed the ongoing development of their own RPG.

More Exandria to come

Exploring different worlds and immersing myself in their intricacies is a passion of mine. While I could potentially use that time to focus on writing my own material, the human brain is complex and mine is not collaborating lately. Life happens. Therefore, I find myself indulging in the vast universe of Exandria instead, not just through gameplay, but also through a novel from Critical Role.

Fiction is truly unlimited.

Given some personal circumstances, I find myself with more time to listen to audiobooks, so that's why this is probably the fastest I've ever read a book in my life. After Lord of Chaos I've found the seventh book more interesting.

Rating: 4/5

This book just continues the events of the story, so my overall opinion is still a bit of the same. It feels like we're just watching events happen, following people around doing things that sometimes feel too mundane or without a clear and specific purpose. It's like we are seeing the scenes that would be cut in other stories. But it still has its charm, and in this instance more happens.

It's probably because we follow Rand for longer, doing random things all over. I really like how at this point he's more comfortable with his powers and position, although he still feels terribly responsible for many things, which clearly shows the mental burden he carries.

We see the powers taking place also with Matt and his Ta'veren status. I really like this because it feels like a passive power that none of them control and that sometimes turns out well and sometimes doesn't. It's not an absolute, they are as much in the hands of destiny as their enemies.

I really like Matt, so the fact that we follow him for a while on this book it's also a positive for me. It's even nicer because we have most of our main characters together, well, mostly split in two, but it's much nicer than having them all individually doing their own thing.

There are also a bunch more confrontations that make me wonder and be hooked into the plot. I loved how the Aes Sedai are forced to realise that they should chill a bit and stop pretending they are the rules of the world. Yes, I freaking hate the Aes Sedai 😂, not all of course, but the air of superiority that surrounds them is so exaggerated and palpable on every scene that becomes infuriating. That's what has made me love the appearance of the Asha'man.

One thing that still tickles me after having finished is how there are a couple of scenes that don't resolve with answers. There are a couple of characters that appear and we don't know who they are. I love this sense of mystery which is not that common in this story.

And I guess that summarizes my issue with the overall story. There is no mystery. Don't get me wrong, of course there are things we don't know and get revealed on time. But overall there is no big mystery that I'm eager to know. We know who is the Dark Lord; their followers are known; even the steps we need to take to destroy them and what needs to happen in the last battle. We may not know all the details, but there is no big mystery either. We are just here for the ride of seeing our characters' lives.

Nothing illustrates more clearly this aspect of just progressing through a big plot that the ending of the books. They mostly seem just another scene that could be anywhere else, and the ending of this book seven is no different. After spending the entire book following Rand around, the book ends just by doing another one of his incursions. Yes, there is a bit of a bigger battle and a tense chapter, which is great!, but the payout doesn't feel that big.

In any case, I already have book 8 ready. Let's go!

So the topic I will discuss here is not really specific to the TCA, but more about domain modeling and types. Let's start by exposing the issue:

Modeling the problem

Let's imagine we want to model the result of some side effect, like an API call, that can succeed and fail. We can easily do this with Swift's Result<Success, Failure> type, but in this case we do not care about the success data at all, only about the failure. In other words, we want to know which specific error occurred, but if it succeeded we don't want to know anything about the success data.

Of course if you have done any meaningful coding with TCA this will feel very familiar, and indeed is where I find this more often, with its other variations of I only care about success data and not the error, I don't care about any of the two, etc... But let's ignore that for now and see what the issue is and why is so important to model this correctly.

Algebra

What? Math? Seriously? Yes! It's actually the easiest way of realizing what you are doing when modeling a solution. Don't fear, it's very simple.

If you want to learn more about Algebraic Data Types I really recommend subsribing to Pointfree (get one month free with this link)

Let's first think how many potential scenarios the most basic design gives us:

Result<Int, Error>

With this type, we have n possibilities for the integer in case of success, and m possibilities for the error in case of failure. (let's assume Int is what the side effect responds with). These are n + m cases we would have to deal with, too many! Remember, we don't care about the success data.

So if we don't care about the success and only about the error, maybe we can ditch the Result type completely and just use the Error.

Error

That will give us m possibilities, but we are lacking a way to know if it succeeded. We want to know that it succeeded, but not about its specific data. But Swift already provides with a tool for it, Optional.

Optional<Error> // Error?

Now we have m from the Error and 1 from the optional nil case, so m + 1. Exactly the amount of cases we wanted!

Simple right?

But let's say we want to still use the Result type for consistency with the rest of the code. How can we use that type, which requires a Success and still keep the same m + 1? We need a type that only gives us 1 option, and again, we have one. Swift calls it Void or () (the empty tuple), called Unit in other languages. With that knowledge, let's use Result again.

Result<Void, Error>

Thanks to Void we can use the Result type and still have 1 + m cases to deal with.

This may seem like a minor thing, after all, you could just use the original data (Int) and just ignore it on your code. But that's a slippery slope that makes your code harder to reason about. When your future self comes back and reads the code, the types will explain the story of what is happening without having to read the code. The compiler will make you remember the decisions you took when you already forgot them. Such is the power of properly modeling domains with a proper type system.

The limitations

This is all nice but we need to use this response in another type, in the case of the TCA we need to embed this in an Action enum, but it could be any other type you use to carry data around.

This is how it would look if we cared about the success data:

struct ApiResponse {
    let response: Result<Int, Error>
}

All well so far. But let's make this type more realistic and make it conform to Equatable, which is something we need most of the time.

struct ApiResponse: Equatable { // Type 'ApiResponse' does not conform to protocol 'Equatable'

Boom! 💥 The compiler can't synthesise the conformance because our Result type is not equatable. Int is obviously fine, the problem is the Error.

The reason for this is a rabbit whole we don't have time to get into now, but there are multiple solutions for it. Thankfully PointFree has already provided one for the users of the TCA in the form of TaskResult<Success> (docs) so we can ignore this exact problem and move on to the one I want to discuss.

struct ApiResponse: Equatable {
    let response: TaskResult<Int>
}

Now the compiler is happy again. Keep in mind that even if we don't see the Error type anymore, the failure case is still there case failure(Error) so we still have the data we care about.

But we are still using the awful Int, let's switch back to use our lovely Void.

struct ApiResponse: Equatable { // Type 'ApiResponse' does not conform to protocol 'Equatable'
    let response: TaskResult<Void>
}

💥 Here we are again! Now it's Void that is not Equatable and if you know a bit about Swift you know why.

Void is a non-nominal type, which in simple terms it means there is not a name you can use to refer to it in some language features. One such feature is protocol conformance, which allows types to adopt a set of behaviors defined by a protocol, in this case equatability. Because Void is not a named type, Swift does not inherently know whether it conforms to any given protocol. Although we might want to make Void conform to Equatable ourselves by defining an extension, we can't do it because we cannot reference it by name! Therefore, we can't retroactively make Void conform to any protocol. 😞

extension Void: Equatable {} // Non-nominal type 'Void' cannot be extended

So if we can't use Void, maybe we can use the alternative of using an Optional?

Well, that brings us back the problem with Error that we solved with TaskResult so is not a solution.

struct ApiResponse: Equatable { // Type 'ApiResponse' does not conform to protocol 'Equatable'
    let response: Error?
}

EquatableVoid

My favorite solution to this problem is just to make Void a nominal type. Of course you can't make the existing one but you can just make your own. Remember how we described Void as the empty tuple ()? A tuple is an anonymous product type, but we can use a named product type instead.

struct EquatableVoid: Equatable {}

Our EquatableVoid it has the same shape a Void, it only has 1 possible value which we can get by calling the initializer EquatableVoid(). Is not as nice as just () but such is the price we need to pay.

With this new type, we can change our response and finally have what we want:

struct ApiResponse: Equatable {
    let response: TaskResult<EquatableVoid>
}

This gives us 1 + m cases, no more, no less. We have expressed exactly our domain.

We can use our types like so:

let ok = ApiResponse(response: TaskResult<EquatableVoid>.success(EquatableVoid()))
let ko = ApiResponse(response: TaskResult<EquatableVoid>.failure(Badabum.granBadabum))

And work with them in a switch statement exactly like we wanted:

switch response {
case .success(let void):
    // not much you can do here, you only have 1 possible value that is always the same
case .failure(let error):
    // but here you have all errors so you can work with them as you please
}

Other unsatisfactory solutions

There are, of course, other solutions that have other tradeoffs, so as usual I give you the tools so you can take the decision on your own.

You could use the optional alternative by using a specific error type that was equatable: SpecificEquatableErrorForYourDomain?. That would work but then you need to reconcile your specific error type with Swift's untyped errors. With time I've learned to embrace Swift's error system and stop fighting it, so I don't recommend this. Is a fix for this exact part of the code, but you will have to write patches in other parts to deal with any errors and default cases.

Another solution would be to use NSError, which is convertible to Error and is equatable. I tend to run away from it. I'm fine receiving it from Objective-C APIs but I want my Swift code to be Swift code. NSError loses the type safety at the usage side. You can't cast it to a specific type but need to rely on strings and integers. It's not a tradeoff I'm willing to make.

And I imagine there are other ways of solving this with different tradeoffs, but I'm not aware of one that gives me what I want in a better way :)

Other usages of this technique

This technique is not something new that I only use for this case, in fact this is the third occurrence in my codebase of this solution.

In our project, we use the TCA to its fullest and I made a generic loading system that we are very happy with. The closure that lets you customize how to get the data receives a parameter that can be injected from other domains. Think of an ID that you need to fetch a user, for example. But not all screens need parameters, so you would want to define the generic type as Void, but again it needs to be equatable. In this case, I employ another trick that let developers avoid even constructing this type at all.

public typealias NoParameter = _NoParameter?
public struct _NoParameter: Equatable {}

By using NoParameter as the generic type, developers (in fact our library has this default cause supported) can just pass nil when constructing the domain and they don't have to deal with the parameter in their implementation.

I should talk about our generic loading system because I think is pretty neat. Ping me if it's something you would be interested in :)

Another place where this pattern occurred is in the API library I implemented, which uses Swift's generic type system to make it very simple to define endpoints. In an endpoint, there is a generic parameter that defines the response model you want to decode, but of course, sometimes you don't really want to decode anything. The same goes for the generic parameter that specifies which parameter to send to the API. For that, again, you would love to use Void but it's not Decodable or Encodable so it won't work.

public struct Ignore: Equatable, Codable {}

Maybe I should think about making a SuperVoid that covers all the cases :)

Conclusion

Domain modeling matters, and having a language with a type system that supports us when designing, is crucial. Swift gets very far, but it still has some limitations with non-nominal types that thankfully can be solved by defining our own types to cover for these cases.

After just short of a month, I've read (a.k.a. listened) the sixth book in the series, Lord of Chaos (The Wheel of Time, #6), what an epic ending to the over 40 hours of audiobook!

Rating: 3.5/5

I've shared my overall feelings about the series before and I don't think they have changed, especially with this installment which feels quite slow. I still love the series for its depth and world, but what makes it really shine are its realised characters and the epicness of its events. Unfortunately, these epic moments diluted among a mountain of text that spends too much time to on chores.

I've spent the vast majority of the book just wondering where things were going because they were not going anywhere. Too many points of view and too much time spent in scenes that didn't move the plot. And is an awful feeling because I really wish I loved more those scenes! I'm pretty sure that all of them are necessary, because when I think about the Wheel of Time I can imagine a fully realised world full of incredible characters, and I doubt this would still be the case without all those filling scenes.

So yes, I'm not saying there is too much filling, but I'm saying there is a bit too much? Again, is hard for me to reconcile this feeling.

Because then, when a scene actually moves the plot forward, you could hear me scream! 🙀 There are moments so memorable and epics in this book that when I finished it last night, I immediately got better feelings about it.

Seeing our characters reunite, Rand accepting his position on all of this, and also friendships that are being muddled by world events... it's very impressive.

During this same month I've been watching Castle, the serial tv show. The fact that every episode has little to do with the previous but that as the seasons go, the writers add more and more details into the overall story line, made me realise that it's how I started looking at the Wheel of Time. Usually when I read fantasy I'm tied to the three story act, expecting the plot to move forward towards a conclusion, but after six books I think that the way to read the Wheel of Time is far from that. Each individual book doesn't strongly follow the classical formula, yes there is a meaningful ending, but the book doesn't really build up only towards that. It's closer to a tv show where we just spent time with the characters while they are doing their own thing, sometimes we spent time with them to know them better (too often) even if the plot doesn't benefit from it. So I've changed my attitude and now I'm just reading the Wheel of Time enjoying the ride with no expectation of what needs to happen or when.

It's a bittersweet realisation but I think this will propel me to the upcoming books, and I still love what's going on, so I really want to get to the conclusion of the series. I can't wait to get more epic moments like the last chapter of this book. Rand is such a freaking main character!

This experience is being strange indeed. I see myself trying to understand what I love and what I hate about the epic story, and I really can't pinpoint what's going on. I have plenty of critiques but I still see how this is one of the best epic stories ever written and I'm still loving the ride. So weird.

Rating: 3/5

I really loved having characters of a different race and seeing a different mythology, Philippine, feed the world where the story takes place. It was a breath of fresh air in a space filled with English lore. On top of that, reading some Spanish sounding words in a fantasy novel was new to me and made me a bit more special than usual.

The underwater scenes require a special mention. They made me live things that I have not experienced before in other books. It felt very original to me. And the writing was to the point, it can be tricky to make the reader connect with otherworldly situations in a way that makes us feel like we are there. Even though being underwater might not seem as unfamiliar as other environments, I have only been a few meters below the surface, and those who have gone deeper, it was surely not without the aid of an oxygen tank. Those scenes being rooted in reality, albeit a reality that few have experienced, made them just more impactful to me.

Something I was not a fan of is how the two POVs were so disconnected throughout the entire book. I was waiting for the characters to touch point always in the next chapter, but to no avail. I imagine they will get closer later in the series, but not having them connect in the first book broke my expectations and made me be more aware of this flaw. More than it deserves, because I don't think it's a bad thing that the two main characters have their separate paths, but I was not expecting it.

The story of the boy didn't quite hit the mark. Aside from the main action scene, the rest of the story felt like a prolonged setup. While it was interesting and left me curious to know more about the world, I found myself more entertained with Olenka's narrative.

Overall, I'm quite happy with it! I enjoyed the reading and I'm interested in knowing more. The next books definitively go on my to read list and I hope to get to them soon! 👏

A clash of styles

This idea came to mind after finding a clashing in styles of development. When I work on my side projects and I have to do things quickly, mostly for fun, I love the new formatting APIs, thePast.formatted(.relative(presentation: .numeric, unitsStyle: .abbreviated)). But then when working in a proper product, in a team, with a long-term vision, you need to use proper engineering techniques, which often involves doing dependency injection.

I use PointFree's dependency library (as part of the TCA) which I've discussed previously (On the new Point-Free swift-dependencies library) but this applies to any other DI technique pretty much. Usually when you want to DI something that lets you format, the best way is to provide a function that takes the input value and gives you an output value, typically a String.

public struct DateFormatter {
    public let format: (_ date: Date) -> String
}

Then the live implementation of this dependency can use a DateFormatter or the new .formatted style. The advantage of having this API as a dependency is that it allows you to very easily switch the implementation for testing and previews.

static var testValue: DateFormatter = XCTUnimplemented("\(Self.self).format")
static var previewValue: DateFormatter = { _ in "Tue, Nov 29" }
static var liveValue = { $0.formatted(...) }

Being able to just have a hard-coded value for previews or testing without having to deal with the formatters themselves is a tremendous benefit that can't be underestimated.

But as nice as this is, I resented the usage side not being as nice and natural as using the Foundation fluent API.

formatDate(selectedDay.date)

It's not bad, but I prefer the fluent API in this case. I just enjoy it a lot more when working on my side projects, so I started thinking how I could keep the joyfulness of the code but still adding the seriousness of DI.

FormatStyle instances

To start, I had to learn more about how the newly fluent API worked. I explored it in the past but Apple's documentation is not super clear in this area, but then I was pointed to Gosh Darn Format Style! which does a great job of explaining how the API works.

The key is understanding that behind these fancy fluent APIs there is one protocol: FormatStyle. All the dot syntax calls create types conforming to that protocol and fluently mutate them. In other words, you can hold an instance of the style that you want.

// wo this seems so complex!
(2.5).formatted(.number.decimalSeparator(strategy: .always).precision(.integerLength(1)))

// but is just really a mutation of structs
let numberStyle = FloatingPointFormatStyle<Double>.number
let withDecimalSeparator = numberStyle.decimalSeparator(strategy: .always)
let withPrecision = withDecimalSeparator.precision(.integerLength(1))
(2.5).formatted(withPrecision)

This seems obvious, but I think this API has so many combinations and you get so overwhelmed with the auto-completion, that is sometimes hard to realise the simplicity of it. I think the eye-opening moment is when you actually understand that the API surface is not in the extension of the input type but in the fluent extensions of the concrete FormatStyle. The Date, Double, ... types are not the ones with the complex API, they just have one method, the .formatted call. It's in their specific formatter styles that the complexity resides.

What this also means is that you can easily create your predefined instances of styles in order to reuse them in your application. I think this is key because otherwise the risk of slightly doing different formats in different views is too big.

extension FormatStyle where Self == FloatingPointFormatStyle<Double> {
    public static var numberFancy: FloatingPointFormatStyle<Double> {
        Self.number.decimalSeparator(strategy: .always).precision(.integerLength(1))
    }
}

// Use numberFancy instead of the long chain from before
(2.5).formatted(.numberFancy)

Dependency inject FormatStyle

With this ability in our hands, let's go back to defining how it would ideally work with dependency injection.

If we consider I would love to keep the fluent API and have DI the obvious usage looks like this:

@Dependency(\.numberFancy) var style
number.formatted(style)

The simple way of accomplishing this with the dependency system just involves declaring the dependency using the FloatingPointFormatStyle type.

extension DependencyValues {
    var numberFancy: FloatingPointFormatStyle<Double> {
        get { self[NumberFancyFormatterStyleKey.self] }
        set { self[NumberFancyFormatterStyleKey.self] = newValue }
    }
}

private enum NumberFancyFormatterStyleKey: DependencyKey {
    static let liveValue: FloatingPointFormatStyle<Double> = .number.decimalSeparator(strategy: .always).precision(.integerLength(1))
}

If you have used the Dependency system, this should be pretty familiar. We just declare the DependencyKey and provide the property DependencyValues to get the KeyPath. The important part is how we can now declare the FloatingPointFormatStyle we want and that is injected into our code, while it lets us still use the nice fluent syntax.

And we are done, right? Nope!

Hardcoding an output

Remember the advantage of using a function: we can easily provide test and preview values without having to deal with the formatters themselves. With the new setup we lost this ability, there is no way, to my knowledge, to mutate a style implementation like FloatingPointFormatStyle and force it to return a custom string.

The alternative I pursued was to create a custom format style, after all, FormatStyle is just a protocol. It may seem that each input type, like numbers or dates, is tied to a specific FormatStyle type, but that's not true. It may be confusing because the types are nested and so it feels they are hardcoded, but in reality, the formatted function is generic.

// From Foundation extension BinaryFloatingPoint
func formatted<S>(_ format: S) -> S.FormatOutput where Self == S.FormatInput, S : FormatStyle

This constrained function lets you pass any FormatStyle with a FormatInput associated type that it's a BinaryFloatingPoint. This means that it accepts a FloatingPointFormatStyle but also a custom type with the correct associated types.

Let's make a format style that always returns the same string:

struct HardcodedNumberFormatStyle: FormatStyle {
    typealias FormatInput = Double
    typealias FormatOutput = String
    
    func format(_ value: FormatInput) -> FormatOutput {
        return "hardcoded"
    }
}

And we can use this to format the Double from before:

number.formatted(HardcodedNumberFormatStyle())

To make it look nicer, we should provide an extension to allow dot syntax as shown above.

This is all good, but how do we stuff this in our dependency system?

private enum NumberFancyFormatterStyleKey: DependencyKey {
	static let liveValue: FloatingPointFormatStyle<Double> = ...
  static let testValue = HardcodedNumberFormatStyle()

Of course, this doesn't compile, the types of liveValue and testValue don't match. But again, we don't care about the specific types, just about the input and output types of the format style. So maybe if we use generics...

Welcome to type system land

If we change the type to some FormatStyle the dependency is fine, but also useless. You can't use the style because it's not constrained, so the formatted function won't accept it. The solution would be to specify the associated types like some FormatStyle<Double, String> but sadly, the FormatStyle protocol doesn't offer primary associated types. So we can't use generics at this level.

A solution that occurred to me is to create a wrapper type that dispatches to the correct formatter accordingly. But the question is how to decide the dispatch.

struct WrappedNumberFormatStyle: FormatStyle {
    func format(_ value: Double) -> String {
        return FloatingPointFormatStyle or HardcodedNumberFormatStyle
    }
}

A typical way I would do this is by passing the correct style at init time. After all, the dependency system makes the decision for us.

private enum NumberFancyFormatterStyleKey: DependencyKey {
    static let liveValue: WrappedNumberFormatStyle = .init(FloatingPointFormatStyle<Double>.number ...)
    static let testValue: WrappedNumberFormatStyle = .init(HardcodedNumberFormatStyle())
}

But of course, this raises the question of how we store the style generically. Maybe we can try to make the type generic...

struct WrappedNumberFormatStyle<Wrapped: FormatStyle>: FormatStyle where Wrapped.FormatInput == Double, Wrapped.FormatOutput == String {

But even if the type itself compiles, we have solved nothing. Generics end up polluting the api surface and it means we are back at the same problem. Using a different Wrapped type results in a different WrappedNumberFormatStyle.

Another possibility is to keep the wrapped property type erased and enforce the correct types in the init, that's a technique that works well when you want to erase some types.

struct WrappedNumberFormatStyle: FormatStyle {
    private let wrapped: any FormatStyle
    
    init<T: FormatStyle>(wrapped: T) where T.FormatInput == Self.FormatInput, T.FormatOutput == Self.FormatOutput {
        self.wrapped = wrapped
    }

But this doesn't compile because the existential type itself doesn't conform to Codable, Equatable and Hashable, all protocol requirements inherited from FormatStyle. This means we would need to type erase all the requirements of those protocols... and at that point I'm starting to lose interest.

But just for fun, let's assume that we don't care about those requirements right now and move on, hole driven development for the win. The next challenge is to make the format call compile.

func format(_ value: Double) -> String {
    return wrapped.format(value)
}

The immediate problem is that since wrapped is an existential, the return type of the format call is not constrained, it returns Any. And since Any is not String it won't compile. The fix here is easy: since we know the only way to create the wrapped property is going through the init that applies the constraints, we can assume the output type is a String, so a force cast should be safe.

func format(_ value: Double) -> String {
    return wrapped.format(value) as! String
}

But now we encounter another problem: Member 'format' cannot be used on value of type 'any FormatStyle'; consider using a generic constraint instead. This error is a bit weirdly explained, but what is happening is that since wrapped is an existential, even though it has the format method defined, the input type of the format call can't be known at compile time and thus the requirement of value: Double being equal to the input type of wrapped is not satisfied.

Here is where I got stuck. I'm able, thanks to the recent additions to opening existential, to create a generic function that opens the wrapped type. But I haven't figured out a way to relate that with the input type. I was hoping the following worked...

private func _format<F: FormatStyle>(
    formatStyle: F,
    value: F.FormatInput
) -> F.FormatOutput {
    formatStyle
        .format(value)
}

func format(_ value: Double) -> String {
    return _format(formatStyle: wrapped, value: value)
}

... but it can't: Type 'any FormatStyle' cannot conform to 'FormatStyle'. Again, the error is a bit misleading because the issue is really with the second parameter. If the _format function just had 1 parameter formatStyle: F the compiler is able to open the existential at runtime and is all fine. But we can't link the type of the second parameter F.FormatInput to another value and keep the relation with the first one.

I was confused by this for some time. I even read the proposal that introduced this functionality twice. But in the end, it makes sense. I'm passing a Double as the second parameter, but that has no relation with wrapped whatsoever. I wonder if there is some trick here that I'm not aware of.

The only way I know of making this compile is to add more force casts. And even though they should be safe since the init constraints the types of the wrapped instance, it feels too much trouble.

Less generic alternative

So I tried to come up with an alternative. The idea of passing the type from the outside is nice, especially because I would have loved to have a generic format style wrapper that could reduce boilerplate; but if that didn't work, I wanted to try a less generic approach.

Let's still keep the dispatch decision on the dependency system, but specify the types of the formatters we need. Keeping the types concrete would solve the problem we have. For this I decided to switch to an enum with associated types since it felt like the quickest solution.

enum WrappedNumberFormatStyle: FormatStyle {
    case foundation(FloatingPointFormatStyle<Double>)
    case hardcoded(String)
    case unimplemented
    
    func format(_ value: Double) -> String {
        switch self {
        case .foundation(let floatingPointFormatStyle):
            return floatingPointFormatStyle.format(value)
        case .hardcoded(let string):
            return string
        case .unimplemented:
            return XCTestDynamicOverlay.unimplemented()
        }
    }
}

There are no generics in this enum. All types are concrete, so we don't have any problems with the type system. We exchange a sort of dynamic dispatch with a static and manual dispatch instead. I also took the opportunity to remove the HardcodedNumberFormatStyle type since a String in the hardcoded does the same job, and also add the unimplemented functionality for tests.

With this, the dependency integration is quite simple:

private enum NumberFancyFormatterStyleKey: DependencyKey {
    static let liveValue: WrappedNumberFormatStyle = .foundation(FloatingPointFormatStyle<Double>.number.decimalSeparator(strategy: .always).precision(.integerLength(1)))
    static let testValue: WrappedNumberFormatStyle = .unimplemented
    static let previewValue: WrappedNumberFormatStyle = .hardcoded("hardcoded")
}

This works!

Now, I admit that seeing case foundation(FloatingPointFormatStyle<Double>) still makes me want to make it generic but we've been through that rabbit hole so there is no need to repeat it 😂

Locale for testing

One of the big benefits of having the dependency system in place is that we can solve one of the annoying parts of formatters: dealing with the locale. It's true that with the code above we can control the format style dependency itself, but if we wanted to still use the real one for testing, we would still have to deal with the locale. A very nice thing we can do is use the @Dependency ourselves in the implementation.

func format(_ value: Double) -> String {
    @Dependency(\.locale) var locale

    switch self {
    case .foundation(let floatingPointFormatStyle):
        return floatingPointFormatStyle
            .locale(locale)
            .format(value)

With this minor change, we now have a formatter that automatically gets the locale, like the default format styles, but with the difference that we can control that dependency.

A bit more magic

Seeing how we can access the dependencies internally, there is another trick that you can employ. Be ready for some magic 🧙‍♀️ .

The way that PointFree dependency system decides which value to provide is using a context value, that is itself part of the dependency system 🤯. This is very powerful because it means you can change the context yourself, or read it and leverage the internal logic of the library.

Thanks to this, we can actually have a type that magically changes.

struct MagicNumberFancyFormatStyle: FormatStyle {
    func format(_ value: Double) -> String {
        @Dependency(\.context) var context
        @Dependency(\.locale) var locale
        
        switch context {
        case .live:
            return FloatingPointFormatStyle<Double>.number.decimalSeparator(strategy: .always).precision(.integerLength(1))
                .locale(locale)
                .format(value)
        case .preview:
            return "hardcoded"
        case .test:
            return XCTestDynamicOverlay.unimplemented()
        }
    }
}

In fact, you can use this trick and expose the format style as an extension, without going through DependencyValues at all! It means that (2.5).formatted(.numberFancy) would look exactly normal, like any other Apple API, but under the hood you made your code fully testable and controllable. This is a huge win in my opinion, and I'm really tempted to use this trick directly without having to deal with the @Dependency in the usage side.

Of course this might be too much magic. Analyze the tradeoffs and decide by yourself if it's worth.

Where does the path end?

Here is where I stopped my exploration. It was fun, and I learned a bunch of things again. We still need to decide if these wrapped types are worth the effort or if we will just keep the function style as the dependency. But for my side project usages I'm very tempted to use the magic solution :)

As always, thanks for coming with me in this journey, I hope you learned like I did. And if you know of other tricks or solutions that could get me the requirements I want, don't hesitate to tell me 😜

Rating: 3/5

My feelings about this book are very similar to the first part of the series, and that's no surprise since the story maintains the same tone. I really like the survival puzzles proposed by the story and how humanity reacts and adapts to (maybe) solve them. This book, since it happens a few centuries later, also shows us a possible future for humanity. It was cool to see the new technology and how it affected society.

But like the first one, it has too much text, and in this case is even worse because the book is longer. The fact that this happens in a more international environment reduces the footnote reading that polluted the first book (for a European reader at least), but the amount of scenes in this book that have very little impact in the overall plot is just too much for me. Some of these scenes are interesting on their own, but the more the book advances, the more these scenes become void.

But then, like in the first book, the overall plot and story are so enigmatic and the puzzle humanity faces is so complex that it leaves the reader wanting more. And so I had to finish the story, even though I almost leave it multiple times, and I will have to read the last book.

Overall, I can see how many people love it, but it hasn't clicked for me.

I really love the work Point-Free does and won't tire of recommending them. If you want to invest in your knowledge and support me at the same time use this referral link and subscribe to Pointfree, we both get a month free :)

Some context...

First, a little bit of context.

I've always been doing dependency injection via init or property with no framework. I find it the best way, no magic, everything is clear and works very well even in a 500k LOC project. Yes, you need to be smart on your architecture to avoid having to carry around dependencies, but it's not rocket science. That's how I've been doing DI for many years.

The first time I switched strategies was when the guys at Point-Free introduced the global dependency struct technique. I used it sparingly, just to access some system dependencies (calendar, locale...) and it worked really well I have to admit, more than it had the right to for being a global variable 😂

But then the TCA happened and with it a huge improvement on application architecture. Their most recent update includes a fully fledged and integrated dependency system, akin to SwiftUI's environment. It works very well and does wonders to clean up and modularise your codebase. It's really amazing.

Where is the hype?

So with that said, I was well aware of how the system worked, and I knew they were intending to break it into a separate package. So when they announced the new library, I was not as hyped as with others. I was using the library (in the TCA) already!

But then I remembered a question that had been hunting me since I saw the dependency system... I know how it works, and it felt to me that it worked very well for the TCA specifically... but there was something that made it unworkable for a general architecture.

So the non-hype of the announcement became a curiosity to know what magic, if any, they pulled off. Or to confirm that I didn't understand things as well as I thought, something that I'm always trying to do, makes me stay true.

How does this work?

To understand my doubts about this system working in a general sense you have to understand how it works. Internally it relies on Swift's Task Locals, a new feature of Swift that came with Structured Concurrency.

Task Locals allow you to set variables in a "context" that is automatically available to your code. But the context modifications are only visible on the scope where they changed. This plays nicely with structured concurrency and normal structured programming. As long as you keep calling functions, all the stack has access to the same context.

func someFunction() {
  Lib.$taskLocalValue  // 1 - Outisde the scope
  Lib.$taskLocalValue.withValue(42) {
    Lib.$taskLocalValue  // 42 - Inside the overwriten scope
    calledFromInside()
  }
  Lib.$taskLocalValue  // 1 - Outisde the scope
  calledFromOutside()
}

func calledFromInside() {
  Lib.$taskLocalValue  // 42 - Inside the overwriten scope
}

func calledFromOutside() {
  Lib.$taskLocalValue  // 1 - Outisde the scope
}

func someOtherUnrelatedFunction() {
  Lib.$taskLocalValue  // 1 - Outisde the scope
}

You can see how this would work very well since the TCA runs everything in reducers that are chained, so they are all in the same scope. That allows the Store to set the dependencies once and run the entire chain.

Action -> Store
Store sets dependencies and calls reduce
Reduce sees the dependencies, next reducer is run in the same scope...

Easy. But when I thought how this could be generalised, I immediately saw problems since in a non-TCA application the scopes of executions are all over the place, there is not a central object that controls the scope.

UI Button calls ViewModel.performAction
Another button calls ViewModel.doSomethingElse

There is nowhere you can overwrite the Task Local context for all the scopes. You need to do it on an ad hoc basis.

The trick

So then I started reading the new library's documentation. And they quickly make the point that you need to instantiate the "next controller" inside the library's closure.

self.onboardingTodos = withDependencies(from: self) {
  $0.apiClient = ...
} operation: {
  TodosModel()
}

And an important note that explains "It takes an extra argument, from, which is the object from which we propagate the dependencies before overriding some. This allows you to propagate dependencies from object to object."

Aha! So it all works as long as you instantiate the object inside the scope. This already tells us a bit about the trick that is being employed.

The above is all well explained in the Dependency lifetimes section. They even explain how Task Locals work ;)

Here is the part that opened my eyes:

Accomplishing this can be difficult because models are created in one scope and then dependencies are used in another scope. However, as mentioned above, the library does extra work to make it so that later referencing dependencies of a model uses the dependencies captured at the moment of creating the model.

There you go, the confirmation. As long as you instantiate the model in the scope that overwrites the task local, your model will see that overwrite even outside of the scope. You can see the code for this, seems like the trick is to keep your own storage so you can overwrite and keep your own "hierarchy" instead of relying simply in the one provided by Task Locals.

They basically made Task Locals "escape", impressive!

Single entry point systems

With the understanding of how it worked, I was satisfied. But, in a typical Point-Free fashion, they went the extra mile and actually wrote an article about the specific doubts I had at the beginning of this post. They even gave me the propar vocabulary needed to form the correct mental model.

Single entry point systems explains why systems like TCA or SwiftUI are ideal for managing a hierarchy of dependencies since it all funnels through a single entry point; and they compare it Non-single entry point systems like ViewModels or UIKit where is more complicated.

Ultimately, I think they have accomplished the right levels of ergonomics for a feature like this. If you use a non-single entry point architecture, you get the same benefits on your dependencies overwrites as long as you remember to instantiate the model inside the proper scope. It still leaves the TCA ahead of the game, but is very nice for people that don't want to jump into the future just yet 😜

And some gifts!

As always, Point-Free provides not only a useful library, but a very well done one. Their documentation is gorgeous, full of details about the library itself but also advice on how to design dependencies and architect your app. They even released some extra goodies with the library!

Some notable details I found interesting even after being using it for a few weeks:

• Cascading rules gives a nice summary of which "value" will be used in each context if not all of them are provided. Useful to reference until you get used to it.
• I was not expecting to read about Concurrency support! They have split a few very useful types that were in the TCA so we can now use them on any project, nice!
  • ActorIsolated is a very useful generic wrapper to isolate a value in an actor. Great for tests but I've found myself using it in some specific cases where yo don't want an ad hoc actor just to isolate a value.
  • I haven't used LockIsolated, and it seems a bit dangerous but useful if you need to do blocking async code.
  • UncheckedSendable is one that helps a lot during the transition period for code that hasn't adopted Sendable conformances yet. Another dangerous to use but useful nonetheless. (I wish I had this one a few months back 😂 )
  • There are even helpers for AsyncStreams! It feels a bit weird to have these in this library, but in a way it makes sense because you will need them to design your dependencies. I think this will make swift-dependencies a must include on every project of mine.
    • "This allows you to treat the stream type as a kind of “type erased” AsyncSequence." this one feels a bit weird. I'm not going to lie. One would hope that with improvements in the generic system, this wouldn't be necessary but oh well ¯_(ツ)_/¯
    • Now, the API for simultaneously constructing a stream and its backing continuation is very useful and something that should come in the standard library.
    • There are a few other inclusions so make sure to check it out!

Consider me learned

I love these quick derails my brain takes me into. I was not planning to get deeper into Task Locals at all this week, after all, I thought I already knew pretty much all about them during my Concurrency obsessive days; but then curiosity sparked, and feeding it was one of the best joys in life.

I can't thank enough Point-Free for not only pushing the limits of the Swift community - you know they even got a proposal accepted recently to fix a missing API in Clocks? - but also for making learning so fun!

Thanks for accompanying in this post and journey.

So I made this video to pitch you on why Memory Ownership in Swift matters and how it will improve your EXISTING code right away without having to learn too much complicated stuff.

The benefits will be real and immediately palpable!

From my review on Goodreads:

5/5

This book is great at so many levels. After having read Sanderson's all Cosmere books reading this narrative with such a different voice is mesmerising. Being a tale narrated by a character in the Cosmere, who is at the same time a secondary character in the story, brings a different perspective that I enjoyed very much.

The characters are great, from the girl that embarks on an adventure to each of the named characters. Sanderson is able to take care of real world situations and human characteristics, I loved the deaf character and the one with very bad aim (😉).

And the plot, oh I loved it! Look, I get bored of a love story told like they do in romance. That's just boring most of the time. Love is just an, albeit important, part of a human live, so it needs to be just a part of a story. For Tress love is what makes her embark on and amazing journey do discover herself and grow. Yes this is not an epic story with armies, but is a romantic journey on the seas, with battles and death! so is not that far <3

To tip it off, the Cosmere. This book may not be a core story of the Cosmere, but it seems quite important to get to know more about what's going on. I love two things: 1) Sanderson doesn't get shy anymore about including Cosmere things in the story. Things that don't break the immersion if you haven't read the rest (I think), but that are like a juicy fruit for any of us that love this universe. and 2) how this little details are included in such a natural way with the narration. The narrator just mentions it like if they were not important; while as reader I was here screaming of excitement and highlighting lines that gave us more details about an important back story.

I've loved Tress of the Emerald Sea, a well rounded book in many aspects and a great start of the Year of Sanderson. I think I will be very fond of this story for many years to come.

A few years ago I felt back in love with reading again. I've always been a reader, but for a long time I prioritized other hobbies. The social web and easy to digest content occupied most of my leisure time for many years. But the desire nostalgia for experiencing fantasy put me again on the right track.

Don't get me wrong, I still spent time on YouTube and reading about other stuff, books are only a part of the amount of things I experience in life, but they are a very important one for me. Reading challenges are a fun way to make sure I don't forget this. They are not a mandatory task, but a pleasant reminder of how much I enjoy it.

Because life is hard, it's tricky sometimes to remember what we should do day-to-day, our mind travels to far places, places that are the total opposite of nice fantastic lands. And when we are in those obscure places, we often forget about the nice things we already have.

Ignoring a very rough 2019, I've been reading more and more every year. This is mostly because I found an author that resonates with me like nothing before, Brandon Sanderson. You can see how the way I talked about fantasy changed when I discovered him. When I decided to pause The Wheel of Time I was about to enter a hiatus on reading again. But thankfully, I gave Mistborn a try, and oh my, was I lucky discovering my favorite novel yet!

So after that, I started devouring the Cosmere, the fictional universe where most of Sanderson's fantasy novels happen. That took me from 2021 to 2022 and I can say now that I finally caught up with the Cosmere and I've even been able to enjoy for the first time a new book launch with The Lost Metal!

2022 in books according to Goodreads

25 books! That's quite a lot for me! The number doesn't really matter, everybody reads at different speeds and kinds of books, what matters is how much enjoyment it brought me!

8,517 pages! It's funny how that gets to an average of only 340 pages per book. When my impression is that I read way lengthier books, and I do, but I've also read a bunch of short stories that pull that number down. From 25 pages of The Hope of Elantris to the 1248 pages of Oathbringer.

My average rating is 4.2/5. That's basically because I only read things that I kinda now I will like, and because I've been reading a lot of Sanderson and, for now, is very rare I don't like something from him.

Cosmere

It would take me too long to write all my thoughts about the different Cosmere books, so I will only highlight a couple. If you are curious, I keep a thread in Twitter with my Sanderson reading and you can see my reviews in Goodreads.

As a side note, with everything that has been going on with Twitter, one thing I would love to do is to move all these reading updates and book reviews to my domain. We'll see if I can get that done.

The Emperor's Soul has been, with no doubt, the nicest surprise of all. A short story about art, in the same world as Elantris, that I still keep thinking about.

All the other smaller stories in the Cosmere (Shadows for Silence in the Forests of Hell, Sixth of the Dusk, etc) are something that many won't bother to read, and you don't really need to, but I love the inter-connected facet of Sanderson's writing so I've put a lot of effort in reading them in what I consider the best order possible for my personal enjoyment. And I have to say that it has paid dividends! I should write about that someday.

Mistborn Secret History is one of these things that you can only enjoy once in a lifetime. It's a short story that you should know anything about. Really, anything you read or see, by small, it's a major spoiler. And the experience I got while reading it and discovering things... I can't describe it.

Mistborn Era 2... what can I say about this. I've been able to finish it with the rest of the fanbase and it has been an experience! It's a very distinct style than the first Era, something that put many people out, but I still like it a lot. The mix of western with new tech and humor worked very well for me. And the ending... what an ending! A new era for the Cosmere begins!

The Stormlight Archive is with no doubt my favorite epic fantasy series of all time. It pulls the best of Sanderson for sure. This year I've continued the series and caught up with it and yes, now I'm waiting the last book of the first half like everybody else. With excitement but also fear. I have no clue how things will go. Well, of course I have many theories like everybody... it's a hot topic of conversion with my friends, BUT Sanderson can pull plot twists that even after paying attention and commenting all potential solutions with friends, nobody saw coming.

Diamantes en Bruto

This is the only non-fiction book I've read this year. I don't really do non-fiction with books since I spent most of my day to day reading it by other means already. But this one was a recommendation to understand better the psychology and mental health of people. It's eye opening to see what others go trough and makes you be more attentive and willing to help.

Partials Sequence

From watching Brandon Sanderson and Dan Wells on their podcast I ended up being very curious about Dan work. I picked up Partials as an introduction to his work, and I have to say I enjoyed it. Is a bit too YA for what I was looking for, but it has many interesting details. I still have book 3 pending, which I'm hoping to finish next year.

League of Legends: Realms of Runeterra

This is a book about the universe of Runeterra, full of artwork and short-stories. I really loved the stories, and the art is astonishing. Runeterra is probably in my top 3 of fiction worlds and I wish people paid more attention to the multitude of stories and characters in it.

Many people discards it because it has the League of Legends brand associated with it, "it's just a game". And that might have been true many years ago but Riot has been working on this universe for so long that it has quickly become a rich world that doesn't have to envy anything from others. I mean just look at this beautiful map.

My favorite part is how nicely in pulls together seemingly incompatible themes and environments. In Runeterra you can find anything you like: Horror and ghosts, pirates, a land of magic and nature, empires at war, ancient dangers in the frozen north, a high-tech city, ancient Egypt like, jungle and elemental magic, and a mountain to ascend to godhood.

I'm still fascinated by how all of this can match in a very nice and coherent way. That is Runeterra. Seriously, visit their site and discover a new Universe.

Dungeon Master's Guide

This year I finished reading the DM's guide to D&D. Of course, being a guide it means I flipped through its pages way more than once, but I still wanted to go trough it in sequence to enjoy the fiction in it.

Reading tabletop game guides is an enjoyable experience for me. It engages not only with my "game mechanics" brain but also with the fantasy literature part thanks to all the lore and adventure suggestions in them.

Sandman Audible Original Series

I started Sandman after watching the Netflix tv show and I have to say I enjoyed it a lot, way more than expected. Neil Gaiman storytelling is so peculiar that makes Sandman an incredible experience way beyond what the plot could give.

I've just finished Act 2, the last thing I will read this year, and there some stories in it I can't wait to see adapted on television. I'm amazed how Gaiman takes folk-tales and religious stories that we all have heard about and gives them a twist integrating them into the Sandman world.

The Law - The Dresden Files #17.4

Okay, this is a weird one. If anybody did what I did here with the Cosmere I would tell them the big mistake they made. I'm not sure how important is with Dresden but I know I was taking a risk. You see, Amazon Prime gave an offer with free access to their Kindle Unlimited books, and even tho there is a lot of content there was not much that I found interesting to jump into.

But I've been hearing about The Dresden Files for ages, and is a series I really want to read sometime, so when I saw this short story I just took it. I knew I was risking huge spoilers since is the 17th book of the series, but I risked it anyway.

And I'm glad, now I'm more curious about Dresden and its world. It seems like a mix that I could enjoy a lot. So it went up on my priority 😜

The Three-Body Problem

Because it was in Kindle Unlimited and I wanted to change a bit to sci-fi, I jumped in the first book of the Remembrance of Earth's Past Series. I had plenty of good things about this book so I was eager to enjoy it. And I have to say... it was difficult to finish.

It's true that when I was done, I appreciated the story and its complexity, and I'm curious to see how it continuous. But I don't know if it's because it is too hard sci-fi and is not for me, or because the different author culture (seriously, having to read footnotes every two pages is not good...) but it didn't pull me in the story much.

I actually started the second book, The Dark Forest, but it's still in progress because is taking me even more to get into. There is simply too much text. I actually switched to Sandman Act 2 to disconnect from it and I finished that one in 2 days 😂 so it's not that I don't want to read! We'll see if I come back to this series.

A couple more...

I've read other books that, for one reason or another, are not in Goodreads. I've posted them as "general updates" on the site, but of course that doesn't count as a book.

This is another reason I would love to find an alternative to it.

Aether of Night, an unpublished novel by Brandon Sanderson

After having caught up with the Cosmere I was eager for more and didn't want to wait for The Lost Metal release. So I started looking at what other things Brandon had done around the Cosmere, I knew there was some unpublished work and that seemed like an ideal way to keep the Cosmere alive in my head.

Aether of Night is an unpublished novel, a draft, that he wrote years ago but never published. He has transformed the ideas in it into other published work. Even knowing that is non-canon and that the writing was in draft form, I really enjoyed the reading.

Seeing some of the early versions of some things that happened in other books was fascinating to me as a hobbyist writer. And know more about, a version of, the Aeathers, something that we are just starting to see in the Cosmere, was a delightful gift.

My post in Goodreads about Aether of Night.

Indie Microblogging by Manton Reece

With everything that happened in Twitter this year, and the move to Mastodon, I've been paying more attention to the indie-web. I think the social network boom has helped in some aspects to move society to a more connecter world, but I really miss the times of blogs and RSS.

Manton Reece is part of the indie-web movement that tries to protect the openness of the web. The book talks about his solution, micro.blog, but is not a sell pitch for it. It's very recommended if you are curious about the dangers that are risking the web as we know it.

My post in Goodreads about Indie Microblogging.

What's next?

My goal for 2023 is to keep enjoying reading as much as I did this year, no matter how many books I read.

I already have 4 that are clear thanks to The Year of Sanderson that will start on January 1st! After that, I may try to finish some open series and look at others on my pending list.

Happy new year of reading!

In Swift Concurrency all your async code runs in a cooperative thread pool, unless you are using Actors (or in the future custom Executors, but that's a topic for another day). The beauty of the cooperative pool abstraction is that it allows us to not care about thread exhaustion, or even about our code running "on the background", something I still see many developers get wrong.

You may have seen this cooperative pool while debugging, pay attention to how Xcode shows a label in the debug navigator:

As you can see the thread is part of the cooperative concurrent queue.

We can use a bit of expensive code to use all the queues and force the runtime to create all possible threads. In my M1 that means 8 threads:

It's actually quite nice to see all threads so nice and tidy ^^

The important thing here is that this is an implementation detail and you should not worry about it, as you should not worry about threads at all.

I know the irony of saying that you shouldn't worry about threads in a post about threads 😂. But if you are having a hard time with Swift Concurrency is probably because you still haven't made the switch to this new way of thinking. There are some legit cases to care about threads, but those are mostly for inter-operation with other systems that are thread based. Free yourself from the threads! 🔥 🧵

In fact this cooperative pool is such a specific implementation detail that it could work totally different in other operative systems or more constrained enviornments. The nice thing about this is that your code should work in the same way, albeit slower and less parallel, in a system with only 1 thread.

Remember that Swift Concurrency doesn't make any promise about parallelism. Most of your code is serial with itself and concurrent with other blocks of code, but you can't make it parallel, that depends on the runtime.

And you can test how your code would behave in such a constrained system thanks to an environment variable that limits the cooperative pool.

Set LIBDISPATCH_COOPERATIVE_POOL_STRICT=1 and see how the runtime will only create 1 thread on the pool.

You can set this in the Scheme editor in Xcode.

After setting that flag and running the same code that before was spawning 8 threads, we can see now how it only spawns 1.

There you have it, a nice utility to force the Swift runtime to use limit the cooperative pool to 1 thread, useful for some debugging situations and for learning purposes.

Posts here are just Markdown files, but they do contain a bit of metadata in form of front matter and they must be in a directory with a specific naming convention since I use a bundle format to have the images and the text side by side.

Since I have a custom CLI tool to build the blog, instead of relying on the default one provided by the static site generator Publish, it's very easy for me to add automatoin to any process. And that's what I had for a long time:

▶ amp help new
OVERVIEW: Creates a new post

USAGE: cli new <title> [--date <date>] [--disable-auto-open]

ARGUMENTS:
  <title>

OPTIONS:
  --date <date>           (default: 2022-12-20)
  --disable-auto-open
  -h, --help              Show help information.

So the only thing I had to do is setup something that triggers that command with some given inputs. I could have build some website that triggered some backend API but there is an easy solution for something so simple: GitHub Actions.

The action ended up looking like this:

name: "Create new post"
run-name: "Create new post: ${{ inputs.title }}"

on:
  workflow_dispatch:
    inputs:
        title:
          description: 'Post title'
          required: true
          type: string

jobs:
  main:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Setup Swift
        uses: swift-actions/setup-swift@v1.20.0
        with:
          swift-version: "5.7.1"
          
      - name: Cache
        id: cache-alejandromp
        uses: actions/cache@v3
        with:
          path: .build
          key: ${{ runner.os }}-cachev1-${{ hashFiles('**/Package.resolved') }}
              
      - run: swift run alejandromp new "${{ inputs.title }}" --disable-auto-open

      - name: Create Pull Request
        uses: peter-evans/create-pull-request@v4
        with:
          commit-message: "New post ${{ inputs.title }}"
          title: "New post ${{ inputs.title }}"

Since I'm just creating files I don't need any macOS specific API so I can run Swift on Ubuntu. I then use the workflow_dispatch in order to be able to trigger it manually from GitHub's UI. I set it up so it asks me for the title so everything is preconfigured by the action itself.

The action is quite simple, it instllas the correct version of Swift, caches the build folder, runs the command passing the given title and finally creates a PR with the changes.

Now I can click a button on GitHub, have a new post draft created and start writing from github.dev.

That coincided with a technical curiosity. As I talk in my meta post about the site redesign this site is built using Swift’s Publish package and served by Netlify. This gives me a blazing fast static website for free. But until now I’ve been generating the website locally from my computer. Back in the day Netlify didn’t really support running Swift in their servers easily, so I didn’t spend time trying to solve that. When I added automatic image generation to the posts for social sharing I used SwiftUI, which means I need to run on macOS anyway.

But now time has passed, and I want to have the flexibility to publish in my blog from somewhere that is not my computer. But let’s be honest, it’s mostly a technical curiosity. I’m sure I will still write most of my content from my computer, but that won’t change unless I remove the friction and make it a possibility.

Updating to Swift 5.7

The first order of business was to update the code to Swift 5.7. One of the main reasons I moved out from other site generators in other languages is because every time I had to update anything, it was a mess of dependencies and language issues in languages I didn’t care about.

Because this is Swift, I’m able to do any update without even thinking about it. But the reality is that this time it took me by surprise.

The aforementioned image generation that runs in SwiftUI has a requirement, it must run in the main thread. Obviously because is doing UI stuff. But Publish updated some internals to make use of Swift Concurrency and that caused problems.

The short story is that Publish has only adopted concurrency half way. It uses it internally to speed up some things, but it still left the entry point as a normal synchronous function. I imagine that was the best solution when that Publish version was released, but nowadays it is a terrible idea. In order to make the runtime wait Publish uses an internal semaphore that blocks the main thread, which as you can imagine it doesn’t play nicely with SwiftUI.

Since the library doesn’t get much attention, I just forked it and fix it myself. I’m still indecisive on what I will do with this. I don’t want to maintain forks, but if the original library doesn’t get more maintainers, I’m afraid of its future.

But with that out of the way, the generator run perfectly in Swift 5.7. I also updated some of my Publish plugins (Item Poster and Reading time) to be up to date with the rest of dependencies.

Running Swift on Linux in Netlify

The next step was to make sure my code could run on Linux, since is what all servers are based on. Thankfully Netlify makes that very easy.

First, Swift is now fully supported as a build environment. By default it uses an older version of Swift but, as the docs explains, you just need to set an environment variable with he version you want and it will be automatically installed on the server image. Easy peasy.

But then we had to update the code to work somewhere else that was not my machine. And one thing I detest of some development workflows is when you can’t try your changes locally. Years ago, I worked a bit on AWS Lambda and the setup that they gave me was so awful that I refused to work more on that project. So of course for this I quickly investigated how to test things locally without waiting for Netlify servers.

And of course the answer was Docker. It still baffles me that the solution to self-created problems by the industry is packaging entire computers. Is a good idea, don’t get me wrong, but it doesn’t solve the root of our problems. Anyway, Netlify has all the instructions you need to run their image locally. And it was very easy to do, even for myself.

With that in place, I just had to run the generator and start ifdefing out everything that required macOS and making some hard-coded paths (yes, I’m lazy sometimes when it’s not a critical project).

Everything seemed to work except, of course, the SASS dependency was not installed in the same way. On macOS I use brew but on Linux I opted to use npm since it was already pre-installed. Took a few tries to get everything setup correctly, but it wasn’t too bad. That said, I despise that my site generation requires non-Swift dependencies. Is such a shame that to do anything on the web you need so many dependencies. In my other site, Pulubi Worlds, I opted to use tailwind instead, but I’m pretty sure it will be the same mess. Well, a fight for another day.

And with that I had my site building on Netlify on every push. Nice!

Using GitHub actions for macOS execution

But of course, those pesky posters wouldn’t generate on Linux. I need to run that on macOS remember?

Until then, the poster generation was part of the site generation, it was just another Publish step. But now I had to look for another solution.

Thankfully GitHub gives some macOS time for free, not much mind you, with their GitHub Actions. So I opted to make a separate command on my CLI to run only the poster creation. I configured the action to only run if there were changes on the Content folder to avoid wasting those precious macOS minutes.

Conclusion

So now I have my site, including social poster generation, running on the cloud, still for free. This means I can write in my blog from anywhere which hopefully inspires me to write more.

I plan to do a couple more things using GitHub actions to reduce the friction. The dream would be to have a CMS that runs on top of GitHub, a CMS for static sites. But for now I can live with some more niceties.

Another thing I’m interesting in exploring is the whole micro.blog, indieweb and federation idea. I know static sites don’t play super nice with some of those things, but is interesting to think about nonetheless.

Update: Thanks to Ole Begemann I've learned more about how frame works and updated the ideal solution.

Streched images

It all started when a colleague made a PR to fix an issue that I raised with an image being distorted. While reviewing the PR, I was surprised to see that the old code already was using aspectRatio and the new code was an ugly mess of ZStack and other seemingly unnecessary things.

The problem is that using aspectRatio in an Image and giving it a ratio just stretches the image, making it look awful and making the aspect ratio useless.

Image("christmas")
  .resizable()
  .aspectRatio(2, contentMode: .fill)

It's interesting how all the search results you find are giving you the solution to the most trivial example without getting deep into how things work. The examples about aspectRatio in images are always without the ratio - .aspectRatio(contentMode: .fill) - and using frame or other combinations that solve the issue at hand.

What I would love is for this to behave like UIImageView and it scaled the image properly without stretching. I want to use aspect ratio, without a numeric ratio and specifying no manual size, and let the image render properly without stretching.

But of course that's now what aspectRatio does!

Of course my curious mind immediately jumped into the code to analyse why there wasn't a better solution. I was sure there was some combination of modifiers that would make it work nicely without ZStack or other hacks. But it seems I was wrong 😑

aspectRatio and the layout process

As with many modifiers in SwiftUI, it is important to realise that they do not really apply any behaviour to the views. It's not like we are telling the Image "object" to respect the aspect ratio. Nope! We are not setting properties to an object here. So don't let your mind complicate things and make you think that you.

The aspectRatio modifier is a layout modifier. That means that it takes part in the layout process of SwiftUI. The layout process is quite simple in reality: proposed sizes go down the hierarchy and taken sizes go up doing the positioning with them.

Armed with some tools from Swift Talk I debugged for a while the behaviour of the modifier to confirm my mental model. This is something I do a lot, even if I think I know how things should work, I want to make sure my mental model is correct. And I dig deeper and deeper until I'm satisfied, when I can't come up with more questions that could shake my mental model.

Note that I'm just giving a frame of 393x400 to avoid the VStack probing multiple times.

Let's start with the problematic example:

Image("christmas")
    .resizable()
    .logSizes("Image")
    .aspectRatio(2, contentMode: .fit)
    .logSizes("Ratio")

You can see how the aspect ratio receives a size, it computes an appropriate size respecting the ratio and passes that down to the image. The image accepts that size and just renders itself in it. If we change it to fill the behaviour is the same, with the difference that the sizes are bigger.

Now let's try without giving a ratio at all, just telling the modifier to fill.

Image("christmas")
  .resizable()
  .logSizes("Image")
  .aspectRatio(contentMode: .fill)
  .logSizes("Ratio")

Now we can see how the image is correctly filling the available space without stretching. But if you look at the layout logs, you can see what happens in reality. Is not that the image is magically avoiding stretching (like UIImageView did), it's that the image receives a proper size that doesn't make it stretch. The aspect ratio modifier does some probing this time to find the correct size that matches the algorithm. And again, the just renders itself in that size, nothing else.

So by now I thought that it made sense. The aspect ratio modifier is just changing the proposed size that is passed down and the image just renders itself according to that size, filling all pixels on that space, not caring if that results in stretching at all.

This explains why so many examples provide a frame and not a ratio, which defeats the purpose of dynamic UIs. So the solution my colleague proposed was on the right track: use aspect ratio to compute a "frame" in which to embed the image, and then let the image fill all the space.

Despite that, my brain was like "there must be a way of doing that by chaining modifiers!"...

Chaining aspect ratios for science!

So the idea was to keep the aspect ratio of the image without a specific number, and use another parent modifier to create the correct size:

I'm using a square ratio as an example because it is clear to see that the result is wrong, not squared.

Image("christmas")
    .resizable()
    .logSizes("Image")
    .aspectRatio(contentMode: .fill)
    .logSizes("Inner Ratio")
    .aspectRatio(1, contentMode: .fit)
    .logSizes("Outer Ratio")

But as you can see that changed nothing.

At this point I added the ratio on the log to see easily if it matched the one I gave.

If you analyze the logs, you can see how the outer modifier changes the size to be a square, but the inner ratio then computes a new size according to its fill rule and is what it uses to probe the image. At the end the result is the same since the image receives that "filled" frame.

Now is when your brain may say "but I specified an aspect ratio of 1, why is that not respected?" and the answer is the same again. The modifier does nothing else than changing the proposed size down. The child's view is free to ignore that and pick another size, which is reported upwards. And when the layout system goes up, there is no correction. The aspect ratio modifier won't force the reported size of the child to be a ratio of 1.

You can see it easily if we use a frame instead:

Image("christmas")
    .resizable()
    .logSizes("Image")
// .aspectRatio(contentMode: .fill)
    .frame(width: 100, height: 300)
    .logSizes("Inner Ratio")
    .aspectRatio(1, contentMode: .fit)
    .logSizes("Outer Ratio")

You can see how the frame picks the size ignoring the parent aspect ratio proposed size, and the aspect ratio can't do anything about it. Again, proposed sizes go down, and selected final sizes go up positioning along the way. Nothing more. Is really that simple.

The simple common scenarios

As a side note, let's look at why the common examples used to teach aspect ratio for images work.

Usually the examples start by showing you how images get stretched:

Image("christmas")
    .resizable()
    .frame(height: 200)
    .logSizes("Image")

We can see here how the frame proposes a size to the image and this one just takes it and renders itself, resulting in obvious stretching.

Then the solution proposed is usually to just use the aspect ratio, without a number, to fix it:

Image("christmas")
  .resizable()
  .logSizes("Image")
  .aspectRatio(contentMode: .fit)
  .logSizes("Ratio")
  .frame(height: 200)
  .logSizes("Frame")

This of course fixes the stretching. Now the aspectRatio probes the image to know its aspect ratio, then computes the correct size giving the constraints, and proposes that to the image to just render itself in it.

But of course you are fixing the sizes which is totally against any modern, adaptable design.

And just for completeness, try to use fill instead:

That's even more annoying because the image draws out of bounds, you need to clip it. But take the opportunity to understand why that happens. The aspect ratio still probes the image for its desired ratio, and uses it to calculate a correct size using a filling algorithm, which makes the size bigger. That report goes up until it find the frame. The frame cannot do anything about it, again the layout process going up is just about positioning, but is stubborn and returns the fix size you gave it. That means the layout outside thinks is 200 but the image rendered way bigger than that.

Image rendering is the culprit

At this point I tried many combinations, but I was just distracting myself, learning along the way and reaffirming my mental model yes, but there was no solution on the horizon. Things worked as they should. The aspect ratio modifier just proposes an appropriate size, that's it.

The issue here is that the image rendering is quite dumb. As soon as you do resizable it just means the image will render all the pixels filling the entire size that is given to it. That makes sense but is annoying given the circumstances. That modifier has a resizingMode that would make you hope it was the solution but no, it's just to change between stretching and tiling. I think that if you could tell that mode to be fitting or filling it would mimic more my expectations.

Solution

UPDATE: See below for a better solution using frames.

So what's the solution? Sadly, we need to break the hierarchy in two.

First create a "frame" by constraining the size to a specific desired ratio.

Rectangle()
  .aspectRatio(2, contentMode: .fit)

Then, embed the image inside that frame and use another aspect ratio to give it the proper size. We also need to clip the result since using fill will make the image draw of out of bounds as explained above.

Note that I'm using an overlay instead of a ZStack. Prefer to use overlay or background instead of ZStacks when is semantically more appropriate.

Rectangle()
  .aspectRatio(2, contentMode: .fit)
  .overlay {
      Image("christmas")
          .resizable()
          .aspectRatio(contentMode: .fill)
  }
  .clipped()

Since this is a bit cumbersome to do, I thought it would be nice to have a reusable modifier for it. But that comes with more questions around API design so feel free to do whatever is more appropriate for your codebase. I just give you my current take as a suggestion:

extension View {
    func framedAspectRatio(
        _ ratio: CGFloat? = nil,
        contentMode: ContentMode
    ) -> some View {
        Color.clear
            .aspectRatio(ratio, contentMode: .fit)
            .overlay {
                self
                    .aspectRatio(contentMode: contentMode)
            }
            .clipped()
    }
}

With this modifier at hand the result doesn't seem that bad:

Image("christmas")
    .resizable()
    .framedAspectRatio(2, contentMode: .fill)

A better solution with frames

After posting this post, Ole Begemann replied on Mastodon with a better solution and some insight on how frame works. It turns out I was not that far when I suspected that there was a way to break the layout in two separate frames. After all, the modifiers in Swift are virtually creating nested views. What I missed is a special behaviour of the frame modifier. It's one of those cases when the answer was in my brain, because I watched Swift Talk, but for some reason I didn't think about it, 😞 .

The documentation of the modifier says this, emphasis mine:

If no minimum or maximum constraint is specified in a given dimension, the frame adopts the sizing behavior of its child in that dimension. If both constraints are specified in a dimension, the frame unconditionally adopts the size proposed for it, clamped to the constraints.

That's exactly what I wanted!

Image("christmas")
    .resizable()
    .aspectRatio(contentMode: .fill)
		// this is the magic trick
    .frame( 
        minWidth: 0,
        maxWidth: .infinity,
        minHeight: 0,
        maxHeight: .infinity
    )
    .aspectRatio(2, contentMode: .fit)
    .clipped()

But I have to admit that I've spend a few hours trying to fully understand the behaviour of frame. When I was happy understanding what passing both constraints does, I found myself confused because when I passed only minHeight: 0 the behaviour is still the one I wanted!

The diagram from SwiftUI Lab was very useful to understand the documentation in a visual form, but even with that the change of behaviour from following the child size to the proposed size is a bit confusing. I understand the common cases, and it always does what you expect it to do, but... I have to think a bit too much, there is still something confusing me.

Thanks to Ole I now have a better grasp of SwiftUI layout system. I will have to watch some Swift Talk episodes again 😂

Conclusion

I love this puzzles! I like to go deep not really to find a solution, but to make sure I understand what's going on. At the end of the journey I'm happy to solidify my mental model of how things work, even if the final answer is not very satisfying.

Ultimately though, I hope this post serves not only as an explanation of this behaviour but also as an inspiration to make you go deep and make sure you really understand how things work. So please don't just copy the final code from the internet, not even from this post!

A final thanks for the guys at Swift Talk for the useful debugging tools and for the great explanations about SwiftUI layout's system. And to Ole Begemann for giving me not only the solution I desired, but more puzzles to solve. They were crucial to help me form the correct mental model since SwiftUI release ^^

As usual, I could have totally missed something, or a new version of SwiftUI changes things, so please don’t hesitate to reach out to clarify anything 🙏.

Subscribe to my channel to be notified when new videos about SwiftUI are released.

The safe area is one of the most relevant changes in the UI paradigm of iOS in the recent years. It unified a bunch of layout ideas into a single API and allowed us to make our UIs adapt to new phones with weird shapes.

One of the most common design patterns that has to deal with the bottom safe area is having a call to action inside a footer on your screen. The difficulty with this design is that you want your content to respect the safe area, but also you want a background that extends to the edge of the screen. You can see it in action in any TabBar:

Implementing this is not as straightforward as it may seem. If you expand your container to the edge, your content will be behind the home indicator. If you fully respect the safe area you will see a different colored background behind the home indicator.

What you need is a combination of both things.

Luckily SwiftUI gives us the tools we need to accomplish this.

Solution for iOS 15

Updated solution for iOS 15 using the new API safeAreaInset(edge:alignment:spacing:content:)

With the new safeAreaInset(edge:alignment:spacing:content:) modifier the way we work with safe areas has changed. Instead of applying a modifier to a view in the main layout making it extend, we apply a modifier to the main view passing another view that we want to extend to the edges.

VStack(spacing: 0) {
    // Your screen content...
}
.safeAreaInset(edge: .bottom, spacing: 0) {
    VStack {
        // Your footer content or CTA
        // It will respect the safe area
    }
    .padding()
    .frame(maxWidth: .infinity)
    // The background will extend automatically to the edge
    .background(Color.green) 
}

Note how you can specify a spacing between the main content (the modified view) and the footer view.

Solution for iOS 14

This solution works on iOS 14. SwiftUI behaviour has changed a bit since the first releases. Thanks to Matthias for pointing it out.

edgesIgnoringSafeArea is a modifier that lets a view ignore the safe areas. We can use this to tell the background of our footer to extend to the edge of the screen.

VStack(spacing: 0) {
    // Your screen content...

    VStack {
        // Your footer content or CTA
    }
    .padding()
    .frame(maxWidth: .infinity)
  	// The background we want to extend
    .background(Color.green.edgesIgnoringSafeArea(.bottom)) 
}

By using the modifier only on the background with still make the rest of the content respect the safe areas which is very important.

Solution for iOS 13

Watch the original video to check the solution we had back in 2020.

let label = UILabel()

But we all quickly realised that it was not enough. You often want to initialize that label with some defaults set, things like font, color, etc. Swift has a way to do it with immediately-executed closures like so:

let label: UILabel = {
  let label = UILabel()
  label.textAlignment = .center
  label.textColor = .black
  label.text = "Hello, World!"
  return label
}()

But that is very verbose. You have to repeat the name multiple times and the immediately-executed closure is weird for newcomers.

The community quickly figured out this need in the early days of Swift Evolution. You can find a bunch of forums posts about the topic through the years, some of them in early days of the mailing list!

• Adding Method Cascades by Erica Sadun, one of the early proposals.
• Fluent syntax (replacing void with a useful default return value) - Discussion - Swift Forums
• Circling back to with - Pitches - Swift Forums
• Customized Inline Init Closure - Discussion - Swift Forums
• Pitch: Scoped Functions - Pitches - Swift Forums
• Discussion Here we go again: Extension Functions - Discussion - Swift Forums

Some of them focus on just adding flexibility to the initialiser syntax and others go beyond that to offer a general solution to these common topics of fluent syntax. The reality is that none of those proposals ever got far, so the language still doesn't offer a pleasant alternative.

But since the early days devxoul/Then was created and quickly became a standard in the community. I include it by default on all my projects. That's how useful it is! That said, I always missed some functionality and recently I started investigating the topic deeper, which prompted me to write this post and open source a new package.

Swift limitations

Accepting that the language doesn't offer the solution we need, let's explore how a library can solve it. It’s important to understand the limitations in the language that limit what a library can do.

Any being a non-nominal type

The first thing you encounter is the impossibility of extending non-nominal types. We rarely think about this distinction in the language, but for the functionality we want is a real blocker. What we would love to do is something like this:

extension Any {
  func then(...
}

But Any is a non-nominal type so we can't extend it! The best alternative to this is to make your own marker protocol (without requirements) and conform all the types you can to it! It's not pretty, but it gets the job done.

protocol Flowable {}
extension Array: Flowable {}
...

Note that by extending NSObject to conform to our protocol, we make all Apple frameworks have this new functionality. (if they are in Objective-C and use classes)

With that in place, we can add extension functions to our protocol when the conformant type is a... well, Any!

extension Flowable where Self: Any {
  func then...

It's a roundabout way of getting there, but it ends up working.

The lack of self rebinding

Also known as receiver closures from Kotlin. This functionality allows a closure definition to specify what the "receiver" object in the closure's scope is. The "receiver" is the object that will receive a method call if we don't prefix it with a target object. It's what self is in a method.

func methodInAClass() {
   callSomeMethodInThisClass() // self is implicit, is the receiver object.
}
...

methodWithClosure(SomeObject()) {
  // This closure could make `SomeObject` the receiver.
  callSomeMethodInSomeObject() // we don't need $0
}

The advantage of this is that you get less boilerplate by avoiding the repeated usage of $0, which is the same reason the language allows us to omit self in methods. It would be very useful to have, since the main purpose of some methods we want is to reduce boilerplate. But alas!

What Flow offers

Even with these limitations, we can still offer a lot of interesting functionality to improve fluent syntax in Swift.

As I said, I've been using the Then library for years, but the reality is that on every project I was a bit frustrated by it. It lacks some functionality that I miss on occasions, especially when having interactions with Kotlin code. That meant that I ended up making my own extensions on every project, and eventually switching some names to better match my preferences.

So after a long time I decided to write my thoughts on it, put together a list of requirements, clean up the methods, unit test them and release it to the world.

I present you Flow, 🌊 Let your code flow. A Swift package that includes a bunch of extensions to make fluent syntax better.

What you see is my take on this functionality. It covers my needs for fluent syntax. Of course, other libraries and languages have inspired it. I will document the direct influences on each method so you can explore the alternative yourself ;)

Below, I summarize all the functionality that I usually want:

• The star of the show is .then. We want this to configure reference and value types. Useful for configuration at the point of initialization.

• .mutate in place value types.
• .let to transform an object into another.
• .do to perform multiple actions with the same object.
• Free function variants, for when you prefer this syntax or don't want to conform to the protocol:
  • with (similar to .then)
  • withLet (similar to .let)
  • run as an alternative to immediately executed closures.

.then

.then let's you perform an object configuration inline. It applies statements in the closure to the object. It's very useful to set the properties of an object when defining it. Is what started this entire discussion many years ago :)

let label = UILabel().then {
  $0.text = "Hello"
  $0.textColor = .red
  $0.font = .preferredFont(forTextStyle: .largeTitle)
  $0.sizeToFit()
}

let size = CGSize().then {
	$0.width = 20
}

There are two overloads of this method provided. One that works on AnyObject (a.k.a. classes) and another that operates on Any (intended for value types). The compiler picks the correct one appropriately.

• In the closure you get a reference to self or an inout copy in case of value types.
• It returns the same reference to the object, or the mutated copy for value types.

Influences:

• Then.with
• Kotlin.apply and Kotlin.also

.mutate

Mutates a value in place. It s like .then but applies to self instead of a new copy. The value needs to be defined as a var.

view.frame.mutate {
  $0.origin.y = 200
  $0.size.width = 300
}

• In the closure you get an inout reference to self .
• It returns nothing.

This should be used only for value types. For reference types is recommended to use .then.

.let

You can think of .let as a map operation but for all the types (not only for Functors). It lets you transform the object into an object of another type.

let dateString: String = Date().let {
    let formatter = DateFormatter()
    return formatter.string(from: $0)
}

It works especially well for type conversions based on initializers:

let number: Int? = "42".let(Int.init)

Don't overuse this when you can use just plain dot syntax. You can use it to access a member of the object Date().let { $0.timeIntervalSince1970 } but that's just the same as Date().timeIntervalSince1970.

• You get a reference to self in the closure.
• It returns the object returned in the closure.

Influences:

• Swift's own let declaration.
• Kotlin.let and Kotlin.run.

.do

Use this method to perform multiple actions (side effects) with the same object. It helps to reduce the verbosity of typing the same name multiple times.

UserDefaults.standard.do {
    $0.set(42, forKey: "number")
    $0.set("hello", forKey: "string")
    $0.set(true, forKey: "bool")
}

This behaves like other methods if you discard their return, but is preferred to use do to convey the intention better. It also lets you avoid writing the return on some occasions.

• You get a reference to self in the closure.
• It returns nothing.

Influences:

• Then.do

.debug

By default, it prints self to the console. This method is useful for debugging intermediate values of a chain of method calls.

let result = Object()
   .then { ... }
   .debug("prefix")
   .let { ... }
   .debug()

• You get a reference to self in the closure.
• It returns the same object without touching it.

The following free function variants are mostly there to workaround Swift limitations. But there are also some people that prefer them. Flow gives you both alternatives ;)

Free function with

Executes a closure with the object. This free function it's a substitute for .then when you can't use the method or if you prefer the free function style.

let label = with(UILabel()) {
    $0.text = "Hello"
    $0.textColor = .red
    $0.font = .preferredFont(forTextStyle: .largeTitle)
    $0.sizeToFit()
}

• You get a reference to an inout copy of self in the closure.
• It returns the returned object in the closure.

Influences:

• Overture.with
• Kotlin.with
• Many other languages have a with or using function.

Free function withLet

Variant of with that lets you return a different type. It's a free function alternative to let.

Free function run

Executes a closure of statements, useful to be used when you need an expression. This is like making a closure and invoking immediately, but sometimes is clearer to have a specific name for it.

let result = run { ... } // same as { ... }()

Conclusion

It has been fun to spend the last few days writing down my thoughts on this topic. I read many times Kotlin's documentation and looked at how other languages solved the problems. Ultimately, I compiled a list of the functionality that I wanted and which names should I use for them. I've been using this code in one way or another for many years, so I'm happy to finally have put the time to polish it.

One of the things I tried was to unify some methods. It worked for then which operates on both reference and value types. I wanted the mutate method to have the same name, but that didn't work out. let is one that I use quite a lot, although I try to not overuse it as the Kotlin community does, in my opinion. do is one that I don't use a lot, but is useful sometimes and since the purpose of this package is to avoid friction, I ultimately decided to include. For the same reason the free functions are included, sometimes I don't want to conform an object to the protocol just for a one of operation, and the free functions are perfect for those occasions. And don't forget about debug, probably the one I use the most ^^.

Thank you all for reading and remember you can find Flow on GitHub and try it by yourself.

You should read this Twitter thread from Jordan Rose about the decisions of making Optional so convenient.

One of the common operations that you want to do with an optional is to coalesce the nil with a default value. For that, Swift provides the handy nil-coalescing operator ??. This operator is so nice that we will use it to improve on the ergonomics of optional later.

But the reality is that there is still a bunch of behaviour that Swift doesn't make so convenient. For example, another part of the language that is convenient to use is Errors. And the language provides a mechanism to silence errors, to convert a throwing error to an optional. That's what try? does. But there is no convenient way of going the other way around!

Another important aspect that people often complain about is how force unwrapping ! has a very convenient syntax but if leads to opaque logs and crashes with very little information.

Not invented here.

The community quickly realised all of this in the early days of Swift. The concern about the lack of proper diagnostics for force unwrapping was put in the table by Erica Sadun on 2017 (see the pitch) and it even had a proposed solution (SE-0217: Introducing the !! "Unwrap or Die" operator to the Swift Standard Library) that was eventually rejected. Even tho it was rejected the core team agreed it was something worth discussing and that improvements on the language (Never being a true bototm type) could offer alternative better solutions.

I was never interested in that operator since I barely want to "die" when working with optionals. And when I do ! is good enough for me. But what I want often is to throw an error if the optional is nil. Conversations about this also started a while back, Unwrap or Throw - Make the Safe Choice Easier and Introducing an “Unwrap or Throw” operator.

If you read all those conversations, you see that there are multiple ways of solving the same problem and everybody has different opinions and needs.

What I want to share today results from my gathering of the solutions mentioned over the years and taking the ones I like the most. I've been using this code in my projects for years, so this is maybe not how Swift will solve it eventually, but it's the way I prefer to solve it.

My Desired solution

What I want is to be able to use the existing tools in the language in all the ways I need. That is, use the nil-coalescing operator?? but instead of giving a default value, throw an error or even crash.

That translates to code that should look like:

try optional ?? throw(Error())
optional ?? fatalError("fancy message")

I don't think new operators are needed. The ?? already provides the semantic definition that we need: unwrap the optional on the left and if it's nil use whatever there is on the right. Usually the right side will have a default value, but it doesn't have to be always like that!

Coalescing with raise

The problem is that if we try to use throw on the right side, we will find a compiler error. That's because Swift's throw is not an expression, so we can't use it in this way.

We can make a very simple function that throws the given error, call it raise. It’s a very simple function, but it makes it possible to throw errors in places where an expression is needed.

try someWork() ?? raise(YourError())

Just with this function, you can get very close to the ideal syntax of an "unwrap or throw" operator. Some will even prefer this to the next alternatives, since it doesn't introduce any new operator overloads into the language. This is the solution with less impact.

Coalescing with ??

But if you want to have a more succinct syntax, you can overload the coalescing operator. With it, there is no need for the raise function.

try someWork() ?? YourError()

I think that's all I wanted! ^^

Method unwrapOrThrow

That said, some people don't love overloading operators or even abusing them in this way. For those, it's quite easy to just make an extension in Optional that gives this functionality a proper name: unwrapOrThrow.

try someWork().unwrapOrThrow(YourError())

You can even make a default error UnwrapError. With that, you can call the method without specifying a custom error.

try someWork().unwrapOrThrow()

☠️ Unwrap or die

As I said, the "unwrap or die" is not something I ever used. But with the setup we have so far is quite easy to retrofit this functionality. All the same techniques that we use for throwing can apply to fatalError.

Why fatal error? The common complain about ! is that it doesn't give a reason when it crashes. It's like a fatalError(). But if we use fatalError("reason for crashing") we can attach a reason explaining why we thought the optional should have had some value and never nil.

We can start by just using the raise function.

try someWork() ?? raise(fatalError("reason for crashing"))

This works but the compiler will show a warning on this line: Will never be executed . That's because the compiler detects that the raise function itself will never be executed.

Instead, we can overload ?? to accept a Never on the right side.

try someWork() ?? fatalError("reason for crashing")

Of course, if you prefer to use the method, it's even easier since it just works.

try someWork().unwrapOrThrow(fatalError("reason for crashing"))

Unwrap or reason?

A common request is to have a way to unwrap or pass a String directly for the reason of the crash, instead of using a fatalError(_:). I barely use the unwrap or die technique, so I don't have the need for further convenience.

If you want to do that, then you start needed other operators and functions since otherwise you make things ambiguous when the optional contains a String. Is the right String a reason to crash or just a safe default?

I will leave this as an exercise to the reader.

Wrapping it all together

After all this analysis, and years of using some of these solutions, I decided to open source a small Swift package with these conveniences: UnwrapOrThrow.

Unwrap Or Throw (or Die!): 🎁 Unwrap an optional or throw an error if nil (or crash the program).

There are other solutions out there, but I liked none of them, so this is just yet another one. But is the one I like ^^.

What is this even called?

The weird thing is that I'm not sure what I was trying to do is even called, because to be honest, I'm not even sure what I was trying to do... Is this what it feels to do R&D?

I think that watching Jonathan Blow Jai livestreams was what planted the seed. In some of those streams, he talked about how the compiler it's like a game loop that keeps trying to resolve dependencies. This allows the language to be very flexible with declaration order. As long as the information is there, it will eventually solve all the declarations. Or that's what I understood ^^ In my mind, this spawned thoughts about "query resolvers".

At the time of writing this there is no website for Jai so the only knowledge I have is from watching Jon on stream. And I never remember in which one he talked about this topic ^^'

What I wanted to work with was a system where every time there was a query, the answer would come eventually, even if it was not immediately there. The premise is simple, but without a proper framework, it seems quite hard to work with. It's not the usual way of working. What you typically would do is to check in a Dictionary and if the answer is not there, well... bail out. The "try again later" is the tricky part, and I wanted to find a framework for it.

I'm sure the Jai compiler implements a delightful way of doing it that's very performant (otherwise they couldn't get those below-second compilation times!). But I don't know what I'm doing here and I just wanted to have fun! And play more with Swift Concurrency!

After doing some research, I saw some examples of what I was thinking about, or at least close to it.

There is a concept called incremental computation, see this Rust library Salsa as an example. I'm not exactly sure if it's what I was looking for or not, but seems related. What is not clear to me is if this system solves the "eventually consistent" part of what I was looking for, instead it seems focused on memoizing the results of operations to reuse them, ideal for incremental compilation!

Talking about compilers, the topic of query-based compiler architectures is a very interesting read. I found out that Rust has a demand-driven compilation system (see the docs) and even Swift seems to be moving in this direction with its request-evaluator system.

The good thing about these rabbit holes is that even if I get nothing useful, I definitely learned a ton of interesting things along the way!

Example

Let's visualize a bit what kind of problem I was trying to solve with one example I've been playing with. Imagine a toy system of files where each file can contain some text, imports (other files), declarations, and usages (of these declarations).

[
    "main": File(contents: [
        .text("Start of Main"),
        .usage("A"),
        .usage("B"),
        .import("other"),
    ]),
    "other": .init(contents: [
        .text("Other file."),
        .import("types"),
    ]),
    "types": .init(contents: [
        .text("Declaring types:"),
        .declaration("A", "Amazing"),
        .declaration("B", "Burr!"),
    ]),
]

You can see how the main file uses A and B before seeing their declaration. The declaration comes from a chain of imports. The goal then was to code a system that could get the final output (concatenating the strings) of this example without having to keep any state or order dependent code.

Developing Prototypes

I started prototyping a Query Resolver where each query would perform a piece of computation. Pretty quickly, I found that the tricky part was how to pause the program when a query was still pending.

My first approach was to follow a "game loop" like system where on each iteration queries could be added, or answers from it could be obtained. This got quite far, but it had some problems. The loop had to be careful with the order of the queries because if the same query was executed twice before another had responded the system could end up adding more queries ad infinitum ^^ This can of course be solved but the big issue was the usage side since the code was not very nice.

func resolve() {
  if // check if the answer you are looking for exists
    // do what you want...
  else
    // enqueue the query that will get you this...
}

This is a literal translation of the "try again later" style. But it got tiresome quickly. Plus, now that we have async await in Swift... wouldn't that help? await is literally a way to pause a function until it gets an answer. So I quickly jumped on that!

That took me down the path of trying how you can pause functions until some data exists. Ultimately, the surface area of async/await doesn't offer low level APIs to control the coroutines easily. Task has a yield() but that doesn't help a lot in this scenario, especially if it's in a hot loop. I eventually end up realising how the continuation API is what I was looking for!

With a continuation, you can await on a function call and resume it later when you are ready for it. It took me a bit to see how to use it to solve this, since the most common usage of them is to convert from a callback based API:

await withCheckedContinuation { continuation in
    callbackBasedFunction(onCompletioin: {
      continuation.resume...
    })
}

But in this case there are no callbacks, it was just data stored in a cache (Dictionary) that eventually shows up. The solution is to keep around the continuation, but that's easier said than done. Eventually I ended up making a small AsyncChannel type that took care of that. Read more here Building a Channel with Swift Concurrency Continuations.

With that piece solved, implementing the Resolver was quite straightforward.

One independent piece of the Resolver is the AsyncStorage type. It's the core part of the system that uses AsyncChannel to await for the data to be in the Dictionary. It may be useful for other scenarios.

Usage

The basic idea is to represent computations with queries that have a key associated:

struct ProcessFile: Query {
    var key: String { fileName }
    let fileName: String
    func resolve(_ resolver: AsyncResolver) async throws {
        let contents = try fs.readFile(fileName)
        let textParts: [String] = await contents.content.concurrentMap { c in
            ...
            let content = await resolver.query(
                ProcessFile(fileName: dependency),
            )
        }
        await resolver.save(textParts.joined(separator: " || "), for: key)
    }
}

You can see some points on the example:

1. The key: String identifies this query. The resolver uses this to return a previously computed output of the same query if available. It could be used for more things but I didn't get that far...
2. The resolve function is where you implement the computation.
3. await resolver.query(...) will add the query to the system and wait for its resolution.
4. await resolver.save(..., for: key) saves the result of the computation.
5. There is a await resolver.addQuery(...) that just adds the query without waiting for its resolution. In fact, query(...) is a combination of both addQuery and read.

The important bit is to understand that a query doesn't have to know how to get the answers for the entire chain. As long as some query in the system has the answer, it will work.

When the result of a computation is saved, every other query in the system that depended on that key would get resolved and computation will continue.

Another important piece here is the concurrentMap. If a computation has dependencies in other queries, it should try to request the results concurrently. This unlocks the power of resolving queries out of order. If you ask for otherwise independent computations in series, you won't get much benefit.

Function like syntax

Having to do query(Query) feels a bit cumbersome. Following the goal of making this as "normal" as possible, I ended up wrapping these calls in functions. This allowed for a much more pleasant syntax:

let result = await resolver.processFile(name: "main")

From the usage side, the only unusual thing is the resolver. The rest seems like a normal async call. You still need to reach for the direct calls for when you want to add a query without waiting for the result, or when you just want to provide results to the system. I'm sure better APIs could be built around that.

Salsa uses Rust's powerful meta-programming capabilities to create these functions for you.

Further improvements

So the system works, at least for the toy examples I tried 😂 But if this was a real project there would be plenty of improvements to make. For example, cycles are not detected, so if you add a cycle in the data, the program will halt for ever. I think that this is usually solved by keeping track of which queries add other queries.

I recommend you to read the linked articles above if you are curious what a proper system is capable of.

Curiosity satisfied!

So that's all! You can check the code on the Query Resolver System repository, including the prototypes. Don't expect high-quality code ^^'

I love getting lost in these experiments and this one got quite far. I didn't expect I could follow through it until the point where I was satisfied with the usage of it and it worked! But I did ^^. I would still love to work on detecting cycles, but I have other interesting things on the to-do list, so I will just leave it here for now.

If you have gotten this far, thank you! 🙏 I hope you found this experiment interesting.

But the other day I needed a tool that, while allowing me to stay in a structured concurrency system, it internally could leverage unstructured techniques. The exact situation is not really relevant besides understanding that I have a system that needs to read a value from some storage with the quirk that the value may not be there yet and thus it should wait for it.

let value = await storage.value(for: key)

I want to follow the structured concurrency principles on the reading side. But we can’t implement this without escaping the confines of this structure. That's because reading the value is not what starts the work of generating it. Instead, it’s another independent subsystem, at another time, that will end up saving the value into the storage.

To accomplish this, we need a way to pause the execution and resume it when another system tells us the value is available.

Consider this a proof of concept and an excuse for me to dig deeper into these topics. You can read the source but if you really need a solution like this for production, I recommend you to review it carefully and maybe look for other tools.

Discarded solutions

1. Future/Promise: I want to stay as much as possible in Swift Structured Concurrency, so this is a no go, although the Channel we're implementing looks a lot like a Future.
2. Combine PassthroughSubject: this is more akin to what we're looking for. A way to pass values from one place to another. But I want to use the tools in the language, not an Apple-only framework. Also, I just want to pass one value.
3. Task: Nope! People still treat this as a Future and I have a lot to say against that (I should have written already about this 😢 ). Suffices to say that it won't work because you need to feed data from the outside and Task doesn't have an API for that, because it shouldn't!
4. AsyncStream: we could use this since it is using just the language tools. But you will still need to write something to keep its continuations (which are slightly different that the ones we're using). Also, I just want to pass one value so this is an overkill.

Building the AsyncChannel

Now that we understand our problem, let's build our own solution! I call it AsyncChannel, although is probably not the best name for it 😂

The following code shows a simplified implementation for illustration purposes. Handling cancellation adds a bunch of verbosity so I left it out of the article. You can read the full source for more details.

Let's start by looking at what we eventually need:

// In one side...
let value = try await channel.value

// In the other side...
channel.send(42)

From this usage, we can already see a couple of important details:

1. We need to be able to await for getting the value (the whole point of this!)
2. We need to be able to send a value without awaiting (we don't want to force other systems to be async)

With this in mind, let's create a class with the methods we need:

final class AsyncChannel<T> {
    var value: T {
        get async {
            ...
        }
    }

    func send(_ v: T) {
        ...
    }
}

To make sure we avoid concurrency problems, we will put the bulk of the implementation in an internal type, called Buffer, that will be an Actor. In this way, we can keep a simple class interface to the outside but ensure we don't have concurrency issues.

To understand what the buffer will do, first let's look at a simplified implementation for the value computed property.

var value: T {
    get async {
        await withCheckedContinuation { continuation in
            Task {
                await buffer.addContinuationIfNeeded(continuation, id)
            }
        }
    }
}

Here is the main point of the solution. The Continuation APIs! You can think of them as a hook into the concurrency runtime, a sort of low-level tool that lets you control the execution of a function. With them, you can pause the execution of the function while having control of when resumption happens. The common usage of these APIs involved calling a callback based function and resuming on its completion, but here we keep hold of the continuation, passing it to our buffer which will resume it at a later point.

A proper implementation should handle cancellation of the current Task to make sure the continuations are released properly. You can see how the full source uses a UUID to identify each value call and makes sure to cancel it appropriately.

The send method is very simple since it just forwards the call to the internal buffer:

func send(_ v: T) {
    Task {
        await buffer.send(v)
    }
}

Since it’s calling an actor isolated method, we need to perform the call asynchronously. It's important to note that the method itself pretends to be synchronous so we don't pollute systems that don't need to be async.

The buffer implementation is not that much more complicated. It keeps the current value and a list of continuations and provides a safe interface to managing them.

The addContinuationIfNeeded checks if the value is already there and resumes the continuation immediately. If it's not there yet, it keeps the continuation around to resume it later.

func addContinuationIfNeeded(_ continuation: CheckedContinuation<T>) {
    if let value = state.value {
        continuation.resume(returning: value)
        return
    }

    continuations.append(continuation)
}

Finally, the send method saves the value and resumes and releases all the continuations:

func send(_ v: T) {
    value = v
    continuations.values.forEach { $0.resume(returning: v) }
    continuations.removeAll()
}

And that’s most of it. The implementation performs extra checks to ensure the channel doesn’t already have a value, or it’s cancelled.

Conclusions

As you can see, the trick relies on keeping the continuations around and resume them later. The complicated part is managing the continuations themselves since they are a delicate object to manage manually.

You need to resume the continuations only once. And if you forget to resume them at all, the piece of code that is waiting for them will hang. And you also need to make sure they are released when no longer needed, especially when Tasks are cancelled, otherwise you may leak resources from other Tasks. That's why you always need to handle cancellation properly.

Think of them as a low level implementation of concurrency. They give you great power and you know what happens with great power ;)

You can read the full source code to see how the cancellation is handled and how the continuations are managed. I will advise against running this code in production since it's just a proof of concept for a very specific need I had.

I hope you found this useful and learned something new!

For the past couple of years the iOS landscape has changed dramatically and I finally feel like we're in a proper position to enjoy making apps again, something I didn't feel since the early days of the platform.

In this article, I want to describe what I think is the best way to build iOS apps. This ranges from how to make UIs to how to structure the overall project, of course touching on the subject of architecture.

These ideas come out directly from my experience over the years building and maintaining applications. Everything I'm suggesting here are things I've tried myself.

As a side note, pretty much all these recommendations apply as well to Android development. I've successfully deployed these ideas to both platforms with excellent results. Some things are trickier in Android due to do nature of the frameworks, but they are totally doable and very desirable.

Suffices to say that I'm not a guru that writes this to spread a dogma. This is just my opinion, my recommendation born from my experience. If there is one thing that everybody needs to learn is to analyse things from themselves, so don't follow this blindly, heck, follow nothing blindly!

Another thing I want to address is the first reaction some will have about this tech stack. If you think that I have decided this tech stack because these are the new shiny things, I encourage you to reconsider and look past that. I'm not one to jump on everything new and compromise the future of my projects. I don't think any good engineering lead should do that. But I'm also not going to pretend the world is not moving forward. When I see that something new I tried for myself to make sure I understand the tradeoffs that it proposes.

Table of Contents:

1. Goals
2. Modularised structure
3. UI
4. Architecture
5. Concurrency
6. Go first party
7. Conclusion

Goals

Before talking about the different points that make my ideal architecture is important to have some goals in mind. We need to have a clear solution space that we can analyse our decisions on.

One of the crucial points to get right is developer experience with fast iteration cycles. In a rapid development environment, these two characteristics help a lot to keep up with new product features in a timely manner.

Another very important aspect is the maintainability and evolution of our codebase. Whatever system we use it needs to allow us to change code rapidly and, most importantly, get rid of it when it’s no longer required. I directly relate this to the desire to facilitate the independent evolution of the different parts of the app and make it simple to have system integration.

One thing to keep in mind too is how these decisions affect hiring. Most people will very soon want to work only on modern tech stacks and the onboarding ramp is something that we need to pay attention to.

With these goals in mind, let's look at the specific points that make a desirable architecture in today's world.

Modularised structure

A key part of the tech stack is having a fully modularised application structure. I'm not talking about having files in different folders, but about enforcing strict boundaries between the different systems in your application.

This has never been easier in iOS! I remember having different project frameworks years ago, hacking Xcode to support them on iOS before any official support. It was crazy pants. But nowadays the Swift Package Manager makes this trivial.

The aim is to have the code separated in multiple small independent packages that are combined by an “application”. This facilitates the maintainability of each package and their independent evolution. Having small packages and a clean dependency graph also improves compile times and unlocks a bunch of improvements in iteration cycles and developer experience.

The important thing to understand is that we're not just talking about modularising helpers or utilities. The goal here is to modularise the distinct features of your app. That, in turn, will force you to think about your structure and modularise the rest.

Many of the ideas you will read in this section have been directly inspired by Pointfree. Make sure you check it out!

An idealistic goal is to have your Xcode project just have the app entry point and immedatly start the code from a feature package. Yes, this makes 99% of your code live in Swift Packages! 🎉

The Mindset

For me, one of the most important aspects of adopting modularisation is the change of mindset that forces on the developers. It’s very important that you get into the mindset of proper modularization. This will break some existing preconceptions that you have about relationships in your code, but it is crucial to embrace them in order to get all the benefits of this approach.

Simple dependency injection and inversion of control becomes crucial. Your package may need to do some work, and it may be tempting to put the code directly in the same package. But you need to have clear responsibilities for each package and know where the walls need to be built. Another way of looking at it is to not just think about the dependencies and the graph (there are always ways to force it to do what you want) but about the knowledge (or lack of thereof) that each package should have.

I use physical metaphors often when describing these concepts. I found they help visualise where the limits of each module are. Everybody knows you can't cross through walls unless there is a door, or what's the difference between your home and the outside. I recommend you to use the same when you are trying to explain some of these concepts.

A very common example is when a package needs something that doesn’t really need to be known to it. It must provide callbacks or customisation points to the outside world. Its responsibility is just to call those hooks - not to know what happens in them. But if the packages just calls back (delegates) to the outside world to do this work, who is then doing the actual work?

That’s where the hierarchy comes in. When a communication needs to be established between two otherwise independent packages, a third package is introduced to depend on both and provide the communication channel between them (see example below). Usually this package ends up being the App target, which will import all features and link them together appropriately. But sometimes it may be beneficial to make these “parent” packages to bring other kinds of functionality together.

This solution has come up so frequently and can solve so many issues that I ended up calling "The third package rule". Making a third package that pulls together two other packages is always a valid solution. Nonetheless you should try to find other solutions to avoid an explosion of this type of package.

Example

Imagine that feature A may want to open a screen that lives in feature B. It may be tempting to make A depend on B, after all you want to open its screen. But that’s the wrong mindset!

Feature A shouldn’t know anything about what happens outside itself. It shouldn’t know anything about that other screen, since is part of B. It should just provide a callback, a hook, to let somebody else decide what to do. Who is that somebody else? A third parent package that will pull together feature A and B, usually the App.

This third package, C, will depend on both A and B. It will hook into A’s callback, and when that callback executes, it will open B’s screen. A and B know nothing about each other. C is the one connecting them together. It’s like an old telephone operator.

The hierarchy

Having multiple modules in a project is very beneficial, but can quickly get out of hand if they depend on each other. When that happens, you just moved the spaghetti mess of your code up one level. That's why I designed some guidelines (rules for my team ^^) to help facilitate the decisions when finding these dependencies.

It is important to realise that not all modules are equal. Even tho all of them just have some code their purpose is different and they take part in different ways on the dependency graph of the project.

The diagram tries to illustrate the different levels in the modules hierarchy.

Apps are the topmost modules. This is where your main app belongs, but also other "feature preview apps" or other targets like widgets and other system integrations. They Can import any other module but Can’t be imported by any other module.

Features are the modules that represent the different features of your app (user profile, feed, ...). This is the most crucial aspect of the graph, and the one that benefits most from this approach. It's important to remember that they can't depend on other modules at the same level or above. They Can only import non-feature modules.

Dependencies are other library like modules. Things like API layers or other subsystems. I like to think about this as my own "first party libraries", so they are not necessarily third party packages. One important detail is that if they depend on heavy third-party libraries, you should break them down in interface and implementation. And if you need to use third-party libraries directly on features, they should receive the same treatment. The Interface module will just contain the interface and dependencies needed. This is the module that will be imported on feature modules. The Live module will contain a live implementation of the dependency. This will only be imported by final apps (top layer). This has the benefit of being able to create fake implementations very easily, directly in the interface module or on their own one if required.

The bottom layer is what I like to call Foundation modules. These are special libraries that are at the bottom of the hierarchy and provide the foundational functionality needed everywhere. They Can’t import any other module and Can be imported by any other module. This one is sometimes hard to grasp since it seems like a lot of things could go here, and is quite the opposite. Usually I just end up having a couple of modules at this layer: Foundation extensions and common UI building blocks. It's important to realise that if something is needed in a lot of places but has dependencies or specific requirements, that’s not a foundational library. Don’t be afraid of making as many specific library modules as needed!

Other app modules

Having this modularisation gives you flexibility to have apps other than your main product. For example, feature preview applications are very useful for rapid development on real devices of a specific feature. They avoid having to go through your entire navigation every time.

But you can think about Playgrounds as another kind of application. It's very useful to have playgrounds to play with some business logic or some subsystem of the application without having to deal with everything else. For example, I made a small playground to play with API calls that has turned out to be quite useful! You could even make CLI applications that reuse your business logic!

UI

It won't come as a surprise that I think a modern iOS app should be using a modern UI framework like SwiftUI. Not because is modern, but because a declarative UI framework has real benefits.

It's not because SwiftUI is the new shiny thing (is not even new anymore 😂 ) but because I truly believe that a declarative UI system reduces a lot of the friction and maintenance burden that you get from more classical imperative systems (UIKit). As you may know, I've been wishing for a declarative UI framework on Apple platforms for years before SwiftUI was announced.

My video about the announcement is still my most watched video, not because of its quality but because I was so excited about that I published it in record time and was the only video about SwiftUI in YouTube for hours.

SwiftUI directly helps with iteration cycles, not only thanks to the Xcode Preview system, but because changing things in views is way faster than with imperative code. The fact that the only thing you write are mappings from data to view makes working with UI as easy as manipulating data. The beauty of which has been lost through the years. I know SwiftUI comes with a change of mentality that not everybody is comfortable with, but it's totally worth it.

I won't elaborate more about the reasons to use SwiftUI here because I sound like a broken record 😆 Feel free to read some of my posts on #SwiftUI or watch my SwiftUI playlist.

But I won't hide the fact that SwiftUI is still young and sometimes you need to fall back to UIKit. I just don’t consider that a tremendous problem! The integration works very well and thanks to the modularisation, you can provide APIs that the rest of the project uses without knowing that UIKit is still there, just like Apple does. The recommendation to my team is to be comfortable integrating UIKit, but try to avoid it like the plague.

I would also recommend that you keep under control the amount of factorization you do for your views. Coming from an OOP framework we feel like we should avoid DRY to the extreme, but composing views in a declarative framework is so easy that sometimes I much rather prefer duplicated code in conceptually different views than not tie them together too early for no reason. I like to delay that decision until it's clear that they are the same view but just with minor differences, and not force that into the code. Refactoring view code is so easy that I don't think is worth risking doing it too early.

Architecture

In terms of architecture, the decision is clear, a modular uni-directional data flow architecture is the desired choice. This type of architecture it's the most crucial aspect for an easy to understand and maintainable codebase.

The more classical approaches (MVC and even MVVM) can quickly become out of hand and hard to grasp. Is not immediately obvious where a change in the application's state happens or where it comes from. It feels to me like those architectures are tied to their OOP roots and show the same defects as that paradigm. Instead, a uni-directional data flow architecture benefits from some functional programming concepts that make things way more controllable and easy to understand.

I've seen the benefits of this approach in other ecosystems for years, but since it's quite a radical departure from what the iOS community is used to do I've never felt that we had a proper library for it. For years, I've been watching this space, and I always had issues with all the candidates so I have a judgemental eye and know what to ask. But then Pointfree started designing The Composable Architecture on their videos. At the start of every episode, I saw the same issues I always had with architectures like this, but by the end of the episode, they answered with brilliant solutions. That's something that never happened to me before! Seeing how everything fitted together so well, and not the fact that was new and shiny, was what made me a big fan of the library and started using it even before it was released officially.

I don't want to make this post longer by elaborating on why the TCA is great, but let me give you a few pointers by touching on the different aspects of the architecture quickly:

• Having the State of your app (and UI!) in a plain struct makes it super clear why the app is showing what is showing in every moment. Makes it incredible debuggable and even reproducible.
• Every single event that the user or other systems perform on the app is encapsulated in an Action. This means you can know every single event that the entire app reacts to.
• Most systems fall apart when you start talking about dependencies. But the TCA comes with an integrated solution thanks to its Environment. Forget about using bulky dependency injection frameworks, the environment is just a plain struct with dependencies. It makes it incredibly easy to switch dependencies on test without having to rely on sub-classing or classical mocks that just cause issues.
• In the same way that SwiftUI makes building UIs easier thanks to its declarative nature (Data -> UI), the Reducer gives us similar benefits to our business logic. It's a pure function that lets us convert the state of the app based on what actions has received. Swift makes this incredibly nice thanks to inout because you feel like you are writing mutable code but you are not. Finally, the Effects are controlled so the purity of the function is kept intact.
• The final piece is what brings everything together, the Store. It's the responsible for keeping the flow of data going and interpreting the managed effects that come out from your reducers. It's a part of the architecture that you barely touch but for me it's crucial because it follows the "interpreter pattern" that I've grown to love so much.

The importance of Swift on the beauty of this architecture can't be underestimated. Having so aproachable value types, that even give us mutable value semantics is incredible. But also more advanced features like KeyPaths make it possible to build elegant APIs. Swift is an amazing language and libraries like this make it very clear.

You can see here the main bullet points of the architecture. But for me, the most important concept that sets this apart from any other architecture is the composability of the domains.

Domain

I use the word domain a lot when talking about features and the TCA because it defines a clear separation between different parts of the code. In my own words, a Domain refers to a specific area of the program that can be reasoned about independently. It can be as small or as big as necessary. For example, a “feed feature” is a domain for an entire feature, but the “list of posts” is the domain for just one screen, or part of. You can go even further and talk about the "post" domain, which represents a single row in the list. Is a useful word to use because it helps describe the structure of the code when we want to break down or compose domains.

The beauty of the TCA is in how easy it makes it to compose different domains. This translates into making it trivial to break down domains into smaller domains. Usually you have 1 domain per screen, but if the screen is too complex, or part of it is repeated in multiple places, you are free to break them down into its own domain and share it between the screens.

I like to classify these domains to facilitate the conversation:

• Embedded domains are those that provide functionality by embedding it into your own domain. This is often what you do when composing different screens in a flow, or when separating a reusable piece of UI. This is particularly useful for navigation or to make a domain for each individual item in a list.
• Generic domains. Domains can be built to reuse generic functionality across the application, for example, the reusable favoriting case study. These are often accomplished thanks to high order reducers, which represent the same concept as high order functions. In my mind, these generic domains come in two forms: polluting and transparent (not very good names I know).
  • Polluting generic domains are those where the types of the store changes. These happen when you need to include domain specific actions and state. They are very powerful but can complicate a bit the types you need to write.
  • Transparent generic domains on the other hand are those that are made out of high order reducers that just add functionality without altering the types of the store. Things like debug().

The Feature level domain

It's important to give a special mention to the domain that encompasses an entire feature. It's the domain that provides the public interface of the feature and all the other reducers and views are hidden internally. You can think of it as the entry point of a feature.

Take a look at Observe actions in The Composable Architecture which provides a nice little tool to hook this feature domains with the rest of the application.

Concurrency

Concurrency is a big topic right now in the community since we finally got Swift Concurrency. It's a topic that I've been following for months and one for which I have many things to say. But for what relates to this post, I would just say that in a modern iOS app you should use Swift Concurrency as much as possible before looking at more complex alternatives. And if you really need to use a full-fledged FRP framework, I recommend you to stick with Combine instead of using a third party library.

My advice is that you really try to learn and embrace Structured Concurrency. You may be tempted to follow the same patterns and techniques you are used to with FRP or Futures, but you will hurt your codebase and future maintainability if you do that.

Swift Concurrency is a game changer and something you should embrace fully. It will make all your async code more maintainable.

Go first party

Finally, I just want to touch a bit on the topic of dependencies. This is something that sets aside our ecosystem from others. We have a "first party" provider, Apple. The relation we have with them is not always perfect, but it's very wise to follow their recommendations as close as you can.

For many years we've had to look to outside libraries for things integral to how we code (things like RxSwift, other Databases or wrappers, etc) and tools (third party package managers). But nowadays I think the situation is much better and for many things you should choose to use a first party solution instead.

We've already seen how this approach fully embraces SPM and Swift Concurrency. But besides that I would also recommend sticking with vanilla Core Data (although GRDB is my preference). Don't confuse this with refusing to use any third party code (TCA is not first party after all!) but about realising that Apple frameworks have come along way and more often than not they provide the tools that you need. You just have to look closely ;)

Conclusion

To summarise, in my opinion an iOS application in 2022 should:

• Be written in Swift (of course I didn't mention that because is obvious coming from me).
• Be fully modularised project structure.
• Use SwiftUI (a declarative UI framework).
• Use a modern uni-directional data flow architecture that is composable (TCA).
• Stick to system frameworks when possible.
• Use all these points to improve the developer experience and iteration cycles.

And these recommendations are not just empty words, but things that I've been actually putting into practice in the main application that my team maintains. An app with ~350k LOC that was born in 2013. I'm thrilled about how nice is to work with, but it's time to move it to modern times.

And here you have a couple of slides that I presented in our engineering gathering before ending the year. ^^ (as you can see, this system is followed by both platforms)

One inconvenience is that the principal object of the architecture, the Store, doesn't have a way to observe the actions that it receives from the outside, the only one that gets actions is the reducer and that is part of your TCA domain. This makes sense since the star of the show is the state.

The state should drive everything and that's why the library comes with a StorePublisher that will provide a stream of changes to the state. With that you can use TCA in UIKit for example, and is very easy to use. But sadly, there is no affordance to observe the actions themselves.

The problem with observing state

Observing the state is totally the right thing to do in features that use the TCA, but it comes with some problems when you want to use it to interact with the exterior world. Having to listen to the state means that you need boilerplate to check if the change that you cared actually happened, furthermore you probably will need an action to reset the state once you've done what you wanted with it. These things are not an issue in a fully declarative world but on the ugly outside it's a big annoyance.

But the big issue is how this usually means polluting your state just so something can be observed from the outside. This may seem not that important, but in my opinion is a big negative point for this solution.

What we really care in these cases are the events that happen inside the feature. In other words, we need to know what actions are passing through the Store.

Relay

The goal then is to hook into the Store to get the actions, but we want to do that without modifying the library. With that limitation, there is only one place we can use to get callbacks when actions are sent, and that's the reducer.

This means that we need to extend the reducer we use for the specific feature on the fly. Something like this would work:

let store = Store(
        initialState: ...,
        reducer: featureReducer.combined(with: .init({ _, action, _ in
                // switch on the action that you want to listen to and run some code
                case .someAction:
                      runSomeCallback()
                      return .none
            }))
...

This works fine and is all you need, but is worth discussing the disadvantages of this approach.

If you look at it with a TCA mindset, you immediately see how we're performing uncontrolled side effects. In a way, it makes sense. That's exactly what we wanted after all! But my fear when I was approaching this was mainly from a teaching point of view. The rest of my team was still learning the TCA, and I was afraid that looking at code like this would pollute their minds.

To cleanup this I followed a good advice and made a high order reducer explicitly for this. This high order reducer gives an explicit name to this operation, relay. Besides this, it makes the closure cleaner since the only thing it receives is the action and it doesn't have to return any Effect. This may feel like a minor detail, but making the closure look different from a normal reducer makes it more clear that what you are doing in the closure has nothing to do with TCA.

So the result looks like this:

let store = Store(
        initialState: ...,
        reducer: featureReducer.relay { action in
          switch action {
            case .someAction:
              runSomeCallback()
          }
        },
  ...

Much nicer!

Thanks to this, we can easily integrate TCA features with the rest of the application that relies in a more typical architecture.

You can read my original GitHub discussion on the topic.

RelayStore

The relay method works well when you create the store in a class (a UIViewController, a Coordinator...) but it breaks down very quickly when you want to use it in SwiftUI.

For example, if you want to use this in a pure SwiftUI App you may start with this code:

@main
struct FeaturePreviewApp: App {
    let store = Store(
        initialState: .init(),
        reducer: featureReducer,
        environment: .init(...)
   )
   var body: some Scene {
        WindowGroup {
            FeatureView(store: store)
        }
    }
}

You may wonder what's the point of this, why not use the TCA fully then. The answer is "Preview Apps". We have tiny apps that run only a specific feature. We don't want to overcomplicate the code in the app itself and we want to use a SwiftUI app since they require so little setup.

Then you may add a local state gets assigned when something happens in the feature. That local state will drive an alert so you can show that something happened on the preview app.

@main
struct FeaturePreviewApp: App {
  let store = Store(
      initialState: .init(),
      reducer: featureReducer,
      environment: .init(...)
  )
  @State var someLocalStateVariable: String?

  var body: some Scene {
      WindowGroup {
          FeatureView(store: store)
      }
      .alert(isPresented: $someLocalStateVariable.hasValue(), content: {
          Alert(title: Text(someLocalStateVariable!))
      })
  }
}

Now it's time to use the relay...

   let store = Store(
      initialState: .init(),
      reducer: featureReducer.relay { action in
        switch action {
          case let .something(value):
          	someLocalStateVariable = value // NOPE!
          ...
        }
      },
      environment: .init(...)
  )
  @State var someLocalStateVariable: String?

As soon as you try to access the local state, the compiler will complain that you are trying to access self too soon. And since this is a struct you can't use the trick of making store a lazy var.

What you need is to use the relay in the body of the View. But if you try to move the store to it, you will end up with issues since SwiftUI will recompute the body of the View and that will recreate the entire store!

   var body: some Scene {
      WindowGroup {
          FeatureView(store: Store( // store will be created on every sate change!
            initialState: .init(),
            reducer: featureReducer.relay { action in
              switch action {
                case let .something(value):
                  self.someLocalStateVariable = value // this is fine now
                ...
              }
            },
            environment: .init(...)
        ))
      }

So we need the Store as a local property but the relay on the body... what a conundrum.

The solution to the problem is what I call the RelayStore, not only is not very original but is also a bit of a lie since is not a Store 🙈.

With it, you can write exactly what you need:

@main
struct FeaturePreviewApp: App {
  let relayStore = RelayStore( // local property 👍
      initialState: .init(),
      reducer: featureReducer,
      environment: .init(...)
  )
  @State var someLocalStateVariable: String?

  var body: some Scene {
      WindowGroup {
          FeatureView(store: relayStore.storeWithRelay { action in
            switch action {
                case let .something(value):
                	self.someLocalStateVariable = value // access to self 👍
                ...
              }
          })
      }
      .alert(isPresented: $someLocalStateVariable.hasValue(), content: {
          Alert(title: Text(someLocalStateVariable!))
      })
  }
}

The trick here is that this fake store doesn't initialise the real store on the init. Instead, it just keeps the parameters (initial state, reducer and environment) as local properties. It's only when you call storeWithRelay where a real store is created, using the injected closure as the relay to extend the reducer and, very importantly, keep that real store around so is not recreated in the next refresh.

Conclusion

The TCA is superb, but it has a shortcoming when you want to observe the actions of the Store to integrate it with an external non declarative system. The relay solution is decent and I like it, but it needed a bit of experimentation and help from the RelayStore to get the polish it needed.

You can find the code for this in the RelayStore GitHub repo.

Type Inference

We know Swift is a strongly typed programming language, that means that every variable you declare has a type defined at compile time.

let name: String = "Kelsier"

The name variable has a specific type: String. But, as with any modern language, having to define the types of every single variable can be tedious and so the compiler infers the types for us.

So you can leave them out in most places:

func someAge() -> Int {
    return 1
}
let age = someAge() // inferred to be Int

The compiler can see that the function someAge returns an Int and thus the variable age must be of type Int. Something that any Swift programmer is used to.

Literals

But let's go back to the original example and rewrite it to use type inference:

let name = "Kelsier"

Now the type of name is not explicitly declared by the programmer. Which means that the compiler needs to infer it from the right side of the assignment, a string literal.

Now the type of name is not explicitly declared by the programmer. So the compiler needs to infer it from the right side of the assignment, a string literal.

And of course the compiler is going to define the variable as a String. Or will it?

The peculiarity of string literals is that they don't have an intrinsic type on their own. The context defines their type. For example, let's look at the number literals.

func iWantAnInt(_ i: Int) {}
func iWantADouble(_ d: Double) {}
iWantAnInt(42)
iWantADouble(42)

Here you can see how the literal 42 is inferred to be an Int or a Double depending on how it's used.

Expressible By Literal

Another interesting feature of the language is that it allows us to make our own types be used with literals. Every literal in the language has an associated protocol in the form of ExpressibleBy*Literal. If your type conforms to that protocol, a literal can be used to initialise it.

For example, let's make our own number:

struct MyNumber: ExpressibleByIntegerLiteral {
    init(integerLiteral value: IntegerLiteralType) {
        // ...
    }
}

func iWantMyNumber(_ d: MyNumber) {}
iWantMyNumber(42)

We can see how our type behaves the same as the standard library types in terms of inference. That's very powerful!

Default literal types

So now that we understand how type inference, let's refer to the original example again and ask, which is the type of name?

let name = "Kelsier"

For this, the language needs to base the inference in the context, and since we're not passing the variable to a function that has an explicit parameter type, the compiler must use some safe default instead. And of course, the best default for a string literal is the type String. So we have the answer!

name is of type String.

... or is it?

One of the best things about Swift's design is to have as much as possible on user land, as opposed to specifically coded in the compiler. I just told you that String is the default type for the string literal, and that's true, but that knowledge is defined in the standard library. Is not a hard-coded decision in the compiler.

So how does the standard library define the default types for literals? Look for *LiteralType. In the string case StringLiteralType is defined as:

typealias StringLiteralType = String

This means that we can define our own typealias with the same name and change the default literal in our context.

typealias StringLiteralType = MyString

struct MyString: ExpressibleByStringLiteral {
    init(stringLiteral value: String) { 
      // ....
    }
}

And now, for the last time, what's the type of name?

let string = "hola"
print(type(of: string)) // MyString

Since the compiler sees our definition of StringLiteralType (since is in the same module) from now on, every literal string in our code will be of type MyString.

Conclusion

In this post I explained a rather obscure feature of the Swift language. It's not something you will see being used pretty much anywhere, but is good to know we can change the default types of literals. It makes the language very powerful. Of course we need to be careful with over using a power, unless is to prank your coworkers for a bit 😉

Tell me, have you used this in a real codebase?

I like to do this kind of small experiments from now and then. It satisfies my curiosity, but doesn't force me to focus on a single thing for a long time. I finish it before it gets boring :) Because of this you won't see the most perfect code in here, but if you have some interesting improvements or alternative implementations share them ^^.

You can find the code in GitHub. Note that the linked tweet code uses a port of p5 for Compose. I've talked about something like this for Swift before in Processing and p5 in Swift, but I'm just using vanilla SwiftUI in this experiment.

A first idea for implementing this it’s using a Canvas view. But, for some reason I don’t remember, I opted to use views for this, although I'm pretty sure using a Canvas would be better. After all, the only layout I'm using is the VStack for the columns. I’m calculating myself the layout of everything else so I don't think I would lose much just dropping to the lower drawing level.

One of the nicest things about building something like this in SwiftUI is the TimelineView. This view recomputes the provided view, providing an up to date Date value, based on the refresh interval you specify. You don’t have to hook into any timer to do this, the view takes care of it for you. From the date, it's quite easy to get a number (TimeInterval) from any reference date. It doesn't really matter which reference you use, since the only thing you care about is to have a number that is incremented as time passes. This is very reminiscent of how game engines work.

One thing I do often when working on these experiments is to try to drive the UI from data as much as possible. By this I mean to not use view state or anything like that. It makes it easier to write algorithms to compute the UI instead of having to mess around with the views themselves. That's why I have a ColumnData struct that has all the properties from the columns that I need to render.

struct ColumnData: Identifiable {
    let id = UUID()
    let characters: [Character]
    let glyphSize: Int
    let x: Double
    let speed: Double
}

I also have a function that creates the data for all the columns that need to be rendered in a given width.

static func columns(_ proxy: GeometryProxy) -> [ColumnData] {
    let estimatedColumnWidth = 26.0
    let width = proxy.size.width
    let count = Int(width / estimatedColumnWidth)
    return (0..<count).map { i in
        ColumnData(
            proxy,
            x: (Double(i) * estimatedColumnWidth) + (estimatedColumnWidth / 4)
        )
    }
}

Well, I lied a bit. The ColumnData doesn't contain all the data needed to render the column. There are a couple of pieces that are decided on the UI on the fly, and that's because I want to change them during the lifetime of the animation.

This mix of approaches worked out nicely, but I really don't recommend it for anything serious. I'm abusing SwiftUI's lifecycle here. I generate the data inside the body function of the root view, which won't be recomputed again.

struct ContentView: View {
    var body: some View {
        GeometryReader { proxy in
            let columnsData = ColumnData.columns(proxy)
            Matrix(data: columnsData, fullHeight: proxy.size.height)
        }
        .clipped()
    }
}

Technically, this is recomputed if the window size changes. Which you can see happening on macOS.

This means that all the random generation is only run once. This makes up for the constant part of the data needed to draw the views. The part of the data that can't change during the animation. But be careful because this is relying on internal decisions of the framework. If SwiftUI recomputes bodies I'm not expecting, the data won't be stable anymore and you will see weird jumps on the screen.

The other parts, the dynamic bits that need to change, are all calculated inside the TimelineView . Things like the y coordinate of the column as shown here. Note how the x position is defined in the constant data, but the y is driven by a tick and the speed of the animation.

.offset(x: data.x)
.offset(y: (tick * data.speed).truncatingRemainder(dividingBy: fullHeight + columnHeight) - columnHeight)

Another part that changes outside the column data is the glyph. The column draws the provided list of glyphs except that sometimes one of the characters is changed for another random one. For fun.

TimelineView(.animation(minimumInterval: 0.5, paused: false)) { _ in
    let pickRandom = Int.random(in: 0...100) < 2
    Text(String(pickRandom ? glyphs.randomElement()! : character))
}

You can see how I'm using yet another TimelineView, this one with its own interval. It's quite a powerful technique to be able to compose views that have their own independent refresh intervals.

One thing that keeps getting me every time is how the offset modifier is purely a rendering modifier. By that I mean it doesn't affect the layout computation at all. It's a quick way of moving things on the screen, but if you rely on layout considering those positions, you will be in trouble.

And that's it. I just wanted to share this little and fun experiment with you. Some techniques are not desirable in production environments but they are quite fun to use in a weekend project ^^

Updated 06/01/2022: Task.sleep now respects cancellation. Improved the timeout example. Linked to Baggins package.

Cooperative cancellation

A cooperative system is one where all the involved parts need to cooperate in order to accomplish a goal. Here, the goal is cancellation, and the parts are all the async tasks involved. This means that when a parent task is cancelled, its responsibility is to tell all the children that they have been cancelled.

When a parent task does this, it sets the Task.isCancelled flag to true, and that's it! That's where the work of the parent task finishes. At this point is when cooperation is needed and is up to the children to check for that flag and stop their work early.

Note that API there is another way of checking for cancellation, try Task.checkCancellation() which will immediately throw a CancellationError up the call stack. This is a convenient way of handling cancellation if your function is already throwing.

In other words, if the child Tasks never check for cancellation, it's like the system doesn't support cancellation at all.

This is an important aspect of Structured Concurrency since it ensures that tasks are never terminated without letting them cleanup their resources and also that there is no task that is left hanging on the ether, since the parent task always waits for all children to finish.

Another aspect where cooperation is necessary is to avoid resource starvation on long running tasks. But that's a topic for another day.

Good citizens

Cooperative cancellation has its benefits, but it also means that we need to be conscious about implementing async functions that cooperate. Let's take a look at what impact it has.

I want to show you how to use the tools that Swift Concurrency gives us to implement of a couple of common requirements when dealing with asynchronous work: timeouts and races. I think they are an excellent example of how important cooperative cancellation is since this functionality relies a lot on early cancellation.

Timeout

One of the significant advantages of structured concurrency is that it provides a way to pass context down the tree of tasks. One thing that the context can help with is timeouts.

Right now that's not something that is part of the Swift's standard library, but we can imagine a function that would provide that functionality:

func withTimeout(
    _ seconds: Double,
    _ work: @escaping () async throws -> Void
) async throws {
    // ... 
}

The way I've implemented this with the existing tools is by using the Task.sleep() functionality to have a way to know when the timeout has passed. Because we need to run both things concurrently, we need to use a TaskGroup:

     try await withThrowingTaskGroup(of: TimeoutResult.self) { group in
        group.addTask {
          try await work()
        }
        group.addTask {
            try await Task.sleep(seconds: seconds)
        }
        // ...
    }

To get the behaviour we want, we add a child task to the group and another "control" task. Both will run concurrently thanks to the TaskGroup and the group scope won't end until both finish. The trick then is to have a sleep in the control task, so it ends at the moment our timeout is reached.

Finally, we just need to await for one of the tasks to finish and cancel the other one.

         try await group.next()
        group.cancelAll()

If the first one that finishes is the timeout, it means we are cancelling early that the given work function. If the passed function finishes first, then we just cancel the sleep.

Now we can use this function:

await withTimeout(5) {
    await busyWork()
}

This will make sure that busyWork is cancelled after 5 seconds if it's still running.

Cooperation

Now let's imagine that the busyWork function is not very cooperative and doesn't check for cancellation:

func busyWork() async {
    print("Starting busyWork")
    for i in 0...100 {
        print(i)
        await nonCooperativeWork()
    }
}

As you can see, this function doesn't check for cancellation, and if we assume that nonCooperativeWork doesn't check either, we have a dangerous scenario for cooperative cancellation. Running this will cause the following output:

Starting busyWork
0
...
5
cancel finished first
6
...
// until a 100!

This is not ideal. So let's make sure our function checks for cancellation when appropriate:

func busyWork() async {
    print("Starting busyWork")
    for i in 0...100 {
      	// Let's check for cancellation on every iteration
        if Task.isCancelled { return }
        print(i)
        await nonCooperativeWork()
    }
}

Now, if we run this, we see that the timeout has the effect we desire:

Starting busyWork
0
...
5
cancel finished first
Program ended with exit code: 0

I hope that this illustrates the importance of being a good citizen in a world of cooperative cancellation.

Note that this is a very simplistic implementation of the timeout. To start, a real implementation would let you return a value from the closure, but besides that it would handle edge cases and inheriting the timeout through the call stack. You can see my implementation of it in Baggins/Concurrency.

Race

Let's try another example to illustrate a bit more how important this is. Imagine that we want to implement a race function. A function that given a couple of async functions runs them both concurrently and returns the result of the first one, cancelling the other because it lost the race. This is a very common operation, for example, if you want to show something to the user and you don't care if it's from a local database or a network call.

func firstOf<R>(
    _ f1: @escaping () async -> R,
    or f2: @escaping () async -> R
) async -> R {
    await withTaskGroup(of: R.self) { group in
        group.addTask {
            await f1()
        }
        group.addTask {
            await f2()
        }
        guard let first = await group.next() else {
            fatalError()
        }
        group.cancelAll()
        return first
    }
}

As before, we use a TaskGroup to run the two functions concurrently and respecting Structured Concurrency. The only difference is that the function that we are running now is not our own timeout, but a passed in function. And we just return the result from the first one that finishes.

You can see how this works very well if the given functions cooperate for the cancellation. Otherwise, even if one wins the race, everybody needs to wait for the others to finish. Which may be nice in a real world race, but definitively not what we want in our programs.

It may be interesting to have a select operation that works with unstructured concurrency and leaves detached tasks dangling.

Standard Cooperation

One thing to note is that in these examples, it seems quite tiresome that we need to be checking for cancellation ourselves all the time. And that if we forget, the system won't behave as desired. This is true, but in reality it is less of an issue that it may seem.

In this toy example, we were just performing an iteration without really calling any system function. So it makes sense that the responsibility is on us. But in real code, it is very likely that you always end up calling a system function, and is expected that those functions handle cancellation properly. That said, if you are building some library of async functions, make sure you respect cooperative cancellation too.

Task.sleep

Task.sleep respects cooperative cancellation. That is, it will throw a cancellation error and finish early if its current task is cancelled.

During the initial betas of Swift Concurrency, Task.sleep was non-throwing, and it didn't cancel early. I personally raised this in a WWDC Lab and in the forums. It got fixed before the official release.

URLSession

The new URLSession async functions follow cooperative cancellation and as soon as the Task is cancelled they also cancel the underlying request. This is very nice since is probably one of the major use cases for async that people will use.

Conclusion

I hope you understand a bit more how cancellation works in Swift Concurrency. I don't think you should worry about it too much since the system frameworks will handle that, like the URLSession case, but it is still important that we all have a clear picture of it so the packages we create behave nicely on the wider ecosystem.

Note that SPM may have soon a way of creating packages from templates. That's not what I'm talking about here but it will be an even better addition to our toolbelt. See the pitch for a package creation command.

Package Collections

A package collection is nothing more than a json file describing a collection of packages. SPM interprets those and they are stored locally on your computer so it's easier to add packages from those collections into your projects.

This new feature came trough Swift Evolution in SE-0291. The nice thing is that not only SPM supports it but Apple also added integration directly into Xcode!

Xcode comes with a default collection containing all Apple's Swift Packages. Many of them feel like part of the standard library so it's very nice to have them available with just one click.

One click?

Yes, because Xcode now can offer a fix-it when you are trying to import a module, and if the module is in a collection you are just one click away!

Author collections

The folks at the Swift Package Index have just released their first feature using the new collections: Author Collections. That is great for adding collections from your favorite authors.

Of course the first thing I did was to add the collection from pointfree!

Your own collection

But since a collection is just a JSON you shouldn't be afraid of having your own. And that's the nice thing about this. I think that making and maintaining your own collection is great for helping your future self bootstrap new projects and packages easily!

I recommend you to watch WWDC21 Discover and curate Swift Packages using Collections for a great introduction and step-by-step guide on how to do it. Is very easy!

Just use the generator to convert a simple JSON to the expected format. Look at my input.json as an example:

{
    "name": "Alexito's favorite packages",
    "overview": "This collection contains my favorite Swift packages.",
    "keywords": [
        "favorite"
    ],
    "packages": [
        {
            "url": "https://github.com/nicklockwood/SwiftFormat.git"
        },
        ...
    ],
    "author": {
        "name": "Alejandro Martinez"
    }
}

You can specify more things on the JSON but if you pass a GitHub --auth-token to the generator it will automatically get all the information that it needs from every repository. I find that very convenient.

Once you have your output json you just need to host it on some server. A GitHub repo is good enough for your own use.

Mine is already on GitHub: Alexito's favorite packages. This will make it easier so much easier to import the packages that I need when prototyping ideas.

Now it's your time! Go, create and share collections of your favorite packages!

One of the things that I was not sure about is how the frameworks will integrate with certain aspects of the concurrency story. Things like how the UI frameworks would integrate with Global Actors were very clear, but how things would integrate with Structured Concurrency was still a question mark.

Lately I've been looking a lot into Kotlin's decisions and how they compare with Swift's. And one thing I'm was not sure is how nice it would be to work with "coroutine contexts" in Swift. Well now at least we have an answer on how SwiftUI is doing it.

Scopes

Up until now the best thing you could do was to start gathering the data for your view with .onAppear. That was a fine way of hooking into the view's lifecycle but once you have Structured Concurrency that's not enough.

To follow the rules of Structured Concurrency your async task must run in a defined scope. In small sample code that scope is defined statically by your source code.

func someAsyncFunction() async {
    await longRunningTask()
}

longRunningTask lives in the scope defined by someAsyncFunction and ties both functions together. The latter won't outlive the former. If the parent function is cancelled it will cancel the child and wait for it to finish. That's Structured Concurrency in a nutshell.

But in a context of a UI app, there is a runloop going. The scope is not as static as our source code. So, how can we attach tasks into a view lifecycle and ensure that when the view goes away all its linked structured tasks go away too?

SwiftUI lifecycle

SwiftUI introduces a new view modifier called .task. In its closure you can start async work that will be linked to the view's lifecycle.

struct DetailView: View {
    @State var list = Array(1...10)
    var body: some View {
        List(list, id: \.self) { n in
            Text("-> \(n)")
        }
        .task {
            await longOperation()
        }
    }
}

This means that the longOperation will be implicitly cancelled if the DetailView goes away. No need to manually manage its lifecycle, or store cancellables so ARC can do it for you. Nope! Structured Concurrency takes care of everything! 🎉

Other SwiftUI callbacks

One thing you need to be careful is that other callbacks like .refreshable don't seem to follow the rules of structured concurrency very well. In this case the refresh control will wait for your task to finish, but it won't cancel it if the view goes away.

I have an open radar about this: FB9139963

Conclusion

Structured Concurrency is a clear improvement to the current status quo of concurrent programming. It's not just about the nice async/await syntax, but about the structure that brings into asyncronous programming. I'm very happy to see SwiftUI offer some affordances for this style and I hope we see all frameworks do the same.

As a general sentiment I don't think this has been a WWDC with a lot of new and revolutionary things. It for sure seems like a year of refined, and that's welcomed! That said the more sessions I watch the more little nuggets I find that are a big deal. Check out my raw session notes to keep up with that.

Did my wishes come true?

First, let me talk about the first impressions I had after the keynote and the SOTU. All that matters at that point is if you got what you were wishing ^^

As expected the more revolutioanry thing this year it's Swift Concurrency. As I said, this was not new, thanks to Swift Evolution I already knew it was coming and spent the recent weeks fully focused on that. I learned a lot, made videos about it and tried many things. I definetly feel like I was ready for it. What is very fun is to see the rest of the community being so excited about it!

It feels like I can finally share with everybody an awesome toy that I've been playing with for a while. ❤️

It's not with a mix feeling if I'm honest. Now that Apple has done official documentation and amazing sessions, is inevitable that my content will become obsolete. Especially when every other content creator will be focusing on that topic. But it's also true that I don't mind very much (a little, yes, for sure) because I do share my knoweldge because I love doing it! I love making those videos explaining technical details that probably nobody else cares about. That's my jam!

We didn't see any System Themes like on Android. It would have been a huge change for iOS so I'm not surprised it's nto here this year.

What is a bit more unfortunate is to not have a Core Data replacement. I know this is not very likely since Core Data is battle tested and ditching it entirely would be a mistake, but some improvements to make it feel right at home in Swift are really needed. Anyway, in the wishlist for next year ^^

We got Xcode CI! That's a positive one. Although I'm still hesitent about its utility and scared about Apple monopolising this sector with their strict rules. Right now the CI industry for mac is kinda screwed, and that just affects developers like us. We'll see how this develops. But not only that, the new Xcode has many cool new features! Although I still wish they ditched the project file.

SwiftUI has tons of very welcomed improvements (see my raw session notes for a list). I'm very excited for the new possibilities and to get used to the refinements very quickly! Sadly there is still no guidance on navigation architecture. And every year that passes it becomes more and more necessary. With the amount of system technologies taht rely on deep linking into your app it feels like Apple is droping the ball here.

So besides the CI I don't think any other wish has been granted ^^'

Let's keep a list for next year!

• Navigation architecture - Better deep linking integration
• CloudKit functions in Swift
• SwiftCore
• Scripting with Swift
• Custom Watch faces
• Custom View Controller and Non-UI Extension Providers
• Custom View Controller and Non-UI Extension Providers
• More control on App version updates

Note that I haven't taken many notes about concurrency because is a topic that I'm already well versed since it was avilalbe for months thanks to Swift Evolution. If you want to know my take on that watch my Concurrency talks.

I will keep updating this notes as I watch more sessions.

Updated: 2021-06-09

Swift

• #if ... #endif can now surround explicit member expression suffixes. (51690082)
• You can now apply property wrappers to function and closure parameters. (SE-0293, 66866426, 78029226)
• Xcode has a new Optimize Object Lifetimes build setting, under Swift Compiler - Code Generation. Enabling this performs more aggressive ARC optimization and shortens object lifetimes, which can help reduce the memory your app uses. This option also helps you find bugs where code makes invalid assumptions about object lifetimes.
• The lazy keyword now works in local contexts. (78028578)
• Whenever a reference to Self doesn’t impede the usage of a protocol as a value type, or a protocol member on a value of protocol type, the same is now true for references to [Self] and [Key : Self]. (78028842)
• It is now possible to use leading-dot syntax in generic contexts to access static members of protocol extensions where Self is constrained to a fully concrete type. (78029041)

Apple Packages: ![[apple swift packages.png]]

Static linking on Linux, good for server apps. Better JSON performance on Linux. Better AWS Runtime lambda performance.

Concurrency

• Apple Developer Documentation
• Concurrency in Swift 5 and 6 - Discussion - Swift Forums
• Maybe it will be backwards deployed?!?!?! Swift Concurrency: Feedback Wanted! - #6 by tkremenek - Discussion - Swift Forums
• Integrated with [[#SwiftUI]] callbacks
  • .task modifier is a task linked to the view lifecycle.
    • use for in here and you have a lot of the things you want from Rx/Combine for free!
  • but the refreshable doesn't follow the lifecycle.
  • BUT CANCELLATION DOESN'T SEEM TO BE TIED TO THE LIFETIME!
  • SDK changes!:
  • UIImage thumbnails
  • URLSession
  • URL line by line
  • FileHandle.bytes
  • NotificationCenter
  • Core Data
    • await context.perform
    • but still, that makes it dangerous to return managedObjects.
    • MainActor.run {} is useful if you want to group multiple calls to the main actor without suspending (await) in between them. Types of concurrency with tasks. ![[Screenshot 2021-06-08 at 18.00.45.png]]

Integrated with XCTest.

SwiftUI

Building a Great Mac App with SwiftUI Add Rich Graphics to Your SwiftUI App

• TimelineView
  • Schedules updates to your view automatically (outside of State changes)
  • Periodic
  • Explicit
  • Animation framerate
  • Custom
  • AsyncImage AsyncImage | Apple Developer Documentation
  • Focus areas, FocusState
  • can be a boolean for 1 case
  • or a hashable (enum) to pick which area to focus on
  • Table
  • Canvas
  • Material
  • use them as background so the content on top takes the correct vibrancy to be legible.
  • Lists:
  • swipe actions
  • Pull down to refresh Apple Developer Documentation
  • Swipe actions Apple Developer Documentation
  • separators
  • ScrollView.safeAreaInset modifier to keep the scroll inside the safe area but let the content be visible outside the area.
  • content is passed in the closure of the modifier.
  • badge
  • .searchable
  • is passed trough the environment, if no view does anything with it, defaults kick in
  • NavigationView puts the searchbar in the navigation bar
  • Environment .isSearching to show results.
  • Use an overlay to show the results so the list behind stays there.
  • optional viewbuilder closure to offer suggestions
    • searchCompletion modifier handles the typical case by converting a non interactive view into a button and changing the searchable text to the suggested.
  • use .onSubmit(.search) {} to perform the search when the user submits the search query.
  • Landscape previews
  • [[#SF Symbols 3]]
  • Default set colors
  • Accessibilty:
  • Rotor:
    • header: from Section or with accessibilityAddTrais(.isHeader)
    • custom rotors: for example if a visual user can see icon alerting on each cell, a blind user would have to go to each cell to know if there is an alert. instead make a custom rotor that goes trough the alerts only.
  • .accessibilityRepresentation use the accessibility representation from one view to define the accessibility of another.
  • .accessibilityChildren modifier to convert a accessibility view into a container with children.
    • nice trick to use a shapes (rectangle) with accessibility
  • accessibilityEleemnt(children. contain) in horizontal carousel of cells, the reading order is top-left -> bottom-right so it would read all top views, then go down to the next element. instead you can mark each "cell" as a container so it reads an entire cell first instead of going to the next. need to understand the id of a view, and use namespace if there is mulitple views with the same id.
  • accessibilitySortPriority(-1)` to read a view last
  • accessibilityElement(children: .combine) to make the entire cell 1 single element, keeping the chidlren's properties.
  • ![[accessibility child behaviour.png]]
  • accessibilityFocusState to control programatically the focus of voiceover
  • better performance on macos
  • Debugging helper: > https://twitter.com/luka_bernardi/status/1402045202714435585 > Call `Self._printChanges()` inside the body of a view to print out the changes that have triggered the view update.
  • Text
  • now supports Markdown strings.
  • with custom attributes in the markdown
  • tapable links
  • dynamicTypeSizes to restrict the range .
  • textSelection modifier to allow it
  • date.formatted()
  • person.nameComponents.formatted() and support for textField bindings too.
  • TextField
  • prompt
  • onSubmit
  • submitLabel
  • ToolbarGroup placement: .keyboard
  • Button
  • .bordered style on iOS!
  • .tint
  • .controlSize (large gives you the typical full with buttons)
  • .controlProminence
  • role: .destructive
  • Confirmation dialogs
  • menuIndicator(.hidden) to make Manu buttons (dropdowns) appear as just a normal button.
  • Menu primary action to allow a one click action, with a context menu as a secondary action.
  • Toggle .button style to make a button that toggles.
  • ControlGroup groups related controls.
  • Core Data fetch request property wrapper now gives binding to sort propery.
  • Core Data sectioned fetch request.
  • importItemProviders modifier to accept data from other apps.
  • exportItemProviders modifier to share data from your app. Nice to integrate it with shortcuts!
  • Mac: ImportFromDevicesCommands() as commands in the window group to add functionity to get images from an iPhone.
  • privateSensitive to redact UI when in private modes like watch always on mode, or widgets on the lock screen.
  • Accessibility modifiers visible in the Xcode inspector.
  • Accessibility preview tab.

Thanks to property wrappers in function parameters we can pass a binding to an array in List and ForEach.

Widgets

New extra large size for iPad. Donate to the system so it can show the widget to the user on smart rotating stacks:

• INRelevantShortcut, from the app, to suggest a widget
• TimelineEntryRelevante, from widget extension, to rotate
• INInteraction, from the app, to suggest and rotate

SharePlay, GroupActivities Framework

Activities. CoreMedia + Group Activities coordinate the video playback across all devices. It plays locally on your app on everybody's device. Based on URLs/Deeplinks. Reliable Data channel, e2e encrypted. For any kind of experience, realtime.

iPad Swift Playgrounds

...

UIKit

• UISheetPresentationController Apple Developer Documentation UITooltips
• keyboard layout guide Apple Developer Documentation UIImage resizing thumbnail creation.
• bars are now transparent. if is not appropiate make a custom barappearance.
• vc.setcontentscrollviewforedge lets you tell uikit which scroll to handle.
• New UIList
  • lists styles: prominentInsetGrouped and extraProminentInsetGrouped for lists with rich content so headers are not lost.
  • separator configuration
  • DatePicker wheel is back, but can type on the dates.
  • Button
  • New configuration API
  • popup and pulldown menu buttons
  • Button now supports multiple lines of text.
  • subtitle configuration property.
  • setNeedsUpdateConfiguration with the configuration closure to update the button. button own properties (highlight) will call the closure automatically.
  • incorporated activity indicator!
  • toggle buttons that keep the selected state. changesSelectionAsPrimaryAction = true
  • pop-up buttons (similar to pull-down buttons with showMenuAsPrimaryAction) but with only 1 selection. works via menus by adding changesSelectionAsPrimaryAction. pre assign the default by setting state: .on in the UIAction.
  • cells and buttons configuration can be applied with a closure based api. no need to subclass cells anymore.
  • [[#SF Symbols 3]]
  • restrict dynamic type sizes.
  • system colors are the same on all platforms.
  • CoreLocationUI
  • Scenes:
  • saving state by giving a user activity to persist
  • and with a new delegate method to restore.
    • can request some extended time to perform async restoration. but don't use this for long tasks like api requests!
  • textField and textView have a interactionState property that gives you the restoration state of the field, but not the text content.
  • uiscene "share this" api
  • iPad center prominent scene like mail.
  • ActivationAction to put on menus and AcitvationInteraction to put on cells or views do use the gesture.
  • customise the preview by giving it a view
  • use QLPreviewSceneActivationConfiguration to use a system provided preview scene.
  • iPad Keyboard support has many improvements for menu and shortcuts.
  • automatic localisation for shortcuts
  • iPad: uibandselectioninteraction (drag a rectangle to select multiple things). automatic support on non-list collection views.
  • iPad pointer:
  • accessory vies that follow the pointer.
  • latching axis so the pointer stays transformed when the view is moving.
  • UIFocus system across all platforms.
  • reconfigure cells without recreating them
  • > https://twitter.com/smileyborg/status/1402056034416398338 Do you use diffable data source? > If so, there are some big changes in iOS 15: > - applySnapshot(_: animatingDifferences: false) now diffs & only performs minimal updates to UI > - New API applySnapshotUsingReloadData if you want reloadData > - New API to efficiently reconfigure items! > Generally speaking, you should continue to use applySnapshot() — whether animating or not — whenever possible, and avoid using reloadData (as that's a big hammer that resets everything, it throws away all your existing cells and more). > But there are some cases where reloadData does make sense, e.g. if you are applying a completely different set of data, or recycle the collection/table view for use on an entirely different screen, or have a huge set of changes and want to skip diffing/updates. > You might find that this behavior change for animatingDifferences:false exposes some issues.The simple quick fix to get the old behavior back is just to use applySnapshotUsingReloadData instead of animatingDifferences:false.But, be aware that may just paper over real bugs. > @jesse_squires Before iOS 15: animatingDifferences:true --> diff + updates (animate) animatingDifferences:false --> reloadData iOS 15: animatingDifferences:true --> diff + updates (animate) animatingDifferences:false --> diff + updates (no animation) applySnapshotUsingReloadData --> reloadData
  • collectionview prefetch changes?
  • drag and drop across apps works on iphone.
  • Location button
  • doesn't ask permission, is a one time only thing
  • customise look
  • ios ensures is always visible and can be used to trick the user
  • The pasterboard banner won't appear if it comes from a user command or if they come from standard paste acitons: paste, paste and go, paste and search, paste and match style.
  • pasteboard data detectors.
  • don't gran access to the data but tell you if it could be a type of data you are interested in.

Xcode

PR comments inline the code. Vim mode Run tests repeatedly to find issues. Better diff and code review Crashlogs into the Organiser in minutes, with user comments in crash reports. Cloud signing based on keys stored in connect. Editing:

• Auto import frameworks as needed
• if let name = name auto completed.
• suggestions go inside intermetiate objects. text.corn -> text.layer.cornerRadius
• switch cases autocompletion without having to click on the fix it.
• for X in array automaitcally gives a singlar name to X based on the array.
• expansion of multiple closures follows the nice new syntax. Column breakpoints, nice to stop only inside a closure.

With package collections Xcode can find modules you want to important and show them so you are one click away.

Alternate app icons in the asset catalog. You can now use platform filters in build phases and target dependencies for all supported platforms.

Instruments

• Analyse network traffic

DocC

Build, view and share documentation for Swift packages using DocC. Documenting a Swift Framework or Package | Apple Developer Documentation The documentation works in Xcode doc viewer and as a web page. Add extra pages like index, articles and even tutorials. Xcode's Quick Help now uses DocC to present project documentation and renders links to your project’s documentation in the documentation window Open sourced later this year.

Xcode cloud

For all Apple platforms. Paralleized testing Static analysis Build results and screenshoots in Xcode and App Store Connect. Auto deploy to testlfihg REST apis. Code signing automatically handledssxx. Needs changes to support Cocoapods, a build script. Seems like there is no way to customise the execution, it only runs Xcode stuff. But if you have them in Git is fine. Apple Developer Documentation

iOS

iOS 15 doesn't drop any device! https://twitter.com/JoshHrach/status/1401986459645530114

JSON5 supported, so Comments in JSON!

Foundation

-Attributed String value type to Apple Developer Documentation - with Markdown support! - full Swift, doesn't rely on NSAttributedString https://twitter.com/jmschonfeld/status/1402038729850585090 - supports attributes and even user defined ones Apple Developer Documentation - compatible with Swift String counting - fully localizable - AttributeContainer to hold attributes without the string - Scopes to securely define what attributes are accepted.

• New formatting API!
  • extensions on Date, Numbers...
  • so no more worry about creating custom formatters and cashing them!
  • get an attributed string so you can customise parts of it!
  • the same formats are strategies to parse dates. custom strategies use string interpolation
  • Morphology
  • System wide user's pronoun.
  • Grammer engine to Expand loaclisation with plurals, gender, et
  • JSON 5 support
  • comments

Notifications

Focus Notifications different alert levels:

• passive: silent, don't awake the device.
• active
• - time sensitive: skips the summary, stay a bit longer, siri speaks it out loud on headphones
• critical: health concerns, requires entitlement.
• message / call Notification summary:
• what shows up is based on relevancy, thumbnail size, amount of notifications... but untimely is user customized.

SF Symbols 3

SF Symbols - Apple Developer 600+ new symbols new color rendering modes workflow optimisation custom symbol improvements more localisation options

• variants (fill) will automatically be picked by swiftui (tabs filled on iOS but outlined on macOS)
• hierarchical: monocrhome but with multiple levels of opacity
• palette: customise the colors of each layer pick styles programatically

WatchKit

MailKit

TextKit 2

TextKit 1 it's there since the NextStep days. TextKit 2 still leverages Foundation, Quartz and CoreText.

• Correctness: abstract away glyph handling. Necessary for international text.
• Safety: value semantics (immutable classes)
  • Element: paragraph, attachment, custom!
  • Performance: viewport-based layout and rendering
  • Non contiguous text layout. More performant for large documents.

ShazamKit

ShazamKit Audio recognition for our Apps, not only Music. Matches audio to an existing catalog. Is not Sound Analysis classification, use ML for that.

• Shazam catalog recognition: for song identification.
• Custom catalog recognition: device matching of arbitrary audio.
• Library management

HealthKit

• Move minutes
• Alcohol consumption (number of drinks)
• Pregnancy tests
• Walking steadiness

AR

Creating 3D Objects from Photographs

Metal

...

Game

New game controller HUD

Screen Time API

100% Swift and SwiftUI code. Parent control apps: needs Family Control capability. Only works on a child's device.

• Managed settings: access to the same restriction that Screen Time has.
  • restriction of apps, custom branding screen when locked.
  • limit access and provided custom actions.
  • Family controls: authorization.
  • allow parents to chose the apps for the kids
  • the app doesn't get the bundle IDs, just tokens, so only the parents know which apps are
  • Device activity: usage.
  • with the tokens from the family controls.
  • register time windows and completion events so your app can react, sending alerts or blocking apps.
  • system calls your extension.

Shortcuts

On mac. Imports Automator flows. Supports shell scripts and applescript. Uses siri intents like in iOS. Exposes a CLI and scripting interface, with ScriptingBridge framework you can run shortcuts from an app. Sharable via files.

![[types-nouns-actions-verbs-intents.png]]

Intents should be:

• Useful
  • Handles a task
  • Not too immersive
  • Repeatable
  • Modular
  • Composable
  • Useful standalone
  • Customizable with parameters
  • Offer outputs so shortcuts can be build
  • Useful ones: Create, edit, delete, get, pick a thing, open app
  • Multimodal:
  • Compatible with UI and Siri
  • Configurable in editor
  • Visually represented in snippets (siri UI)
  • Clear (in the editor)
  • summarised in a sentence
  • consistent between suummary and title
  • include default values
  • Discoverable
  • icloud links
  • add to siri

App Store / StoreKit

StoreKit 2 introduces a modern Swift-based API that takes advantage of new language features like Swift concurrency. Use this API to load product information, display in-app purchases in your store, allow customers to make purchases, manage access to content and subscriptions, and receive transaction information signed by the App Store in JSON Web Signature (JWS) format

Other

Human Interface Guidelines with Inclusion in mind Inclusion - Technologies - Human Interface Guidelines - Apple Developer

But it has hooked me up. There are so many interesting conversations and so much to learn! I've written a big number of notes about the topic and decided that it was worth making a video series to help the community understand what really Swift Concurrency entails.

That's what this series of videos is trying to do. I explain to you parts of the Concurrency story, making it clear how they relate to each other. Some of these concepts can be quite new to a lot of developers so you will also find the theory and story behind them. As always, my goal is not to make tutorials, but to explain to you what things are and why they are how they are. To give you the tools so you can dive deeper into those topics. I just want you to be ready for when all of this lands officially into the language. The Swift programming language inspires these videos, and the examples use it to drive the point home. But the theory and principles widely apply to any other programming language. So I hope that this helps other communities too.

First look at async await

This first video serves as an introduction to the whole Concurrency story, focusing on the new keywords, what they are and what they are not. I also explore how we can bridge between an existing callback system and this new world of async functions, and how this will affect our codabases.

Actors

This second video is fully focused on the Actor System. This system is not new, but is not very well known either. That's why I thought it would be very good to explain what Actors are, what's the theory behind them, what problems they solve and what things we need to be careful about.

Structured Concurrency

Structured Concurrency is the underlying topic that pulls the entire Swift Concurrency story together, it brings very important fundamentals that help design the rest of features. But is not something that the everyday programmer has heard about. This video goes into the story and theory behind it, hopefully making it clear to everybody why Swift is going in this direction.

AsyncSequence

AsyncSequence is a new protocol that aims to cover those cases were we need more than one value to be computed asynchronously. This will remind you to RxSwift and Combine and that's because the principles behind it are the same. How will this be integrated with those frameworks? All of this and more in the video!

... more

Right now these are the four videos of the series. I have a couple of more drafted but with WWDC21 approaching fast I'm not sure I will have enough time to finish them.

If there is any interest in other concurrency topics, feel free to reach out :)

To make a preference you need to create a type that conforms to PreferenceKey. That can sometimes get repetitive but today I don’t want to solve that part. The bit that bothers me more is what comes next. With that new type written you then start a dance of boilerplate that gets boring very quickly. Let's explore how we can make our lives a little bit easier.

Reading a preference

The first thing you need to do is make the child view write to the preference.

childView
	.preference(key: MyPreferenceKey.self, value: value) }

This will make value available to the parent views. Next step is reading that, and it’s where the boilerplate gets too much repetitive for me.

@State private var childValue: String? = nil
var body: some View {
    VStack {
        Text(childValue ?? "")
        MakeChildView()
            .onPreferenceChange(MyPreferenceKey.self) { value in
            		childValue = value
        		}
    }
}

Declare a @State property to store the value read from the preference, use a onPreferenceChange modifier that needs the type and a closure. A closure that it's usually doing the same thing: storing the read value into the state property.

This API is very flexible. If you are doing something different on that closure every time it makes sense to use it, but most of the time we just need to mutate some local state to trigger a redraw. In that case, the API turns out to be too flexible.

So... what if we could simplify this a bit?

Reducing this boilerplate to the core of what we need is really easy. We just need an alternative method that reads the preference and stores it directly into the property that we want. Thankfully doing that is very easy.

extension View {
    func readPreference<K>(
        _ key: K.Type = K.self,
        to binding: Binding<K.Value>
    ) -> some View where K : PreferenceKey, K.Value : Equatable {
        onPreferenceChange(key) { value in
            binding.wrappedValue = value
        }
    }
}

With this we can rewrite the previous code to get rid of the closure.

@State private var childValue: String? = nil
var body: some View {
    VStack {
        Text(childValue ?? "")
        MakeChildView()
      			.readPreference(MyPreferenceKey.self, to: $childValue)
    }
}

The new modifier reads very nicely and does its job without asking us for custom logic every single time. Note how the method accepts a binding, which means we could use other things to store the preference other than a state property.

Conclusion

As you can see, there is nothing revolutionary in this idea. Is just a simple method extension that implements a default behaviour. But that's the whole point that I wanted to transmit. Sometimes we get stuck into repeating the same boilerplate over and over without realising that it's very easy to get rid of it. Specially when the code is well architectured and the language provides you with the right tools.

This is not the only place where a small amount of boilerplate shows up when writing SwiftUI. With this post I want to show how reducing it is not very hard thanks to the architecture and the language. So keep an eye open and build your own library of little modifiers that get rid of the boring parts!

Dictionary literals

One place where we've grown accustomed to a nice and simple syntax is literals. You can create a dictionary literal with keys and values easily. If you don't have experience with other languages, you may not realise how nice it is.

[
    "key": value,
    "hello": "world"
]

But often you may need to only add keys to the dictionary based on some condition, like if the value is not nil. And when that happens, the literals don't make the cut anymore.

You need to start using the Dictionary API to add values after its original creation. But that means that you need to have a variable to mutate. And not only that, but now you need to put the constant values on the literal init and anything that requires logic after that. This is quite annoying when you want to define the dictionary with a specific order to make it easier to read.

var dictionary = [
    "key": value
]
if let welcome = optionalMessage {
    dictionary["hello"] = welcome
}
...

Of course, this is not a big deal with such a simple example. But in reality, the function where this code lives is probably more complex and having to keep a variable just for this adds extra complexity. What if we could just make the literal initialisation support conditions?

Result builders

Result builders is a Swift feature introduced by SwiftUI and officially added to the language on Swift 5.4. I talked about it in the context of the SwiftUI DSL but also as a deep dive on result builders feature on itself. Because this feature is much more than just an implementation detail of SwiftUI. It allows us to make very nice DSLs.

People in our community always have a tendency to look bad at these more advanced, Swift features. This one specifically is always countered with the question of what utility does it have outside SwiftUI. And it's true that the typical examples are all about a very similar use case, like building HTML. But there are other interesting applications of it and the one I'm proposing here is not even to improve a separate framework, but the language itself. You can't get more useful than that!

DictionaryBuilder

Let's build a result builder that helps us make dictionaries. And the nice thing is that is pretty easy.

I won't go into much detail of how Result Builders work. I recommend you to watch my deep dive video to get a better understanding.

@resultBuilder
struct DictionaryBuilder<Key: Hashable, Value> {
  ...
}

To start, we just define a type and annotate it with the special attribute @resultBuilder. This tells the compiler that this type can be used as an annotation of its own to enable the special DSL syntax in the body of a function.

Then we need to make the builder do something useful. We do this by adding special functions.

static func buildBlock(_ dictionaries: Dictionary<Key, Value>...) -> Dictionary<Key, Value> {
    dictionaries.reduce(into: [:]) {
        $0.merge($1) { _, new in new }
    }
}

This will make the builder accept dictionaries. But with this we gain very little. We could merge multiple dictionaries easily, but that's not our goal. To support conditionals, we need to add another special function.

static func buildOptional(_ dictionary: Dictionary<Key, Value>?) -> Dictionary<Key, Value> {
    dictionary ?? [:]
}

With these two simple functions, we have unlocked a huge potential of this feature. There are way more things a function builder can do but for now lets stick to the scenario that we want to solve.

Using the new builder

Now we have a new annotation available: @DictionaryBuilder<Key, Value>. To use it one approach is to make a new Dictionary initialiser that let's use use this new DSL.

extension Dictionary {
  init(@DictionaryBuilder<Key, Value> build: () -> Dictionary) {
      self = build()
  }
}

This is quite simple. The only thing we're doing is to mark the closure parameter as a builder. This indicates the compiler that the body of that closure will have super powers.

let dictionary = Dictionary<String, String> {
    [
        "id": "1",
        "name": "alex",
    ]
    if let welcome = optionalMessage {
        ["hello": welcome]
    }
    [
        "more": "values"
    ]
}
...

This allows us to use a let, which simplifies our code. It also lets us mix literal dictionaries with keys that require some logic, which lets us keep the order of the keys like we want it. This may seem like a trivial thing, but in some occasions it helps tremendously to improve the readability of the dictionary construction.

But there is another way of using the builder. If you have watch my AnyView vs. @ViewBuilder video you probably know what I'm talking about. The dictionary initialiser is very useful if you are in the middle of a bigger function, but if your function is just there to return the resulting dictionary you can't skip the initialiser altogether and use the DSL directly!

@DictionaryBuilder<String, String>
func makeMeADictionary() -> Dictionary<String, String> {
    [
        "id": "1",
        "name": "alex",
    ]
    if let welcome = optionalMessage {
        ["hello": welcome]
    }
    [
        "more": "values"
    ]
}

Conclusion

We have seen how this Swift feature is not only there to make SwiftUI nice to use, but it can unlock a huge potential to improve our code. DictionaryBuilder is not just making the syntax nicer, but is helping to make our code easier to understand thanks to avoiding variables and letting us define the keys in the order we want.

And this is just the tip of the iceberg. Function builders are even more powerful than this, and I'm sure we will find more incredible applications. I think we need to stop complaining about the complexity of new features as long as the learning curve is not impacted. Some of this features are crucial to make Swift a better language and even to simplify the barrier of entry. Keep your mind open folks ;)

You can find all 13 videos on my Apple's SwiftUI tutorial playlist. You can start watching the first one to know what was my purpose with these videos.

When I started doing the tutorials, I already knew SwiftUI. The framework is still young, so I'm by no means an expert, but I've been working with it since its release. So I was not going with the mentality of learning how to build an app. My intention was to take an analytical approach at the tutorial to know how good it is and if I would recommend it to others.

During the series, you can see me complain about some details and praise other decisions. I'm well aware this is not entertaining for everybody, but I find this kind of content very interesting, so it's what I want to create. I find really enjoyable watch other people's mental process, it’s the best way to learn!

If you are even just a bit like me, I recommend you watching the videos, but if you just want to know how good are the tutorials from my point of view, you can just skip to the last episode.

Overall, I'm thrilled with the series, specially because now I have a better idea of what to answer when people ask me what to do to learn SwiftUI.

Yes, I know that's now what the title of the video says. But I think there is not very much to take out from that video about federation. They mention a bit about organisation structure, but nothing that caught my attention. Instead, there are some important things to learn about modeling and designing systems.

Let me share my experience and views on the topic.

Modeling

At Lifeworks we've been using GraphQL for over two years now. So one could say I have a bit of experience with it. During all this time there is one thing that just keeps coming back: the most important part of GraphQL is knowing how to model your domain.

Seems quite obvious, right? After all, you are defining a graph of entities for your domain. But often we get lost in other more fancy things like how nice is having a schema for your API, types, an amazing cache, subscriptions, etc. But none of that matters if your schema design is not ideal.

If you want to focus on something important, that will help you be good at GraphQL, my advice is to learn how to model domains. It’s not specific to GraphQL, but is a skill that often developers ignore. Luckily for me I had excellent teachers at University that reiterated the importance of it.

The nice thing that is discussed in the video is about understanding that the graph is something that can evolve. And I agree with that sentiment. Defining your graph is an iterative process that benefits from experimentation. You don't have to be afraid of taking some decision that is now correct for your product and later deprecate it and evolve it in another direction. That's a nice thing about GraphQL, it understands deprecations. This is often important if you're trying to sell managers on GraphQL. It's likely that it involves a migration and you can't "stop the press" for it. So focus on delivering value and do a migration bit by bit.

This is how we did it at Lifeworks. We started our schema as a proof of concept for a new and shiny new feature. After that we started migrating the rest of features that are related to the first one (they belong to the same feature team). And nowadays we are undergoing a migration of the rest of features using Federation.

Being able to do it bit by bit and keep growing the schema is important. But this shouldn't be used as an excuse to have a poorly design graph. Think about it properly and try to do it properly sooner rather than later. Make every step a correct step. Yes, you can deprecate things and perfect it over time, but it won’t be without friction. Know how to model and you will do yourself a favour. 😉

Backend driven UI

Another interesting topic that the video talks about is backend driven UIs. This is another thing I introduced in the product years ago. I implemented a simple backend service that returned a JSON structure for a landing page build out of components. In fact, this is where the beginning of HubKit started, a homegrown UI component framework.

Having a system like this is super cool when you want to have a dynamic screen that can adapt and change a lot. For me the goal was to improve our Perks home screen. It's also interesting because you can slowly build up the system. You can start with a simple backend returning a hardcoded JSON. Then you can introduce dynamic elements, eventually linking it to a CMS or even some fancy AI.

But then enters GraphQL, which in people’s mind contradicts this completely since GQL is all about giving the power to the frontend. But in reality, it can totally be done. You just have to design your graph based on some component entities. The FE still benefits from being the one in control. For example, the component library can grow without breaking changes.

Some slides from the video to illustrate the point:

Yes, you need to have components and a proper design system to do this. But you should have that anyway nowadays.

Conclusion

The video is very interesting. I really recommend it if you want to see how GraphQL is used in production and how a company migrates from old technology to a modern graph.

If you need to take one thing out from all of this, it should be: learn how to model a domain. That will help you in so many aspects, not only on GQL but also in any other product development.

I've wanted to have fancy poster images on my posts for a while, but I didn’t want to have to make them manually, or even manage them at all. Since this website is built using Publish it means I already have all the power of Swift available. And because I run the generation on macOS, it means I also have access to SwiftUI. So why not take advantage of that and use SwiftUI to generate the images for every post?

From SwiftUI views to images

Getting images from a SwiftUI view is the first problem to solve. I will not discuss it much here because I already wrote a whole post about it. I also made a Swift Package that encapsulates this functionality so we can skip directly into how to bend Publish to our needs.

Vanilla Publish

To start this process, I will assume we're working with a vanilla installation of Publish. I have some tweaks and changes on the tool to facilitate some things, that I need for this website. But I will stick to the basics for this post.

The first thing to understand is that Publish already comes with support incorporate this type of images on your post. The Item has an imagePath property and if you check the provided Plot components; you see that the default head adds the twitter card as follows:

.twitterCardType(location.imagePath == nil ? .summary : .summaryLargeImage),

That is very good! It means we just want to worry about generating the images and setting that path.

The step

To avoid having to make the images manually we will add a step that creates all the images for our posts.

additionalSteps: [
    .generatePosters()
]

The structure of the step is quite typical in any Publish step:

try context.mutateAllSections { section in
		try section.mutateItems { item in
				...

We need to iterate over all items of all sections to perform the work. Note that we are using the mutating variants because once we have the poster generated we want to set its path to the item imagePath property so the theme can pick it up.

The rough plan for the work is as follows:

1. Skip the generation when appropriate
2. Generate the poster image
3. Save the image
4. Assign the path to the item's image property

Avoid the work

We want to avoid doing the work for multiple reasons. The first check we should do is to detect if the item already has an imagePath set. That indicates that the item already has an image associated, we don't want to overwrite that.

guard item.imagePath == nil else {
    return
}

The second reason to avoid doing the work is performance. Generating views and rendering an image out of them can be costly, especially if the site contains many posts. That's why it should only be done once and just change the image if the data used on the view changes.

Unfortunately, I haven't found a pleasant way of doing this in vanilla Publish. The context has a method to create or retrieve a cached file cacheFile(named:) but I haven't found a convenient way of knowing if the file was just created or already existed.

In my website I don't use the cache because I persist the images in a different way. See below.

Generate the image

Since we already have a package to generate the image, the only thing we need is to build the actual SwiftUI view. This is what everybody can customise to best fit the style of the website. For this exercise, I’ve just created a very basic view that displays the title of the post.

struct Poster: View {
    let title: String
    
    var body: some View {
        Text(title)
            .font(.system(size: 200))
            .bold()
            .background(Color.gray)
    }
}

The view needs to accept the data that it needs, usually data from the post or the website. In this example I'm just using the title of the post but you can use the date, tags, etc.

I recommend you to design your view to be rendered at big sizes, this will give more resolution to the final image. In the example I use a big font size to accomplish that.

With the SwiftUI view created, we can just use Raster to make an image out of it.

let size = CGSize(width: 1600, height: 840)
let image: NSBitmapImageRep = Poster(title: item.title).rasterizeBitmap(at: size)
let data = image.representation(using: .jpeg, properties: [:])

Save the image

This is probably the most problematic step of all. It should be simple, after all we just have to save the Data in disk. But the question is, where exactly?

In my site I treat the posters as Content and that's why I save them alongside the markdown file. That works nicely because I don't have the markdown files all in the same folder. Instead, each post has its own folder with its own resources, what we often call a "bundle". After many years of working with static site generators, I definitely think this is the best approach. That's why I just save the file in the post bundle and everything is packaged nicely.

But in a vanilla Publish installation we probably don't want that. The more basic scenario is to just save the file directly in the output directory. That's easy since we just have to combine the item path with a name for the poster image. But keep in mind that this will slow down generation.

let posterPath = item.path.appendingComponent("poster.jpg")
let file = try localContext.createOutputFile(at: posterPath)
try file.write(data)

Use the poster

To use the poster we just have to assign the path of the image to the item, a supported property of Publish's Item type.

item.imagePath = posterPath

And because we're using the mutate APIs they will propagate this change to the next steps of the pipeline. That's going to let the theme use this path to create the proper HTML.

Conclusion

As you can see, the work is not very complex once you have a way to create an image from a view. The rest is working with Publish API to get the desired effect. For some things the API is a bit too restricted and you need to workaround it, but it's all possible.

If you want to use this system on your own site, you can check out the plugin that I open sourced: ItemPosterPublishPlugin. By default the plugin works as explained on this post, but it's fully customisable with closures in order to be as flexible as posible. This allows me to use the same plugin on my site, which has a different behaviour.

I would love for Publish to support officially bundled posts, a better way to detect the local path of an item and better cache interaction. With these things I could make the plugin way better by default. I understand that all of these may be requirements for a narrow use case but these things are almost the only ones that forced me to maintain my own fork of the tool.

In any case I hope you enjoyed this post and the Plugin. If you integrate this on your website be sure to mention me on Twitter so I can see your fancy post images!

Let's explore how all this ties together.

SwiftUI and the Type System

One major difference of SwiftUI with other declarative UI frameworks is how it uses the power of Swift at its maximum. Swift is a statically typed language, and that opens the door to a lot of interesting techniques with real benefits.

When you create a view hierarchy in SwiftUI, it is not only encoded at runtime with a tree of instances, it's also encoded on the type system. The framework uses views with generic type parameters to define the view hierarchy.

Watch What's behind SwiftUI DSL? - Swift Function Builders to know more about SwiftUI DSL.

Having the view hierarchy encoded in the type system lets the framework do a better job at diffing. Diffing happens when the UI needs to change. A declarative UI frameworks takes the new state of the UI, compares it with the previous one, and just performs the smaller amount of changes necessary.

It's easy to imagine how having more information available can help with this. If each decision point on a hierarchy has its own type, it means that the framework only needs to do runtime checks for the ones that can change, and even in those cases having a specific type for each case makes it easier to optimise.

To illustrate this behaviour, let's define a simple view and analyse its type.

var body: some View {
    VStack {
        Text("Hello")
        Image(systemName: "square")
    }
}

To easily see the type, you can just change the return type to an Int and read the compiler error.

Cannot convert return expression of type 'VStack<TupleView<(Text, Image)>>' to return type 'Int'

You can see how the view hierarchy is encoded in the view's type using generic parameters. We have a VStack with a TupleView that has a Text and an Image. We can imagine how with this information the framework could be able to know with no runtime check that the hierarchy is not going to change, just the content of the leaf views.

That's nice, but having to provoke an error to see the type is quite annoying. We can implement a small extension to print out the type of a view.

extension View {
    func debugType() -> some View {
        print(type(of: self))
        return self
    }
}

Adding this let us see the type of the view in the console. Much better.

But let's focus again on the return type. That some View. That's Swift's opaque return types feature being tremendously useful. Without that, having a framework like SwiftUI that creates such complex types would be impossible to work with.

Watch Swift Opaque Result Types to learn more about this feature.

some View makes it so we don't have to know any of this internal view types and avoids a lot of boilerplate. But is crucial to understand that the type is fixed at compile time, and it must be one concrete type. You can't have multiple returns with different types, it must be always one type. In other words, opaque types don't add dynamism into the system. The function has a static type as always, it's just that you don't have to write it yourself.

And this is problematic on some occasions, for example, when you want to return two different views based on some condition.

func labelOrText() -> some View {
    if showLabel {
        return Label("Bye", systemImage: "circle")
    } else {
        return Text("Bye")
    }
}

This code will give you the following compiler error:

Function declares an opaque return type, but the return statements in its body do not have matching underlying types

Type erasers and AnyView

If you really want to have multiple types in a such a strongly typed system, there is always a scape hatch: type erasers. This is a technique that deserves its own post but suffices to say that they are quite common in Swift. The type eraser for SwiftUI views is called AnyView.

By wrapping a view in an AnyView we erase the underlying genuine type of the view. The compiler doesn't know anymore what was there, a Text? an Image? No way to know. That may seem bad, but it gives us the benefit of mixing different views.

func labelOrText() -> AnyView {
    if showLabel {
        return AnyView(Label("Bye", systemImage: "circle"))
    } else {
      	return AnyView(Text("Bye"))
    }
}

Although this works, it is far from ideal. By using type erasure, we're denying useful information to the framework.

So let's look at an alternative!

Function builders with conditions

Wanting to return multiple views based on a condition often required to use AnyView in the beginning of SwiftUI. Thankfully, since Swift 5.3 function builders, the Swift feature that makes the DSL possible, added support for multiple control flow statements, including if conditions.

Watch Swift Function Builders deep dive for Swift 5.3 to see all the amazing things this feature can do.

Thanks to that you can use if conditions in SwiftUI body with no problem.

var body: some View {
    if showLabel {
        Label("Bye", systemImage: "circle")
    } else {
        Text("Bye")
    }
}

But we're still using some View as the return type. So you may ask, how are we able to have multiple types? And that's the magic, there are no multiple types, there is only a single return type. SwiftUI is using function builders to use another of its internal types, to encode the hierarchy in the type system, just as we saw before.

In this case the hierarchy has a condition, so it has a special view type for that:

_ConditionalContent<Label<Text, Image>, Text>

Use it in your own methods

Being able to use if in the body is nice, but as you can see, our previous problematic example was using a separate method. That's when most people use AnyView or move the code into the main body property. But there is a better way.

To use SwiftUI DSL a method must be marked with a special annotation: @ViewBuilder. By default, a view's body property is marked with it, that's why we can use the DSL without by default.

But when we make our own function, we're outside the DSL world. That's why we were forced to write the return statements and why the power of the if didn't work. But we can solve it easily! Just add the annotation yourself and you are back into the DSL world.

@ViewBuilder
func labelOrText() -> some View {
    if showLabel {
        Label("Bye", systemImage: "circle")
    } else {
        Text("Bye")
    }
}

Conclusion

SwiftUI uses Swift's powerful type system at its fullest. some View helps us not to have to write the complicated types, but it doesn't give us dynamism. Using AnyView denies that, so it's better to avoid it if possible. Just use @ViewBuilder when you are outside a view's body and you will be ready. That said, sometimes is still needed, so don't be afraid of it. Just know the tools you have at your disposal and pick the best for the job.

Sadly, SwiftUI doesn't provide a native way of generating images from its views. We need to resort to tricks used in its ancestor frameworks.

The main use case that I have for this is to generate images from a command line tool, that means we need to use AppKit since the code will run in a macOS machine. You can do a very similar thing in iOS with UIKit, for example, if you want to share something via share sheets.

Rasterize SwiftUI views

SwiftUI provides a very good interoperability with AppKit. You can display SwiftUI views in AppKit views and vice versa. We can use that capability to use AppKit APIs.

First, we need to create a NSHostingView with the SwiftUI view that you want to create the image from.

let nsView = NSHostingView(rootView: swiftUIView)

With an NSView in hand, the rest of the process is no different that what you would do to rasterize a native AppKit view.

let bitmapRep = nsView.bitmapImageRepForCachingDisplay(in: nsView.bounds)!
bitmapRep.size = nsView.bounds.size
nsView.cacheDisplay(in: nsView.bounds, to: bitmapRep)

This code gives you a bitmap representation of the view. This is already an image, but one that can hardly be used. If you want to use the image in any other software is very likely that you want to convert it to a common format and save it to disk.

let data = image.representation(using: .jpeg, properties: [:])
try data?.write(to: path)

And that's it. Now you have a jpeg image of your SwiftUI view stored on disk. With it, you can do whatever you please! So much power!

Raster package

I've packaged up this code in a Swift Package. You can find it on GitHub and even in the Swift Package Index. If you have any suggestions or improvements, feel free to open a PR. It's not like I'm an expert on AppKit!

If you want to know how to share a package in the Swift Package Index make sure you watch this video.

At a high level the process is very similar since the goals are the same: to have full control of what rules are run over our code.

The process

The process starts very similar as with swiftformat. First, I check and track the time it takes to run the current version of the tool to detect big regressions. Second, I check the changelog and take a quick look at what changes I will have to work trough. Then I update the binary and start the process.

In this case, I rarely go one version at a time. This is because the linter never touches our code, so I'm less afraid of regressions on a specific version.

One important detail is that I have the linter configured to only run the rules I enable manually, by using the only_rules option. This means that not even the default ones will run without my approval. As with the previous post, I keep all rules in the configuration, including the disabled ones, which have a friendly comment explaining why they are disabled.

To see what changes have happened, I run this command:

./swiftlint rules --config ./swiftlint.yml > ./swiftlinttable.txt

This saves a table with all the rules in our git repo. The git diff makes it really easy to see the new rules, and because they are all disabled, I can easily go one by one and check them out.

Conclusion

That's it. As you can see, this one is a little more straightforward thanks the keeping a list committed in gif.

The two important things from this system are:

1. Use only_rules to manually enable rules instead of relying on defaults.
2. Commit the list of rules in git to make use of the diff.

I hope you learned a bit from reading my process and if you have a better one, make sure to reach out 😉.

I just have praises for swiftformat, it's an amazing tool. This post is just a description of the process I follow when I have to update it. The way I want to configure the tool seems to be a little out of the ordinary, so after the years I've developed a specific process with various steps. As with many things, I just have this process interiorised and I do it automatically every time I'm working on an update. But once you sit down and write it down, something I did for the internal documentation of my team, you realise that is quite involved.

The principal reason for such as process is because I want to have full control of the options and changes of the tool, something that is usually the opposite of what authors want. And that's not something bad. A tool needs to be easy to use, it needs to be ready in a couple of steps. And that works fine for most people, but I want to know exactly what rules are being applied at all times. That's why I check the changes on every update and have the configuration the way I have it.

The process

Configuration

The configuration file is set up in a way that allows me to have full control of the rules and makes it easier to update. This allows me to know exactly what will happen when formatting and don’t let new versions touch code without explicit consent.

Thankfully, swiftformat has a way to make all the rules opt-in. Which is great because this means I must specify all the rules I want, even if they would be enabled by default.

Another important point is that all the rules are listed, the ones I don’t want are commented with a reason of why they are not enabled. This helps a lot when in a future update the reason is no longer valid, because of a fix or a new option.

I also keep the list of rules ordered alphabetically, this makes it easier to detect if you already have a rule or not. In theory it shouldn't be necessary since all rules are listed, but it wouldn't be the first time I missed one!

After all the rules, there is a list of options. As with the rules, this list is ordered and contains all options, with the ones I don’t want commented and with a reason.

It’s very important that this configuration is kept with these rules, to summarise:

• First rules, then options.
• Ordered alphabetically.
• All are present, the ones I don’t want are commented with a reason.

Update process

1. Check the time it takes tor run

Before changing the version or the configuration is necessary to record the time it takes to run in order to detect vast increases. This is quite important since with our big codebase any process takes quite a bunch of time, so I want to keep an eye to make sure it doesn't get disproportionally worse.

I use hyperfine to benchmark command-line tools.

2. Check the changelog

First, I check the version that is installed by running:

./swiftformat --version

Then I go to the releases page and check how many releases have been since last time. At this point I take a first glance at the changes to detect any major breaking things that could block me later.

3. Update each version

Yes, I update each version one at a time. This is very important since I want to see what changes every version introduces and go step by step. Sometimes fixes in a version change the way things look and is very hard to detect where is the problem if you change multiple versions at once.

3.1 Update the binary

On each release page there is a binary attached. This is very convenient because I like to keep the binaries in the project to make sure everybody is running the same version of the tool.

3.2 Give it a try

I then run sh format.sh (a small script that runs the formatter) to see changes. Ideally nothing would have changed between versions, but sometimes there are changes that are actually desirable, due to a bugfix on the tool.

If everything looks good, I keep going.

Otherwise, if the format changes to an undesirable state, there are multiple things that I often do:

• Check the changelog for related fixes in upcoming versions. If there is a newer version with a potential fix I just finish the update for this version and go to the next one.
• Check if a new rule or option has been added that would allow me to keep the old format.
• If the format is broken after trying the recent version, I raise an issue on the repo and don’t update yet. The author is so responsive than usually there is a fix pretty quick.

3.3 Update rules

I then check the changelog of that version for any mention of rules and options.

If there is a new rule or option, I give it a try and decide with the team what we want to do with it. If the team decides to add the rule, I make a note and do it in a separate PR (unless doesn’t affect much code). Remember that no matter if is enabled or disabled, the rule needs to be added to the config file (with explanation if disabled).

If there is an existing rule or option mentioned, I check if I have it disabled. If the changes on the rule would fix the reasons I had to disable it, I talk with the team to decide if we want to enable it now.

3.4 Commit the changes

This helps the PR review by having a trace of which changes were done in each version.

Conclusion

I follow this process step by step so I know exactly what are the new changes and I can take proper decisions. It takes a bit more time that just updating willy-nilly but for me is totally worth.

LoR is a great card game with many good things that I could talk about for a while. I've played other collectible card games before but, apart from MtG in university, I didn't like any of them that much. But the quality of the game, its mechanics, its great pricing model it is not what I want to talk about it today. Today is all about the amazing art it has.

The first thing you see when you open the game is a stunning animated art piece of one character and region. From that point on, you just keep being more impressed by the art on every card. And not only that, but that art is telling you a story, the story of Runeterra.

Inevitably, I wanted all those amazing art pieces as wallpapers for my device. And that's why I made this little tool: Runeterra Wallpaper Downloader.

This tool downloads the official card assets from Legends of Runeterra and copies the card full screen art into the desired location. I built this to help me keep up to date the wallpapers every time a new set is released. Doing it manually takes too much time since the assets come organised in folders that have together the card images and the full screen art, also those folders contain images for the spells which don't have big images that can be used as wallpapers.

The tool is of course built with Swift following the typical SPM structure for CLI tools: there is a package with the core code and an executable target with just the CLI. It makes it super nice to work with, and it allows the core code to be used in other projects.

As always, I have some more ideas for improvements that could be nice to do at some point. But as it is right now is usable, so there is no reason to hold it back. I want everybody to enjoy the amazing art of Runeterra!

As always, let's start with an example type:

struct Object {
    let flag: Bool
}

Let's pretend that your code receives an optional instance of this type: Object?. Optional equitability becomes important when in your code you want to do something with the flag directly like so:

if object?.flag {
    ...
}

flag is a boolean so you may expect that to work, and in other languages it might, with some rules you have to learn of it behaviour and its corner cases. But in Swift the compiler will forbid this dangerous code giving you this error message:

Optional type 'Bool?' cannot be used as a boolean; test for '!= nil' instead

That's an unfortunate error message because its suggestion has nothing to do with what you want. Yes, you could bind the object to a new variable with if let but that introduced new names into your code that only increase the cognitive overload while reading the code.

But don't worry, you can convince the compiler to treat that expression as a boolean. You just need to explicitly use the equitability operator ==:

if object?.flag == true {
    ...
}

The best way to understand how this works is to analyse all the cases that this interaction has. Remember that you are not dealing with a boolean here, but with an optional boolean. This means you have three cases: true, false and nil.

If we declared the cases as variables they would look like this:

let oT:    Object? = Object(flag: true)
let oF:    Object? = Object(flag: false)
let oNil:  Object? = nil

Now let's try all the equalities and see their results:

oT?.flag == true			// true
oF?.flag == true			// false
oNil?.flag == true			// false

oT?.flag == false			// false
oF?.flag == false			// true
oNil?.flag == false			// false

oT?.flag == nil				// false
oF?.flag == nil				// false
oNil?.flag == nil			// true

With these examples in mind I hope you can now see how it works. A good mental model to follow is to think that what the compiler is doing is promoting the literal to an optional and just comparing those.

In our case we could rewrite the example to make it more obvious:

if object?.flag == Optional(true) {
    ...
}

Once you realise that you are dealing with optionals, and not boolean, in both sides and that you have three cases instead of two, the results become obvious.

But even so, I would like you to take a closer look at one specific combination:

oNil?.flag == false			// false

This just says that nil is different than false. This is obvious because they are two different cases of the three we have available. But if you are used to other languages, this may trip you out since you could imagine that false and nil are equivalent. Be careful with this one.

To have an example to work with, let's pretend we want to link a custom UIViewController with its ViewModel. This is a typical scenario when building UIKit apps, but the same can apply to any other scenario that involves two classes, inits and closures.

The ingredients for a problematic cycle

One ingredient for this scenario to occur is that you want to inject all dependencies through the initialiser of an object. Yes, there are other ways of injecting dependencies, and if we use any of them this problem would go away. The most common, that you can use in any codebase, is doing injection via a property. But I don't like that at all since it forces your class to deal with optionals (or implicitly unwrapped optionals if you're brave enough) and that just introduces more burden.

The second ingredient you need is a dependency to a closure. This is not typically a problem unless during the creation of the closure you need to reference an uninitialised object.

And that's the third ingredient you need, a cycle. The cycle appears when the object you need in the closure needs the object you're initialising with the closure itself. You can't have one without the other, so you must find a way to break the cycle.

Put in a concrete example:

class ViewController {
    let viewModel: ViewModel
    
    init(viewModel: ViewModel) {
        self.viewModel = viewModel
    }
    
    func run() {
        viewModel.closure() // for example
    }
}

class ViewModel {
    let closure: () -> Void
    
    init(_ closure: @escaping () -> Void) {
        self.closure = closure
    }
}

func create() -> ViewController {
    let viewModel = ViewModel {
        // access viewController here
    }
    let viewController = ViewController(viewModel: viewModel)  
    return viewController
}

As you can see, the ViewController(viewModel: viewModel) needs the viewModel. But let viewModel = ViewModel { ... } needs the viewController. Congratulations, you just cooked a problematic cycle.

Reference the future

The fix for the problem is quite obvious at a first glance. You just need to have a reference to a variable that will be set later.

let viewController: ViewController
let viewModel = ViewModel {
    viewController...
}
viewController = ViewController(viewModel: viewModel)  
return viewController

But that's easier said that done. Because the compiler, caring so much for our safety, won't let us declare a variable and use it before it's initialised. And capturing it in the closure counts as a usage.

To have an uninitialised variable we need to use an Optional, but then you also need to use a var, otherwise you will be forced to assign it before usage.

var viewController: ViewController?
let viewModel = ViewModel {
    viewController?.run()
}
viewController = ViewController(viewModel: viewModel)
return viewController!

Now this works, as in, you can access the instance inside the closure and the compiler is happy about it. But... congratulations! You just created a reference cycle.

Avoiding the reference cycle

We can easily see the reference cycle that is created from the above code:

If we focus on the closure, this is not a new issue, Swift developers are used to keep an eye for reference cycles on closures. Typically, we need to be careful with self but in this case we need to be careful with viewController. So let's do the obvious thing and add a capture list that weakifies the instance.

var viewController: ViewController?
let viewModel = ViewModel { [weak viewController] in
    print("access viewController here: \(viewController?.viewModel)")
}
viewController = ViewController(viewModel: viewModel)
return viewController!

This indeed breaks the cycle, but if you run it will see this output:

access viewController here: nil

What is happening here is that the capture list is creating a new weak variable that points to the same memory as the original one. Yes, a new variable. That means that what the closure is capturing is a pointer to nil and that won't change no matter what we do later. So when we're assigning the instance later, we are not changing the variable inside the closure, only the one outside.

To solve this problem, we need to cook the weak variable manually.

Manual weak

Since we can use the capture list, we must reference the original variable. And to avoid the retain cycle, we must have a weak reference. Luckily for us we can declare a local weak variable (something I forgot).

weak var viewController: ViewController?
let viewModel = ViewModel {
    print("access viewController here: \(viewController?.viewModel)")
}
viewController = ViewController(viewModel: viewModel)

We just need to add weak on the declaration and remove the capture list.

But now we have yet another problem. Since the variable is weak, it means nobody is retaining the instance and keeping it in memory. As soon as the method execution ends the viewController will get deallocated.

To solve this, we need to make sure we keep a strong reference to the instance. We need to have two variables, a weak one for the closure and a strong one to retain it. And we need to assign the instance to both of them.

weak var weakViewController: ViewController?
let viewModel = ViewModel {
    print("access viewController here: \(weakViewController?.viewModel)")
}
let viewController = ViewController(viewModel: viewModel)
weakViewController = viewController

And this is the result. We successfully got a reference to an object that still doesn't exist and we made sure there were no retain cycles.

If your code is more complex than this simple snippet, I recommend you to drop an assertion to make sure your future self doesn't forget to assign the instance, without an assert this would silently fail.

Conclusion

Mostly, Swift lets us forget about memory management and references but it's always good to know what's going on under the hood to be able to solve these scenarios when they inevitably occur.

It's also very nice how the compiler has give us errors and warnings on almost every step of this process.

Next time I won't forget I can use weak in local variables ^^

As I teased last time, this is my entrance into Brandon Sanderson’s Cosmere. On March 2019 I tried with The Way of Kings, but I was not mentally at the right time to take an epic fantasy story. So that year I went for something lighter. When I decided that it was time to start with Brandon’s books again, I preferred to avoid its bigger piece. After putting on pause The Wheel of Time I wanted something smaller, more approachable.

I’ve always had a curiosity for Mistborn. I think it’s the name that attracted me first. It makes my imagination fly. But then when i heard it was a fantasy heist plot, I got overly excited. Ocean’s Eleven, but with magic? Heck yes! And now that I’ve finished the first book, I annoyed that I didn’t read it sooner!

As my first Sanderson’s book I have to say that I really like how he writes. I’m sure the style will vary from book to book, but I found Mistborn’s prose very good but approachable. Something that as a non-native speaker I really appreciate.

The characters are lovely. Not only the main two but also the rest of the crew. Vin is arguably the principal character of the story and it has been very enjoyable to see her grow, from the first chapter to the last. She has learned and changed a lot, but you can still see her past self in her. It’s so well done.

The plot makes you flip pages like there was no tomorrow. There are no slow parts. Even the chapters with less action, there is still something very interesting happening. There is no filling. The plot moves page after page. If there is one detail to comment is that the heist itself takes a bit of a back sit, but it’s to focus on the characters and make them shine, so it’s all for a good purpose. And don’t get me wrong, the heist is still there. Is the main driver of the story. It’s just not a one hour film where everything that matters is how to rob the bank. It’s way more than that!

And the setting? Well, well well. The setting is so vivid in my mind. It’s so different that I really feel like I was running through the mists at night with our protagonists. And the best thing is that it doesn’t take much time boring you with explanations of it. Sanderson is able to sell us this world with very little. No filling.

But let’s get to what had me more curious. The magic system. A hard magic system. Pretty much everything I read has been soft magic systems, and I was very expectant to see what everything was praising Brandon for, the king of magic systems. Well, people were not mistaken. He delivered. Now, if you don’t get pumped up by details about how magic works, this may not excite you as much. And it’s truth that there is a bunch of word count dedicated to the magic by necessity. But even if you are not a fan of this style I think you will like it because it’s so well woven into the character development and action scenes that I don’t think there is a single paragraph where you will be bored.

And those action scenes! Between the characters, the big plot behind each scene and the spectacular magic, I would say that Mistborn has some of the best action scenes I’ve ever read. And there are a lot of them.

Finally, the world building. As I said the, setting is magnificent, but it doesn’t stop there. The wider world and universe are what interests me the most. Being able to finish this book and step into the bigger world of the Cosmere is something I’ve wanted to do for a while. And just with this book, I can already see glimpses of what could be. I’m eager to enjoy the discovery.

So yes, I don’t know if this is my favorite novel, but it is. And the best thing is that Brandon is a machine, and he keeps writing and writing. So I signed up for an amazing long ride!

So I went for the first and thought it was fine, but not amazing. It was the first one and seemed like an introduction to the world with not a lot of interesting action. So I kept going. Now I finished the fifth entry on the series, The Fires of Heaven. And I’m still with this weird sensation of missing something.

The book is wonderful, but I don’t think is such as amazing as the huge fans say. And that’s normal. They wouldn’t be fans otherwise. But I’m talking about myself here.

The characters are very well realised, and there are a lot of them. Which maybe is the big problem for me? Too many characters. I know their stories and interwoven, but I can’t avoid the feeling of being lost every time the scene changes. That’s probably my fault. To read epic fantasy, you need to be well versed on novels, so maybe I’m just not there yet.

The magic is very, very interesting. It’s not a hard magic system by any means, but the combination of different sources of magic and styles in the same story is super interesting. It’s something that is very close to my fantasy world. Maybe I should have read this long ago!

The plot is also very, very interesting. Is an epic fantasy after all. The world is at risk of being destroyed by the evil overlord, and our main characters need to stop it. But that’s not it, there are a lot of subplots happening constantly. Each character pursuing their own motivations without forgetting about the big picture.

When you read that it seems like the best thing in the world. And I keep thinking about that. Or at least about the promise of that. But after finishing every book, I can’t stop feeling that not much has happened. Yes, the plot has moved forward and the characters have grown, but the proportion of that with the number of pages is way too low for my taste.

And for other people that may be fine, since all those extra pages are dedicated and making us feel like part of the world. This immense world with very detailed cultures. But I guess I want a bit less of that and more action. And I FEEL BAD for saying that about world-building, which is one of my passions. But really, I don’t need hundreds of pages to tell me how Aiel are.

As the Spanish meme says...

I still like the books. And I still want to keep reading and finish it. But is a daunting task. With the feeling of not much happening on every book and still nine books to go. Without mentioning that apparently on the seventh one there is a big depression where the pacing slows down, even the fans have trouble with those. So I’m scared. I don’t want to leave it, but it won’t be easy.

So my plan is to pause it before I burn out of it. I want to go back to it after the first season of the show airs, and I’m hooked by the story and the characters again. But for now, I want to disconnect for a bit.

So what’s next?, you may ask. Well, it is time to taste a hard magic system.

When I decided to pursue a career on software development is not just because of the technical aspect of it, but also because I was a very creative person. If have never written code you may not relate it to creative thinking, but it is. Think about it this way: you are literally creating something, whatever you want, from nothing. That’s what made me go to university to study computer science. The freedom and limitless creative possibilities of it.

Those old word documents of mine got lost between a plethora of other hobbies and life. But one of the major reasons for my younger self to stop writing was that was not a good writer. We wrote and shared our text with a group of close friends, yes we had a writing group even without knowing that was a thing, and their prose was much better than mine. So I knew that pursuing a professional career in writing was out of my reach.

And that was the big mistake.

No. I’m still convinced I don’t have enough skill to be a good writer. You won’t see my novel in a bookshelf. I was correct in that. The mistake was about thinking writing had to be a professional career. Nobody had ever told me that writing could be just a hobby. And that’s something that is very rotten in our society. We all played on some sports team. As a hobby, nobody was pursuing being a pro realistically. It was just fun and healthy. I even did drawing and painting classes. As a hobby. But writing? When you think about writing you immediately think about those authors that have been blessed with enough skill to be in a bookshelf.

So I didn’t write for many years.

I, and my friends, made a similar mistake with D&D. We heard it was too hard, and since we didn’t have examples, we just accepted it was too difficult for us. So we never played. But then in my late twenties I discovered FATE, Critical Role and the D&D renaissance. Suddenly role-playing seemed something we could enjoy doing, but now with a friend on each corner of the world not that easy. Too late.

But that didn’t stop me of organizing some sessions when we were together. And we had fun. Or at least I had. I went from never playing to being the dungeon master, skipping the player position completely. And I loved it! For the first time in years, I could externalise somehow the world that my mind has been creating for twenty years.

And finally, early this year, I started being curious again. It all started by being hooked up with fantasy again. When I decided to read The Wheel Of Time I started hearing more and more about Mr. Sanderson and his part in finishing the series. I’ve heard about him before and I still have on my list getting into his world. But his charisma made me follow him, even reading nothing from him yet.

Then is when I discovered he had a complex inter-winded world of fantasy, the Cosmere. Something very exciting because an inter-connected fantasy world is something that excites me a lot. And then I found out he does university classes about writing fantasy and sci-fi and, more importantly, they are available online. So one night, alone, during the pandemic, I decided to take a look.

And it changed my perception on writing.

I finished watching @BrandSanderson 2016 lectures and now 2020 show up! :D The introduction is great, I wish somebody had told me "writing can be JUST a hobby" 15 years ago. Funny how when I was on my 14/15 I actually wrote half a book, and started another
But I stoped.

— Alejandro Martinez (@alexito4) January 23, 2020

Are you saying that I can write just for fun? Without having to suffer because not fulfilling expectations? SAY WHAAAT?

So I opened Scrivener. Recovered the old documents of my novels, pulled the world-building from my D&D sessions and started writing.

Even at that point I was not convinced that I could write a novel, I’m still not sure to be honest. So I just started with the mission of keeping memories. As I said before, I’ve been building this fantasy world with dozens of stories in my head for many years. Of course not everything is good material, but my brain has been an imagination machine for a long time. But I’m a human that is getting old, and those memories from fantastic worlds, creatures and battles will fade away at some point. So my task was just to write a list of what my imaginary characters have gone trough. Keep a list of the major story lines, how they connect and the peculiarities of my world.

But you can guess what happened.

That sparked a wave of inspiration in me again. With everything that has been happening this year, and spending so much time alone enclosed at home with my girl int he other side of the world the fantasy realm was a more comfortable place to be. So I took the present story that my brain was developing and started writing it down.

Of course things have to change a bit when you put them on paper, but overall I’m excited about it. My plan is to finish it before my next birthday. I don’t want to leave other parts of my leave behind, but I think I will dedicate a bunch of time to this.

We’ll see how it goes. There is no pressure. Is just for fun.

It’s my new old hobby.

I've had this in the back of my head for too long so I decided to do something about it. Last year I promised to myself to ship a new app just for myself to have fun again. So this year I will try to finally write a novel, I've been ignoring this passion of mine for too long. https://t.co/5xFnImJAUS

— Alejandro Martinez (@alexito4) August 20, 2020

The abstraction dogma

We all know that unit testing the logic of your code is important. Over the years the industry has created tons of material explaining how abstracting your types with protocols (a.k.a. interfaces) is the best way to accomplish maintainable and testable code.

Although some of it is objectively true. There is a lot of dogma and close mindedness in a lot of the narrative surrounding tests and architecture. I've personally always been in two minds on this topic (and many others, which is hard in today's extremist world).

Yes, I do love a good unit testing suite but no, I don't want to force my code into a complex net of systems just to make unit testing easier.

Many will argue that unit testing is a tool that helps shaping and designing good code, and again, I agree partially. When they teach you how to do unit testing and use interfaces they often forget to tell you that every interface you add to your code increases its complexity. There is more stuff to keep in your head, and more files you need to click trough to finally read the code that really matters.

The more code I need to maintain the more I appreciate simplicity. As a young engineer I bought into the OOP dogma and tended to implement future proof systems with protocols and abstractions all over the place. I was so naive.

We've seen this attitude get into the mindset of iOS developers with things like VIPER that are so overly complicated that everybody runs away just by hearing its name. And again, I'm pretty sure there are places where deploying a system like this is worth the complexity that it adds.

Personally, nowadays, if I can use a concrete type and avoid having protocols all over the place I'm a much happier programmer, and so is the rest of the team.

The useless abstraction

Abstractions are good when they are good abstractions. When they create a new language that helps us talk in a higher level way about a problem. In those occasions a protocol becomes a good abstraction, when it emerges from the design of a solution to a problem. But that's not what protocols required by unit testing are. And in Swift we tend to make a lot of those since runtime hackery is not at the level that we need to fully mock all objects.

That's why I'm so happy to see an impactful site like Pointfree talk about this. I'm not gonna put words on their mouth, maybe I interpreted too much on their words, but their current series of episodes felt like a liberating chant. Finally!

But, just because it’s popular doesn’t mean it can’t be improved. - PointFree about protocol-oriented problems.

The problem with the protocols that show up from unit testing is that they are only necessary for unit testing. If you have a very complex piece of software that require multiple implementations that can be used trough a single interface, then yes, by all means, use protocols!

I'm gonna leave here a quote from Pointfree's video about dependencies. It summaries very well the thoughts that I've been having for years but that are so hard to merry with the dogma that permeates our industry.

There is something a little strange about what we have come up with so far. We created a protocol to abstract away the interface of getting weather results, but only created two conformances: a live one that makes an API request and a mock one that synchronously returns mocked data. - PointFree about protocol-oriented problems.

It has always smelled badly to me the fact that we're so happy just making a protocol to make unit testing happy.

A protocol that only has two conformances is not a strong form of abstraction. There is not a single protocol that Apple gives us that is meant to only have two conformances. For example, the Sequence and Collection protocols have dozens of conformances. - PointFree about protocol-oriented problems.

When reality strikes again

But of course, as with many topics that I talk about in this blog, reality is here to stay. It's very likely that you are working in a codebase that requires this unit testing protocols because there is no other way of doing it. Even if adopting some of Pointfree's ideas wouldn't take too long we already have work to do and we can't stop the printing press just for this.

So here's my tip, something that I've been doing recently.

Embrace that those protocols must exist and accept that, on their own, they don't add anything valuable to your codebase. They are just there for unit testing. They are just there to create boilerplate. And what do we do with boilerplate? We summon a sorcerer!

I used Sourcery to generate all the boilerplate necessary to have nice unit tests.

// sourcery: AutoProtocol, AutoMockable
final class AuthenticationDataManager

Just with that annotation you get a protocol that reflects the public interface of the type and a mock implementation with a lot of helpers to know what method has been called, to fake return values, etc.

I haven't invented anything here. AutoMockable comes with Sourcery and AutoProtocol is a modification of this AutoInterface template. What I've done has been tweak a little both of them.

First because AutoInterface naming is too close to Java for my taste. I don't want to see IType in a Swift codebase. We prefer to use Protocol as a suffix.

And second, because these templates are thought to be used individually. You can get a protocol from a class. And you can generate a mock from a protocol. But what I wanted is that from a concrete type that I write, to first get a protocol for it, and from that protocol get a mock. This is not hard to do but it requires modifications and some duplication in the templates.

This is not perfect. You still need to be aware of the existence of the protocol because that's what you need to use on your consuming types. But at least you don't have to write the boilerplate and it makes sure that everything is always in sync.

I leave the templates that I'm using in this Gist.

Conclusion

As usually, just have an open mind and don't follow dogmas blindly. Just with that you will be a much happier programmer, and human being ^^.

Protocols are nice and powerful but don't over use them. Especially if they don't add any value as an abstraction.

And finally check out Pointfree. I'm in no way affiliated to them (apart from that link being an affiliate link LUL) but their content is so good that I can't miss any opportunity to recommend it.

Thanks for reading.

Last year, at the start of my new season, I made myself a promise: release a new iOS app. I've been an iOS developer for many years now. But at some point I stopped making apps for myself. I was busy with work and life, and the time that I had I put it in experiments to learn and explore new things. Swift has been a big topic on this space, but also the blog, making videos... I never stop learning or creating, but it's true that finishing a personal project is not something I'm very good at.

So here I am. One year later with an App on the Store. I present to you GoodProgress!

GoodProgress was born from necessity and curiosity.

Since I'm recovering the love for reading and fantasy I needed to build an app to help me keep track of the progress of books. You know that I love tracking progress, remember WishFilms? Well, for books Goodreads is basically the go to website. There is very little to no competition. And it's noticeable because the web and apps are quite bad.

Without exaggerating: between navigating the confusing interface, waiting for pages to load and fighting the constants bugs it can take you up to a minute to update the progress of your book. I wanted something quick and fast.

And that's how this app idea took shape. I just needed a single screen with the book I'm reading and a big fat button to update the progress. That was my primary motivation.

SwiftUI and the promise of WWDC showing us a more polished version of it was exciting too. So I decided, after working with SwiftUI for a year, to put something on the store with it, combined with The Composable Architecture.

But making an app like that would be too easy, right? Well, yes, except that the Goodreads API is worse than their app. Just read this: XML. Yes, in 2020. And the format of the responses is not such a big deal as so many developers on the community forum pretend to be. The real problem here is that the API is not maintained at all. The documentation is worse than generated docs. API calls missing or not working at all. And the worse, in my opinion, is that the entity organisation and relationships are so much more confusing that they should be.

But I was determined. I started listening to audiobooks with Overcast because of its Smart Speed feature. That meant that I didn't know the progress or even the page. I just had the number of the chapter I was in. So one of the most useful features of the App for me is the chapter update progress screen.

Design wise is not a piece of art. But I'm not disappointed. As always design is one skill I need to improve but I like the color contrast and full screen cover art. It makes it stand out for a simple stock list of books.

That's it, I just wanted to leave some thoughts for posterity on the release of my new App. More features are planning so hopefully I will write another post about it at some point.

iOS Home Screen Quick Actions

Implementing Quick Actions is quite straightforward from an API perspective. UIApplication has a shortcutItems array property that you just need to assign when you want to set the quick actions. It really doesn't get simpler than that.

Note that you can also define quick actions statically in your Info.plist. But here we're focusing on dynamically updating them which is the most common case.

The shortcut item itself is a simple object with an initialiser where you pass the data you want to display: title, subtitle and icon. You need to define a type so you can later differentiate between different kinds of actions. And finally, as many other iOS APIs, it offers a userInfo dictionary where you can set any custom data that you want.

As you can see the API itself is quite simple to use. The inconvenience of is given by the your specific use case and architecture of choice. As any good architecture out there you probably have multiple features or screens completely decoupled between them. What one screen does shouldn't affect any other random screen. And that glorious benefit is a small issue to overcome on these situations.

To know when to update the quick actions, and which ones to display, you need to detect some changes on the data of the user. These changes can happen from different features of your application and thus complicating a bit this code that needs to know about all of them.

If you're lucky you may have a database. And then you can make sure that any change that provokes the quick actions to be updated is saved into database. Or at least that you inform the system with a notification. And then you also need to make sure to never forget about those things when adding more features!

As you can see, there are solutions of course, but you start relying on external systems or compromises on your architecture.

The beauty of the composable architecture is that its centralised design of state and actions makes implementing features like this a breeze. But it's also fully composable so you are not sacrificing the decoupling between features. And by using functional concepts like high order reducers you can plug and play this functionality without affecting the rest of your app.

To show case this I'm gonna use one of the amazing example projects that comes with the composable architecture library: Todos.

Updating the shortcuts

Let's start by creating a new file called QuickActions.swift. I like to have everything that is needed for a feature like this to work in a single file.

import UIKit
import ComposableArchitecture

The first thing we need to add in the file is a definition for a new high order reducer.

High order reducers are like any other reducer you make in your application with the difference that work generically. They're just like a high order function.

extension Reducer {
    func quickActionable() -> Reducer {
        ...
    }
}

But this reducer is completely generic. We don't have any information about the state or the actions. To solve that we need to use Swift's generic constraints to restrict this reducer to our application.

extension Reducer where State == AppState, Action == AppAction, Environment == AppEnvironment {

We could definitely make this reducer fully generic and make it work with any application. Read the section below for some words about that.

Now that we have a reducer that has access to our application state we can just chain it in our main reducer.

let appReducer = Reducer {
  ...
}
.quickActionable()

Just with that single line we've added a full set of functionality to our app!

Well, now we need to implement it ^^'

Our new function needs to return a new Reducer that adds the work you want. When implementing a high order reducer usually the first thing you want to do is let the reducer chain run and do their normal work. For that we just need to call self and keep the resulting effect around to return it later.

func quickActionable() -> Reducer {
    Reducer { state, action, environment in
        let effect = self(&state, action, environment)
        ...
        return effect
    }
}

Before we write any code for the quick actions we need to tweak the enviornment to give us access to the iOS API. Yes, you could access UIApplication.shared from the reducer but that breaks the pure function nature of a Reducer. It's a big NO NO.

Since we're hooking into the appReducer we need tweak its AppEnvironment. You could pass an instance of UIApplication but the best practice is to have closures as properties in your environment. That makes it easier to mock with anything you want. For example you could fatalError() in tests that you want to make sure don't touch the quick actions, that's way harder to do if you just inject an object directly.

struct AppEnvironment {
    ...
    var updateQuickActions: ([UIApplicationShortcutItem]?) -> ()
}

// when initialising the environment
updateQuickActions: { UIApplication.shared.shortcutItems = $0 }

With that scaffolding in place we can add our quick actions functionality.

We reach into the state to get the pending tasks and create UIApplicationShortcutItems from them. For now we only care about passing the description of the task and, since we're not gonna have multiple types of actions, a hardcoded type.

let quickActions = state.todos.elements
    .filter { $0.isComplete == false }
    .map { todo in
        UIApplicationShortcutItem(
            type: "MarkTodoAsDone",
            localizedTitle: todo.description,
            localizedSubtitle: nil,
            icon: nil,
            userInfo: nil
        )
    }
environment.updateQuickActions(quickActions)

And with this we can now add some todos and see how they appear as a quick action.

Handling a quick action

When a user taps in a quick action the system notifies your application in two different ways.

If the app was already launch the SceneDelegate will receive a call to the following method:

func windowScene(_ windowScene: UIWindowScene, performActionFor shortcutItem: UIApplicationShortcutItem, completionHandler: @escaping (Bool) -> Void)

Instead, if the app was closed and the user opened it via a quick action, the information of the shortcut comes as part of the options UIScene.ConnectionOptions.

No matter from which method we get the shortcutItem we can forward it to a private helper method.

private func handleQuickAction(_ shortcutItem: UIApplicationShortcutItem) -> Bool {

This method's purpose is to send an action to the Store so our reducers can handle it. For that we need to tweak the SceneDelegate in order to have a property that lets us access the store. We also need to add a new action to our AppAction enum.

enum AppAction: Equatable {
    ...
    case handleQuickAction(todoId: UUID)
}

As you can see the new action has an associated value indicating the identifier of the todo that the user selected. To know this information we need to give it to the system when we create the UIApplicationShortcutItem, that's what the userInfo property is for.

userInfo: [
    "todoId": todo.id as NSSecureCoding
]

But to avoid having to work with string keys from different places of our app, let's extend UIApplicationShortcutItem to add a computed property that gives us the todo id.

extension UIApplicationShortcutItem {
    static let todoIdKey = "todoId"

    var todoId: UUID? {
        (userInfo?[Self.todoIdKey] as? String).flatMap(UUID.init(uuidString:))
    }
}
...
userInfo: [
    UIApplicationShortcutItem.todoIdKey: todo.id.uuidString as NSSecureCoding
]

Now that we're passing the todo id trough the shortcut item we can extract it in the scene delegate and send the appropriate action to the Store.

private func handleQuickAction(_ shortcutItem: UIApplicationShortcutItem) -> Bool {
    if let todoId = shortcutItem.todoId {
        ViewStore(store).send(.handleQuickAction(todoId: todoId))
        return true
    } else {
        return false
    }
}

The next step is handling the new action. We could add this logic into our main app reducer but, as I said in the beginning, I prefer to have everything related to this feature in a single place. So instead, let's ignore the action in the main reducer

case .handleQuickAction:
    return .none

and implement it in our quickActionable reducer.

let effect = self(&state, action, environment)

if case let AppAction.handleQuickAction(todoId: id) = action {
    return .init(value: .todo(id: id, action: .checkBoxToggled))
}

...

To handle the action in this case is quite simple since we just want to mark the task as done. We just forward the id into an already existing action. We also stop the function here because there is no need to update the quick actions since they will be updated as soon as the task is marked as done.

Tests

The first thing worth mentioning is how the tests still pass. We've added all this new functionality just by extending our app features without modifying any of them.

Let's start by preparing a TestStore

func testQuickActions() {
    let store = TestStore(
        initialState: AppState(),
        reducer: appReducer,
        environment: AppEnvironment(
        mainQueue: self.scheduler.eraseToAnyScheduler(),
        uuid: UUID.incrementing,
        updateQuickActions: { ? }
        )
    )

To track what changes we do to the shortcut items we can have a history array keeping track of them. This not only will allow us to check if the correct items are given to the system, but also how many times we change them.

     var quickActionsHistory: [[UIApplicationShortcutItem]?] = []

    let store = TestStore(
        ...
        updateQuickActions: { quickActionsHistory.append($0) } // <--
        )
    )

Now we can just write a series of events that exercise our new functionality.

First we add a new task and check how the quick actions has been modified:

store.assert(
    .send(.addTodoButtonTapped) {
        $0.todos.insert(
            Todo(
                description: "",
                id:  id,
                isComplete: false
            ),
            at: 0
        )
    },
    .do {
        XCTAssertEqual(quickActionsHistory.count, 1)
    },

Now we change the description of the task and check that is reflected correctly in the quick actions.

     .send(.todo(id: id, action: .textFieldChanged("Cookies"))) {
        $0.todos[0].description = "Cookies"
    },
    .do {
        XCTAssertEqual(quickActionsHistory.count, 2)
        XCTAssertEqual(quickActionsHistory[1]?[0].localizedTitle, "Cookies")
    },

Finally we ask the store to handle a quick action and check how it doesn't change the history immediately, but instead it forwards the job to another action.

     .send(.handleQuickAction(todoId: id)) { _ in
        XCTAssertEqual(quickActionsHistory.count, 2)
    },
    .receive(.todo(id: id, action: .checkBoxToggled)) {
        $0.todos[0].isComplete = true
    },
    .do {
        XCTAssertEqual(quickActionsHistory.count, 3)
        XCTAssertTrue(quickActionsHistory[2]!.isEmpty)
    },
    .do { self.scheduler.advance(by: 1) },
    .receive(.sortCompletedTodos)
)

And with this set of steps we have fully tested our quick actions integration.

One thing to note is that we're not refreshing the quick actions when the app starts. In theory this wouldn't be a problem if the example persisted the tasks. But since the example is not doing it, when the app starts it doesn't have any todos while the system still keeps the old shortcut items. This is left as an exercise to the reader.

Alternative

Fully reusable high order reducers open the door to a great deal of reusability. Plug and 'play features that can be shipped as packages. You can see how this would work in the reusable favourites example.

For the feature we have in hand there may be a generic design that could work on any application, but I haven't found a nice one. If you look at our resulting code you will notice that there is very little generic code in there. Almost everything is tailored to our needs. Yes, you can make a generic reducer. But then you need to inject so much functionality from the outside, that you ended up with a more complex system for very little gain.

That's why I hope this article shows that there is nothing bad about writing adhoc functionality, even if at first glance one could imagine and desire a more generic approach.

Write the usage code first.

Conclusion

With this example I wanted to illustrate how nice it is to add functionality to an application even when it requires to have access to any feature. And all of it without impacting any of the existing apps logic.

Keep in mind that even if we have access to the entirety of our app state, the composable architecture allows us to break it down in features and compose them into one. So we don't lose any separation of concerns. In the example you can see how managing the entire list of tasks is separate from managing a single task. It doesn't get more separated than that!

I hope you enjoyed this article and learned a little bit. If you are curious about the code you can check this diff in GitHub.

This year I've changed the format and I will keep the notes grouped by their topic instead of session. Over the years I've come to realise that different sessions repeat a bunch of the same content so a topic based system seems more appropriate.

This post will be kept up to date with information with my notes as I keep watching the sessions. Check out other WWDC posts. Last Update: Saturday.

You can find my notes separated by topic below. The sessions in bold are those that I think are a must watch. If you have any other suggestion or comment feel free to reach out to me.

SwiftUI

• 10041: What's new in SwiftUI
• 10048: Build complications in SwiftUI
• 10119: Introduction to SwiftUI
• 10042: Build SwiftUI apps for tvOS
• 10037: App essentials in SwiftUI
• 10185: Visually edit SwiftUI views
• 10649: Add custom views and modifiers to the Xcode Library
• 10031: Stacks, Grids, and Outlines in SwiftUI
• 10039: Build document-based apps in SwiftUI
• 10149: Structure your app for SwiftUI previews
• 10033: Build SwiftUI views for widgets
• 10040: Data Essentials in SwiftUI

I recommend to start with the introduction to SwiftUI. Even if you're already an expert in the framework is a good refresh of the cool technology we have in our hands.

There is a lot of new things in SwiftUI, it definitely feels like the improvements that we were all expecting. I plan to make a proper deep dive once I've watched all the sessions. I don't want to release something that may be wrong, so I will wait for the end of the week. For now here's a summary of what's new!

• New API for Scenes and Apps :
  • WindowGroup, create new windows in iPad, macOS (automatically gives a New comment)
  • SettingsGroup
  • DocumentGroup, document based apps (automatically gives a Save command)

• @StateObject lets SwiftUI manage the lifecycle of the model, its tied to the View (not the struct) lifecycle. As opposed to @ObservedObject that doesn't manage the lifecycle for you (a.k.a. will be recreated every time). @SceneStorage keeps and restores the state for a Scene. @AppStorage does it for an entire app (user defaults). Use this just to persist the UI state of your app, your data should still be persisted as part of your model layer.

• Event sources: User interaction, onReceive, onChange, onOpenURL, onContinueUserActivity, closures run on the main thread.

• .commands modifier

• and .keyboardShorcuts that can be used with Buttons too!

• Launch Screen with just the Info.plist. Bye bye storyboards!

• Lists become outlines by using the children KeyPath para meter.

• LazyGrids are composed with ScrollView (not with List)

• Toolbar and ToolbarItem

• semantic placements and positional placements

• Label adds semantics to Text + Image, but you can use any other views.

• help tooltips on macOS, accessibility hint for the rest of platforms.

• ProgressView, linear and circular styles.

• Gauge only watchOS. I don't get why they don't ship the same UI everywhere :(

• Other system frameworks provide SwiftUI views

• matchedGeometryEffect lets you animate a view between “screens”. This is amazing.

• .clipShape(ContainerRelativeShape().

• Custom fonts supported in text that automatically scales. You can even specify a relativeTo parameter to scale int he same way that a specific system style, by default is relative to body style.

• @ScaledMetric scales other numbers based on the dynamic type accessibility settings. You can pass a relative to like with custom fonts.

• Text now can interpolate Images and other Text.

• ContainerRelativeShape() takes the closer shape from the parent including corner radius. Very useful to make sure your radius is the same as the system you're running on, ideal for widgets.

• accentColor for macOS and AppAccentColor in the asset catalog for all the platforms. listItemTint for list items or sections. Switch and other control styles now support specific custom accent colors.

• Link opens the url with Safari or universal links. Ideal to use in Widgets to open the App. The environment now has a openUrl` that lets you open a URL manually.

• New UTType framework. It helps with drag and drop support.

• CardButtonStyle for tvOS effects.

• tvOS has a bunch of new focus APIs for SwiftUI.

• LibraryContentProvider protocol to include your views in the Xcode Library.

• One cool thing about @StateObject in an App struct is that Xcode knows about it and doesn't initialise the model when running under previews.

• If you want assets or tests data only for previews use Xcode's Development Assets option.

• Xcode previews work on device and update immediately. And you can have previews in multiple devices at the same time. You even have an icon on Springboard to go back to the last preview.

• One thing I'm very glad the SwiftUI team says clear: your view struct initialisation should be cheap. Don't perform heavy work in there, use events to trigger those side effects.

Swift

• 10170: What's new in Swift
• 10169: Explore logging in Swift
• 10165: Embrace Swift type inference
• 10217: Explore numerical computing in Swift
• 10648: Unsafe Swift
• 10167: Safely manage pointers in Swift

What's new in Swift is worth watching but it doesn't add anything that we didn't know about the language, the beauty of open source! If you're interested in some deep dives check out my Following Swift Evolution videos.

Lots of nice improvements for the language coming with Xcode 12 (Swift 5.3)

Something that was not clear from the session is if the new SwiftSystem framework would be part of Swift.org or a private Apple framework. Ted has confirmed that it will be part of the open source project.

New Swift logging APIs on Xcode 12. It uses compiler integration to be really performant. Numeric types are redacted by default. use privacy: .public in string interpolation to disable that. It includes log levels. Logs can be retrieved on the console app or streamed live, also in Xcode. String interpolation has many things like fixed with with padding and formatting capabilities.

Xcode 12 brings a bunch of better error reporting capabilities from Swift type inference engine. The presentation does a great job of explaining what the compiler does to resolve all the type constraints of your code.

Float16 is new to the standard library. The Numerics package introduced a Real protocol that you can use to write generic numeric code. It adds a Complex type that conforms to Real, useful for complex numbers.

I'm so glad that the "Unsafe Swift" exists. It clearly states what safe means in Swift, which is often misunderstood by programmers that have not spend a lot of time with the language. The session slides have very nice tables with the correspondence of C pointers and Swift unsafe API.

Xcode, Swift Package Manager and Playgrounds

• 10169: Swift packages: Resources and localization
• 10096: Explore Packages and Projects with Xcode Playgrounds
• 10654: Create Swift Playgrounds content for iPad and Mac
• 10091: Write tests to fail
• 10164: XCTSkip your tests
• 10687: Triage test failures with XCTIssue
• 10643: Build a SwiftUI view in Swift Playgrounds
• 10221: Get your test results faster
• 10147: Distribute binary frameworks as Swift packages
• 10644: Use Swift on AWS Lambda with Xcode

The new features of SPM are the missing parts that we've waiting for to fully replace other dependency managers. It has been part of the open evolution so no new surprised there. I can't wait to have all of this in Xcode!

Swift Playgrounds is fully integrated with Xcode build system. That allows them to support:

• Swift Packages
• Frameworks in the same project
• Other resources (including machine learning models that need to be compiled).

Build logs from playgrounds are now displayed in Xcode.

XCTSkip for when you want to skip specific tests, even conditionally. Xcode has a third state "skipped" so distinguish from Pass and Error.

New setup and tearDown "with error" functions that can throw.

XCTIssue encapsulates the failure message, file path, line number and others. It now keeps the stack trace of the failure so you can follow it until the point of the assert. Much better than passing #file and #line around, although you may still want to keep that to improve clarity. You can overwrite record(issue) on the test class to do whatever you want with it. This seems like a very nice thing for testing frameworks.

The new option execution time allowance lets you add a timeout to tests so they fail instead of hanging the suite for ever. By default is 10 minutes.

It's pretty cool to see a session about AWS Lambda. The fact that the library comes with a solution for local development out of the box is huge. In my limited experience with lambdas this was a big pain. It's great to work with these technologies from our familiar tools.

UICollectionView

• 10097: Advances in UICollectionView
• 10045: Advances in diffable data sources
• 10026: Lists in UICollectionView
• 10027: Modern cell configuration

The new additions on UICollectionView look amazing. They continue with the modern APIs included last year. Unfortunate I haven't been able to look too much into them since for old projects you can use it and for new ones I've been using SwiftUI.

What I'm more interesting in is the configuration pattern making it into UIKit. I will have to look again at it when new sessions are released, because for now I don't see how it will work with custom views.

Widgets

• 10028: Meet WidgetKit
• 10034: Widgets Code-along, part 1: The adventure begins
• 10035: Widgets Code-along, part 2: Alternate timelines
• 10036: Widgets Code-along, part 3: Advancing timelines

The best thing about WidgetKit is how it's fully using SwiftUI. They use the declarative nature of the framework (your UI is just data) to serialise that and make sure the home screen always has a valid UI to show without loading screens.

Key takeaways:

• Widgets are not mini-apps, they just project your content on the home screen.
• Widget bundles to have different widgets on the same app.
• You should support as many sizes as make sense.
  • supportedFamilies: systemSmall, medium, large.
  • Configuration system is based on intents. The system makes the UI from them.
  • static configuration
  • intent configuration
  • You provide a placeholder view that is used as the default content, without user data. This is usually only used on environment changes.
  • In small widgets the entire view is one tappable area ( .widgetURL). In medium and large you can have different subviews deep links to different parts of the app (Link).
  • Snapshots are used in the gallery so what you see there is your real UI, no mock designs.
  • You can perform reloads by:
  • widgetcenter.reloadtimeline to force a reload from in the app
  • background url session
  • timeline api (similar to the old complications API on the watch)
  • Use previewContext(WidgetPreviewContext) in your SwiftUI previews.
  • Use .isPlaceholder(true) to get a placeholder UI for free. AMAZING.
  • Environment has a .widgetFamily
  • URL Background session completion is handled in the widget itself. onBackgroundURLSessionEvents

App Clips

• 10174: Explore app clips

App Clips are really interesting and I'm curious to see if they become a common feature on iOS Apps.

• App clip experiences are based on URLs.
• Invocation methods: Safari, Messages, Maps, NFC Tag, QR Code and Location.
• They are like universal links URLs handled by app clips instead of a browser. Registered in App Store Connect instead of the existing associated domains file.
• They are mutually exclusively with apps. When the app is installed you need to handle the app clips URLs.
• They are just a standalone app (target) that has access to all iOS APIs (with some privacy restrictions).

Intelligence, Siri and Shortcuts

• 10068: What's new in SiriKit and Shortcuts
• 10086: Design for intelligence: Apps, evolved
• 10087: Design for intelligence: Make friends with "The System"
• 10088: Design for intelligence: Discover new opportunities
• 10200: Design for intelligence: Meet people where they are

Intelligent system experience. "How the operative system works with apps that people use everyday to make the everyday easier for people." It's a platform convention.

• Intents.framework
  • Define, learn and execute.
  • Donations.

Location

• 10660: What's new in location

More privacy controls.

• (iOS 13) Never, Ask Next Time, While Using, Always. The flow from 13.4 has changed!
• Let's the user select precise or approximately.
• This is fully controlled by the user, the app needs to adapt.
• authorizationStatus class function becomes a property.
• A new property to know the accuracyAuthorization.
• New didChanteAuthorization method that covers both dimensions.
• Reduced locations still come on the same delegate but with low accuracy and updated only four times per hour. They contain the user true location but not the exact point.
• Significant location changes API doesn't change much. The amount of deliveries are the same. The timestamps are still accurate, but the location is more approximate.
• Bacons and regions need accurate access.
• New constant to ask only for reduced precision.
• If the user only shares approximatly location but you need full you can:
  • send user to settings
  • prompt for temporary full accuracy. The purpose must be in a new dictionary of the Info.plist.
  • asking only when is needed is better for the user.

iOS

• 10668: Meet Nearby Interaction
• 10052: Build with iOS pickers, menus and actions

The U1 chip is accessible by devs with the Nearby Interaction framework.

• Both devices need to grant permission.
• Get distance and direction.
• Have different sessions with different devices at the same time.
• You need to share the discovery token on your own, with multi-peer connectivity or a backend service.
• It works in the simulator with different simulator windows.

Minor UIKit design updates across standard controls. Menus may be a replacement for UIPicker in many contexts. UIPageControl supports unlimited pages and custom icons. New color picker. UIDatePicker has a compact style and a full calendar. Menus UIMenu on controls triggered by a long press, or you can trigger the menu directly with showsMenuAsPrimaryAction = true. Navigation back button now has menu with the history. UIAction menus can be added to bar button items.

macOS

• 10104: Adopt the new look of macOS
• 10056: Optimize the interface of your Mac Catalyst app

I really like the new macOS design. Some details need to be polished IMO but the new style feels very fresh.

• Full height sidebars.
• Accent color tint fully supported in sidebars.
• Unified toolbar style.
• New search bar item that collapses when there is no space.
• New multicolor accent color that lets app use their own tint. Specified in Info.plist and Asset Catalog.
• Large control size.
• Text Styles come to macOS!
• SF Symbols come to macOS!

Enabling the optimised mode for Mac on catalyst apps seems to be a very nice way of migrating your iPad app for the mac.

iPad

• 10206: Design for iPad

Make your apps profit from the iPad size, don't just make it a halfway product between iPhone and Mac.

• Show more content: Sidebars help you fill the screen with content, faster navigation and easy drag and drop. Tweak the density to better use the screen space.
• Keep the context: keep people in context, keep controls at the same level instead of overlays.
• Immersive experience: big display but with only your content so you can focus on it with custom layouts.
• Keyboard shortcuts, pointer/trackpad/pen/scribble. Combine multiple inputs, like keyboard with touch or pencil and touch.
• Sidebars with 3 column layout in all iPads.
• Keep tabbars for compact mode and iPhone. Don't just move the tabs into a sidebar, enrich the sidebar with shortcuts to the most important content, but don't overload it with everything.
• Don't mix sidebars and tabbars.

Symbols and fonts

• 10207: SF Symbols 2
• 10175: The details of UI typography

SF Symbols supported on macOS! The app lets you now organise in custom categories. Check the app for the names. Some symbols have changed the names to be consistent.

SymbolConfiguration/.imageScale lets you change the scale of the symbol independent of the size of the text/icon. Label is handy for combining text and image in one go or even interpolating Image in Text string.

Some symbols are localised automatically.

Symbols are now multicolor. isTemplate false to have the multicolor variant.

Apple is moving to a single font SFPro instead of having to download multiple files for all the variants. Thanks to variable fonts. Design tools will let you tweak granularly the weight and optical size. In code is all automatic.

If you need to make letters close together don't use kerning, is better to use tracking for that. But is just better to enable allowsTightening. The font has tables that use the proper tracking based on size, etc.

Use text styles, this year macOS has support for them too (although without dynamic type).

And if you need a little more visual difference you can get their descriptor and apply a symbolic trait.

The system automatically adds more leading (space between lines) to locales that have a lot of vertical letters, like arabic. You can see how the default controls get taller. Or in watchOS the leading is reduced to show more content. You can apply the same variations to your text if needed.

And you can use SF rounded, NY or SF mono with these traits too. You can also use these font styles on webkit.

watchOS

• 10046: Create complications for Apple Watch

Complications are complicated.

HealthKit

• 10182: What's new in HealthKit
• 10661: Getting started with HealthKit

Very short video. I really like the new format!

• Symptoms support.
• Electrocardiogram exposed to HealthKit.
• Mobility data types.

AppStore and In-App Purchases

• 10659: Introducing StoreKit Testing in Xcode
• 10651: What's new in App Store Connect

It's pretty cool how testing can be when Apple gives us a proper framework. It completely changes the development flow for in-app purchases.

iOS 14 has a separate account slot for sandbox user accounts.

Family sharing for subscriptions and other in-app purchases.

App Metadata and analysis tools are now part of the App Store Connect API!

Web

• 10665: Meet Safari Web Extensions

Safari has extensions again, based in standard web technologies so people can use the same code they use for other browsers. More privacy controls and being able to be sold on the App Store. I still find weird that you have to use Apps to distribute extensions, especially when the App doesn't do anything.

First of all, I love the new format.

Seeing the presenters in a "real" environment, so beautiful as is Apple's campus, is way more engaging than dark rooms and slides. And the fact that they can now be flexible with time is so welcomed. If they don't have one hour of content they just cut it short. It feels like my 2x technique is not that necessary this year.

Looking at the announcements and session titles it feels like there was not too many new things. At least I don't have the feeling that there are a lot to keep track of.

Because of that, and because of the new format and short videos, this year I took a slightly different approach for my note taking.

In previous years I was taking notes of every little detail and I ended up being overwhelmed. This time I'm just taking notes about what I find really important. Even for new frameworks I think their usage is quite obvious and not many notes are needed. And with the videos being so short rewatching them is not a big deal. We'll see how it goes!

I've created WWDC20 session notes post that will be updated constantly with the new things I find interesting.

And this morning I've woken up very early to reflect on the announcements and give my view of the keynote. You can watch the following video to get the full picture.

I'm very happy with the keynote. There has not been much revolutionary things, apart from the start of a new Mac era of course. I'm fine with a year of evolution, having to deal with revolution every year is too much. And we already had last year for that.

What I was more grateful for was the format of the keynote. I was very afraid they wouldn't make a good show. During the pandemic I've seen other major companies do a very poor job with their conferences, and I didn't want that to happen to Apple. Why? Because for me WWDC is all about the show. It's not just about the material. New frameworks, documentation, etc. All of that is nice but can happen any day for any technology. What makes this week special is how I enjoy watching all of this unfold from my couch with popcorn.

And I have to say, I really enjoyed this new format. The high quality production makes up for the fact that is not live. And I think it's even better in some aspects. It lets the presentation get straight to the point and be free to make cuts and edits that make sense for the flow.

Furthermore, now everybody has realised that watching the keynote from home has its advantages. I've been having fun seeing how everybody was excited for a "remote WWDC" when for me (and the majority of people) it's always been like that. Nothing has changed this year for us, except the got a much better format.

Now I need to start preparing my J.O.B. for the summer and wait for the sessions to show up at Californian time. I can't wait!

One small inconvenience (well, not so small since I'm writing about it) is the amount of places you need to change the code to make it compile after a change.

As an example lets take a look at the code that is given to us by Xcode's default templates.

The SceneDelegate has code to initialise the root view of your application:

...
let contentView = ContentView()
...

And the same code can be found in the PreviewProvider of that ContentView:

struct ContentView_Previews: PreviewProvider {
    static var previews: some View {
        ContentView()
    }
}

This can become quite an annoyance since every time that you change your ContentView initialiser, or any other change that affects the shape of your view types, you have to tweak the code in the scene delegate and in the preview provider.

In early stages of development, while you're still discovering your application, this can happen quite often. My personal recommendation is that you change this structure until you're comfortable enough with your app that you don't do such foundational changes that often.

The trick is simple. Just treat your preview code as the source of truth.

Change the line on your scene delegate to:

let contentView = ContentView_Previews.previews

In this way, every change that your view needs will only need to be done in the preview code. This makes the iteration cycles even faster, which is crucial on that discovery phase.

If you want to make sure that you don't ship preview code to your users you can just surround that line with an #if DEBUG and use the real view initialiser on release.

I hope this little trick serves you well ;)

As I'm starting to write this piece I have to admit that the excitement levels are not even close to what they were in the previous edition. Last year was the most important WWDC since Swift's release, not only for SwiftUI, but also for Dark Mode and Catalyst.

Reflecting on it a year after I still feel the same: last year's WWDC was the start of a new era. I don't expect this year to be anything close to that, but still, there are some things that one always expects.

SwiftUI... 2?

Last year we got SwiftUI, the declarative UI framework that I've been waiting for years. And it was much more that what I expected.

"SwiftUI 2" is a name that has been thrown around lately. I don't get why suddenly we have decided to add numbers to frameworks. Maybe people adds a number to indicate they really want a big change?

Of course I want improvements on SwiftUI, but I just want evolution not revolution. Some people complain about things that are just how the system should work. I understand that it's still early days and we need to adapt, but I want to give a big kudos to the Apple folks because the framework is very well done.

But of course there are things that need improving! The first of them, cleaning up some bugs. There are things that are just broken, specially around navigation. You can workaround with ugly alternatives but that's not ideal. I hope Apple has put effort on polishing this rough edges so we can enjoy this amazing framework without worrying about its problems.

In terms of API surface I hope they add some of the missing pieces that anybody coming from UIKit/AppKit would miss. It's true that they did an amazing work around interoperability with UIKit/AppKit. You can reach into those worlds and use any existing UI from there. But having to do this work should be reserved by edge cases, the basic building blocks that already exist should be available directly in SwiftUI.

The TextField is a good example. The new API is very nice and fits well in a declarative paradigm. But it's also missing quite a lot of functionality. I don't really mind about the look'n'feel, SwiftUI lets you customise things quite easily. But what we can't do is add functionality. For example, there is no way to focus programatically a textfield, we can't make something a first responder. And to be honest, I don't really want the complexity of the responder chain, we can leave that in the past. I just want a way to indicate via state that a text field should be focused.

A UICollectionView like component is the other necessary thing. A lot of people argues that there is no reason for it, which I completely disagree with. It's true that you can roll your own grid layout, but a collection view is not just a gird layout. The magic of that class is that it handles all the reusing for you. Is the same reason why SwiftUI has a List when you can do the same with a ScrollView and a ForEach. The former deals with reusing each item in the list, the latter is just scrollable content. And not only that, but last year's additions to UICollectionView were too great, giving, finally, an answer to a common UI pattern in many Apps. Is probably the only reason why I look back at UIKit with envy eyes. We should have that facility in SwiftUI too, without having to roll your own.

As a side note, I was quite disappointed when I saw the List view to be honest. In UIKit land UICollectionView superseeds UITableView in everything. There is practically no reason for the later one to exist. Many of us were for the day they deprecate UITableView and just move any functionality into an improved flow layout. So I'm quite sad they repeated the same mistake in a brand new UI framework.

We'll see what they have been cooking for a year ^^

Navigation

Better integration with deep linking support is something I already wished for last year. I hope is something that Apple is actively working on. Nowadays is a crucial part of any medium complex application.

SwiftUI actually makes navigation way more simple than ever before (when it works without bugs of course). You don't really need any complex flow controllers/coordinators/whatever you call them.

The fact that your entire UI, including its navigation, is a pure function of simple objects makes it really easy. You just need to drive it from your state. It's hard to make it simpler than that.

That said, it would still be nice to have some reusable functionality to incorporate this fully into the OS with deep linking, user activity, etc. I'm open to be surprised.

Tooling

Tooling is one of the aspects that I wish got better, much better. Swift it's part of that but I talk about Swift constantly so I don't want to repeat myself here. The future we're expecting with Swift 6 covers a lot of my desires so I prefer to focus on other things.

One interesting thing I'm waiting for is to see if Apple has something new around Swift being secretly developed. Recently there has been some, unfounded in my opinion, feelings about the Swift Core team accepting features just because Apple needs them internally, ignoring the community's feedback. That's a big topic that I don't want to get into, but I just want to see the discussion resolve.

One thing I do want to see Apple taking more seriously is open source tooling. Since the Swift project was open sourced a lot of tooling is being developed on the open. But because Xcode is still close source it's quite hard to notice. It also doesn't help that the IDE, the main tool we use, is released with such a long cadence. This all contributes to the feeling that we don't really see any of those improvements and we can't even try what's coming easily.

Toolchains help a bit with trying new Swift versions, but they have many issues with Xcode. Every time I want to work on a video about new Swift features I spend hours fighting Xcode and Playgrounds. That said it would be very nice it we could try pre-release version of other tools like SPM integration.

And of course, one can wish for Xcode being open sourced and having a decent plugin system. Let's keep hoping :)

Apart from that I just hope performance and bug-fixing is a priority for the tools team.

iCloud and Swift

As I said last year I really want to be able to run Swift functions on iCloud. Every year that passes this becomes a more obvious missing feature.

The improvements on the Swift project that are happening recently and that are planned for this year have a very positive impact on Swift on the server. We're seeing other companies offer ways of running Swift very easily so it's a shame that Apple hasn't done the same yet.

Apple should do something more to contribute to this space.

Old classics

There are many things that I'm still hoping for, you can read more about them in older posts.

• SwiftCore, Scripting with Swift and the usage in Shortcuts.
• Custom watch faces
• Custom View Controller and Non-UI Extension Providers
• More control on App version updates

Conclusion

Having low expectations before a WWDC is nothing bad, quite the opposite. I'm gonna be pleasantly surprised with any new thing they announce, and that's exciting by itself :D

What are your feelings about WWDC'20? Are you waiting for something not mentioned here? Are you hyped? Tell me more!

Subscribe to my channel to be notified when new videos about Swift Evolution are released.

Generic constraints

To understand the changes introduced by Swift 5.3 we first need to understand the power of the where clause. This keyword is mostly used to apply constraints to generic types. So let's start by defining one of such types.

struct Wrapper<T> {
    let value: T
}

Wrapper is a simple type that wraps a value of any type. The wrapper itself is generic over the type of the wrapped value.

In Swift you can add methods to a struct without any problem:

struct Wrapper<T> {
    let value: T
  
    func someFunc() { ... }
}

This method is gonna be available to all instances of that type, doesn't matter which specific type we use. But more often than not, the ability of having a generic type opens the doors to offer functions only when the wrapped value is of a specific type.

For example, lets suppose we wanted to have a function that requires Equatable conformance. We can add this functionality to our type only when the wrapped value is equatable.

extension Wrapper where T: Equatable {
    func equatable(other: T)  {
        // value == other
    }
}

In the body of that function you're free to use == because the type system knows that self.value and other are equatable, because T is constrained to conform to that protocol.

That's what where T: Equatable does.

Of course we can do the same with another protocol.

extension Wrapper where T: Comparable {
    func compare(other: T)  {
        // value < other
    }
}

The limitations

One of the limitations of this system is already visible in the previous snippets. The where clause can't be applied to the function definition itself. We need to create an extension that contains our function and apply the constraint to that extensions. This is not a major limitation in most cases, but conceptually it would be very nice if you could express exactly what you want.

extension Wrapper  {
    func equatable(other: Wrapper) where T: Equatable {
        // value == other
    }

    func compare(other: Wrapper) where T: Comparable {
        // value < other
    }
}

The above snippet is equivalent to the previous ones. The difference is that we moved the generic constraints to the function definitions themselves. So we can have all the functions in one extensions with their requirements specified individually.

Another advantage of this is that you can still add the constraints to the extension itself, which gives a lot of flexibility in terms of reusing them.

For example we could add a third constraint to the above system just by adding it to the extension:

extension Wrapper where T: Hashable  {
  ...

Now this constraint applies to the entire extensions and is an added requirement to the individual constraints specified on each function.

Conclusion

As you can see Swift's type system is quite powerful and with this addition on Swift 5.3 it becomes even more flexible. This seminally small addition lets us express our type requirements in the most appropriate way for our use case.

You can watch the video to see more examples of how this can be used and how it impacts the usage side of your types.

Subscribe to my channel to be notified when new videos about Swift Evolution are released.

Up until now there were multiple ways of adopting conformance to this protocol, each one with different degrees of inconvenience.

Even if Swift 5.3 solves all of them, it's still useful to know these techniques for the rare cases when you want to implement the conformance manually in order to customise some behaviour.

Comparable Raw Values

The first trick and the one that requires less code is to bake your enum with a comparable raw value, like an Int.

enum Priority: Int, Comparable {
    case low
    case medium
    case high

Having access to an integer makes it really easy to implement the comparison function.

     static func < (lhs: Self, rhs: Self) -> Bool {
       return lhs.rawValue < rhs.rawValue
   }
}

The problem with this is that now the users of your type will be able to treat it like an integer by accessing its raw value. This is something that you rarely want and it should be avoided.

Private Raw Value

The alternative is to keep the raw value private. This can't be done automatically so it adds some boilerplate.

private var comparisonValue: Int {
    switch self {
    case .low:
        return 0
    case .medium:
        return 1
    case .high:
        return 2
    }
}

static func < (lhs: Self, rhs: Self) -> Bool {
    return lhs.comparisonValue < rhs.comparisonValue
}

This lets you keep the comparison function simple and without opening the type to misuse.

Hardcore comparison

Another alternative, and probably the most correct one, is to implement the comparison without using any proxy value, by just checking the cases themselves.

private static func minimum(_ lhs: Self, _ rhs: Self) -> Self {
    switch (lhs, rhs) {
    case (.low, _), (_, .low):
        return .low
    case (.medium, _), (_, .medium):
        return .medium
    case (.high, _), (_, .high):
        return .high
    }
}

static func < (lhs: Self, rhs: Self) -> Bool {
    return (lhs != rhs) && (lhs == Self.minimum(lhs, rhs))
}

Conclusion

As you can see the automatic synthesis of Swift 5.3 it's very welcomed. Without it we can't avoid adding some boilerplate and even hurting the API of our type. You also have to consider that if your enum has associated values it adds another layer of complexity.

So use Swift 5.3 features when possible, but keep these techniques on your toolbelt for those rare cases where they may be necessary.

"This isn't a Louie Mantia color."

(That means it isn't 5° increment for Hue or ⅛ of 100% increment for Saturation and Brightness.)

— Louie (@Mantia) February 25, 2015

I immediately thought that it would be a cool little project to build a color picker with SwiftUI that followed those rules. I just wanted to have some fun and practice a bit.

That ended up being one of the things I worked on my streams for a couple of sessions. Now it's in a decent state and it does what I wanted it to do. So I'm done :)

But before I move on to something else I wanted to open source the code for demonstration purposes. Is not a production ready application but I think it serves as a simple example of what SwiftUI can do.

One thing I like about this little application is that it is so simple that it doesn't need any complex architecture, not even a view model! It's really nice to do simple things sometimes.

You can check the code on GitHub alexito4/mantia-color-picker.

I want to thank Brandon and Stephen for giving me early access to the library. That has allowed me to get my hands dirty with the code and to make this content in order to hype more people ^^

If you want in-depth material their videos will do a better job than me. Consider this a What's the point? from an outsiders perspective.

Building a macOS App with TCA

The streamings I've been doing are about developing a macOS application with SwiftUI and the composable architecture. I've focused more on showing what the architecture can do than on the app itself so it should be a good way of seeing what the library is capable to do.

You can see next a list of the livestreams I've done, together with clips from them showcasing specific things.

Livestreams

• Building Six! App PART 1
• Building Six! App PART 2

Part 1 serves as an introduction to the application I want to make, some SwiftUI and main concepts behind the architecture. I had some connection issues so we had to stop short.

Part 2 continues with the development of the application but focusing more on 3 things that I wanted to showcase. I've made clips of those examples so you can watch directly how the architecture gives us elegant solutions.

Unit testing example

This clip shows how unit testing with this architecture is not only more simple but also more powerful and fun. And making unit tests fun to write is a huge endeavour.

High order reducers and debugging

This clip serves as an introduction to the concept of high order reducers. It also shows a specific high order reducer that makes it really easy to debug your application and to get a feeling of how a feature works without looking at the code.

Building Time Travel from scratch under 1h

When I announced that I wanted to build time travel into the application I was not really convinced I would pull it off in a livestream. But it was totally possible! This only speaks to how great are the powerful concepts behind TCA and how flexible it is. I can't wait to have a more polished version of this on every application!

Method Dispatch

Method dispatch is the system of the language that is used to decide what method implementation should be used in a polymorphic scenario. Swift has multiple dispatch systems that are used depending on the kind of type and the knowledge the compiler has about it.

Static dispatch is used when the compiler knows at compile time the concrete type being used and exactly which method implementation to use. This is fast at runtime and easy to understand.

Message dispatch is used when Swift needs to interact with the Objective-C runtime. Objective-C uses message passing to invoke all the methods so Swift needs to follow the same pattern when it needs to bridge to code that comes from that language.

Dynamic dispatch is used when he compiler can't know at compile time the specific method implementation that needs to be used. This is commonly seen on class hierarchies and protocols were the concrete type is not known until runtime.

This is the scenario we are interested in today.

Protocols with default implementations

To examine the issue we first need to prepare some examples. We need a protocol with a method requirement that is implemented in an extension.

protocol Model {
    func execute()
}

extension Model  {
    func execute() {
        print("Default implementation")
    }
}

Note that the method we implement on the extension is part of the protocol definition. We could add methods that are not part of the protocol but that behaves in a different way.

This is easily one of the most powerful features of the language. Thanks to the combination of protocols and extensions we can provide functionality for free, while still allowing those types to implement custom more specific code. This is a design that is very common on the standard library.

To illustrate the part where the compiler can't know until runtime the specific types we're using let's make a class that calls the method on a property defined with the protocol type:

class Controller {
    let model: Model
    
    init(model: Model) {
        self.model = model
    }
    
    func execute() {
        self.model.execute()
    }
}

As you can see when execute is run, Controller only has access to a property of type Model. The compiler can't know what specific type we're using, it just knows is a type that conforms to that protocol.

Now let's prepare two conforming types that illustrate Swift dispatching behaviour:

class ClassUsingDefault: Model {}

Controller(model: ClassUsingDefault()).execute() // prints Default implementation

This first type doesn't implement the method itself, instead it relies on the default implementation provided by the extensions.

class ClassWithImplementation: Model {
    func execute() {
        print("ClassWithImplementation")
    }
}

Controller(model: ClassWithImplementation()).execute() // ClassWithImplementation

This time we have a type that is implementing its own version of the protocol requirement. We want this implementation to take precedence over the default implementation and indeed that's how Swift behaves.

This is the behaviour we want and expect from dynamic dispatch. Thanks to Swift's runtime we're able to use default or concrete implementations whenever we want.

The danger of inheritance

Now let's take a look what happens when you include class inheritance into the mix.

class SubclassOfSuperclassThatHasImplementation: ClassWithImplementation {
    override func execute() {
        print("SubclassOfSuperclassThatHasImplementation")
    }
}

Controller(model: SubclassOfSuperclassThatHasImplementation()).execute() // SubclassOfSuperclassThatHasImplementation

This time our type is subclassing a superclass that has a concrete method implementation. As expected the compiler dynamically finds the correct method to execute.

Pay attention to the method definition. The compiler is forcing us to write override because we're not only implementing a method required by a protocol, we're also overriding a method implemented on the superclass.

This all makes sense and works as expected.

Now let's implement a class that inherits from a superclass that relies on the default method implementation from the extension.

class SubclassOfSuperclassThatUsesDefault: ClassUsingDefault {
    override func execute() { // ERROR: Method does not override any method from its superclass
        print("SubclassOfSuperclassThatUsesDefault")
    }
}

When writing this you can already see something weird. The compiler tells you that using override is not allowed. This is correct because the superclass doesn't implement that method.

But even if it makes sense it's a little weird. You know the superclass conforms to a protocol, so the method must be on the superclass set of callable methods. That is correct but still Swift doesn't consider that you are overriding the method because is not specifically defined on the superclass.

And this is were the problem resides.

Let's trust the compiler error and remove the override. We still want a custom implementation of the method but let's agree with the compiler that we're not overriding anything from the superclass.

class SubclassOfSuperclassThatUsesDefault: ClassUsingDefault {
    func execute() {
        print("SubclassOfSuperclassThatUsesDefault")
    }
}

Now the compiler is happy. So let's try to use this and see what dispatching behaviour we get.

Controller(model: SubclassOfSuperclassThatUsesDefault()).execute() // Default implementation !!!!

🚨 💣

We get the default implementation. Even if we've written a concrete method on our type, in the same way we've done on all previous cases, we still get the default implementation.

This is because Swift only checks the superclass when deciding if a type has concrete implementations of a protocol requirement. Since our superclass doesn't have that, it relies on the default implementation, the compiler doesn't even check the subclasses.

The worse part is that from a user's perspective there is no way to fix this. You can't stick a fancy keyword on your method and expect it to work. It's also really subtle and if you're not paying attention it's very easy to introduce bugs with this. The good part is that you can't break it by removing a superclass implementation since the compiler will warn you about the override keyword.

This is considered a limitation of Swift (as of 4.2) and is tracked as a bug. There are also conversations on the forums that discuss a nice solution for this scenario.

Conclusion

Protocols are very nice in Swift, and together with default implementations on extensions they become an amazing feature of the language. Almost like a superpower. And you know what they say about that.

This was a tough decision. Since I moved to Gatsby almost two years ago I realised that it was not a good investment of my time to just rebuild websites for the sake of it. I would much rather prefer to sit down and spend that time writing articles.

Gatsby was great and I learned a lot, so there is nothing bad about that. But, for me, it has the same issue that the previous generators that I used had. All these site generators are build on ecosystems that change at a fast pace. That may not be an issue if you are part of the ecosystem and keep up with it, but for me, as an outsider, it's always been a problem. For example, months after I released that version of my site Gatsby 2 came out and I had to spend some time updating it. It was not a big deal since I still had some fresh knowledge about the system, but it was not a walk in the park either.

For a long time after that I was subconsciously afraid of touching the site. I knew I would have to lear again the ecosystem just to have an up to date code before I could add any new functionality, because after some time of not updating nothing works. This resulter in almost 2 years of no updates on the site.

This is not a critique to Gatsby, the same happened with Jekyll before. Is just an observation of how fast things move in certain ecosystems and how software breaks if you are not on top of it almost daily.

So that's why I finally took the decision of migrating the site once again. This time to Publish a static site generator made in Swift. How is that gonna be different? Well, I'm in this ecosystem. I breath Swift. I keep up to date with the language evolution, write posts and make videos about it. Software would probably break anyway, but I will know how to fix it without even thinking about it.

I took some time before starting the migration exploring Publish. I know its internals and I'm comfortable with them. I feel more in control of the situation now than ever before.

New features

This change has allowed me to finally develop some new features that I wanted for a while. My site has always had some special requirements with a taxonomy system. This is because one very important thing to me is that this is NOT a site about one exclusive topic, even if that's the worse decision for marketing purposes ^^'

This is very important to me since I like to share things about different topics and thus is hard to keep it interesting for everybody. __This is a personal site after all__. It's something I always struggle as a *content creator ™️*. Dedicated Pages offer a good balance.

— Alejandro Martinez (@alexito4) April 12, 2020

But thanks to Publish flexibility and a little Swift love I've been able to fully integrate my custom taxonomy system into the site and I'm very happy with the results, which in turn has allowed me to create specific Topic pages.

For example you can see a page only about Swift. That's probably the main topic of this site so it was really important to me to have a URL to which to point to. But if you don't want to focus only on Swift, you also look at the broader Development page. Even more, I was able to create a page to show case my companion articles to my videos.

Hopefully this helps you a bit to navigate the site and focus on the topics you are interested in.

There are other small features across the site that I will be detailing a bit more on future posts so stay tuned for more Publish articles ^^

Deployment

This is still a static site so the deployment keeps being straightforward. I keep using Netlify because it has given me great results without any problem.

One thing to note is that Netlify still doesn't officially support running Swift during deployment (they have a PR for that) but it is not a big deal since you can generate the code locally and just push the Output folder.

One great thing is that to switch the DNS to the new site I just had to change one configuration on their site and that's it, everything worked in seconds. And thanks to their redirect system I've been able to switch the slugs of my site (they don't contain dates anymore) while keeping all the previous links working!

I can’t recommend Netlify enough, the service is great and with all the basics that you need for free.

Conclusion

The switch as taken a couple of weeks to complete (mostly fighting CSS) and it has been really enjoyable without any major roadblocks. I’m more comfortable with the current setup than ever before and I'm really happy with that.

There are some improvements that I expect to be releasing soon and some articles explaining some specific custom parts of the site in hopes to help everybody that wants to use Publish. You can check the Publish tag or even the Youtube playlist to know more.

An in-app debugging tool

FLEX is a library that adds an in-app debugging menu with a bunch of tools into your project. This is really helpful when you’re on the wild and want to check something on a real device. As developers, we’re probably more comfortable using other tools like LLDB, but this is for another context. An in-app debugging tool is way easier to use so it opens the gates of debugging to other people, like your QA and design teams or other stakeholders.

The library has constant activity with many developers using it and with improvements coming constantly.

Before you go and integrate the library make sure you read one important detail. This library is not designed to be released to the App Store so you need to make sure your installation process doesn't include it for release builds.

I personally think that FLEX is one of the best libraries for this. In-app debugging libraries should offer a basic set of tools that are generally helpful, but also offer a powerful API to extend it with custom tools that are easy to write and feel as integrated as the default ones.

The list of tools included by default with FLEX is not short, I won't go over them one by one but there are some that I would like to give special mention since they are the most useful to me.

Included tools

One of the most used tools that FELX includes is the network debugging utility. It’s something that you use constanly if your App connects to an API. Of course you can use more sophisticated tools like Charles, but having the ability to debug network calls in the app itself without requiring any external setup is invaluable.

Not only you can see all the information of a request, but also its contents and even copy a curl request to easily send it to other developers. It makes debugging API related issues so much easier!

Another really powerful tool is its UI hierarchy introspection. You can see all the views that are on the screen and explore the classes and data behind them. For example, this allows you to easily check that the content of labels or margins are what you expect. This is specially useful to allow designers to double check your work directly in a device.

But the UI introspection tools not only lets you check your UI, it also lets you change it! This is really interesting when somebody without access to developer tools wants to do some tweaks into the UI to see how it would look.

This ability of changing data at runtime is not only available for the UI, you can use it in many other tools offered by FLEX. For example the Database and NSUserDefaults exploration tools benefit a lot from this, letting you tweak on the fly user's data.

There is a tool for pretty much anything you want to do on your iOS App. And thanks to the Heap Explorer if there is some object that doesn't have a special menu, you can just search it yourself and tweak it.

Customisation

But of course every app is unique and it’s very likely that you have some set of data or information that you want to expose to QA or other alpha testers. You can probably access that data with the existing tools but sometimes is much better to build some simple custom UI that shows your data in the way it makes more sense.

I’ve been using custom tools with FLEX for years and recently decided to open a GitHub issue with some feedback on how the API could be improved. If it was good enough I can’t wait for it to be even better!

The nice think about extending FLEX is that the only thing you need to do is create your custom UIViewController and register it to the menu. That's it.

FLEXManager.registerGlobalEntry(withName: "Fancy custom tool") { hostViewController in
    let viewController = ...
    hostViewController.present(viewController, animated: true)
}

Another powerful thing you can do is register custom keyboard shortcuts than can speed up a lot some flows. For example you can bind the key o (out) to an action that logs out the user from the App. Really useful for when you are working on a feature that forces you to switch accounts often.

But not everything you want to do may need a custom screen. Sometimes is useful enough to just have a button that triggers some code. For that you can register custom actions on the menu. They look the same as other entries but don't open a screen, they just let you execute code.

To do this I had an ugly workaround for years. But now (still in PR) this functionality is exposed with an official API.

My tools

I imagine that by now you already have some ideas on how to help your peers with amazing tools. But, just in case, let me show you some of the tools I've developed over the years to help my team.

On our app we have feature fences that allow us to merge changes that are still in progress without the risk of impacting our users in production, but still letting testers try them. To toggle those fences on and off we build a simple screen that lists them and updates the local device flags.

One thing I developed around 2018 was an in-house UI component framework, it improved the team's UI development flow so much that is one of the things I'm most proud off. But something I didn't anticipate is the lack of discoverability. When you want to make sure that components are reusable and avoid making new similar ones all the time is crucial to have a way too easily see the ones we already have. To help with this an improvement was made to the components to support examples with the different states so it was easy to have a catalog with all of them. So the HubKit examples entry you see on the menu is a screen that is automatically generated via a combination of protocols and code generation.

Analytics tracking libraries are always a pain to work with. And even if they sell realtime updates on the Dashboards that's rarely the case. To help us implement and test events I added a screen that shows the events and screens the App is capturing. This helps testers discard issues on our side very easily.

This screen is nothing fancy in terms of design but it gets the job done. And it even has some level of complexity with the filters and segmented control. But it was developed in a very small amount of time, the secret? SwiftUI 😃.

SwiftUI is ideal for this. And since this is not going to production you are more flexible in terms of using cutting edge frameworks. In fact this is the first SwiftUI code that we have on the LifeWorks app. I recommend you to give it a try, SwiftUI for tools is amazing.

Other interesting tools that we have are actions linked to shortcuts. Clearing the image cache is very useful when you want to make sure the initial impression of a screen is as nice as it can be. We also have an action that triggers a local notification with a payload that lets us test the behaviour of the app without having to force a real notification to come from APNS.

I've already mentioned the logout action, but we also have a login action that triggers what we call the magic login (or is the witchcraft one?). This is probably the most used action of all by a long shot.

Conclusion

If you haven't integrated FLEX on your App yet you are probably wasting somebody's time. This tool is a real time saver just with the default tools that it includes.

But building tools in a team is something really important that helps keep productivity high, so the fact that FLEX offers a menu to have all these things integrated is why I consider this an essential tool.

If you have other library preferences or ideas for custom tools feel free to send me a message 😉

Enjoy your new superpowers!

Because the CSS file is part of the Resources folder it needs to be copied over to the Output every time you modify it. But not only that, you will also need to perform the difficult task of hitting refresh on the browser. This may seem trivial when the site generates in milliseconds, but the more complexity you add the slower is gonna get and breaking the flow of work is the worse that can happen.

Luckily you can use the simple technique of using SASS for your site. It will give you live reload but also open the gates to a more powerful (and sane) CSS.

Watch the video to get the full picture of the issue and how to solve it.

To make this work you will need to install SASS and make sure the library is accessible on your computer. Once you've done that the Publish SASS Plugin should work out of the box.

I recommend you that you use compressed: true when deploying your site so the CSS is minified. It you save you some bytes!

With the live reloading css, in combination with live reloading the HTML, we have a decent solution for our development workflow.

Make sure to checkout the Publish tag for more content about this static site generator.

You can watch the video to see how it works and how is implemented.

You can check out Browsersync for more information. It does a lot more things that I need but you may find interesting. I'm just using its functionality to live reload the web browser while developing.

Make sure to checkout the Publish tag for more content about this static site generator.

This is something that Peril was designed to solve, but I never had time to look into it and probably I wouldn't have used it since it required self-hosting (at least the last time I checked).

But time has passed and GitHub has now a feature that can help with this: GitHub actions. Let's take a look at how they improve the situation!

Checkout GitHub Actions for your Swift Package for another great usage of this GitHub feature.

Many Dangers

One thing to take into account is that by now there are many different versions of Danger in different languages and ecosystems. The one I'm talking about is Danger Ruby.

You may wonder why I'm still using Ruby instead of Swift, since Danger accepts that now (although I'm not fond that it needs JS under the hood for that, even if it makes sense for the project). The answer is two folded.

For one, it's already setup and working and I don't see the need of migrating the rules for not much gain. Writing them in Swift would be cool but then we have he other reason: Android.

The majority of the rules on our Danger file are about PR etiquette and that is shared between iOS and Android. If wouldn't be nice to make my Android team switch from Ruby to Swift just because I like it more ^^.

Configure the action

To configure an action you need to make a new yaml file in your repo at the path .github/workflows/file.yml. You can do that manually but I usually just do it from GitHub's own actions interface.

That page will show you relevant actions for your repo but, at least at the time of writing this, the suggestions for iOS/Swift are quite poor. You may find some predefined action for Danger but I was not able to make any work so I just rolled with my own. This gives me more control about what's happening so it's my preferred option anyway, at least for now.

Let's take a look at the configuration needed to run Danger.

name: 🚧 Danger

The first thing you want to do is give it a name. It may seem a trivial thing but in my case I will have another Danger instance running so is important that the names help differentiate them.

on:
  pull_request:
    types: [opened, reopened, edited, synchronize]

This is probably the most important setting of the action, since it's what allow us run Danger when we need it (when a PR is opened or modified), not like before that we were stuck on running it only on commit (called synchronize in the action config).

jobs:
  build:

Now let's describe the work that needs to be done. Starting with the machine that needs to run it.

     runs-on: ubuntu-latest

We pick a linux distribution since is usually the standard and we don't have any specific requirements for this job as long as it can run Ruby.

Let's move on to the steps:

     steps:
    - uses: actions/checkout@v2

The first thing you need to do is checkout your git repo. For it you can use an existing action that will automatically pull the correct commit.

As many modern CI systems GitHub actions use containers that start from scratch every time they run. This ensures that there is no stale state but also means we can't rely on previous files being there.

     - name: Set up Ruby
      uses: actions/setup-ruby@v1
      with:
        ruby-version: '2.6'

The ubuntu image we defined above doesn't have the specific Ruby version we need, so we must install it first.

For that we use another existing action that installs a specific ruby version just by passing it as a parameter.

I was not able to get it to install the specific patch version we use so I'm just asking for the latest version matching the minor we require.

     - uses: actions/cache@v1
      with:
        path: vendor/bundle
        key: ${{ runner.os }}-gems-${{ hashFiles('**/Gemfile.lock') }}
        restore-keys: |
          ${{ runner.os }}-gems-

Adding a cache is an optional step but really useful. There is no need to run trough the gem installation every single time since they don't change that often.

To ensure that when we change a gem version the gems are refreshed we use the Gemfile.lock hash as the key for the cache.

The cache action uses a very interesting feature that allows it to install a post action. This means that the action will run first at the point that is defined, to restore, but also at the end of the steps, to save, automatically! This is such an improvement compared to other CI systems.

     - name: Bundle install
      run: |
        gem install bundler
        bundle config path vendor/bundle
        bundle install --jobs 4 --retry 3

Now it's time to install bundler and the specific gems that we need. This ensures that we're running the specific version of Danger that we want.

Note that we also configure the path to store the gems, this needs to match the path specific previously on the caching step.

     - name: Run danger
      run: |
        bundle exec danger
      env:
        DANGER_GITHUB_API_TOKEN: ${{ secrets.GITHUB_TOKEN }}

And finally we run 🚧 Danger! Note how we run it using bundle, to ensure it runs the known version.

We also pass the environment variable that it expects to access the GitHub API. And this is another great advantage that GitHub actions have. Because they are a first party service you can just use the secrets to get a token for the action, without having to configure anything else.

name: 🚧 Danger

on:
  pull_request:
    types: [opened, reopened, edited, synchronize]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2
    - name: Set up Ruby 2.6.3
      uses: actions/setup-ruby@v1
      with:
        ruby-version: '2.6'
    - uses: actions/cache@v1
      with:
        path: vendor/bundle
        key: ${{ runner.os }}-gems-${{ hashFiles('**/Gemfile.lock') }}
        restore-keys: |
          ${{ runner.os }}-gems-
    - name: Bundle install
      run: |
        gem install bundler
        bundle config path vendor/bundle
        bundle install --jobs 4 --retry 3
    - name: Run danger
      run: |
        bundle exec danger
      env:
        DANGER_GITHUB_API_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Finishing touches

I recommend you go into your branch setings and select this new Danger check as a requirement, and disable the old one if you were running it in another CI.

You can now also cleanup your previous Danger setup from Fastlane or wherever you had it before.

Conclusion

You can see how easy is to use GitHub actions and how convenient they are since they are fully integrated into GitHub.

Go and check them out if you haven't yet!

One of the fantasy series that I've always heard good things of is The Wheel of Time by Robert Jordan and Brandon Sanderson. I heard ramblings about it but never paid attention or did any research about it. That was until the tv show started to be rumoured. I immediately got worried about that. I didn't want to watch the show without having read the book first!

Of course, thanks to the creepy Internet we live in, it didn't take even five minutes for Youtube to show me videos from Daniel Greene talking about it. And, this time, I'm happy it did because I've become a huge fan of his channel.

His video convinced me on giving this series a chance. Even if I was a little scared, fourteen books are not a joke. But the, very, positive thing is that the series is finished and right now that's something that I'm very keen on.

So I decided to give it a go. I bought the book for my Kindle and started reading for a couple of evenings. But one of my flaws quickly showed up, I have always some trouble with starts, specially in epic fantasy where they present to you a thousand characters in a couple of pages... and I'm very bad at names!

The other inconvenience that I found is that my eyes are already drained enough after an entire day in front of a computer to keep forcing them until midnight. I have many issues with eye sight and so I'm always careful with adding more work to them.

I was about to drop it but then took the decision of switching to the audio-book instead. For me this was the best decisions, it solved all my problems. I have to admit that took me a couple of chapters to get use to the voices, specially since they change the narrator depending on the main character and I'm not a big voice of the woman's narration. But once I got use to it everything changed.

First of all, I can read more and faster. As you may know I usually consume content at 2x, but reading at double my usual speed would be quite tricky. But whith an audio book I can crank up the speed with no problem. I keep it at 1.5x because of course comprehending a fantasy story is way harder than a youtube video but still, I gain some time with that. But more importantly, I can read while doing chores at home. This means I can read more often and, as a good side effect, that I don't mind doing them ^^.

I finished the first entry, The Eye of the World, in about a month. Sadly I was not really impressed by it. I was aware that it's really just an introduction to the series, to a huge world and story, but that's not an excuse for moving on so slowly. You can read on Goodreads the review I left just after finishing it.

But that didn't made me stop. Just by the end it got interesting so I quickly jumped into the second one before I lost the hype. Right now I'm about 80% on The Great Hunt and I have to say that I'm liking it way more. The story still moves really slow but I think the characters caught my interest already, which is good.

I hope I can finish it soon and have enough energy to continue with the series!

Road to Swift 6

Hello everyone and welcome to this video where we're gonna explore the Road to Swift 6. I'm very excited for what is coming so this video is very special to me.

Ted, from the Swift Core Team, made a post on the Swift forums talking about the goals for Swift 6. So it seems like a good oportunity to discuss what's coming and what I'm most excited about.

But before we focus on the future, it is important to surface the big gaols that have been accomplished already, so we have a clear picture of the position we are on before focusing on what's next.

Of course we had many language improvements and great features, so making a list here would be too much. But there are 2 specific things that make now a good time to discuss what the future looks like.

The first one is ABI stability. Even if it's not a big deal for platforms outisde Apple, this was a main focus for the engineering team at Apple and it has been going for a while, being Swift 5 the big release for it. Now that it's done it means they can focus on more big things.

The other big accomplishment is the Swift Package Manager, which has been integrated in Xcode and includes better support for other IDEs. This provides to the Swift community a common and cross-platform solution for building and distributing Swift libraries. This is a MUST if we want the langauge to grow.

And that's the point, with the introduced features and a good base for the ecosystem now Swift is in a good position to grow and expand.

So what's the deal with Swift 6? The Core Team likes to focus on themes for every Swift release. These are the broad topics that the Core Team would like to see Swift 6 tackle. It doesn't mean that other features won't be added of course, but this servers as a guide to know what to prioritise.

1. Accelerate growth of the Swift software ecosystem
2. Create a fantastic development experience
3. Invest in user-empowering language directions

It is important to understand that, as with many existing features like ABI stability, a specific feature is not the work of only a single release. Features are worked trough mulitple releases and shiped only when they're ready.

This means that some things we will mention are already being worked on (like the ownership model) but the important thing is that the core team expects Swift 6 to be the culmination of a bunch of those. So we will see more 5 point releases until everything is ready for a big major release.

But let's dive into each theme because there is so much interesting things to talk about!

The first major theme is to Accelerate the growth of the Swift ecosystem. Swift is the the facto language for Apple platforms, and is growing in other domains (like services and server side or machine learning with Swift for TensorFlow and Apple's own frameworks). But the core team wants to focus on accelerating this growth and making Swift available for EVERYONE.

• More Platforms
• Improve installation and deployment of Swift software
• Support cross-platform tooling
• Cultivate a rich open source library ecosystem
• A package registry?

The main thing that a language needs to keep growing is to expand the number of platforms where is available and supported. Some community members have done a great work on this, like supporting other unix systems, Arduino or even the port to Windows (the responsable of which, is now part of the core team!). But it would be great if the Swift project had official support for all of this. This would mean integrate those into the main compiler, CI infrastructure, official releses and documentation. I personally would love to see an easy to support Windows and official support for WASM.

An important diasctintion to make here is that we're not talking about supporting other Application Platforms, this would require huge efforts on UI frameworks that are outside of Swift.org, the focus here is on making the language available on more platforms, which, of course, is the first step for anything bigger to occur.

The next point is to Improve how software written in Swift is installed and deployed. I rarely use Swift software that doesn't come in form of an App, which is easily installed, or that I run myself from a binary as a CLI. But it would nice to see improvements on this last use case and specially around server code deployment.

Tooling is a really important part of any programming language. So the next focus is about Supporting cross-platform tooling such as the Language Server Protocol, things like, code formatting and refactoring, and of course the Swift Package Manager. Right now I’m perfectly fine with using Xcode for Swift development, I think is a great IDE and is my main tool, but it's true that having more options is always a good thing, specially for people that will mainly target platforms where Xcode is not availalbe, and the Language server protocol is a great solution for this. And of course, the Swift Package Manager, right now is the way to go, it's so nice to use, specially with Xcode integration, that we can say we finally have a decent official package manager. But there is still lots of things to improve so any progress here is always exciting.

And probably the most important point of all of this: Cultivate a rich open source library ecosystem. I think this is the key. Other languages have such a huge number of libraries, providing solutions for so many problems, that sometimes Swift can't compete with. In my opinion this is the main reason why someobdy would pick another language over Swift, so we must do better here, quickly.

The goal for the Core Team here is to help cultivate libraries that help on specific domains. For example SSWG is helping with libraries for services, or the release of Swift Numerics which is a big boost for Swift in scientific scenarios.

But the question is, how can we encourage great libraries? The SSWG is doing a good job with this thanks to its incubation process, maybe this can be expanded to other domains.

And one thing that is not mentioned here is a package registry. This is something crucial in my opinion. GitHub announced Swift package integration but I still haven't seen anything public about that. Let's hope this is not forgotten.

Moving on. Growing the langauge won't be worth unless developing with it is a great experience. So I'm glad this is another main theme for Swift 5.

Simply put, developers should be both highly productive and experience joy when programming in Swift. Ted Kremenek, On the road to Swift 6

This is a direct quote from the forum post and IT IS great! In my opinion Swift is a joy to program in, is the language I have more fun with and it makes me use it not only for work but also as a hobby.

I was talking with a friend about languages, and the topic of making games with Unity came up. I love making games with Unity, and I like C#, it's a great language, but at the end of the day i’m more motivated to work with Swift. Is as simple as that.

But is true that the experience needs to get better, compiling time is one of the big hurdles so I’m glad is the first thing the core team mentions.

• Faster builds!
• More informative and accurate diagnostics
• Responsive code completion
• Reliable and fluid debugging experience

Faster builds! Who doesn't want that! Not publicly announced yet, but checking GitHub you can see how there is work going on already to significantly improve the performance of incremental builds, they are doing some refactors to have a more precise dependency tracking in the compiler itself.

Diagnostics! Another crucial aspect of a compiler. There is a blog post on Swift.org that goes into great detail about this new system, and Xcode 11.4 is already improving them so much. Diagnostics were one of the big issues on early swift versions, on Swift 5 there were not that bad, but then SwiftUI came and its error where really awful, it reminded my about my time writing C where the errors from the compilers could be 50 files away from the original error. The good thing is that these improvements are not about fixing specific diagnostics, but about having a better overall system across all language

Responsive code completion is somethign else that is already being worked at. Improving code completion performance, reliability, and experience is a really important thing because is the major way a developer interacts with the langauge. Autocmpletion should show up faster than I can write, otherwise is not that much helpful.

Debugging is a real pain point. lldb is amazing, when it works. And it fails more often than not. It’s getting better, but it still has issues. I was hoping that with a more mature language, with things like ABI stability, this would have a favorable impact on this, but what do I know.

These are crucial endeavors, and they represent most engineering work that is happening in the project right now. They will remain an area of focus until these are nothing short of excellent. Ted Kremenek, On the road to Swift 6

Ted finishes this part of the post by ensuring us that developer experience is a crucial part of the work they want to focus on, and that they won't stop the efforts until is almost excellent! This is music to my hears.

Moving to the last big theme, a theme focused more on the language itself and what is capable of.

The Core Team also wants to continue to make Swift a more powerful programming language and a better tool for solving problems. Ted Kremenek, On the road to Swift 6

I love this quote from Ted because it shows how the original vision of Swift is still intact and pushing harder than ever before!

• Round out capabilities to support expressive and elegant APIs
• Refine Swift’s to allow it to be used for low-level systems programming
• Provide excellent solutions for major language features such as memory ownership and concurrency

The first point of the theme is to keep improving the capabilities of the language to support expressive and elegant APIs. You know that this is one of my favorutie aspects of Swift, is such an expressive language that the APIs you can get with it are beautiful.

One of the best examples of this is SwiftUI with its usage of function builders and generics. But this framework also showed that the lagnauge needs more improvements around variadic generics and its DSL capabilities. So I'm glad this keeps being a major focus.

The next point is one that is often forgotten by App developers. Swift wants to shine too in low level systems programming, but right know there is some pain points that need to be fixed. The focus here is to improve Swift internal implementation to allow it to be used in constraint environments. One major aspect here is Swift's depdency to the unicode definitions, there have been talks already exploring what would be the best way to strip that when not required.

And a really exciting point in terms of new features! I’ve been waiting for the memory ownership model for a while now, I think is one of the aspects that will set Swift apart. Being able to close some of the gap with Rust in this aspect would be amazing.

And of course the concurrency model! It's one of the features that people makes fun of when talking about Swift, and I think that the sixth version of the language shouldn't miss the opportunity to introduce it.

But to accomplish all these goals there should be a better organisation of the community, becuase there is so much stuff to do! So what's the idea?

The working group model is something that has worked really well in other communities like Rust. But it Is important to understand that this are not a team of developers, but a group of people that focuses on a specific area to guide and supports the community investment and efforts.

This is something that has worked really well for Rust and fir Swift Server Working Group. It seems that the new concurrency model will have a working group, because it will need research and agreements to get into an excellent solution.

But I would love to see more investment on this structure and get even more working groups like Rust. And I think not all groups need to be technical centric. It would be great to have one for documentation, or teaching for example! How cool would it be to work on that?

By this point I know what you're asking, so when is all of this gonna be shipped?

When it's done!

There are NO RELEASE DATES. This efforts will take time to investigate and implement, but meanwhile we will keep having 5 point releases. The release of Swift 6 is gonna happen when those efforts culminate.

If I understand this corectly I think is a great way to make the Swift project evolve without being tied with Apple yearly releases.

• Coroutines
• Memory Ownership
• Compile Times
• Package ecosystem
• More focused and lovable community

Let's finish with my favourites.

Of course coroutines and the concurrency model are the most exciting features that will have a great impact on our day to day coding. The majority of other language have this feature already so it is something that Swift needs to do soon. I don't mind is taking them long because the plans they have are amazing. I'm still exciting about the technical details they shared on the concurrency manifesto. Making the async/await coroutines the building blogs instead of a higher level concept seems like a really exciting proposal.

And another feature. The memory ownership model. This one has me really excited. Right now the other language that competes with Swift in my personal love for programming is Rust. Rust was a ground breaking language for all the safety and concepts that it added to the main stream. If Swift can learn from it and bring some of those concepts, in a Swifty way, it will be more than great. I've been thinking about talking about what memory ownership implies, for app developers that are not deep into this low level things, but not sure how much interest this topic has. 😀

Then we get into tooling. Compile times. There is not much to say here. They need to get better, we all know that.

As I said before, I think what sets apart a language ecosystem is the quantity and quality of their packages. I don't need Swift to have so many packages like other ecosystems, but we need more of them and keeping with the high quality standards expected.

And finally for all of this to happen I would hope to see this year a more focused community, but specially a more lovable and positivy community. I'm a little tired of seeing people argue and attack members of their own community (I mean you shouldn't attack anybody, never, but cmon share a common love here!). Stop critising the people that dedicates time to the langauge attaching them of langauge nerds, be more open minded and for the love of god, stop confusing the Swift community for Apple. This project is a community project so you should start taking ownership of it. Rant over.

But tell me, what are you most excited about?

Our goals for Swift are ambitious: we want to make programming simple things easy, and difficult things possible.

To finish in a more, I got this quote is from Swift.org, and is what makes Swift so exciting. This clear goal, and not being conformed with the status quo is what makes this such an exciting language, ecosystem and community. Let's keep it that way!

So this has been my video about Swift 6. I hope you enjoyed and got as excited as me with the future our beloved langauge has.

But one of the things I rarely enjoy when publishing any open source repo is the setup of the CI. Yes, nowadays is not that hard with many companies offering free resources for open source repos, but still, having to create an account, linking it with GitHub, manually creating configuration files... sometimes is too much effort for a simple and small repo.

Thankfully GitHub has been improving its platform quite a lot this past year, and one of the new features are GitHub actions. These actions allow us to create automated workflows on our repo using GH servers and fully integrated with our commits and pull requests.

The amazing thing is that adding this to your Swift package repo takes less than one minute!

Try it by yourself:

1. Go to your repo's Actions tab.

2. GitHub will detect that your repo is a Swift package and it will already suggest the proper action. Just click on Set up this workflow.

The basics of this workflow should work for most projects. It builds and tests your Swift package in a macOS machine on every push to the repo.

3. Commit or create a branch with the changes.

AND THAT'S IT!

From now on every push on the repo will trigger this action and report the results back to the commit.

And if the commit is part of a PR you will also see the action run as part of the PR checks.

From here you can expand your integration as you want, but it is quite amazing that in less than a minute and with 2 clicks we can have a CI integration directly into our repo.

Now you just need to write unit tests for it 😉

ForEach(humans) { human in
    Text(human.name)
}

This works out of the box assuming your model is Identifiable. Otherwise you will need to pass a second argument to the ForEach giving a KeyPath to the id.

It gets a little trickier when you want to display no only your data but also its position on the list.

You may try the correct solution directly, but I would like to show here the different options we have and discard many of them, since they can provoke errors and even crashes. Sadly those are the ones you will find recommended online so always be careful. Don't even take my word for granted!

Let's see what options we have.

enumerated()

One of the obvious ways of doing it is using the enumerated() function on your collection. This will return a new collection with a tuple of the element and its offset.

element and offset are the labels of the tuple, even if there is no clear documentation saying it, it can be deduced from some signatures.

The first problem we encounter with this approach is that we need to provide an ID, since the tuple of the collection is not Identifiable.

ForEach(humans.enumerated(), id: \.offset)

But this doesn't work, the compiler gives us this nice error:

Referencing initializer 'init(_:id:content:)' on 'ForEach' requires that 'EnumeratedSequence<[Human]>' conform to 'RandomAccessCollection'

The issue here is that ForEach needs a RandomAccessCollection, presumedly to access directly specific elements of the collection to reload only those that change. But when using enumerated() we get back an EnumeratedSequence, a sequence that doesn't provide random access.

reversed()

You can use reversed() to get a RandomAccessCollection.

ForEach(humans.enumerated().reversed(), id: \.offset)

This satisfies the compiler and works as expected:

But of course, this is not really useful unless you want your list to be reversed.

Still, it helps us understand what's going on. The reason this satisfies the compiler is because the reversed function returns an Array, which is a RandomAccessCollection.

So what if we do that ourselves?

Array

One correct approach is to take the enumerated sequence and consume it immediately to create an array. In that way we get our RandomAccessCollection and the ForEach view can do its work.

ForEach(Array(humans.enumerated()), id: \.offset)

This works fine and, as far as I know, it won't provoke any errors.

But... performance. Remember, any performance claim needs to be backed with real data, which I don't have, so don't take this as pure truth but... seeing that Array creation, from a sequence is suspicious. To create that array the sequence needs to be iterated fully, so on big datasets it could be noticeable. And remember that this code is inside SwiftUI View body function, so it will run quite often.

You can probably live with this for a while if you control your data set and is not that big, you may even want to make it nicer with some extension on collection that gives you directly an enumerated array or even a fancy custom initialiser in the ForEach.

But there is another alternative.

Ranges

Using enumerated() is really convenient because it gives you the offset and the element at the same time without more effort. But there is always the alternative of iterating over a range, and with each index of the iteration access the collection to get the element.

ForEach(0..<humans.count) { i in
    Text("\(i+1). \(humans[i].name)")
}

This is one of the most recommended ways I see online, but in my experience this can crash your App.

Note that SwiftUI is still pretty young. This may be intended behaviour or a bug. Maybe it's already fixed or maybe is that my code triggered some edge case.

Because there is not much documentation and we don't have access to the source is quite tricky to know the reasons, but knowing how it may work we can deduce something.

I've seen this kind of code crash when the collection changes, SwiftUI runs the body function of the views again and suddenly this code accesses an invalid index. Stepping into the debugger you may see how your array has the correct data, but the index is trying to access is from an older version of it.

This seems to me that SwiftUI is trying to be smart in the way it computes UI differences. Maybe is caching the indices too heavily, but my theory is that the issue comes because we're using a literal range and it assumes that the Range will be static, so when it needs to recompute the layout it just runs the closure again.

Interestingly enough this doesn't happen if you are in a fully dynamic view since the entire view needs to be recomputed for a diff. But if you're in a static view and this For is the only thing that can change... you may be surprised.

indices

The idea of iterating indices and getting the element afterwards was not bad. A literal Range can cause issues but we can use a function that gives us the indices, avoiding any literal use. We can just use indices().

ForEach(humans.indices) { i in
    Text("\(i+1). \(humans[i].name)")
}

This seems safe to use in my experience. When SwiftUI needs to recompute the view it will correctly retrieve a new range of indices avoiding any crash.

Careful with Slices

Not specific to SwiftUI, but is worth being reminded. Keep in mind that any use of indices is dangerous unless you know that the collection you're working with is 0-indexed. If you're working directly with an array then you're safe to use this techniques, otherwise be careful.

Imagine that our data is a slice of the original:

humans.suffix(2)

In my example with 4 original Humans, now we have an ArraySlice of count 2, but the index of them still is based on the original array.

In the case of a literal range you will get an Index out of bounds and crash the App. In the indices case the App won't crash but you won't see the list start at the proper number on the UI:

Indices as part of your data

One alternative that I haven't mentioned yet is to simply avoid doing this on the UI. You can always bake the index of each element as part of your data model or any other intermidiate layer.

That depends on your application but is worth mentioning ;)

Conclusion

It's quite surprising that something so simple can get so complicated.

As you can see there is no silver bullet but I hope that with this post at least now you get an understanding of the situation and can analyse the tradeoffs on your situation.

The goal of my strategy is to make sure everything is gone, that no traces in the codebase of this old feature last. This is important to understand because this technique doesn't favour speed so doesn't expect tips around that.

Modules

Before we go into the tips, of course I must give you an important recommendation: modules.

If you split your features in different modules you will have an easier time getting rid of them. But you won't always have this privilege, specially in older codebases.

But even in the cases you have, maybe that module has dependencies or assets that are pulled from somewhere else that you also want to remove.

That's why I still use this technique even if my code is properly modularised.

Step 0: The note

The first thing you should do is open a note on your notes app of choice.

This technique relies evenly on keeping track of things in a note, so make sure you setup your environment to quickly jump between your IDE and the note. Multiple screens, split windows, shortcuts… whatever works best for you.

The only small requirement for the notes App is that it should allow you to paste code without messing with the formatting or quotes. You will need to copy the code from the note later, and if quotes are messed up it will be a pain to find what you're looking for.

Step 1: Removing code and Gathering dependencies

Delete one file at a time: Removing an entire folder is quicker but I assure you there will be dependencies outside that folder that you will forget to remove. Go file by file skimming the code looking for dependencies, strings, assets, etc. Your IDE should color strings differently so they will be easier to catch.

Gather the dependencies, don't remove them yet: It may be tempting to remove every string or other dependency as you find them. But that constant change of context will make you slower and is really error prone. Furthermore, that dependency may be used somewhere else so it shouldn't be removed. Remember that note that I mentioned? Write down every dependency on the note.

If you're removing code in a language with headers you're in luck! The explicit imports will help you trace dependencies down. Copy and paste each import line in the note for later. And don't bother about duplicates for now. Just paste it all there, at this point you don't have to worry about the dependencies, you just gather them all.

If you're using a modern language without headers, you still can do the same with external modules. For your own code dependencies is gonna be harder. Try to keep an eye open for code that may seem only used in this feature. This is often the case with helpers that are used in different parts of the codebase but with time they ended up just using in one place, if this is the last place they should be removed!

Do the same for strings, assets or other external resources, but make sure you keep each kind of dependency in a separate list, you don't want to be jumping around on the next part.

The goal of this step is to gather all the dependencies in the note while removing the code. It is important that you don't act on the dependencies yet.

Step 2: Remove dependencies

Once you've finished removing all the files from your feature you will likely have a note with a bunch of dependencies: modules, file imports, strings, images, etc. Now is time to get rid of them.

Start with code dependencies because this ones are likely to surface more dependencies, and because the compiler is gonna help you more than with the rest.

One important thing to keep in mind is that during this process you may find other code that you can remove, when that happens keep in mind the methodology. Remove the code, but just gather the dependencies. Iteration!

Before continuing with any of the list, I recommend you to sort them alphabetically. Your editor will probably have a command to do that, and if not copy paste the list in an editor that has it or some website. The advantage of having the list sorted is that you can very quickly see duplicates and reduce the times pend in the following steps.

If you have a list of imports, for example in Objective-C, paste them all in a header file and run the compiler. Any import that the compiler can find will mean that is for a file that you removed, good job!

For the imports that the compiler finds you can to a search for those types and check if they're still used in another part of the codebase. If the only result is the import you just pasted you're in luck, you can remove that code too!

Now that all the code is removed, you can work on strings, images and other assets. You can just do a search for each item on the list and see if they have any other usages. If they don't it means is time to remove them! Your users will be happy that the App has shrink in size ^^

If the assets are used in other parts of the code I still recommend you to check them. The usage of those assets may mean that that code can be also removed!

Step 3: The PR

Once your job is done is time to PR the changes into the main branch. The resulting PR will likely be huge and your colleagues may quickly skip it and approve it, after all is just removing code ¯_(ツ)_/¯ . WRONG!

First of all, during this removal you're likely to modify slightly some parts of the code to avoid using stuff that you removed (maybe an enum case doesn't make sense anymore, and that affects some switch statements). Those parts must be reviewed carefully like in any other PR.

But even more, ask your colleagues to take a look at the files that have been removed, this technique is not infallible so the more eyes there are looking at the PR the more likely it is to find something you missed.

Making sure everything is removed now is important. Yes, you can always do it in some months when you find that something is not used, but when that happens nobody remembers why that thing was there in the first place, and nobody is sure if it can break something else. When that happens in the middle of something more urgent the result is that nobody removes anything. Leaving dead code or assets in the codebase for even longer. You're gonna regret it, and your users won't be happier.

Numbers

Because this is a tedious process I recommend you that at the end you have some fun.

Before merging the PR run some analytics to count the number of lines you removed from the codebase. You can use GitHub numbers but if you want to go into more detail I recommend you to manually run tokei or any other similar program of your choice.

The last feature I removed was an important portion of our codebase, specially in terms of assets. More than 200 files and 20k lines of code.

GH may be a little misleading, as that includes strings, an external Pod and tests.
Checking only production and test folders (ignoring Pods):
209 files removed
23,177 lines (including blanks and comments)
15,873 lines of code

— Alejandro Martinez (@alexito4) August 16, 2019

And that was before one of my colleagues found more stuff to remove! That's why the PR is so important! ^^

Tools

A quick note on tools.

It's likely that there are a bunch of tools that check for dead code, unused assets, etc. I recommend you to use them but don't rely on them. Those type of static analysis tools often miss things in complex codebases or if you do anything at runtime.

Conclusion

0. Open a note
1. Delete code. Gather dependencies like other modules, helpers, strings, assets...
2. Delete the dependencies.
3. PR.

This may seem like a longwinded way of doing this task. But after doing it many times over the years and always missing stuff I've organically developed this series of tips to try to reduce what's missed.

If you have any other tips don't hesitate to send them over! ^^

And be happy! You removed some code! The best feeling eva :P

Alert presentation

What makes presenting an alert so nice is the fact that the API uses a binding.

.presentation($showAlert, alert: { Alert(title: Text("Alert!")) })
//            ----------
//                ^ this is a binding to a boolean

With this simple line the framework takes care of presenting the alert when the flag showAlert is true, and setting it to false when the alert is dismissed. You don't have to manage the presentation or maintain the state, it's all taken care for you.

This makes it really easy to present alerts. Usually you just need to keep a State property around and set it to true when appropriate.

@State var showAlert = false
...
VStack {
    Button(action: { self.showAlert.toggle() }) {
        Text("Show alert!")
    }
}
.presentation($showAlert, alert: { Alert(title: Text("Alert!")) })

Modal presentation

Let's take a closer look at the modifier to present a modal:

.presentation(Modal?)

The first thing that you notice is how this method doesn't accept a binding to a boolean. Instead, to decide when to show the modal, it uses an optional. If you pass nil, the modal is not presented; if you pass a Modal the view is presented.

This seemingly small difference causes a big impact in the way we use it.

First of all, we still need to know when to present it or not, for the simple case let's use a boolean like we did for the alert. But now instead of just passing it as a binding, we need to perform the check ourselves.

.presentation(showModal ? Modal(Text("Modal screen")) : nil)

This is not that bad, not as nice as passing a binding but not the worse.

@State var showModal = false
...
VStack {
    Button(action: { self.showModal.toggle() }) {
        Text("Show modal!")
    }
}
.presentation(showModal ? Modal(Text("Modal screen")) : nil)

But there is a big problem in this code. When the modal is dismissed the flag it's still set to true, and thus any change that triggers the UI to be re-rendered may cause the modal to appear again. Or more obviously, when the button is pressed again the modal won't show up, because toggle will change the flag from true to false. ☹️

Our State and UI are out of sync!

This API is causing the very same problem that SwiftUI promised to fix.

To implement a proper modal presentation we need to make sure that the flag is changed properly. Maybe your modal screen is so custom that you want to change the flag from the modally presented view, but for the majority of cases it would be enough to change the flag when the screen is dismissed. We can use the onDismiss closure from the Modal view for that:

.presentation(showModal ? Modal(Text("Modal screen"), onDismiss: {
    self.showModal.toggle()
}) : nil)

Now our UI and State are in sync again. 😃

Even if this is problematic and cumbersome it makes sense from an API design point of view. An alert has a fix UI that the framework controls, so it can know when to change the state. Instead, a modal is a completely custom piece of UI and the framework can't know when to change our state.

That said, I think we could have a simpler API for the typical use case.

An improved modal API

The default modal presentation doesn't prove any visual way for the user to close the modal, but as of iOS 13 the user can swipe down the view to make it disappear.

This is another reason why it would make sense for the modal API to take care of changing the flag for us.

This interaction is really nice, but 90% of the time you will want to add some affordance for the user to know how to close the modal. And usually this is just done by a Done button.

Assuming this is the UI we want, is quite simple to build an improved modal API that makes our code look like this:

VStack {
    Button(action: { self.showModal.toggle() }) {
        Text("Show modal!")
    }
}
.presentation($showModal, title: Text("Example modal"), modal: { Text("Modal screen!") })

Now we're talking! This looks much better, similar to how the Alert API looks like. 🎉

With this new method we just need to pass a binding to the boolean, like the Alert did.

We can also pass a title for the modal screen, which is gonna be used to create a NavigationView with a Done button that will help the user close the screen.

Finally you pass the View that you want to present modally. The method takes care of wrapping that view inside a Modal and changing the status of the flag when appropriate.

The method looks like this:

extension View {
    func presentation<T: View>(_ isShown: Binding<Bool>, title: Text, modal: () -> T) -> some View {
        let view = NavigationView {
            modal()
                .navigationBarTitle(title)
                .navigationBarItems(trailing: Button(action: {
                    isShown.value.toggle()
                }, label: { Text("Done") } ))
        }

        return presentation(isShown.value ?
            Modal(
                view,
                onDismiss: {
                    isShown.value.toggle()
              }
            )
            : nil
        )
    }
}

This may not make sense as part of the framework, but there is no doubt that it's a vital method to keep around on your projects.

But don't take it as is! Tweak it so it makes sense for your app: maybe say Close instead of Done, or add an option to add a Cancel button. The possibilities are endless!

Conclusion

What I want you to take from this post, apart from a nice presentation helper method, is not that SwiftUI presentation API is not ideal. Quite the opposite!

I want you to appreciate how thanks to the design of the framework (based on value types, protocols and function modifiers) it's really easy for us to learn from its API and extend it to accommodate for our needs.

Check out the rest of SwiftUI posts.

Styles with ViewModifier

Let's start by having a simple default SwiftUI button:

Button(action: {}) {
    Text("Default style")
}

In the previous post I used ViewModifier to encapsulate and reuse some styles. The problem with that technique is that you're forced to apply the modifier to the content of the button (SwiftUI calls this Label).

Button(action: {}) {
  	VStack {
        Image(...)
        Text("...")
    }
    .myButtonStyle() // <- my custom modifier
}

This was acceptable for a provisional workaround, but it's kind of weird to apply styles to the content of the button instead of the button itself.

And remember that we could not apply the modifier to the button itself because then things like padding and background were applied at the incorrect level of the view hierarchy. (read the previous post if you don't understand this because is a crucial aspect of SwiftUI)

ButtonStyle

Luckily for us SwiftUI has a better way of doing this. A button has a modifier that accepts a ButtonStyle:

Button(action: {}) {
    Text("...")
}
.buttonStyle(.default)

We can use this ourselves and create our own custom styles as structs conforming to the ButtonStyle protocol.

public struct BackgroundButtonStyle: ButtonStyle {
    
    public func body(configuration: Button<Self.Label>, isPressed: Bool) -> some View {
        configuration
            .accentColor(.red)
            .padding()
            .background(.yellow)
            .cornerRadius(4)
    }
}

This follows a recurring pattern on SwiftUI, you create a struct conforming to a protocol. This is quite nice because it becomes familiar pretty quickly.

In this case the protocol is similar to ViewModifier. It defines a function body that accepts a configuration Button . This is the view to which you need to apply the modifiers.

It also has a second parameter, a boolean that tells us if the button is pressed or not. This is something that we don't have access with other styling techniques. It helps us change the style of the button based on the pressed state of it. As usual with SwiftUI, the body function will be called when this state changes, so you just need to declare the style based on it. SwiftUi takes care of the rest.

public struct BackgroundButtonStyle: ButtonStyle {
    public func body(configuration: Button<Self.Label>, isPressed: Bool) -> some View {
        configuration
            .accentColor(isPressed ? .yellow : .red)
            .padding()
            .background(isPressed ? Color.red : .yellow)
            .cornerRadius(4)
    }
}

In this example we change the background and accent colors of the button depending on the pressed state.

The question now is, how do we apply this style to the button?

StaticMember

I'm not gonna lie, took me a while to figure out how this is supposed to work.

The first thing that you may try is to just pass the style to the modifier:

.buttonStyle(BackgroundButtonStyle())

But this doesn't work. The signature of that modifier expects a StaticMember:

.buttonStyle(StaticMember<ButtonStyle>)

But what is a static member?

The documentation describes it like this:

A concrete wrapper for enabling implicit member expressions.

Let me try to explain this. implicit member expressions are most commonly known by "dot syntax" on static members. This is when you can use .red in a method that accepts a UIColor. Because the compiler knows that the method expects a UIColor, and that this class has a static property called red that returns a UIColor itself, then it let us use this dot syntax without having to write UIColor at all.

The limitation with this is quite big. The compiler only looks for properties on the type of the parameter, and of course, it only accepts properties that return the same type.

This is quite an issue in some API designs. For example if you want your methods to accept protocols your users won't be able to use the implicit member expressions because the compiler won't look for static properties on the concrete types that implement the protocol.

In SwiftUI this is a big deal.

Think about the buttonStyle modifier for example. This modifier wants to accept a ButtonStyle, this makes it really flexible but also not that nice to use as you wouldn't be able to do .buttonStyle(.default).

To workaround this the framework provides a StaticMember, a simple generic type that helps to avoid this problem. You can see a detailed example on Apple's documentation.

SwiftUI declares the modifier to accept a StaticMember that wraps a ButtonStyle. It's just a workaround for the type system and the compiler. Hopefully in the future this won't be needed.

What it means for us is that in order to be able to use this custom style we need to accept this dance with the compiler 💃🏻. We need to extend StaticMember to add a static property that returns our style.

extension StaticMember where Base : ButtonStyle {
    public static var background: BackgroundButtonStyle.Member {
        StaticMember<BackgroundButtonStyle>(BackgroundButtonStyle())
    }
}

As an aside, I'm omitting the return in this single line function. Watch my video about Swift's new Implicit Return if you want to know more.

Now that we have all the pieces in place we're free to use our custom style!

Button(action: {}) {
    Text("Background style")
}
.buttonStyle(.background)

Combining styles

The nice thing about styles being just views that wrap other views is that we benefit from their composability.

Let's make another custom style. Just for fun and to show you how easy is to do nice effects with SwiftUI, let's make the button scale when pressed.

public struct ScaledButtonStyle: ButtonStyle {
    public func body(configuration: Button<Self.Label>, isPressed: Bool) -> some View {
        configuration
            .scaleEffect(isPressed ? 1.4 : 1)
            .animation(Animation.spring().speed(2))
    }
}

Now you can combine both styles as you combine any other view in SwiftUI.

Button(action: {}) {
    Text("Background style")
}
.buttonStyle(.scaled)
.buttonStyle(.background)

Take a moment to appreciate how nice an powerful this is.

##Conclusion

Making custom styles in SwiftUI is as easy as making normal views. SwiftUI uses the same pattern of structs implementing a protocol that returns a body View for many of its APIs.

In this case it's a little more complicated because we need to use this StaticMember workaround. But once you know it is quite easy to repeat. And the final syntax is as nice as it can be 😊 .

A concern that I have, with beta 2 at least, is that Xcode is not able to suggest this static members yet. So even if .buttonStyle(.background) compiles, it's quite obscure to figure out what styles you have available. Hopefully is fixed in upcoming betas.

I was able to do it by requiring a ForEach but I was not happy as that's not how HStack works. SwiftUI stacks allow you to nest views individually or use a ForEach. I wanted to support both systems also.

Then, while editing the video about Opaque Result Types, I realised how HStack keeps the information of its views in the type thanks to TupleView.

TupleView is a generic view with a tuple as its type. This allows it to keep the information of every single subview. Then I remembered some discussions on the forums about Swift not having, yet, variadic generics, and a possible solution came to my mind.

The trick is to make different init with @ViewBuilder that are overloaded on the return type of the closure.

init<A: View, B: View>(@ViewBuilder content: () -> TupleView<(A, B)>)
init<A: View, B: View, C: View>(@ViewBuilder content: () -> TupleView<(A, B, C)>)
init<A: View, B: View, C: View, D: View>(@ViewBuilder content: () -> TupleView<(A, B, C, D)>)
...

You can see the pattern.

This allows me to get access to the specific subviews of the stack, store them in an array and then add a Spacer between them in the body, in the same way that was done in the previous post.

But this journey doesn't end here. There are still a couple of things that I don't like.

To support a single subview overloading the init with a tuple of 1 element doesn't work, the TupleView needs to disappear:

// This doesnt' allow for a single subview:
init<A: View>(@ViewBuilder content: () -> TupleView<(A)>)
// It needs this overload instead:
init<A: View>(@ViewBuilder content: () -> A)

The problem with having that overload is that it's called when there are a number of subviews that we don't have another init for, so in that init we receive a TupleView and we treat it as a single view without adding spacing. Too fragile.

The other problem is that in order to gather the views they need to be wrapped in AnyView, a type erased container. (Watch Opaque Result Types to know more about this view)

So this is still not the ideal solution implementation wise, but at the API surface is what I wanted:

Text("With reusable view manual")

EquallySpacedHStack {
    Color.red.frame(width: 50, height: 50)
    Color.blue.frame(width: 50, height: 50)
    Color.green.frame(width: 50, height: 50)
}

Text("With reusable view for each")

EquallySpacedHStack {
    ForEach(1...4) { _ in
        Color.red.frame(width: 50, height: 50)
    }
}

Check the GitHub repo.

HStack and VStack are fine for the majority of cases, but there is one case that bothers me that is not as easy as it should.

This is how a HStack with 3 views looks like:

HStack() {
    ForEach(1...3) { _ in
        Color.red.frame(width: 50.0, height: 50)
    }
}

The 3 views are centred and with a default spacing. You can change the alignment if you need to, but you don't have any options for what UIStackView called "distribution".

What if you want it not to be centred but with equal spacings?

This is totally doable by using the Spacer view. The problem is that is a little cumbersome.

HStack {
    Spacer()
    ForEach(1...3) { _ in
        Color.red.frame(width: 50, height: 50)
        Spacer()
    }
}

Of course you can extract that into a function that given some data it calls a given closure.

func EquallySpacedHStack<Data, Content>(_ data: Data, content: @escaping (Data.Element.IdentifiedValue) -> Content) -> some View where Data : RandomAccessCollection, Content : View, Data.Element : Identifiable  {
    
    HStack {
        Spacer()
        ForEach(data) { item in
            content(item)
            Spacer()
        }
    }
}

Now you can create it like if it was a ForEach:

EquallySpacedHStack(1...3) { _ in
    Color.red.frame(width: 50, height: 50)
}

And that's something I don't like. I don't want to have to pass the data in and be limited to a for each like structure. I want it to be able to use it as any other stack.

I've tried to replicate it with a custom view that uses the @ViewBuilder in the initialiser, and is better:

struct EquallySpacedHStack2<Items: View>: View {
    let items: [AnyView]
    
    init<Data, Content: View>(@ViewBuilder content: () -> Items) where Items == ForEach<Data, Content> {
        let views = content()
        self.items = views.data.map({ AnyView(views.content($0.identifiedValue)) })
    }
    
    var body: some View {
        HStack {
            Spacer()
            ForEach(0..<items.count) { index in
                self.items[index]
                Spacer()
            }
        }
    }
}