Empower Apps

Donny comes on yet again to give his thoughts on 2024 - Swift Data, Swift Testing and Swift Macros while we mourn the death of Combine.

Guest

Announcements

Links

Related Episodes

Social Media

Email
leo@brightdigit.com
GitHub - @brightdigit

Twitter
BrightDigit - @brightdigit
Leo - @leogdion

LinkedIn
BrightDigit
Leo
Patreon - brightdigit

Credits

Music from https://filmmusic.io
"Blippy Trance" by Kevin MacLeod (https://incompetech.com)
License: CC BY (http://creativecommons.org/licenses/by/4.0/)

  • (00:00) - Bushel 2.0
  • (00:37) - Swift Data
  • (09:37) - Swift Testing and Macros
  • (14:37) - Swift Concurrency
  • (25:33) - Combine ā˜ ļø
Thanks to our monthly supporters
  • Holly Borla
  • Bertram Eber
  • Edward Sanchez
  • Satoshi Mitsumori
  • Steven Lipton
ā˜… Support this podcast on Patreon ā˜…

Creators & Guests

Host
Leo Dion
Swift developer for Apple devices and more; Founder of BrightDigit; husband and father of 6 adorable kids
Guest
Donny Wals šŸ‘¾
iOS Engineer, blogger, and author at https://t.co/GXOvs3nr0S. Loves learning and sharing knowledge. ā¤ Dorien -- #swift #ios #swiftlang #iosdev (he/him)

What is Empower Apps?

An exploration of Apple business news and technology. We talk about how businesses can use new technology to empower their business and employees, from Leo Dion, founder of BrightDigit.

[00:00:00] Bushel 2.0
---

[00:00:00] 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.

[00:00:24] Leo Dion (host): 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.

[00:00:37] Swift Data
---

[00:00:37] Leo Dion (host): 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

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

[00:00:54] 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.

[00:01:02] 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.

[00:01:29] Donny Wals (guest): 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.

[00:01:38] 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?

[00:01:51] 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.

[00:02:10] Donny Wals (guest): 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.

[00:02:31] Donny Wals (guest): 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

[00:02:53] Leo Dion (host): Right, right.

[00:02:55] Donny Wals (guest): But, so those are also the two that I would be thinking about testing and swift data.

[00:02:59] Leo Dion (host): let's first start with swift data. What's missing?

[00:03:03] 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.

[00:03:34] Donny Wals (guest): 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

[00:03:50] Leo Dion (host): Yeah.

[00:03:51] Donny Wals (guest): So those kinds of things, there are still a lot of rough etches like that.

[00:03:55] Donny Wals (guest): 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.

[00:04:36] Donny Wals (guest): I don't know.

[00:04:37] 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?

[00:04:58] 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.

[00:05:15] Donny Wals (guest): 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.

[00:05:34] Donny Wals (guest): 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.

[00:05:58] Donny Wals (guest): 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.

[00:06:06] 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.

[00:06:29] Leo Dion (host): 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.

[00:06:50] Leo Dion (host): 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.

[00:07:15] Leo Dion (host): 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.

[00:07:35] Leo Dion (host): Like queries are great, but like it's very incomplete with what you actually need for SWIFT UI and SWIFT

[00:07:41] 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.

[00:08:00] Donny Wals (guest): 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

[00:08:16] Leo Dion (host): Yeah.

[00:08:17] Donny Wals (guest): Yeah

[00:08:17] 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

[00:08:28] Donny Wals (guest): probably. Yeah. 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.

[00:08:48] Donny Wals (guest): 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

[00:08:54] Leo Dion (host): Would you even like write a chapter maybe for swift data in your core data book?

[00:09:00] 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.

[00:09:22] Donny Wals (guest): I'll leave that up to the eyes of the beholder,

[00:09:25] 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.

[00:09:37] Swift Testing and Macros
---

[00:09:37] Leo Dion (host): 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.

[00:09:44] Leo Dion (host): And what was your favorite thing about SWIFT testing over XC testing?

[00:09:50] 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.

[00:10:12] Donny Wals (guest): 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.

[00:10:23] 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.

[00:10:39] 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

[00:10:52] Leo Dion (host): Okay.

[00:10:53] Donny Wals (guest): Test methods in SWIFT testing our async, and they work really well with your async weight code.

[00:10:59] Donny Wals (guest): 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.

[00:11:20] Donny Wals (guest): 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.

[00:11:45] Donny Wals (guest): 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.

[00:12:08] Donny Wals (guest): 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

[00:12:16] 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?

[00:12:28] Leo Dion (host): 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.

[00:12:40] Leo Dion (host): 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?

[00:12:58] Donny Wals (guest): Exactly. Yeah. Yeah. I know what you mean.

[00:13:00] 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.

[00:13:10] Donny Wals (guest): sure. Yeah. It would've been cool.

[00:13:12] Leo Dion (host): have you ridden any macros or anything?

[00:13:15] 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.

[00:13:36] Donny Wals (guest): 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

[00:13:48] Leo Dion (host): No. Totally.

[00:13:49] Donny Wals (guest): stretch of like.

[00:13:50] Donny Wals (guest): 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.

[00:14:08] Donny Wals (guest): I don't feel too inclined to be writing my own

[00:14:11] 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.

[00:14:27] Leo Dion (host): Once you do it, it's like you.

[00:14:30] 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.

[00:14:35] Leo Dion (host): Right, right.

[00:14:37] Swift Concurrency
---

[00:14:37] Leo Dion (host): Okay, well you mentioned concurrency. So let's talk about concurrency. Yeah. So what do you think is the most challenging part about concurrency?

[00:14:47] 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.

[00:15:10] Donny Wals (guest): 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.

[00:15:38] Donny Wals (guest): I think that sort of creates this mix of overlaps and differences that's really hard to follow for

[00:15:44] 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.

[00:16:17] Leo Dion (host): You know what I mean?

[00:16:18] Donny Wals (guest): For sure. Yeah.

[00:16:20] 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?

[00:16:27] 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.

[00:16:47] Donny Wals (guest): 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

[00:16:56] Leo Dion (host): Okay.

[00:16:57] 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.

[00:17:28] 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,

[00:17:37] Donny Wals (guest): A global executor

[00:17:38] Leo Dion (host): global

[00:17:38] 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.

[00:18:03] Donny Wals (guest): 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.

[00:18:22] Donny Wals (guest): 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.

[00:18:45] Donny Wals (guest): 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.

[00:19:02] Donny Wals (guest): 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.

[00:19:23] Donny Wals (guest): '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.

[00:19:36] 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.

[00:20:14] Leo Dion (host): 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.

[00:20:27] 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.

[00:20:51] Donny Wals (guest): 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,

[00:21:06] Leo Dion (host): Do you think

[00:21:07] Donny Wals (guest): is a whole other rabbit Hal to do I think I, I think what they did with it is really useful.

[00:21:14] Donny Wals (guest): 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

[00:21:32] Leo Dion (host): Right, right,

[00:21:33] 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.

[00:21:51] Leo Dion (host): I.

[00:21:52] 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.

[00:22:10] Donny Wals (guest): 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.

[00:22:33] Leo Dion (host): Do you think, I mean, do you like that? Do you think that there's performance issues with doing that?

[00:22:39] 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.

[00:23:00] Donny Wals (guest): 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.

[00:23:14] Donny Wals (guest): 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.

[00:23:31] Donny Wals (guest): 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.

[00:23:48] Donny Wals (guest): 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

[00:23:58] Leo Dion (host): Teach their AI model the correct way to do it.

[00:24:01] Donny Wals (guest): yeah. So AI for Swiss is already a big mess, right? 'cause every dot release changes things.

[00:24:06] Leo Dion (host): Yeah

[00:24:07] Donny Wals (guest): but this is definitely going to hurt, people's ability to Google or use LLMs to learn about concurrency.

[00:24:14] 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.

[00:24:25] 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.

[00:24:37] 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?

[00:24:45] Donny Wals (guest): So if they revert, it's not, it is not technically reverting. But if they revert the current model,

[00:24:50] Leo Dion (host): yeah.

[00:24:50] 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.

[00:25:28] Leo Dion (host): Right. Let's see, what else. So let's talk about it.

[00:25:33] Combine ā˜ ļø
---

[00:25:33] Leo Dion (host): Do you think combine is dead?

[00:25:36] 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.

[00:26:09] Donny Wals (guest): 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?

[00:26:27] Donny Wals (guest): 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.

[00:26:49] Donny Wals (guest): 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.

[00:27:08] 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?

[00:27:17] 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.

[00:27:34] Donny Wals (guest): 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.

[00:27:51] Donny Wals (guest): 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.

[00:28:08] Leo Dion (host): So like

[00:28:08] Donny Wals (guest): usable. You can do it,

[00:28:10] 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.

[00:28:22] 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?

[00:28:28] 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.

[00:28:35] Donny Wals (guest): Sure. Yeah.

[00:28:36] Leo Dion (host): what I've ended up

[00:28:36] Donny Wals (guest): but it is, it's, yeah, it is just not as convenient as published.

[00:28:41] 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.

[00:28:52] Leo Dion (host): 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.

[00:29:18] Leo Dion (host): The timer? Yep. Those are the ones where I end up using Combine mostly.

[00:29:23] Donny Wals (guest): And I think it's still the right tool for the job in those

[00:29:26] Leo Dion (host): Right,

[00:29:26] 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.

[00:29:44] Donny Wals (guest): 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.

[00:29:53] 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,

[00:30:05] 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.

[00:30:31] Donny Wals (guest): 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?

[00:30:44] 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?

[00:30:56] 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.

[00:31:12] Donny Wals (guest): 'cause that's where currently I think everybody is at. And so I just follow the flock.

[00:31:17] 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.

[00:31:37] Leo Dion (host): Bye.

[00:31:38] Donny Wals (guest): So, yeah.