Firebase
Dynamic Links are Dead. What's next?
You might have heard that Firebase Dynamic Links is being deprecated. In case you've never heard of Firebase Dynamic Links before, they're supercharged deep links.
Deep links allow you to register custom URLs with your app (like this one that will take you straight into the Spotify app: spotify:track:ewtuJdN6DDb) that will open your app when the user clicks on the link. The problem is, this doesn't work if your app isn't installed.
Dynamic Links solve this problem by implementing so-called deferred links: if your app is not installed, the user will be sent to the App / Play Store, and after installing the app, the app will navigate to the deep link represented by the deferred link. And in case the app is already installed, the system will navigate directly to the deep link inside your app.
As explained in much more detail in the Dynamic Links Deprecation FAQ, ecosystem changes have made it increasingly difficult to provide a consistently stable experience for this post-install experience. So instead of continuing to support a less than ideal experience, Firebase decided to sunset Firebase Dynamic Links, with a shutdown date of August 25, 2025.
In this article, Pavel Ryabov discusses a solution that uses Firebase Extensions to provide much of the key functionality of Firebase Dynamic Links, and as of a couple of days ago, this extension is live on the Firebase Extensions Hub: FlowLinks - Dynamic Links Replacement.
It looks very promising! To see it in action, check out the GIF in this tweet.
medium.com
Swift
Skip code during debugging in Xcode
Often, when stepping through your code when debugging your app, you spot the cause for the bug, but since you already built up so much context, you'd rather not want to stop execution, fix the bug, recompile, and restart the app.
Instead, it's often a good idea to just change the value of a variable or skip execution of a line to verify this actually fixes the bug.
If you think "that's not possible", Marco Eidinger will prove you wrong in his article about skipping code in which he demonstrates how to jump over one (or several) lines of code.
And in this other article, Marco explains how to modify variables while debugging.
Pretty useful, but - as Marco points out - please use with care, or you will hurt yourself.
eidinger.info
Swift’s print vs dump: A Deep Dive
Let's face it - even though we know that using a debugger is the right thing to do, we often end up using print statements for debugging. You might also have heard (or even used) the dump statement. But what's the difference? And when should you use which? Learn all about it from forceUnwrap.
Swift.org - Debugging Improvements in Swift 5.9
It's probably not a secret to most that the Xcode debugger in just a thin veneer on top of lldb, and if you've developed for iOS for any amount of time, you've probably run into situations in which this integration seemed to be broken. For example, Xcode sometimes refuses to inspect the value of a variable. A typical way out is to use the p or po commands on the debugger command line.
In Swift 5.9, the Swift team has improved the performance of those commands, and also enhanced their versatility: po can now print Swift objects even when only given a raw address.
Stepping through Code With Breakpoints
To top off this section on debugging, here is Bart Jacobs with a CocoaCasts episode on some basic debugging techniques, including some tips for debugging asynchronous code.
cocoacasts.com
SwiftUI
Better Markdown Rendering in SwiftUI
I recently wanted to display some Markdown in a SwiftUI view.
Now, SwiftUI added support for Markdown a while ago, and this works reasonably well for simple Markdown - but in my case, I wanted to be able to display advanced Markdown, including tables. Unfortunately, his is not supported by SwiftUI out of the box.
Enter MarkdownUI by Guille Gonzalez - it is compatible with the GitHub Flavored Markdown Spec, and supports images, headings, lists, blockquotes, code blocks, tables, and more.
If you need to support Markdown in your SwiftUI app, definitely check this out!
github.io
Running Code When Your View Appears
Chris discusses the difference between the onAppear and task modifiers. It's a subtle, yet important difference that you should definitely be aware of if you need to run code (such as fetching some data) when the view appears.
Conferences
SwiftLeeds Live
Like in the past years, SwiftLeeds has a fantastic lineup of speakers and topics this year. If you can’t make it in person, don’t fret - they’ve just announced that they will be streaming the entire two-day programme!
When visiting the conference website, I also noticed that they’ve got a nicely made App Clip - that's actually quite useful.
Oh, and by the way - if you are looking for an App Clip that you’ve previously used, they’re really easy* to find: just go to the App Library, tap the search bar, and then scroll down to the end of the alphabetical list.
(*) I hope you noticed the sarcasm. This literally is the description from Apple’s knowledge base
x.com
Computer History
The Disappearance of General Magic
The Wikipedia entry for General Magic reads like science fiction:
General Magic was an American software and electronics company co-founded by Bill Atkinson, Andy Hertzfeld, and Marc Porat. Based in Mountain View, California, the company developed precursors to USB, software modems, small touchscreens, touchscreen controller ICs, ASICs, multimedia email, networked games, streaming TV, and early e-commerce notions.
This 4-part podcast series tells the story of a company that invented so much of the technology that we take for granted in all of the devices that surround us, but was a few years too early, and failed - or did it?
I immensely enjoyed this story, in which you meet many figures like Tony Fadell and Andy Hertzfeld, who later became instrumental in creating many of Apple's products.
There's also a great movie: "General Magic tells the tale of how a great vision and an epic failure changed the lives of billions."
castro.fm
Hey everyone!
Do you write perfect code? Me neither.
Developers tend to spend a good chunk of their time debugging (depending which research you look at, this number is anything between 25-50% of their time per year).
Anything we can do to make debugging our apps more efficient is time and effort invested wisely. In this episode of Not only Swift, we will look at a couple of ways how the debugging process can be improved and made more enjoyable overall.
Some of the languages and IDEs I've used in the past even supported stepping backwards (which raises all sorts of questions about how you preserve the state of the program execution to make this even possible), but short of that, stepping over and skipping lines is the next best kind of debugger magic, and in this episode, I've included an article that teaches you how to do this.
I hope you enjoy reading the articles in this episode of "Not only Swift". If you do, share the newsletter with a friend. And if you don't, let me know, so I can improve!
Thanks for being a subscriber!
Peter