Practical Year - Part 1 with Donny Wals - Empower Apps

Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Leo Dion (host) (00:00):
Hey folks, I'm excited to announce the release of Bushel two.

(00:03):
Bushel two introduces the newscreenshot and screen recording feature.
This allows you to record yourVM and add titles, notes, and
export to anywhere you want.
So please give bushel two atry if you haven't already.
I'm excited to keep working onBushel and looking forward to
adding new features in 2025.

(00:24):
There's still a sale for BushelPro for first time users.
It's 50% off, so definitelytake advantage of that.
Thank you so much and Ihope you enjoy this episode.
Welcome to anotherepisode, empower Apps.
I'm your host, Leo Dion.
Today I'm joined with Donnie Walls.

(00:44):
Donnie, thank you somuch for coming on again

Donny Wals (guest) (00:48):
Yeah.
Hey.
Yeah, great to be on again.
Thanks for inviting me.
Always love catching up, love chatting.
So

for people who don't practically know who you are.
Yeah.
Thank you.
I'll let you go aheadand introduce yourself.

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 platformmostly pretty much since what
came out a little bit before that.
And a couple years ago, I decidedthat I was going to write some
books to help people learn some ofthe more interesting to me topics

(01:26):
in the realm of building apps.
So that would be core datacombined concurrency, and yeah you
might've seen me around on socialmedia, on my blog, on my books,
YouTube, those kinds of places.

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 thinkingabout writing about next?

yeah, so, so last year apple had swift concurrency
more how would you say that?
Like, not necessarily finished, butit was getting close to finished.
It felt like I wasn't moving as much.
I was very wrong on that, but we'lltalk about that more, I assume.
So I decided last year I'm gonnado a book on concurrency, and
Apple also launched swift data.
So for a moment I thought maybe I needto be working on two books this year.

(02:14):
So I immediately went ahead and startedplanning out a swift data book, but
there was still so much missing fromSwift data last year that I decided.
It's not worth mewriting 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.

(02:34):
And then this year Apple didn'treally change that much in swift
data, and so I'm still waitingfor that to be more baked.
And then there's swift testing, whichis a topic that I am interested in.
But I just didn't have that muchtime to actually dig into that 'cause
yeah, I can only focus on so many

Right, right.

But, so those are also the two that I would be
thinking about testing and swift data.

let's first start with swift data.
What's missing?

Oh, okay.
So definitely it, it doesn't havesupport for sharing records, right?
It has a public database,I believe, and that's it.
Whereas with core data, youcan have public, private.
And shared records.
So that's already a huge difference.
There's pretty much no tooling toproperly use swift data outside of Swift

(03:25):
UI views, whereas with Core data, you'reyou can use some of Swift UI built
in property wrappers, but you're alsofree to do a lot more customization.
There's still bugs when you insert stufffrom a background context where the main
context doesn't automatically updateunless you perform some workarounds
or re not even when you save it.
You have to listen for anotification from core data and then

(03:48):
manually trigger a redraw on your

Yeah.

So those kinds of things, there are still
a lot of rough etches like that.
I just feel like Apple didn't getto around, to addressing them this
year and with what they did do.
Right.
'cause now we can havecustom underlying stores.
They showed that where you canwrite your own I'm honestly not
even sure if next year they'll havecore dates as to default anymore.

(04:13):
'cause you would think that theywould have been able to bridge
more and more functionalityfrom core data into swift data.
That doesn't seem too hard.
He said Right.
Not knowing what goes into it.
But I mean, like, thefunctionality is there.
So I felt like maybe this yearthey'll bridge more of that, but they
didn't bridge anything additionally.
Instead they made it sothat you can swap stores.

(04:34):
So maybe they're movingaway from court dates.
I don't know.

I mean, do you think, and we'll talk about combine later,
do you think Daniel had made thispoint in a I think it was the swift
deep dish talk that he gave thisyear about combine and swift data.
Do you think like, are we evergonna have a combined situation with
SIF data where they're just like,yeah, just keep doing core data?

