Leo Dion (host): Hey folks. I'm trying to get these episodes out as soon as I can. Here's another great episode I did recently with Daniel on his new book, the Case of The Crimson Test Suite and Swift Testing. Hope you enjoy it. I'm really excited about going to. Server site Swift at the end of September. Daniel will be there too. He's given a great talk on macros. I if you're gonna be in the area, I highly recommend checking it out. There's a discount code EMPOWERAPPS, all caps, one word.
If you put that in, you'll get 15% off. So definitely check that out. I'll put that in the show notes as well. Thank you and I hope you enjoy this episode. Bye everybody. Welcome to another episode of Empower Apps. I'm your host, Leo Dion. Today I'm joined with Daniel Steinberg. Daniel, thank you so much for coming on. Daniel Steinberg (guest): My pleasure. Leo Dion (host): This is second time you've been on the podcast and Daniel Steinberg (guest): time.
I think we talked about functional Leo Dion (host): we did. We did. Yeah. Well, before we jump in, I'll let you go ahead and introduce yourself. Daniel Steinberg (guest): Okay. I know a lot of you, I see a lot of you, at conferences. I tend to write books and do contract coding and teaching both at conferences and privately on iOS and Mac OS topics. Leo Dion (host): Speaking of functional programming, where do you think that is right now? In a somewhat post combined world?
Daniel Steinberg (guest): That's a good question. In some ways we're seeing more of it in Apple APIs. You're seeing maps and filters and things all over the place. You still see them in, for instance, async sequences. So you still see a lot of the things we did in combine have surfaced in other places. So. I think we came to terms with the fact that as we knew Swift wasn't really a functional language, but we could do functional things with it, and I still like to code that way a lot.
Leo Dion (host): Yeah, same here. Yeah, that's a good point. I feel like if anything, we still have, I mean, combine's still around obviously, but if there's anything we still have from That is a lot of you can see traces of it and the way. Functional programming is everywhere with anything new that comes out, including the async sequence stuff.
so yeah, that's Daniel Steinberg (guest): of the problems though, is that, you know, functional programming works best with value types, and we've got that emphasis to use value types and value tips work best with async and all that. Yet, Swift UI is pushing us to use more reference types on the backend for observable and for Swift Data and things like that. So it's a bit of a mixed message between Swift and Swift UI. And so with Swift, it's a, it's easy to use.
Functional with Swift UI, it's a little harder. Leo Dion (host): Yeah. Yeah, that's true. That's a really good point. Yeah, and on top of it we have like, non copyable types, which is a whole other like, Pandora's box. Daniel Steinberg (guest): Understand them yet, so. Leo Dion (host): that makes two of us.
Okay, so today we're gonna talk about Swift testing kinda I guess give the overview of Swift testing, what it offers, alternative to XC testing, and what have you liked, what have you disliked about it I guess. Daniel Steinberg (guest): That's a lot. So the first thing is what attracted me to it. Every once in a while something gets released and it just feels like something I want to get involved in. I wanna write a book about, I want to understand it better. And Swift testing.
Not only did I like the APIs, but the way the team has. Work through the process, the support they've given the community through docs. It's just been really, I think a model project from Apple. And so it's been nice to see Leo Dion (host): What I think, and I'm gonna, I'm gonna just say I'm ignorant, but what does SW. Daniel Steinberg (guest): even after I've written a book. I. Leo Dion (host): I went into the videos and I'm like, okay, what is this offer that XC testing has?
And I do the fact that it's pure Swift for a hundred reasons, but I'm not sure it offers, what is it offer that XC testing doesn't already offer outside of the fact that it's not tied to Objective-C. Daniel Steinberg (guest): So I don't know if you remember when Steve Jobs came back to Apple. When Steve Jobs came back to Apple, there were all sorts of devices that Apple was selling all sorts of Macs, and Steve said, no, we're gonna simplify the line.
We have pro, we have consumer, we have laptop, we have desktop. And in my view, that's one of the biggest things that Swift testing brings is it says, we're gonna simplify. There's not a thousand XCT asserts. You have to know. You set things up and then you either expect a result. You require a result. And then, so that's the one axis. And then the other axis is if you expect it to succeed, that's great. If you expect it to throw an error, there's an expect throws or require throws.
And so the expectations to begin with are so much easier to work with. Leo Dion (host): Well, let's talk about that a little bit. What do you when you say expectations, are we talking about from what. I remember with XC test is like you basically have the ability to wait for an expectation. If you have something that gets called an closure, for instance, is that what we're talking about when we say expectations?
Daniel Steinberg (guest): No, the ex expectation that I'm talking about is the equivalent of the XCT assert true XCT assert equal XCT, all of those. And so instead of that, we have a pound expect. The pound expect accepts a Boolean where you say, this thing equals this thing. And so, Everything in Swift testing is a macro, the at test that decorates the method or the function is a macro. And the pound expect is also a macro. The attest is an attached macro, excuse me.
That decorates the method that it modifies that it's attached to, and the pound expect is one of those freestanding macros that expands into all the things that we need. So there's a lot less ceremony, which is kind of nice. Leo Dion (host): Yeah, that you could definitely say that. What. What, if somebody wants to jump into it, what's the first thing that they may be overwhelmed by? Or that they may feel intimidated by, that you think helped you get into Swift testing?
Daniel Steinberg (guest): Well, actually what made it harder for me and for those of us that looked at it right away was it wasn't integrated in X code and we had to do things to make it work. All that is gone with Xcode 16. What made it hard from the command line with Swift packages was we had to add a flag to Swift test to make it work That's gone with Xcode 16 beta five.
Leo Dion (host): Okay. Daniel Steinberg (guest): a lot of the things that made it hard to get Your feet wet with are gone, and that's really nice. As for writing your own tests, it depends on if you're coming from XC test or not. If you're coming from XC test. Then you're used to creating some class that subclasses from something, and then you have to write the name of the methods a specific way and things execute a specific way.
And so one of the things that might surprise you is your first test can just be a free function. It doesn't have to be part of a structure class or anything. Leo Dion (host): Do you think that do you think it's gonna be easier to like, organize tests and make them a little bit more readable? In Swift testing. That's the biggest benefit I've seen. Daniel Steinberg (guest): Well, so the Swift testing team has given us several axes to do that with.
So if you have a test, you can name it anything you want. I tend to prefer T names. Then if you want to see a more descriptive name, when you run the test, you have the freedom to create a display name. So in the AT test, one of the arguments is how do you want this to appear? And that's a display name is a string. And then you say, well, I've got this test here and this test here, and this test here that I want to group somehow.
Do they have a common reason for being I can create a tag and now I can run all the things with a common tag? Do all these things belong together conceptually and hierarchically, and I want to use the same setup for them. I create a struct, which is a suite, and I can name that suite and I can provide different things there. And so there's all these ways of organizing your tests that are very handy. Leo Dion (host): How about, sorry, I'm trying to remember. How do you keep your tests organized?
Are you doing like your just functions out in the main. File or are you setting up STRs or what do you suggest? If you wanna keep your test organized in a fashion and using your display name properly and stuff. Daniel Steinberg (guest): So I use a mix. Some tests can run on their own. Some want to be organized into a suite. I almost always will use tags. You can use which we didn't talk about yet. Suites within a suite.
So one of the nice things is so I, if I'm building a calculator as I do in one of my running examples and I have all these things that are testing the stack, but inside of there are ones that test the stack and they also test the display. I might create a strt within a struct that does those, and now I can run those separately or altogether. The problems with Swift testing are generally not with Swift testing. They're limitations of Swift.
So, for example, if I have a property in my outer struct and I want to view it from my inner struct, you can't. And because we don't create the setup code, I can't even pass it in. And so you do have to duplicate some of the setup if you're doing a struct within a struct. Leo Dion (host): Okay. Got it. What are some other benefits that you saw with Swift testing over XC test? Daniel Steinberg (guest): So one of the things is out of the box tests automatically run in parallel in random order.
And so you don't get these issues where, oh, I didn't, expose that issue because my tests always run in this order, and maybe I've got some dependencies that I don't remember. On the other hand, there are some tests that you might wanna run in a specific order, and there's an easy flag, they call them traits that you can set that says, run these as serializable. And so that's a nice handy thing that you can do. Serializable. Ones one runs then the next, and so that might increase your time.
You're not getting the parallel. The other thing is they play nice with asic. So I can have async tests and to your question from before, like I can do an XC test, but so much easier. I can require that a test completes in some amount of time. Leo Dion (host): Oh wow. Okay. Daniel Steinberg (guest): I don't wanna wait forever for this, but I can run something that is actually async. Leo Dion (host): That's awesome.
Like the things, like I get frustrated with XY tests is, like you said, it's a lot of boiler plate code. Is there even like an idea of like setup and tear down? In Swift testing. Really, do you even need Daniel Steinberg (guest): You can, but what happens? For example, if I have a suite that contains four tests, what happens is. A separate instance of that suite of that struct is created for each of those tests and they are run separately. So you're not getting the cross-contamination there.
I don't have to worry about the setup and the tear down there. So maybe I have just an a knit for my struct if I need to set up fancy things, but for the most part, I'm just adding a property and giving it a value, and that's all the setup I need. Leo Dion (host): What so one of the things, you know, we had a question or comment in Twitter from someone behavior tree said. It needs in-source testing better snapshot serialization, where you can omit fields, content for dates, IDs, et cetera.
One thing, yeah. That I've heard a lot of is just well that was one of the things I was expecting is like the ability to do mocking, things like that, that are difficult to do in SW Swift basically because we don't have the dynamic abilities that we got in Objective-C. And I was looking forward to maybe some macros for that. Where do you see that stance for things that people want?
Do you think there's gonna be kind of a community around that, or do you think it's just not something that's necessary as much as people say it's. Daniel Steinberg (guest): I think both sides of that I think in general when something doesn't do something you want, you can both question that it doesn't do it, and you can question whether you really want and need it. Are you doing something that, that you need to do? There are some things that Swift testing doesn't do yet, for example.
it explicitly does not do performance testing. It explicitly does not do UI testing, and so these are things that are excluded. The other thing is this is a first release, and as a first release, I find it very robust. In fact, it isn't even released yet. In a way it's, you know, in September when Swiss six comes out that we'll see, oh, now it's released. So. There's a side of me that when people complain, I just wanna say, come on people. Leo Dion (host): What if you were that was one thing.
I wanted to mention is that it is, it does require Swift six. Correct. And it's delivered as a Swift package, which is really great. It's like basically it's all open source, I would assume, right. So you Daniel Steinberg (guest): It is open source and you can submit issues there. It's an apples. It's an apple's repl repo on GitHub. The team is amazingly responsive. If you publish on social or you participate in the forums. the team members have been just amazingly responsive and helpful.
Leo Dion (host): Are they keeping it under the Apple organization or are they gonna move it to Swift by any Swift Lang by any chance? Daniel Steinberg (guest): I think it's on, or I Leo Dion (host): It is Swift Link. It is Swift Daniel Steinberg (guest): not there yet, they announced that it was going to be. Leo Dion (host): Yeah. No, it is right now as of the recording, so yeah. Yeah. That's awesome. Definitely check that out. Really great documentation here. One other thing.
So do you think what other things do you think are missing that you think the community could use in Swift testing that. Either you could use additional or you feel missing from XXI testing. Daniel Steinberg (guest): What I've, what I found a lot of with my early experiments with Swift testing is if something isn't behaving, it's often something the team knows too. So I'll give you a fun example. I'm writing the book and I have this example where I'm serializing.
The whole reason I'm serializing is just to demo this thing that they have. Generally, you don't wanna serialize your tests. You want 'em to run in random order, Leo Dion (host): Right. Daniel Steinberg (guest): and they're failing. They're not running in random order, but they're not running in the order I expect. And so they're running first and third, and all of a sudden, I realize they're running in alphabetical order of the method name. But it turns out the team already knows that.
They fixed it and in the next release there it was, in fact, they'd known it before I'd encountered it. It just hadn't made its way through the release cycle. So sometimes these things that we run into, it's not a limitation of the framework, it's that sometimes things aren't correctly implemented yet the things they've thought about are deep. Now there are some lacking and there's good reasons for the lacking. So I don't know, have you worked with Swift macros at all?
Leo Dion (host): Yes, I've written one Swift macro. Daniel Steinberg (guest): So one of the nice things about Swift macros is you can create tests for them and they have a really nice test template for XC tests where you can say, here's what I typed in, here's what I expected to expand to, and even if something fails, here's how I expect it to fail.
There's an issue with, Swift testing with that because you can't get a cyclic dependency to have things work out so you can make it work with Swift testing. I am, excuse me, I am updating the macros book to accommodate that, but It's, we're all encountering this together and so I don't know if you remember the early days of Swift UI. But part of it was a lot of engineers internal at Apple weren't using this thing in anger, and so they weren't realizing what needed to change about it.
And you saw in Swift two and three as they started using it internally, they said, oh, you guys were right about the navigation view. It needs to be something stronger. And now we get a navigation stack. I think the same thing will happen with Swift testing as more internal people use it. Leo Dion (host): One thing we didn't mention and I think is a huge benefit of Swift testing is like the data driven stuff where you can set up.
Series of and say these should equal, these should result into these, you know, you know what I'm talking about. I'm not sure the exact Daniel Steinberg (guest): I think what you mean more is the testing Leo Dion (host): Yes, that's exactly what I mean. Thank you, Daniel. Daniel Steinberg (guest): for. you know, five tests that essentially do the same thing, but each one takes a different piece of input. You can say, okay, here's these pieces of input.
Put 'em in an array and say that this test depends on these arguments, and now it'll run them. And what it does is very clever. This single test will create five instances of the test, one for each of the inputs. So if one fails, you can see it. You can see what went wrong. You can fix the issue, run the wrong tests first, and then run all the tests to make sure it's fixed for all of them. The other thing is, say you have two axes and so you want two arrays.
And so if I have two arrays, what it'll do is it'll create tests for each combination. And so if I have five in the first array and four in the second, I get 20 tests. Now, that's the limitation, unfortunately. I can't put in a third array. So the limitation is two arrays, and at least at this point, the warning, if you put in a third array doesn't say that's what you've done wrong. It's calling out something else.
But if you try two more than two arrays, but you can get clever and you can zip two together, or you can group them differently or have an array of tuple if you want. So there's many ways around it. I don't find it a deep limitation. Again if you're wanting to do more than two arrays, you may need to ask, do I really need to, or is there another way to look at it? And what they're trying to prevent is, it's so easy for us to feed in so many arrays and now we've got an explosion of tests.
And often there's so much redundancy that why are you taxing the system like that? Leo Dion (host): Yeah. Yeah, that's a fair point. If you were gonna start a project, let's say you're gonna do an app, would you go with Swift testing or would you go with Ixy test? Daniel Steinberg (guest): I would go with Swift testing, but I tend to do almost no UI testing.
My, my UI layer is very thin, and so if I've really tested the model and what I still call the controller layer, you know, the view model, the presenter, whatever you call it, if I've really tested those properly. Then the connection of the UI to those I don't really test that much, but if you've seen my apps, the designs aren't pretty. And so I'm not looking at screenshots to see if, Things look right.
In fact, I will say thank goodness for tech reviewers In a previous example of my calculator app, I had no four and five buttons. I had two, two and three buttons. So. Leo Dion (host): Nice. And so you would go it require, but it requires Swift six, right? So if you're, you have to use X code 16 basically, if you're gonna do Swift testing. right? Daniel Steinberg (guest): But if I'm creating a new project, that's what I'm gonna do. You said if I'm creating a new app, what would I do?
The other thing is if I'm creating a new package. I would absolutely do it in Swift six. cause one of the nice things in Swift six is you can mix Swiss five and Swift six packages. So if I'm creating a new package, I do it in Swift six, I use Swift testing and I'm not doing much UI in a package anyway, so I'm feeling pretty good about that. And one of the really nice things Apple did with this transition to Swift six is package by package.
They can be Swift five, Swift six, and everything works well together. Leo Dion (host): Yep. Yeah. That's awesome. Daniel Steinberg (guest): I know I sound like such a fan boy Leo Dion (host): with Swift six or Swift testing? Daniel Steinberg (guest): with all of it. Leo Dion (host): I know, I mean, yeah, so sw, so ga, you would totally go on board with Swift testing. As far as moving forward, there's nothing you miss from XC test at all.
Daniel Steinberg (guest): so I was a fan of behavior driven development, not test driven development. And that's the given when then type of setting. And so years ago I'd like the sort of the kiwi, the cucumber type of testing frameworks, XY test. Was kind of like a port of the old J unit, not even what J Unit has become. Leo Dion (host): That's a Daniel Steinberg (guest): other thing is, yes, Leo Dion (host): Okay.
Daniel Steinberg (guest): And, so the other thing is that Xcode, as much as I really like Xcode. There's some things that Xcode has never done that makes testing much easier. So for instance, IntelliJ for I think 20 years since the old Java days when they were first getting started, had this thing where in a test, if you said, I want to test that this class has this method and it didn't have this method, Intej would say, well, do you want me to stub it out for you?
There's no reason that Swift, which is strongly typed, and Xcode can't do that for us now, but it doesn't, and that makes testing so much easier if you can, if you really want to do TDD and drive your development with tests. And so I tend to do more test my things as I create 'em. I don't drive it. But one of the key features of testing for me is not that I'm testing the app. I'm writing API that consumes the thing that I'm creating.
And so it's the first code that I write that consumes this new thing that I, so I can look and go, well, I don't know, like the way I call that method, I'm calling it from a test. But what it means is then I go in and I change the way I call that method. I change its name. I change its parameters. I make a, an invisible label so that I'm not having to call a label colon, whatever. And so to me, one of the big benefits of testing is design. Leo Dion (host): I agree with that a hundred percent.
Yeah. because it's inter you're testing the interface, but it's like the interface of the code, right? Like it's not it's like now you get to see it in actual use and you're like, yeah, I don't like how that looks. And yeah, that makes total, I like that analogy a lot. Daniel Steinberg (guest): One of the things I like is with packages, you can also run it from the command line and the reports you get in the command line are really nice.
So one of the limitations was, I said before, if you tag something, you can run just the tags. Currently, you can only do that in X code. Leo Dion (host): Oh, really? You can't do it in command line. Daniel Steinberg (guest): You can't do it in the command line, but the team has said, oh, we see a way forward, and it's something they're considering for a future release and that'll be nice.
The other thing from the command line, and this isn't a Swift testing limitation, so much as the way things are built. If I want to test a project, not a package, I have to specify a lot more things. I have to tell you what the scheme is and I gotta tell you what the target is. And so that's not as simple as just typing Swift tests. Leo Dion (host): Yeah. Right. Overall, what's been your impression of what's come out from WW this summer? You know.
obviously we've talked about Swift testing, but has there been a lot of like new APIs or new oss that you've been interested in over the past few months? Daniel Steinberg (guest): Well, clearly Apple's push is the move to Swift six and getting complete with the, Async APIs, and so that's clearly their push. I think if you read between the leaves, App intents are gonna be very big.
It's not something I'm playing with much yet, but it's clear that what they're offering now is telling us you need to start using these are gonna be become more important. Apple intelligence. I don't know how much is shipping in the betas, but I'll tell you yesterday I went for a walk. I forgot to turn off that I was walking and I drove home and it said that I walked eight miles In an hour and that was awesome. Leo Dion (host): Yeah, we've all had those before.
Have, you, used any of the betas Daniel Steinberg (guest): Intelligence or whatever would say, Hey, you're going 30 miles an hour, maybe you're not walking anymore. Leo Dion (host): Maybe you should, you know. Apply to the next Olympics, I guess, with that kinda speed. Did You have you installed, the bait on anything yet? Daniel Steinberg (guest): Yes. cause I'm an idiot. I've installed the beta on everything.
Leo Dion (host): Okay. Daniel Steinberg (guest): I made it to Thursday of WW week before I put it on my phone. I put it on my iPad right away. Leo Dion (host): Okay. I. Daniel Steinberg (guest): And so it's been on my carry device. I have a separate partition where I'm running it on my Mac. Leo Dion (host): Oh, see, I'm more stupid than you. 'cause I'm running it right now on this Mac. that I'm recording, I'm running 15 one, so, I'm even crazier.
But then of course my iPhone is still on, what is it? 16? Yeah. Six. No, 17. Right. So I, do you have, you, have you done 18 one yet? Played around with Apple Intelligence on the phone? Daniel Steinberg (guest): I've not played around with it. As I said, if it was there. I mean, it should have told me different things, so I have it on the phone, but if it was there, it should, I'm not convinced. Leo Dion (host): Yeah, Right, right.
Daniel Steinberg (guest): But, you know, I feel very strongly that for me, AI is not LLMs is a separate discussion and I'm not really interested in LLMs. I'm very interested in what Apple can do with AI and ml 'cause. I look at what photos does with ml, and I think that's a compelling use case. Leo Dion (host): Yeah, and I think that's a big problem is that AI has become LLMs essentially in marketing speak, and Apple has been ahead with like other forms of ai.
Like you said, photography's the big one, right? Where like they've been doing photography stuff for years. And other things that they've done with the watch and various things where they've detected things. The vision. Pro is a great example of that. But now it's like the total focus is on generative and LLM and it's I don't know. We'll see how far that goes. I wouldn't say I'm a skeptic, but there's only so much LLMs, and generative can do.
Daniel Steinberg (guest): Well, I'm gonna say you're a skeptic. Leo Dion (host): you're gonna say, I'm a skeptic. I'm just, I'm not a skeptic. I think there are big, there's big benefits, but it's not gonna. We're have next year. So, a little bit like I don't think it's the, revolution people think it is, let's put it that way. I dunno where you stand on it. Daniel Steinberg (guest): I think there are things there. I recently gave a keynote at Swift, which talked about.
How do you look at all these things that come out at WW and decide what's for you? And for me, it's a combination of things that are interesting. So Swift testing was interesting, but I also have to find my place in it. And so Swift testing, I find my place in it is, it's something I want to teach. It's something I want to explain and it's something I want to use in my own code. Before I wrote the book on Swift testing.
I used it in my shipping apps, and so, you know, the ones that I sent to TestFlight using Swift six have Swift testing in 'em. But for A IML, it's interesting, I don't see where I fit in there because in order for me to do it, I need access to big clean data sets. And that's not something that I, as an indie usually have access to. Leo Dion (host): Let's I really like that topic. The, 'cause you talked about that too in Chicago on.
Deep dish where you were, like, you talked a little bit about it, where you're like, oh, I wrote a whole book on combine. And well, your talk was specifically about Swift Data, right? But you talked about combine, you loved combine, you jumped into combine And then you know, it's been crickets for ever since combine came out.
And then now you, they came out with this new thing, Swift Data, and it's like, how do you, how like without giving away Daniel Steinberg (guest): one of the things I said was because Swift Data had come out last year and deep Dish was about a month before Dubb Dub, and what I said was, I like Swift Data, but before I tell you to dig into it, I would see what Apple does with it. At this year's WW, if there are no sessions.
If there's no changes to the APIs, then I would be wary and combine was my warning. That Combine was a beautiful framework. It was great to use. I got a lot out of it, but it clearly was a step, maybe not intentional, but it was a step along the way to Async. And once they made the step towards Async and even async sequences. Start something that are pushed as much as I would've expected. Async sequences initially looked like a replacement for app published. And then we move quickly to async.
And so my, my, my only caution there was make sure you're seeing a commitment from Apple into these things before you go in. You know, there was a year, if you're old enough, you remember there was a year where we were gonna have garbage collection on the Mac. And then we weren't.
So just sometimes sometimes the people who aren't able to implement what's new because they have support to back, sometimes they're in a great position because they get a couple years to see if something is gonna stick or not. If something's gonna become as important as it looks when you're seeing that first presentation, that is so attractive and enticing. Leo Dion (host): Yeah. What did you think about Swift Data this year? Because all, I mean, we just got history stuff, right?
Is that sufficient for you to feel like, oh yeah, Swift Data is the future, or are you a bit like, eh Daniel Steinberg (guest): get some of the things I wanted. I wanted to see a more powerful predicate. For example, I wanted to see that it could be used outside of Swift UI better because, for example. I don't like this move to us getting rid of the controller layer. I prefer to have the controller dealing with a lot of this and then lightly updating.
I'm writing a lot of controller code and model code in my view now, and I don't like that trend, so I was hoping we get more support for outside of Swift ui. One of the things we did get is a very nice support for previews, and so the new, Leo Dion (host): Yes. Daniel Steinberg (guest): that helps us not sorry, I implemented as a macro. The new support we got for previews is very nice. Leo Dion (host): Yeah. Yeah. 100%.
Yeah. I mean, so in my, app I pretty much have gotten rid of query in Swift UI just 'cause it doesn't do what I want it to do. And I've moved all my Swift Data stuff to observable objects like the controller essentially. Right? And yeah, I Daniel Steinberg (guest): how are you getting updates from that? You then reflect to the. Leo Dion (host): I don't like this answer. I use notification center. So there's a way to because underneath, right, it's just core data.
And so I use the core data notifications to basically know when something is updated, and then I have basically a bunch of like listeners set up, and then that's how I know when the data has been updated. I think I did Daniel Steinberg (guest): By the way, did you see the announcements of what may be coming to Notification Center? This is I think, big news. Leo Dion (host): Okay. Go ahead.
Daniel Steinberg (guest): a notification cannot be sendable because a notification is a reference type and it create, contains a user info dictionary, which can contain anything. Leo Dion (host): oh God. Daniel Steinberg (guest): And so there's Leo Dion (host): my existence is these dictionaries with s Yes. Anyway, sorry. Daniel Steinberg (guest): so so there's this new proposal to have this notification.
I don't remember if it's notification center, do message or notification message, which is sendable. Leo Dion (host): Okay. Daniel Steinberg (guest): It's a great solution to use with Async, and now I can use Notification Center in a very powerful way and not be sending things across actor boundaries and getting all those warnings.
Leo Dion (host): To me, like the ba like that, like I don't want to get into a Sendible rant, but like the fact that there's so much old code that's like an object based or any base that's there's no way to tell if something is sendible or not. It's just been a real pain in the butt. So yeah, that's gonna be awesome. But. Daniel Steinberg (guest): one of the nice things if you have architected your app, which I tend to using lots of packages.
You can address those one package at a time and update one package at a time, and I find that very powerful. Leo Dion (host): Yeah, so speaking of Swift Data, that's kind of where I'm in the middle of right now with my app, my VM app bushel is the fact that I I ended up having a session and they're like, yeah, you can't do persistent model cannot be sendable. I think we've even talked about this offline. But so now I have to change a lot of my code.
To basically take into the fact that it cannot be sendable and do everything in closures or grab the persistent identifier. And that to me has been a big pain in the neck is like to me. So I would think Swift Data would be even more friendly to async away considering how new it is, but it's like kind of not. And I think, we specifically talked about the fact that like why is model, why are models, classes and things like that.
Daniel Steinberg (guest): Well, and that's what I was gonna say is that's the difference between the Swift team and the Swift UI team is Swift Data, I thought would've been the opportunity to make these things value types. And then they would've been easier to send. Although we might have gotten into issues with non copyable but it would be nice to be able to send these things across And so you end up sending sort of a representation of them so that you can get updates.
Leo Dion (host): Right, right. Yeah, that's kind of what I'm doing is just grabbing the persistent identifier and using that and then kind of co copying the fields. but that's so it feels like so awkward and it could be so easily done in another way Like I get that it's a class because underneath It's a reference to some. SQL light file somewhere. Right. But at the same Daniel Steinberg (guest): we know that Leo Dion (host): Right, right. I know. I'm agreeing.
Yeah. Daniel Steinberg (guest): So, so all of what? All of what you just said, I lost my thought. I'm sorry. Leo Dion (host): that's okay. I mean, I kind of think that's what I feel like they're trying to push away from classes as much as possible and get everything to be a non copyable, structor or an actor. it almost feels like That's kind of the trend in a lot of ways. Daniel Steinberg (guest): I'm, so a lot of what we have to do is put things on the main actor.
It looks like we're putting a lawn on the main actor until you actually go through debugging or look at instruments, and you find out that things are pushed off the main actor when they can be every time you hit in awai. And so at first it feels like we're putting everything on the main actor and why isn't this slowing things down?
But when you dig into the async, sometimes you find out, yeah, but when the system can push things off to a background thread, it's happening for you, Leo Dion (host): Oh, okay. That's really interesting. Makes sense. Yeah, so I wanna talk a little bit about your Swift craft talk that you did in England a few months ago. Macros. Macros are one of those things where I'm afraid they put, they invest. Apple invested a lot into it.
And then we haven't heard a lot as far as making app, making, building at macros better. But then at the same time, we do see a lot of macros everywhere whenever they can. Where do you, like, where do you see the future of macros and where they're headed? Daniel Steinberg (guest): So one of the problems with Swift evolution is we see everything that's being added to Swift, and we think everything is for us.
Some of the things aren't for us, like you can go through the rest of your life and never write a macro and still benefit from macros. Pound preview in Swift UI is a macro that got rid of so much dumb boilerplate code. It's, in my opinion, the perfect macro and so Swift testing at Sweet at test. The tags are at tag pound, expect pound require. These are all macros. And so I'm using it all the time. Do I have to be writing my own?
And also the ones that we write, as opposed to the ones that Apple writes, we have to bring in Swift syntax, which slows down a clean build. And so, although I liked writing macros and I still write macros, I don't think they're for us primarily. I think they help. I think they help make the environment we live in better. But before you write your own, you really should question, can you do it any other way? Could you do it with a function, for example? Could you do it with a protocol?
And so if there's another way to accomplish what you wanna accomplish, then don't reach for a macro that macros are great when they're used for What they should be used for. Leo Dion (host): What do you think is a great example of when you should create a macro? Do you have a checklist of Daniel Steinberg (guest): so my example was pound preview. 'cause if you think of pound preview before pound preview, we had to come up with Some name and we tended to name it whatever the view was.
Under previews, we had to conform to something. Conforming to that thing meant we had to implement something, and so we implemented this computed property inside of the struct, and all we cared about was what are we presenting in the preview pound preview says type pound preview, and give me the thing you're presenting. End of the day, that's a beautiful macro. That's a great use of macro. So, in Swift Data for example, they gave us a way of creating something that would present data in a macro.
And most of what we have to type in is nonsense. And I would've done this in a function except if you give me a function that accepts a vari inside the function that's transformed into an array.
I can't then turn around and call apple's function that requires a very at, so I had to create a macro, and so I created a macro, that makes adding preview data really trivial and gets rid of a page of this boilerplate, which is just it's, not that it's not important, but it's non-interesting and it never changes. Leo Dion (host): Do you think at its core macros are a way to bring the dyna dynamic abilities of Objective-C into Swift, essentially.
Daniel Steinberg (guest): I, don't think that the dyna, I think that the dynamism of Objective-C is very powerful and a runtime thing. So macro is a compile time thing. Leo Dion (host): The reason I'm saying that is like with Objective-C, you could change stuff on the fly all the time. And there's certain things You could do with Objective-C reflection wise, for instance.
And it seems like with macros, it's a way of like basically changing a certain type on the, kind of, on the fly, but not really like by, by basically modifying the code. Because it's Daniel Steinberg (guest): I wanna stress it. It's a compile time issue. It's not this change isn't happening at runtime. Leo Dion (host): right, right. Obviously. Yeah. Yeah, Daniel Steinberg (guest): well, it not obviously be it needs to be, say, stated, right? Because that's Objective-C.
We could do stuff at runtime. Leo Dion (host): Yeah. Yep. Yeah, that's a good point. Before we close out you got. Books. You got a books a book coming out specifically on Swift testing. Do you we'll put a link, you'll have a pre-order link that we can share with our audience. Okay. Awesome. Do you have any other books coming out? Probably updates right. Daniel Steinberg (guest): I have both books and I have updates. What I'd like to do is make sure that my, my books are still relevant.
So I updated my Swift intro book for the last time I've End of Life Did, but it now works in Swift six. I don't think the intro material will change. I'm going to write a Swift six book, which is for sort of that next level stuff. What have we gotten, not just in Swift six? 'cause a lot of what we call Swift six, we got in Swift five, nine five, ten five. You know, it's been evolving towards this. And so I want to talk about that just because I'm an idiot.
I don't know if you've noticed, my last books have all used sort of a detective theme and so I've had this running detective story. The Swift six book will have a Winnie the Pooh theme because of the Winnie the Pooh book. Now we are six, of course, now we are Swiss six. And so Leo Dion (host): Right, right, right. Daniel Steinberg (guest): looking forward to playing with that. I have to update my async book to Swift six, my macros book to Swift six, my data flow in Swift UI, book to Swift six.
and I may also update, it should be a light update, the functional book and the Swift UI kickstart, and those will be end of life with those updates. But the Async book, the data flow and Swift UI and the Macros book, those will continue to live. I'll continue to update those. Leo Dion (host): Awesome, and we'll put links to those in the show notes as well. And then you have a bunch of conference appearances you'll be making. Mostly Europe, I think, right?
Daniel Steinberg (guest): Mostly Europe. I'm just a stranger in my own land. But so, so the easy answer is if I'm at a conference, it's because I was invited. If you ask me, I generally say yes. And so if I'm not at a conference, 'cause I wasn't invited, and so, I'll be going to Swift Island and ISW uk. Those will probably be before this post, I'm doing a Swift testing workshop at iOSDevUK and then at NS Spain.
I'll also be doing a talk at NSSpain on macros and another talk on macros at server side swift at the end of September. And so, Busy time coming ahead. And then finally in October, I hope to see you in Bologna for Pragma call, which is just also, these are all just such great conferences, great community and amazing organizers. Leo Dion (host): And I will see you in London for Server side Swift. I'll be doing my talk on how does Server Side Swift work out in the real world.
And I literally mean out because it's a fitness app. So yeah, I'm really looking forward to that. We'll have links to all that stuff in the show Daniel Steinberg (guest): It'll be great to see you there and maybe we'll do a meal together. Leo Dion (host): I know. Yes, I know. Locks, locks and bagels like, you know, I'm like addicted to it. Thanks to you So. Daniel, thank you so much for coming on. This was fantastic. Daniel Steinberg (guest): My pleasure.
Leo Dion (host): W can people find you online? Daniel Steinberg (guest): Dim sum thinking pretty much everywhere. Dim sum thinking.com includes links to everything I do. And then on socials, I'm blah, blah, blah. Dim sum thinking. Leo Dion (host): Yep. Awesome. People can find me on. Social media at Leo Dion. At Leo Dion at C Im on Mastodon. If you're watching this on YouTube, please and subscribe. I'd really appreciate it. As you can see, I'm in, can you see? Let's see. No, maybe not.
I'm moving. So, I don't know when this episode will come up, but hopefully soon. You know, where it's still relevant, so, yeah. Yeah, that'll be my busy project for the next few weeks. Thank you everybody for joining me, and it was good to see you. Bye.