Leo Dion (host): Hey folks, I'm excited to announce the release of Bushel two.
Bushel two introduces the new screenshot and screen recording feature.
This allows you to record your VM and add titles, notes, and
export to anywhere you want.
So please give bushel two a try if you haven't already.
I'm excited to keep working on Bushel and looking forward to
adding new features in 2025.
There's still a sale for Bushel Pro for first time users.
It's 50% off, so definitely take advantage of that.
Thank you so much and I hope you enjoy this episode.
Welcome to another episode, empower Apps.
I'm your host, Leo Dion.
Today I'm joined with Donnie Walls.
Donnie, thank you so much for coming on again
Donny Wals (guest): Yeah.
Hey.
Yeah, great to be on again.
Thanks for inviting me.
Always love catching up, love chatting.
So
Leo Dion (host): for people who don't practically know who you are.
Yeah.
Thank you.
I'll let you go ahead and introduce yourself.
Donny Wals (guest): Sure.
Yeah.
So, so my name is Donny Walls.
I've been making apps, websites, service side things for
probably about 18 years now.
Was 10 of them on the iOS platform mostly pretty much since what
came out a little bit before that.
And a couple years ago, I decided that I was going to write some
books to help people learn some of the more interesting to me topics
in the realm of building apps.
So that would be core data combined concurrency, and yeah you
might've seen me around on social media, on my blog, on my books,
YouTube, those kinds of places.
Leo Dion (host): we'll have links to all that stuff in the show notes.
So we're talking before the show.
You didn't put out any books this year.
What's why is that?
And maybe what are you thinking about writing about next?
Donny Wals (guest): yeah, so, so last year apple had swift concurrency
more how would you say that?
Like, not necessarily finished, but it was getting close to finished.
It felt like I wasn't moving as much.
I was very wrong on that, but we'll talk about that more, I assume.
So I decided last year I'm gonna do a book on concurrency, and
Apple also launched swift data.
So for a moment I thought maybe I need to be working on two books this year.
So I immediately went ahead and started planning out a swift data book, but
there was still so much missing from Swift data last year that I decided.
It's not worth me writing about right now.
I already have concurrency, which is, a hot topic.
So maybe I'll do swift data this year.
So I saved myself for that.
And then this year Apple didn't really change that much in swift
data, and so I'm still waiting for that to be more baked.
And then there's swift testing, which is a topic that I am interested in.
But I just didn't have that much time to actually dig into that 'cause
yeah, I can only focus on so many
Leo Dion (host): Right, right.
Donny Wals (guest): But, so those are also the two that I would be
thinking about testing and swift data.
Leo Dion (host): let's first start with swift data.
What's missing?
Donny Wals (guest): Oh, okay.
So definitely it, it doesn't have support for sharing records, right?
It has a public database, I believe, and that's it.
Whereas with core data, you can have public, private.
And shared records.
So that's already a huge difference.
There's pretty much no tooling to properly use swift data outside of Swift
UI views, whereas with Core data, you're you can use some of Swift UI built
in property wrappers, but you're also free to do a lot more customization.
There's still bugs when you insert stuff from a background context where the main
context doesn't automatically update unless you perform some workarounds
or re not even when you save it.
You have to listen for a notification from core data and then
manually trigger a redraw on your
Leo Dion (host): Yeah.
Donny Wals (guest): So those kinds of things, there are still
a lot of rough etches like that.
I just feel like Apple didn't get to around, to addressing them this
year and with what they did do.
Right.
'cause now we can have custom underlying stores.
They showed that where you can write your own I'm honestly not
even sure if next year they'll have core dates as to default anymore.
'cause you would think that they would have been able to bridge
more and more functionality from core data into swift data.
That doesn't seem too hard.
He said Right.
Not knowing what goes into it.
But I mean, like, the functionality is there.
So I felt like maybe this year they'll bridge more of that, but they
didn't bridge anything additionally.
Instead they made it so that you can swap stores.
So maybe they're moving away from court dates.
I don't know.
Leo Dion (host): I mean, do you think, and we'll talk about combine later,
do you think Daniel had made this point in a I think it was the swift
deep dish talk that he gave this year about combine and swift data.
Do you think like, are we ever gonna have a combined situation with
SIF data where they're just like, yeah, just keep doing core data?
Donny Wals (guest): Yeah I'm not too sure about that.
It is most certainly looking like it, right?
Because combined came out and we were just like, oh, there's
just a couple pieces missing for it to be as powerful as rx.
They're almost there, so surely next year they'll do it.
And then they said, eh, we're done with combined.
We think it does what it needs to do.
We'll do a couple quality of life improvements.
And that's about it.
I think Swift data, what they're doing, I think they wanted to do a lot
more than they actually got to ship.
Because they shipped so little, like from the outside point
of view where it's like, okay, so we can make our own stores.
Why would we want to do that?
Swift data itself doesn't even seem completely finished yet.
And so it felt like maybe they were trying to do something much
bigger, and this is the one part that they could ship this year.
And then next year in June we're gonna maybe see something huge.
So I think it might not be like combined because it really feels
like they set themselves up to do something much bigger with swift data.
But we'll have to see at dubbed up.
I think if at this dub up they don't do much or they do something similar, then
maybe it is gonna be more like combined.
Leo Dion (host): Yeah.
Yeah.
I mean, that's a great point.
I think if they don't do it.
This year.
Last year was, so we'll talk about AI later.
It was so emphasis on ai.
There wasn't much of anything this year, but like yeah, if they don't
do anything with swifty y then or Swift data, then yeah, I could see
how, what the heck is going on guys.
So yeah the issues I've run into with swift data, I so I've done
a lot of swift data with bushel.
Hopefully by the time this episode is out, bushel two will be out.
And I open sourced a lot of the like, agnostic code into a
library called Data Thespian.
Thank you very much.
'cause it has to do with actors and data, so, yeah.
Thank you.
So, yeah, the issues I ran into were like the whole temporary Id.
Like if you start doing stuff with things that are temporary
and not yet saved, it crashes.
And then dealing with contacts and switch ui, like the
auto save is not that great.
Like I moved over to auto saved and I was just surprised
at how little it saves.
So there's a lot of points in bushel where I just end
up having to save manually.
And then, yeah, I ended up doing a lot of stuff with using that core
data notification to let things know that things have been updated.
'cause yeah, as far as like Swift UI is concerned, you're pretty
much like you end up having to do a lot of manual stuff.
Like queries are great, but like it's very incomplete with what you
actually need for SWIFT UI and SWIFT
Donny Wals (guest): Yeah, it is great.
You mentioned context.
'cause I think probably my biggest thing that I'm missing is child context.
Like I use them all the time, make a child.
Managed object context.
I'll load an object into it, pass it to a view, allow the view to edit it.
If I don't want the changes, I just throw the context away.
If I do want the changes, I save it into the main context.
That just doesn't exist in SWIFT data.
So, so you're stuck copying every property from an object into a
state VAR so that you can then manipulate the state var when you
save it, you copy everything back.
It's way more
Leo Dion (host): Yeah.
Donny Wals (guest): Yeah
Leo Dion (host): anything else you wanna talk about?
Swift data.
So you think, would you write a book, I guess, are you thinking
I'll write a book if stepped up?
Says a lot of stuff, but otherwise
Donny Wals (guest): probably.
Yeah.
It's because it's, I have the Coordin a book and I feel like
that's still the much better option.
So it would feel weird to write a book about the other
technology where basically.
Almost every chapter is going to end with, but if you want everything,
you should check out core data.
I don't want that, so I'm not sure yet.
It really depends on what happens at dub whether I would feel that's
a feasible book to be working
Leo Dion (host): Would you even like write a chapter maybe for
swift data in your core data book?
Donny Wals (guest): I've considered that core data is up for an update.
So it's something that's still in the back of my mind.
Like maybe I should just, write about that.
But then it would mostly be about like interoperability.
Like when you hit something that's not there in swift data or where it
doesn't work how do you build a bridge between the two because you, you can
do it whether it's pretty or not.
I'll leave that up to the eyes of the beholder,
Leo Dion (host): Yeah, if you want some really good content on Swift data and
Core Data, I recommend F Fat Bob Mann.
He's got some really great blog posts.
I'll link in the show notes, but definitely check his stuff out.
So the other thing you mentioned was SWIFT testing and we had a really
great episode on SWIFT testing with Daniel a few episodes ago.
And what was your favorite thing about SWIFT testing over XC testing?
Donny Wals (guest): that's, I think just the overall the overall syntax of it.
Right.
When I look at it, the fact that I could just write at test funk and then write
anything basically, like in any file in a test target is already so useful.
Like, it makes it super quick, super easy to just throw in
a bunch of tests and yeah.
I've been thinking about this the other day actually, like, like
why am I so much more eager to write tests with swift testing
than I ever was with XC test?
And I'm just not entirely sure.
I think it's the whole package.
Leo Dion (host): Do you think, so we just talked about
SWIFT data, SWIFT testing.
Is there anything missing from XE testing that you are like really
desperate for outside of UI testing, which is a whole other thing.
Donny Wals (guest): Yeah.
Yeah.
So, so UI testing, I don't do much of that anyway, so,
so that I'm okay with that.
I do feel like Apple dropped the ball on giving us a good way to
test our completion handler base
Leo Dion (host): Okay.
Donny Wals (guest): Test methods in SWIFT testing our async, and they work
really well with your async weight code.
But then if you want to test something that you use as a completion
handler, apple recommends that we use something called a confirmation
which gives us a closure, and we can call that confirmation any amount
of times that we specify we should.
So if we have.
Something that does a piece of work in 10 steps, we can say this
confirmation's gonna be called 10 times.
The issue is that you call that function and you give it a closure, and then that
closure runs and it's an async closure.
So you can await things in there.
And then when the closure returns, you're expected to have called
all of your confirmations.
So in practice that means if you call an old school completion handler
based API then your confirmation closure is returning before your
completion handler got called.
So you need to have something to await inside of that thing.
And it's like, so I already have this asy weight code.
Why am I using this confirmation thing then?
Like it has its uses, but what I want to do is just test my old code with it.
And I can only do that when I use a continuation.
So there is a tool for that.
It's a spoken currency tool.
But it really feels like swift testing should have had something for that
similar to test expectations and XC
Leo Dion (host): Right, right, right.
Do you like, one of the missing pieces that I saw was like a lack of one of
the problems with SWIFT is you can't go in and like swizzle stuff, right?
It's specifically a static type language and we have macros, but then like.
I was expecting maybe like a macro to be able to create mocks easily and
things like that, stubs and so on.
And that, that I feel like is something I'd really want is like
just a easy way to like, okay, it's a protocol, just implement everything
and then here's a few implementations.
And the macro would just handle it for me and then that way I
can easily test that kind of stuff, you know what I mean?
Donny Wals (guest): Exactly.
Yeah.
I know what you mean.
Leo Dion (host): Yeah.
That would be, I would love to have that and yeah, someone could
write that, but we all know macros are a pain in the butt, so, yeah.
Donny Wals (guest): sure.
Yeah.
It would've been cool.
Leo Dion (host): have you ridden any macros or anything?
Donny Wals (guest): I have not, no, I looked very briefly at how to do it.
But I I've never really felt the need to write one.
Yeah, I'm trying to think of like places where I could have maybe used a macro,
but there's so few and far in between where it's like all the hassle of
making a macro probably wasn't worth it.
And I'm also always a little bit cautious with those things
'cause I don't want to end up going overboard with it.
Like once, once you start using them, maybe you go overboard and you almost
end up with this version of Swift that's only recognizable to you.
I know that's
Leo Dion (host): No.
Totally.
Donny Wals (guest): stretch of like.
What macros can do.
I think C or whatever, C sharp, one of them people go overboard
with that, where you can basically have a completely new dialect
of C just because of the macros.
Yeah, I think that's like pulling it, like, stretching it really far.
But yeah I think the macros that we get from Apple are good.
I don't feel too inclined to be writing my own
Leo Dion (host): Yeah, 100%.
I wrote one for option sets.
Recently and I was like, yeah, that's good.
And then I tried something else that was more difficult.
I'm like, yeah, I'm not pulling up a syntax tree or anything like that.
Like not something I'm interested in deep diving into.
'cause it's like a rabbit hole, right.
Once you do it, it's like you.
Donny Wals (guest): Yeah.
Just like a whole bunch of things that you have to know and understand
before you can properly make your own.
Leo Dion (host): Right, right.
Okay, well you mentioned concurrency.
So let's talk about concurrency.
Yeah.
So what do you think is the most challenging part about concurrency?
Donny Wals (guest): Oh.
I think for me the hardest part is when you have an existing project and
you're trying to understand all the bits and pieces, so you're basically
learning this on top of your existing skill set, and you're taking in
every proposal, every piece by piece.
There's so much changing.
And the proposals aren't always written in the most easy to follow language.
Like it's very academic, very compiler engineer oriented, not
necessarily end user oriented.
And as a result, I feel like you start tripping up over details and
over complexities that somebody that's coming into it fresh.
Maybe even in a new project, like won't be bothered by too much.
I think that's the hardest part is taking your existing code,
your existing knowledge, and then putting concurrency into it.
I think that sort of creates this mix of overlaps and differences
that's really hard to follow for
Leo Dion (host): Right, right.
Yeah.
And it's not as intuitive for a lot of swift developers, especially when
you get into actors and like, okay, main actor, where does that go?
Well, a lot of us have pre knowledge already, right?
Of dispatch groups and DIS and GCD, right?
So we come into it with this preset of knowledge, and then we
try applying those same rules to concurrency, and it's just not,
it doesn't match up quite right.
You know what I mean?
Donny Wals (guest): For sure.
Yeah.
Leo Dion (host): What do you think is the biggest revelation you've had when
you've, written blog posts or books about the new stuff with concurrency?
. Donny Wals (guest): I, I think it, it happened a while back where, and
it's also the part that Apple is probably going to change, but that
it's super easy to have work that's not on the main thread right now.
If you write a function, make it async, you make sure it's not like
somehow isolated to an actor or to the main actor specifically.
That's always going to run in the background.
I think and Swift 5.5, or whenever they first introduced
concurrency, that wasn't always the
Leo Dion (host): Okay.
Donny Wals (guest): but then they formalized the behavior and he said
every non-isolated async function.
Is going to run on the global executor.
So that means it's on the main thread and that completely eliminates
the need to have detached tasks.
Right?
So that on top of the fact that an await from the main actor
doesn't block the main actor.
I think those two things for me when I first started learning were
very eye-opening and very important details of how concurrency works.
Leo Dion (host): What's the ramifications for that?
As far as like having everything run on the global thread or
the global actor, I should say,
Donny Wals (guest): A global executor
Leo Dion (host): global
Donny Wals (guest): Yeah.
Yeah.
So that's basically like the thread pool that contains
everything except for Maine.
So the biggest ramification is probably that a lot of your code is
going to be considered concurrent.
Even when you don't want it to, right?
So let's say you have a view model with an async function and you have your main
actor annotated swift UI view, which all views since I was 18, are by default.
What happens is you're now calling from the main actor to
a non-isolated async context.
So you're immediately going to the background and that will have you run
into issues where the compiler's going to tell you in so six mode that you're
bridging your view model instance, which is tied to the main actor
into a non-isolated async function.
So problems start to happen immediately where you're just
like, okay, what do I do here?
And then what happens is a lot of people just start slapping
main actor on everything.
'cause that gets the warning to go away.
And then in theory you could argue that's fine, right?
Because you are normally interacting from the main
thread with that view model.
So calling functions on that view model would have the functions
run on main anyway, right?
In most code bases, I would say you go from the view to the view model, from
the view model to your data layer, from your data layer to the network.
And it isn't until URL session starts to make the call that
you leave your main thread.
I think very few people explicitly leave the main thread in their
view model or their data layer.
But now you're applying the main actor annotation to all these things and
you feel like, oh no, I'm definitely blocking the main thread right now.
So that becomes scary.
And yeah, so, so that, that is a problem both in adoption and fixing it.
'cause a lot of people are now dealing with sendable issues.
Where they technically don't even need something to be sendible.
'cause they just wanna send it from the main actor all the way to the network.
And that's it.
They don't even want to use certain models in the background.
Leo Dion (host): So all my view models are basically main actor and
then, like, what I ended up doing is either a, making an actor so that
way it like runs on its own space.
Because you'll have stuff where you can read a brain at the same time.
That's essentially the issue.
Right.
The other thing that's really thrown me a curve ball is the stuff with
like, so they added a bunch of prefixes to parameter arguments, like kinda
similar to the non-op rule stuff, but like where you have to say this
consumes it or this doesn't consume it.
And that's where I've run into issues lately is ambiguity about that.
Even when you mark something as sendable, it's, you have to
still be careful about that.
I found, you know what I'm talking about.
Donny Wals (guest): I think I do.
Yeah.
There's just a lot of rough issues around that.
And they're trying to solve some of this with more keywords like
descending keyword right, where they basically allowing you to say, okay,
so, if I pass a non sendable thing into this function, that's fine.
But after it's been passed to this function, the caller
can't use that object again.
Right?
That's how you can pass stuff from one isolation boundary to the next and tell
the compiler I know what I'm doing.
I intend to do this.
Just warn me if I'm using this object again.
After sending it to some other place,
Leo Dion (host): Do you think
Donny Wals (guest): is a whole other rabbit Hal to do I think I, I think
what they did with it is really useful.
And I think it also solved a lot of errors for a lot of people.
Like when you, like task currently has a sending closure
instead of a sendable closure.
And that makes it so that you can safely use certain nons sendable
things inside of your task as long as you don't also use them in other
tasks or after you've made your
Leo Dion (host): Right, right,
Donny Wals (guest): So I think for a lot of people that solves an issue.
I think the underlying problem that a lot of people still run into is the
fact that non-isolated async functions don't inherit the caller's isolation.
Which means if you have your main actor view, your non main
actor view model, you're leaving the main actor immediately.
Leo Dion (host): I.
Donny Wals (guest): And that's a problem that Apple wants to
solve now that they've been publishing some proposals and.
Manifests around this in the past few weeks where they basically
say, okay, maybe we should change how that model works.
And yeah, almost revert, not entirely, but almost revert
that thing that changed round.
So 5.6 or right after five five or whatever it was where non-isolated
async functions will inherit the isolation context of their collar,
which means, right, if you have your main actor annotated view, your non
main actor annotated view model, that an async function on your view model
will still run on main, if it was called from main, basically getting you
back into your old GCD like behavior.
Leo Dion (host): Do you think, I mean, do you like that?
Do you think that there's performance issues with doing that?
Donny Wals (guest): I, I think performance issues,
we won't get that so much.
I think that's not a concern.
The thing I'm most concerned about is we've had three and a half
years now with the current model.
And before Apple's going to introduce this change, we'll
probably have had four or so years.
I doubt they'll do it just randomly.
So I think maybe dubbed up is a good moment where we have a beta period.
But yeah, we'll have had a whole bunch of times with the current model and
a lot of people aren't explicitly aware of how this model works.
So I think for a lot of people, code just works the way it does.
Apple's going to make this change and people are probably
not even going to really notice.
But for those that do know the behavior and do have like their
expectations around it, it's going to be really important
that Apple has a good migration path which I'm sure they can do.
'cause they can detect non-isolated async.
So if there's like some annotation that we have to
add, they could automate that.
The part that's most worrying to me is that we have a backlog of, by then,
probably four or more years of content.
That's out there online telling people how this thing works, but then they've
changed it in some swift version.
And so a lot of people are going to have to go back to update their blog
posts, rerecord YouTube videos, add annotations here and there to make
sure that people don't come to expect
Leo Dion (host): Teach their AI model the correct way to do it.
Donny Wals (guest): yeah.
So AI for Swiss is already a big mess, right?
'cause every dot release changes things.
Leo Dion (host): Yeah
Donny Wals (guest): but this is definitely going to hurt,
people's ability to Google or use LLMs to learn about concurrency.
Leo Dion (host): that's an interesting point.
I hadn't thought of that, but I mean, there's a lot of stuff online where
it's like, oh, we changed it in this, so I could see that's a problem,
but eventually it'll get fixed.
Donny Wals (guest): I think long.
I think long term it's probably the right thing to do.
I think short term it's a little sad that we've had four years with this
model and only now apple's deciding that this is not the way they want it to go.
Leo Dion (host): how so if they go with the old way, can there,
can you mark a method as it should not run in the main actor?
Donny Wals (guest): So if they revert, it's not, it is
not technically reverting.
But if they revert the current model,
Leo Dion (host): yeah.
Donny Wals (guest): Yeah.
So, so what they're wanting to do is introduce either another keyword, an
annotation, or something like that where you can say like, um, it's, it is
going to turn into something like an.
A, a detached funk, my name Async Throws or whatever, or non-isolated
funk or something like that, where we have to get explicit in terms of
what we want, as in, we don't want this to inherit isolation context.
I think if Apple, that it'll be fine long term, but it's definitely
going to make our functions messier.
Leo Dion (host): Right.
Let's see, what else.
So let's talk about it.
Do you think combine is dead?
Donny Wals (guest): Oh, okay.
That's an interesting one.
I don't, I really don't, and I think probably me and like 20 other
people in the world to this day will say, I don't think it's dead.
I've tried to not use combining projects and the problems really arise.
When you try and observe states, if you have an observable object with
published properties and you want to observe those published properties for
changes doing that with Async streams, it's possible, but it's more tedious.
If you want to have the full feature set of what publishers can do,
you have to use swift algorithms.
And even then you don't get the full feature set because you can't
have two iterators on the same async stream at the exact same time.
So there's still like a couple things missing there
for state observation, right?
So I wanna be very specific on that state observation.
For everything else, I think combined was always not the best tool, right?
So if you had your networking layer that would give you a publisher, and
a publisher would give you the result of a network call that worked, right?
It was a fine model and it fit this functional, reactive way of thinking
that some people really subscribe to.
But I think for like most folks, that never was the most elegant way to do
networking or to do async processes.
So for the parts where I use async or combine as an async
programming library for those parts of it combine's definitely dead.
But it should have never been fully alive to begin with, I think.
Leo Dion (host): Do you when you say state observation though, you're
assuming it's an observ object.
What if it's just using observable?
Donny Wals (guest): Right?
So, so that observing properties that are observable is a pain either way.
Like, I don't like the syntax we have for doing it right now.
I actually dug into why it is the way it is, right?
'cause you have to write that with observation track enclosure, access to
properties that you're interested in.
And then whenever you get an update, you have to resubscribe
or something like that.
It's almost like the very old web socket APIs that Apple had.
And the whole reason it is like that is Apple made this, and they actually
had somebody say this on the forums.
They made this so that Swift UI could have it, and then
they stopped working on it.
And that's two years ago.
And they did express interest, or at least the person that worked in
the proposals expressed interest in making it more general purpose, but
they just never got around to it.
I don't think Apple has a ton of interest in making observable convenient
outside of Swift UI at this point.
Leo Dion (host): So like
Donny Wals (guest): usable.
You can do it,
Leo Dion (host): What I've ended up doing, so everything in.
Bushel is observable and I just end up using will set to monitor changes and
make changes within the object itself.
Donny Wals (guest): yeah.
So that's within the object, right?
But what if you have another object that wants to observe a
property from your observable?
Leo Dion (host): Yeah.
How do I do that?
That's a good question.
Yeah.
I mean there's always a way passing in a method or Yeah.
Donny Wals (guest): Sure.
Yeah.
Leo Dion (host): what I've ended up
Donny Wals (guest): but it is, it's, yeah, it is just not
as convenient as published.
Leo Dion (host): percent.
Yeah.
So where I've ended up using Combine a lot is with the built-in publishers
that exist like we had talked about previously with swift data.
Like, I have, I'm using combined to observe notifications
about changes to the data.
Right.
That, that works out really well.
Or if you do anything well that's Notification Center, right?
So if you do anything with those, built-in ones what was the other one?
There's three, right?
URL Session has a publisher, notification Center has a publisher,
and there's one more I'm missing, but, oh, timer, that's what it is.
The timer?
Yep.
Those are the ones where I end up using Combine mostly.
Donny Wals (guest): And I think it's still the right
tool for the job in those
Leo Dion (host): Right,
Donny Wals (guest): I've tried like going all in on async
sequences, like async for loops.
It's just too easy to create memory leaks.
If you make your own async streams, you can't have more than one for loop on it.
You don't often need it, but when you do, it's nice that it's
possible to have like multicasting.
So, yeah I don't think combine's dead yet.
I think Combine is just sitting there having its one or two purposes in
the world, and that's where it sits.
Leo Dion (host): Do you think there's a place for any of the
functional programming stuff and or do you feel like async sequence
or async algorithms fills that void if you want to go that route?
Or like,
Donny Wals (guest): I think for the most part it does.
I think it's not fully there yet.
I couldn't give you great examples from the top of my head
other than Multicasting, but I think it's not fully there yet.
But at least the nice thing with SWIFT algorithms is it's open source.
It is Apple managed, but the nice thing with these packages is that they can
be updated without needing a swift update, without needing an iOS update.
So anything that's in these packages is essentially by definition something
that you can just pull in right now and use on any project and you'll have
backwards compatibility for years?
Leo Dion (host): Well, Donnie, it was really good to talk to you.
We'll talk more about some of the other stuff like the Vision Pro and AI and all
that in the next half of the episode.
Before we close out, where can people find you online?
Donny Wals (guest): Yeah.
Well first of all, thanks for having me and I look forward to
continuing that conversation.
People can find me on X threads, masted on blue sky, right?
Pretty much every social network.
YouTube, I'm also on there, but if you really wanna have a conversation with
me or hang out or just be where I'm most active, come find me at Blue Sky.
'cause that's where currently I think everybody is at.
And so I just follow the flock.
Leo Dion (host): Awesome.
People can find me on Twitter at Leo g Dion.
My company is Bright Digit.
I'm also on Mastodon Blue Sky Threads.
Leo g Dion if you're listening to this on a podcast, please gimme a review.
And if you're watching this on YouTube, please like and subscribe.
It's good to see everybody.
Talk to you later.
Bye.
Donny Wals (guest): So, yeah.