Yeah I'm not too sure about that.
It is most certainlylooking like it, right?
Because combined came out andwe were just like, oh, there's
just a couple pieces missingfor it to be as powerful as rx.
They're almost there, sosurely 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 qualityof life improvements.

(05:19):
And that's about it.
I think Swift data, what they'redoing, 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 evenseem completely finished yet.
And so it felt like maybe theywere trying to do something much

(05:42):
bigger, and this is the one partthat they could ship this year.
And then next year in June we'regonna maybe see something huge.
So I think it might not be likecombined because it really feels
like they set themselves up to dosomething much bigger with swift data.
But we'll have to see at dubbed up.
I think if at this dub up they don't domuch or they do something similar, then

(06:04):
maybe it is gonna be more like combined.

Yeah.
Yeah.
I mean, that's a great point.
I think if they don't do it.
This year.
Last year was, so we'lltalk about AI later.
It was so emphasis on ai.
There wasn't much of anything thisyear, but like yeah, if they don't
do anything with swifty y then orSwift data, then yeah, I could see

(06:27):
how, what the heck is going on guys.
So yeah the issues I've run intowith swift data, I so I've done
a lot of swift data with bushel.
Hopefully by the time this episodeis out, bushel two will be out.
And I open sourced a lot ofthe like, agnostic code into a
library called Data Thespian.
Thank you very much.

(06:47):
'cause it has to do withactors and data, so, yeah.
Thank you.
So, yeah, the issues I ran intowere like the whole temporary Id.
Like if you start doing stuffwith things that are temporary
and not yet saved, it crashes.
And then dealing with contactsand switch ui, like the

(07:07):
auto save is not that great.
Like I moved over to autosaved and I was just surprised
at how little it saves.
So there's a lot of pointsin bushel where I just end
up having to save manually.
And then, yeah, I ended up doing alot of stuff with using that core
data notification to let thingsknow that things have been updated.

(07:28):
'cause yeah, as far as like SwiftUI is concerned, you're pretty
much like you end up havingto do a lot of manual stuff.
Like queries are great, but likeit's very incomplete with what you
actually need for SWIFT UI and SWIFT

Yeah, it is great.
You mentioned context.
'cause I think probably my biggestthing that I'm missing is child context.
Like I use them allthe time, make a child.
Managed object context.
I'll load an object into it, pass itto 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, Isave it into the main context.

(08:04):
That just doesn't exist in SWIFT data.
So, so you're stuck copying everyproperty from an object into a
state VAR so that you can thenmanipulate the state var when you
save it, you copy everything back.
It's way more

Yeah.

Yeah

anything else you wanna talk about?
Swift data.
So you think, would you write abook, I guess, are you thinking
I'll write a book if stepped up?
Says a lot of stuff, but otherwise

probably.
Yeah.
Yeah.
It's because it's, I have theCoordin a book and I feel like
that's still the much better option.
So it would feel weird towrite a book about the other
technology where basically.
Almost every chapter is going to endwith, but if you want everything,
you should check out core data.
I don't want that, so I'm not sure yet.

(08:50):
It really depends on what happensat dub whether I would feel that's
a feasible book to be working

Would you even like write a chapter maybe for
swift data in your core data book?

I've considered that core data is up for an update.
So it's something that'sstill in the back of my mind.
Like maybe I shouldjust, write about that.
But then it would mostly beabout like interoperability.
Like when you hit something that'snot there in swift data or where it
doesn't work how do you build a bridgebetween the two because you, you can
do it whether it's pretty or not.

(09:22):
I'll leave that up tothe eyes of the beholder,

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, butdefinitely check his stuff out.
So the other thing you mentioned wasSWIFT testing and we had a really
great episode on SWIFT testingwith Daniel a few episodes ago.
And what was your favorite thingabout SWIFT testing over XC testing?

that's, I think just the overall the overall syntax of it.
Right.
When I look at it, the fact that I couldjust write at test funk and then write
anything basically, like in any filein 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.

(10:12):
I've been thinking about this theother day actually, like, like
why am I so much more eager towrite 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.

