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.