Do you think, so we just talked about
SWIFT data, SWIFT testing.
Is there anything missing from XEtesting that you are like really
desperate for outside of UI testing,which is a whole other thing.

Yeah.
Yeah.
So, so UI testing, I don'tdo much of that anyway, so,
so that I'm okay with that.
I do feel like Apple dropped theball on giving us a good way to
test our completion handler base

Okay.

Test methods in SWIFT testing our async, and they work
really well with your async weight code.
But then if you want to testsomething that you use as a completion
handler, apple recommends that weuse something called a confirmation
which gives us a closure, and we cancall that confirmation any amount
of times that we specify we should.

(11:13):
So if we have.
Something that does a piece ofwork in 10 steps, we can say this
confirmation's gonna be called 10 times.
The issue is that you call that functionand 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

(11:33):
all of your confirmations.
So in practice that means if youcall an old school completion handler
based API then your confirmationclosure is returning before your
completion handler got called.
So you need to have somethingto await inside of that thing.
And it's like, so I alreadyhave this asy weight code.

(11:54):
Why am I using thisconfirmation thing then?
Like it has its uses, but what I wantto do is just test my old code with it.
And I can only do thatwhen I use a continuation.
So there is a tool for that.
It's a spoken currency tool.
But it really feels like swift testingshould have had something for that
similar to test expectations and XC

Right, right, right.
Do you like, one of the missing piecesthat I saw was like a lack of one of
the problems with SWIFT is you can'tgo in and like swizzle stuff, right?
It's specifically a static type languageand we have macros, but then like.
I was expecting maybe like a macroto be able to create mocks easily and

(12:38):
things like that, stubs and so on.
And that, that I feel like issomething I'd really want is like
just a easy way to like, okay, it'sa protocol, just implement everything
and then here's a few implementations.
And the macro would just handleit for me and then that way I
can easily test that kind ofstuff, you know what I mean?

Exactly.
Yeah.
Yeah.
I know what you mean.

Yeah.
That would be, I would love tohave that and yeah, someone could
write that, but we all know macrosare a pain in the butt, so, yeah.

sure.
Yeah.
It would've been cool.

have you ridden any macros or anything?

I have not, no, I looked very briefly at how to do it.
But I I've never reallyfelt the need to write one.
Yeah, I'm trying to think of like placeswhere I could have maybe used a macro,
but there's so few and far in betweenwhere it's like all the hassle of
making a macro probably wasn't worth it.

(13:36):
And I'm also always a littlebit cautious with those things
'cause I don't want to endup going overboard with it.
Like once, once you start using them,maybe you go overboard and you almost
end up with this version of Swiftthat's only recognizable to you.
I know that's

No.
Totally.

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 basicallyhave a completely new dialect
of C just because of the macros.
Yeah, I think that's like pullingit, like, stretching it really far.
But yeah I think the macrosthat we get from Apple are good.
I don't feel too inclinedto be writing my own

Yeah, 100%.
I wrote one for option sets.
Recently and I waslike, yeah, that's good.
And then I tried somethingelse that was more difficult.
I'm like, yeah, I'm not pulling upa syntax tree or anything like that.
Like not something I'minterested in deep diving into.
'cause it's like a rabbit hole, right.
Once you do it, it's like you.

Yeah.
Just like a whole bunch of thingsthat you have to know and understand
before you can properly make your own.

Right, right.
Okay, well you mentioned concurrency.
So let's talk about concurrency.
Yeah.
So what do you think is the mostchallenging part about concurrency?

Oh.
I think for me the hardest part iswhen you have an existing project and
you're trying to understand all thebits and pieces, so you're basically
learning this on top of your existingskill set, and you're taking in
every proposal, every piece by piece.
There's so much changing.
And the proposals aren't always writtenin the most easy to follow language.

(15:10):
Like it's very academic, verycompiler engineer oriented, not
necessarily end user oriented.
And as a result, I feel like youstart tripping up over details and
over complexities that somebodythat's coming into it fresh.
Maybe even in a new project, likewon't be bothered by too much.

(15:30):
I think that's the hardest partis taking your existing code,
your existing knowledge, andthen putting concurrency into it.
I think that sort of creates thismix of overlaps and differences
that's really hard to follow for

Right, right.
Yeah.
And it's not as intuitive for a lotof swift developers, especially when
you get into actors and like, okay,main actor, where does that go?
Well, a lot of us have preknowledge already, right?
Of dispatch groups andDIS and GCD, right?

(16:07):
So we come into it with thispreset of knowledge, and then we
try applying those same rules toconcurrency, and it's just not,
it doesn't match up quite right.
You know what I mean?

For sure.
Yeah.

What do you think is the biggest revelation you've had when
you've, written blog posts or booksabout the new stuff with concurrency?

. Donny Wals (guest) (16:27):
I, I think it, it happened a while back where, and
it's also the part that Apple isprobably going to change, but that
it's super easy to have work that'snot on the main thread right now.
If you write a function, make itasync, you make sure it's not like
somehow isolated to an actor orto the main actor specifically.

(16:47):
That's always going torun in the background.
I think and Swift 5.5, orwhenever they first introduced
concurrency, that wasn't always the

Okay.

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 mainthread and that completely eliminates
the need to have detached tasks.
Right?
So that on top of the fact thatan await from the main actor

(17:18):
doesn't block the main actor.
I think those two things for mewhen I first started learning were
very eye-opening and very importantdetails of how concurrency works.

What's the ramifications for that?
As far as like having everythingrun on the global thread or
the global actor, I should say,

A global executor

global

Yeah.
Yeah.
So that's basically like thethread pool that contains
everything except for Maine.
So the biggest ramification isprobably 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 withan async function and you have your main

(17:58):
actor annotated swift UI view, which allviews since I was 18, are by default.
What happens is you're nowcalling from the main actor to
a non-isolated async context.
So you're immediately going to thebackground and that will have you run
into issues where the compiler's goingto tell you in so six mode that you're
bridging your view model instance,which is tied to the main actor

(18:20):
into a non-isolated async function.
So problems start to happenimmediately where you're just
like, okay, what do I do here?
And then what happens is a lotof people just start slapping
main actor on everything.
'cause that gets the warning to go away.
And then in theory you couldargue that's fine, right?

(18:40):
Because you are normallyinteracting from the main
thread with that view model.
So calling functions on that viewmodel would have the functions
run on main anyway, right?
In most code bases, I would say you gofrom 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 sessionstarts to make the call that

(19:00):
you leave your main thread.
I think very few people explicitlyleave the main thread in their
view model or their data layer.
But now you're applying the main actorannotation to all these things and
you feel like, oh no, I'm definitelyblocking the main thread right now.
So that becomes scary.
And yeah, so, so that, that is aproblem both in adoption and fixing it.

(19:23):
'cause a lot of people are nowdealing with sendable issues.
Where they technically don't evenneed something to be sendible.
'cause they just wanna send it from themain actor all the way to the network.
And that's it.
They don't even want to usecertain models in the background.

So all my view models are basically main actor and
then, like, what I ended up doingis either a, making an actor so that
way it like runs on its own space.
Because you'll have stuff where youcan read a brain at the same time.
That's essentially the issue.
Right.
The other thing that's really thrownme a curve ball is the stuff with

(19:58):
like, so they added a bunch of prefixesto 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 issueslately is ambiguity about that.

(20:19):
Even when you mark somethingas sendable, it's, you have to
still be careful about that.
I found, you know whatI'm talking about.

I think I do.
Yeah.
There's just a lot ofrough issues around that.
And they're trying to solve someof this with more keywords like
descending keyword right, where theybasically allowing you to say, okay,
so, if I pass a non sendable thinginto this function, that's fine.
But after it's been passedto this function, the caller

(20:49):
can't use that object again.
Right?
That's how you can pass stuff from oneisolation boundary to the next and tell
the compiler I know what I'm doing.
I intend to do this.
Just warn me if I'musing this object again.
After sending it to some other place,

Do you think

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 lotof errors for a lot of people.
Like when you, like taskcurrently has a sending closure
instead of a sendable closure.
And that makes it so that you cansafely use certain nons sendable
things inside of your task as longas you don't also use them in other

(21:30):
tasks or after you've made your

Right, right,

So I think for a lot of people that solves an issue.
I think the underlying problem thata lot of people still run into is the
fact that non-isolated async functionsdon't inherit the caller's isolation.
Which means if you have yourmain actor view, your non main
actor view model, you're leavingthe main actor immediately.

I.

And that's a problem that Apple wants to
solve now that they've beenpublishing some proposals and.
Manifests around this in the pastfew weeks where they basically
say, okay, maybe we shouldchange how that model works.
And yeah, almost revert, notentirely, but almost revert
that thing that changed round.
So 5.6 or right after five five orwhatever it was where non-isolated

(22:14):
async functions will inherit theisolation context of their collar,
which means, right, if you have yourmain actor annotated view, your non
main actor annotated view model, thatan async function on your view model
will still run on main, if it wascalled from main, basically getting you
back into your old GCD like behavior.

Do you think, I mean, do you like that?
Do you think that there'sperformance issues with doing that?

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 aboutis we've had three and a half
years now with the current model.
And before Apple's going tointroduce this change, we'll
probably have had four or so years.
I doubt they'll do it just randomly.

(23:00):
So I think maybe dubbed up is a goodmoment where we have a beta period.
But yeah, we'll have had a whole bunchof times with the current model and
a lot of people aren't explicitlyaware 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 thischange and people are probably
not even going to really notice.
But for those that do know thebehavior and do have like their

(23:23):
expectations around it, it'sgoing to be really important
that Apple has a good migrationpath which I'm sure they can do.
'cause they can detectnon-isolated async.
So if there's like someannotation that we have to
add, they could automate that.
The part that's most worrying to meis that we have a backlog of, by then,
probably four or more years of content.
That's out there online telling peoplehow this thing works, but then they've

(23:46):
changed it in some swift version.
And so a lot of people are going tohave to go back to update their blog
posts, rerecord YouTube videos, addannotations here and there to make
sure that people don't come to expect

Teach their AI model the correct way to do it.

yeah.
So AI for Swiss isalready a big mess, right?
'cause every dot release changes things.

Yeah

but this is definitely going to hurt,
people's ability to Google or useLLMs to learn about concurrency.

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.

I think long.
I think long term it'sprobably the right thing to do.
I think short term it's a little sadthat we've had four years with this
model and only now apple's deciding thatthis is not the way they want it to go.

how so if they go with the old way, can there,
can you mark a method as itshould not run in the main actor?

So if they revert, it's not, it is
not technically reverting.
But if they revert the current model,

yeah.

Yeah.
So, so what they're wanting to do isintroduce either another keyword, an
annotation, or something like thatwhere you can say like, um, it's, it is
going to turn into something like an.
A, a detached funk, my name AsyncThrows or whatever, or non-isolated
funk or something like that, wherewe have to get explicit in terms of

(25:15):
what we want, as in, we don't wantthis to inherit isolation context.
I think if Apple, that it'll befine long term, but it's definitely
going to make our functions messier.

Right.
Let's see, what else.
So let's talk about it.
Do you think combine is dead?

Oh, okay.
That's an interesting one.
I don't, I really don't, and Ithink probably me and like 20 other
people in the world to this daywill say, I don't think it's dead.
I've tried to not use combiningprojects and the problems really arise.
When you try and observe states, ifyou have an observable object with

(25:59):
published properties and you want toobserve 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 featureset of what publishers can do,
you have to use swift algorithms.
And even then you don't get thefull feature set because you can't
have two iterators on the sameasync stream at the exact same time.

(26:23):
So there's still like acouple things missing there
for state observation, right?
So I wanna be very specificon that state observation.
For everything else, I think combinedwas always not the best tool, right?
So if you had your networking layerthat would give you a publisher, and
a publisher would give you the resultof a network call that worked, right?
It was a fine model and it fit thisfunctional, reactive way of thinking

(26:46):
that some people really subscribe to.
But I think for like most folks, thatnever was the most elegant way to do
networking or to do async processes.
So for the parts where I useasync or combine as an async
programming library for those partsof it combine's definitely dead.
But it should have never beenfully alive to begin with, I think.

Do you when you say state observation though, you're
assuming it's an observ object.
What if it's just using observable?

Right?
So, so that observing properties thatare observable is a pain either way.
Like, I don't like the syntaxwe have for doing it right now.
I actually dug into why itis the way it is, right?
'cause you have to write that withobservation track enclosure, access to
properties that you're interested in.
And then whenever you get anupdate, you have to resubscribe
or something like that.

(27:37):
It's almost like the very oldweb socket APIs that Apple had.
And the whole reason it is like thatis Apple made this, and they actually
had somebody say this on the forums.
They made this so that SwiftUI could have it, and then
they stopped working on it.
And that's two years ago.
And they did express interest, orat least the person that worked in
the proposals expressed interest inmaking it more general purpose, but

(28:00):
they just never got around to it.
I don't think Apple has a ton ofinterest in making observable convenient
outside of Swift UI at this point.

So like

usable.
You can do it,

What I've ended up doing, so everything in.
Bushel is observable and I just end upusing will set to monitor changes and
make changes within the object itself.

yeah.
So that's within the object, right?
But what if you have anotherobject that wants to observe a
property from your observable?

Yeah.
How do I do that?
That's a good question.
Yeah.
I mean there's always a waypassing in a method or Yeah.

Sure.
Yeah.

what I've ended up

but it is, it's, yeah, it is just not
as convenient as published.

percent.
Yeah.
So where I've ended up using Combinea lot is with the built-in publishers
that exist like we had talkedabout previously with swift data.
Like, I have, I'm using combinedto observe notifications
about changes to the data.
Right.
That, that works out really well.
Or if you do anything well that'sNotification Center, right?

(29:04):
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 Iend up using Combine mostly.

And I think it's still the right
tool for the job in those

Right,

I've tried like going all in on async
sequences, like async for loops.
It's just too easy tocreate memory leaks.
If you make your own async streams, youcan't have more than one for loop on it.
You don't often need it, butwhen you do, it's nice that it's
possible to have like multicasting.
So, yeah I don't thinkcombine's dead yet.
I think Combine is just sitting therehaving its one or two purposes in

(29:50):
the world, and that's where it sits.

Do you think there's a place for any of the
functional programming stuff andor do you feel like async sequence
or async algorithms fills thatvoid if you want to go that route?
Or like,

I think for the most part it does.
I think it's not fully there yet.
I couldn't give you greatexamples from the top of my head
other than Multicasting, but Ithink it's not fully there yet.
But at least the nice thing withSWIFT algorithms is it's open source.
It is Apple managed, but the nice thingwith these packages is that they can

(30:27):
be updated without needing a swiftupdate, without needing an iOS update.
So anything that's in these packagesis essentially by definition something
that you can just pull in right nowand use on any project and you'll have
backwards compatibility for years?

Well, Donnie, it was really good to talk to you.
We'll talk more about some of the otherstuff like the Vision Pro and AI and all
that in the next half of the episode.
Before we close out, wherecan people find you online?

Yeah.
Well first of all, thanks forhaving 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 youreally wanna have a conversation with
me or hang out or just be where I'mmost active, come find me at Blue Sky.
'cause that's where currentlyI think everybody is at.
And so I just follow the flock.

Awesome.
People can find me onTwitter 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 thison a podcast, please gimme a review.
And if you're watching this onYouTube, please like and subscribe.
It's good to see everybody.
Talk to you later.
Bye.

So, yeah.

All Episodes

Practical Year - Part 1 with Donny Wals

Episode Transcript

Popular Podcasts

On Purpose with Jay Shetty

Crime Junkie

Ridiculous History

.css-15opob5{left:0;position:absolute;top:0.8rem;} All Episodes

.css-14f5ked{margin:0;word-break:break-word;display:-webkit-box;-webkit-box-orient:vertical;box-orient:vertical;-webkit-line-clamp:2;overflow:hidden;}Practical Year - Part 1 with Donny Wals