Jon (00:05.326)
Welcome back to another Gone Mobile. Well, we got through episode 100 and this is 101. And 101 is a great number for describing classes and stuff, right? Like the entry level course or something like that. It's...

Allan Ritchie (00:15.924)
class.

Allan Ritchie (00:19.604)
Oh, I thought we could go all downhill from here.

Jon (00:22.414)
Well, that too. I mean, maybe it's a, it's a restart, right? We can, it's like gone mobile one -on -one, your, your basic intro. Everything's new again.

Allan Ritchie (00:32.052)
Hmm. Yeah, I'm gonna stick with my original assessment. Let's go downhill from here.

Jon (00:37.646)
Let's go downhill or at least down a rabbit hole. Is that what we're doing today?

Allan Ritchie (00:40.948)
Sure, that's a bad lead in, that's a dad joke, but let's go with it.

Jon (00:46.03)
So yeah, what are we talking about? We talked about bindings on a previous episode, I think, right?

Allan Ritchie (00:51.252)
Yeah, today we're going to talk about slim bindings because the community is squawking up a storm about it. Let's talk about it. I think a lot of people don't understand what it means. But I think if we look at the definition of slim,

Jon (00:58.222)
Yes, it is pertinent. Yeah, so...

Yeah thin slim, whatever narrow little Small folk. Yeah, I like oh that would have been a bad. We should have called them focused bindings Hmm

Allan Ritchie (01:07.508)
It means little, little focused.

Allan Ritchie (01:15.828)
Focused bindings. Who's in charge of your marketing? Is this a David thing?

Jon (01:22.606)
I don't, I mean it's not too, I just used the term slim at some point because I had to describe it. I didn't think, naming is hard, right? I mean.

Allan Ritchie (01:26.246)
Oh, you've dubbed it.

Allan Ritchie (01:31.092)
Okay. All right.

Jon (01:33.422)
I didn't call them like, you know, slim bindings, 5 ,000 EXNT or something like that. So we were not as bad as it could be.

Allan Ritchie (01:39.796)
True, true. All right. All right, so stick with slim binding, focus binding. Let's see if it catches on.

Jon (01:45.71)
It might, in that vein, in that train of thought, you know, it might surprise you or it might not to know that I came up with the name for resizatizer as well.

Allan Ritchie (01:57.588)
Oh, I did know that because that was marked as an original RET package.

Jon (02:03.694)
Yeah, yeah, yeah, which is now, oh yeah, fair, that's fair.

Allan Ritchie (02:05.588)
You're just gonna start calling your red thunder though. I think that that's easier. Red thunder from now on.

Jon (02:12.364)
All right, so, so slim bindings. So we talked about bindings, bindings, I think you can go back and listen to that episode if you haven't, we're not gonna go through that all again. And I think we talked a little bit about slim bindings on that episode, or at least mentioned them maybe, did we? All right. We talked a little bit. Right. So if we wanted to recap, slim bindings, how would you describe them?

Allan Ritchie (02:25.204)
I don't remember. I'm old. I forget things now. Probably we did. Probably. Because it's recent enough. It's recent enough we had to have.

Allan Ritchie (02:39.988)
Do you mean how would I describe fat bindings or slim bindings? Slim bindings and focus bindings. Basically picking out the stuff that you want. I think really the troubles with the full bindings is requires, you know, a good chunk, basically all the package, right? You can't really just focus on the one method signature because then you have to deal with all the types of it, which means you have to dig in, see all the types, all the members that you need out of that.

Jon (02:42.702)
No, it's like focused bindings. Yeah.

Allan Ritchie (03:09.812)
Is it async? Is it generics? All that fun stuff, right? Depending on which side of the spectrum we're talking in terms of slim bindings, but it requires a lot of knowledge about the actual package you're consuming. And if you're not working in Xcode or kind of a maveny Java world, it's really hard to see that, right? So, I mean, slim bindings aren't going to get rid of that, but it's going to force you to go into kind of that world, right?

and really understand what you're about to consume. So for instance, if we talk about something like Firebase, that one I love to bring up because that's fresh, right?

Jon (03:46.67)
Yeah, well, and that's an area of focus. So to give a little backstory to, um, Alan and I have done a little bit of work more recently together on, on creating some pat, you know, examples or the short of it is they're not, I can't link them to you today. Uh, to not to you, Alan, you obviously have the link to them cause you've written some of them, but, uh, you know, we've got this, I, this concept that we're, we're working through. We want to make sure that we, we do it.

that we're happy with it, that it's working well, that we think it's scalable, sustainable, et cetera. It's looking really good and soon we'll push some stuff over the fence, I think. And the idea being, there's a bunch of these bindings that haven't been updated in a while. Like we used to do updates for bindings for Firebase stuff. The problem is there's a lot of work and for the reasons that you described, it's something that takes a lot of time. And we're in this weird spot where there's...

some customers that these things are very important to, but it's definitely not the whole breadth of customers that actually use them. So it's a smaller group, but it's pretty critical to that smaller group. So we want to move everyone forward and get them upgraded happily and everything. But we kind of want to take a different approach to how to do that. And part of it is kind of helping people help themselves. So we're not sure yet if...

If it's going to be like, here's NuGet packages and stuff, because that has its own set of challenges and things that you had to do. Or if it's just going to be like, here's a good structured example of how to do Firebase. And maybe it has the slim bindings for the things that you need, and you're good to go. Or maybe you need some more, and you can pull it down and extend that yourself. So.

Allan Ritchie (05:34.836)
Well, so talking about messaging, messaging is one of those good ones because there's not really a lot. Like a lot of people are really, really kind of uppity about needing Firebase messaging for iOS. And there's quite a, there's quite a few types. Like there's delegates, like Firebase injects their own stuff because they're trying to make it more or less the same as the, the Android equivalent, but it's really just a small subset of methods that you need. Right.

So why expose this big package and all these dependencies and stuff and, and try and consume it. Because the other thing is, is John and I went through this, it's like, what's the cool package manager with Xcode right now? Is it Carthage? Is it, is it, um, pods? I, I, yeah, I've been using CocoaPods forever and now it's Swift package manager. And I'm like, Oh,

Jon (06:16.782)
Cocoa pods. Is it?

or it's go download the zip file with the frameworks in it from someone, right? Like there's, yeah, there's a bunch of different ways. And that, you know, I know one of the arguments that I hear too is like, well, the hard part of this all isn't, and I've made this argument myself, the hard part isn't necessarily as much the binding part of it. I mean, it is, that is a hard part, but getting the actual packages and knowing how to build those into your project and link.

Allan Ritchie (06:26.236)
exceeding frameworks.

Allan Ritchie (06:43.282)
Yeah.

Allan Ritchie (06:47.86)
late kingdom.

Jon (06:50.35)
and making sure this all kind of works well together is one of the hardest parts of it especially on iOS and on Mac catalyst with Xcode.

Allan Ritchie (06:59.316)
And that was, I mean, as we worked through the, the, the Firebase stuff, I mean, John and I hit a whole bunch of stuff. We had the iOS team going, guys, what are we doing wrong here? Right. And so we went through the X XC frameworks. John had this whole make fix, make files set up. It screwed up my builds and we kept going back and forth about who, okay, this is broken. We're missing this. And eventually when you read the docs, it's like, okay, well,

Right now, the cool way to do it and the way that Google wants to do it is through Swift Package Manager. And as soon as we started switching to that, we understand that the dependencies, you know, we were able to build stuff and lo and behold, we got Firebase Messaging and some analytics stuff working in, in once we understood the path and how we were going to link things, it just stuff started kind of going bang, bang, bang from there, right?

Jon (07:50.094)
Yeah. Now, now I will say I had trouble using, trying to use Swift package manager with some other ones too. So like, I think the story here is unfortunately there's no one size fits all choice. And this is part of why I say like going between the idea of, do we want to try and ship out a bunch of, of these kinds of slim bindings, uh, as packages or, or really is it more the foundation of like, okay.

we know the bet we've, we found a good pattern to use for Firebase for instance. And so we're going to give you, you know, the code and the structure and the Xcode project set up and all the, and we'll talk about what that means exactly in a bit too. And all of the things kind of in place that are in a good state where you generally just build them and as it kind of work so that you can have that as a starting point, right? So you don't have to figure out the hard stuff. Like do I use Swift package manager? How do I link these things in? What do I,

need to set up in my project like that, the idea would be that's in place for you. Now, if you've got some random, you know, library that you want to use, like obviously we're not going to do this for everything under the sun. But the goal is to have the popular ones anyway, you know, covered and maybe even get community to kind of contribute back some of that too, right? So maybe there is a something that.

people are using and somebody wants to put an example that's working up in there and we pull that back in for others to look at too.

Allan Ritchie (09:19.22)
be honest if we're talking about slim bindings obviously stuff like Firebase where the calls are very they're pretty straightforward you don't need to you know bring out a whole huge API surface they work really well so for Firebase we can bang those out on the iOS side it's it's actually quite easy now when we talk about controls this is where things get a little bit heftier

I don't think that we've determined yet if slim binding is actually an answer there or not yet. I think John's kind of fighting that battle in a different, different binding right now. Is it, is a slim binding too slim? Is it just, is it a middle man that's now become unnecessary, like an unnecessary abstraction? And do we just need the fact binding for that? The full, the full kitten caboodle, so to speak, to get the whole map, like a map, right? Are you going to do a slim binding on a map control? Probably not.

Jon (09:54.414)
Yeah.

Allan Ritchie (10:14.708)
Probably not.

Jon (10:15.886)
Well, I mean, I don't know. I liked to use Mapbox as one of my examples, kind of the canonical example, because it has a lot of parts that make you think harder about that question, right? So with a map control, well, like one of the things you're gonna have to do is bring that actual map view from that native library back into your app, right?

and display it within say like a Maui page. Like how do you do that? There's a few different steps that you have to make. And this is one of the things that I was starting to work through with. I think it was Google mobile ads was, you know, the one that I was kind of wrestling with, is this better as a binding? Is it better as a slim binding? And I'm, I'm, I will, you know, give you the spoiler of I'm torn honestly at this point, because doing the binding itself, not super easy.

Even like the working with what gets generated like finally got it to a point where it's building and I think it's mostly good But if I have to think through what it's gonna look like to do updates to that It might be fine for a while Like let's say we're at version 11 or whatever and you know 11 .3 Maybe isn't so bad 11 .4. Not so bad not that many changes But if you look back through even that library's history there's been massive changes between some of the major versions at which point you're kind of

back to a square one of you just gotta do it fresh again. And then by the time you make that move and part of what you do, especially on iOS when you're creating binding, like the full bindings is you're kind of tweaking the output that you get from like Objective Sharpie, which kind of gives you the first pass at generating this thing that is describing how to generate the binding, right? Like it's this really niche concept that is hard to learn and...

Even like I had to go back to like Alex Soto, you know, the iOS team lead and like you're saying, I'll be like, what do I, what do I do here? I don't know how to do this. And I used to do this, like this was my job for years. Right. And I forget already. Um, so for something like they are there. And so it's.

Allan Ritchie (12:22.77)
bindings are hard. They can be. Once you understand how to do the mapping though, it's actually quite simple. The fact that you went with objective Sharpie out of the box. So that was an interesting choice. I did not.

Jon (12:33.39)
Well, no, but because the difference here is when you try and bind the full API of something like Google Ads, Google Mobile Ads SDK, there's a lot of weird objectives. Well, I think, is that one still? Yeah, that one's still Objective -C. There's a lot of weird Objective -C things that Sharpie doesn't know how to process very well, because at the end of the day, they're trying to parse C header files, and there's just a lot of inconsistencies there to make that work. It's just the reality.

So if I was doing that manually for one, it would take me forever. Like the API definition for that file is hundreds and hundreds of lines long. Like it's not small. There's probably 50 classes in it or something, right? And then you're having to go, you know, grab selectors. I was like, to do it from scratch manually, no, no, no, no, thank you. That's gonna be not a productive use of my time and very air prone. To use Sharpie, fine as a starting point, but there's so like...

Allan Ritchie (13:08.596)
Right.

Jon (13:30.414)
So many changes that I made to like massage this thing into like what you want it to be to get it to build even because there's just different like delegates and callbacks and then different structs and enums and stuff. And like C functions that you kind of didn't think you needed, but then there's some code examples that are like, oh no, I really do need to do that, but it's printing back a CG rect or something and it actually needed to be an end pointer. And just.

So many of these changes that are not obvious that if I have to go redo or like, yeah, like I said, if I have to start from square one again at some point, it's just a lot of work. And so the difference of thinking about it rather as the slim binding is more the, I'm not gonna expose any of that really weird stuff that doesn't map well to C sharp from a binding in my slim API, my wrapper API.

And if I don't do anything weird, it's going to generally be very easy to bind. And so that's, that's the foundation of the premise, right?

Allan Ritchie (14:35.604)
Right. But see, you're working with a lot of complex types and stuff there, which is kind of what the points I was making where the slim binding is good because you can really take it down to the base types. So again, going back to it, to Firebase messaging on our iOS, really they have some complex objects you can pass and they have a complex delegate. Actually, I don't want to call it complex. It's really like two methods, but really when you break it all down, it's just like, okay, we don't need any of that. We need a couple of strings. There's some async methods here, right?

which you can really, the binding sits on quite nicely. It'll turn that into a C sharp, you know, task does a good job of that out of the box, but kind of really breaking down the calls and doing some of that work in Swift or in Objective -C where you know, you can work with all the types and realizing, you know, I need this kind of information out of it. And maybe I need to send just this small bit of information into it, right? So it, you can really kind of simplify what it is that you're about to bind and therefore,

therefore make everything easier because again, that binding can be difficult. And it just...

Jon (15:40.878)
Yeah, and then when there's big updates between versions, right, you just need to update your layer, like your implementation of that layer. And that's generally going to be a lot easier than trying to redo the binding.

Allan Ritchie (15:47.796)
Exactly.

Allan Ritchie (15:53.492)
Yeah, because now you don't know is the bot okay, where's this thing screwed up because again, a lot of dotnet developers kind of in the Maui don't, I'm going to guess a lot of them don't even open Xcode. It's just maybe, you know, I'm going out, but I'll bet you a lot of them don't code in Xcode. I mean, even Swift, I've never personally used Swift professionally. I want to, it's kind of a nice language. I have done Objective -C, so Objective -C is easy to consume. So obviously you're going to have that scare factor of, oh, I don't know Swift.

But you know, you kind of got to know the layers you're sitting on. So once I figured out Swift and got in there, OK, it's pretty easy. Now I understand what I'm converting, right?

Jon (16:24.172)
Mm -hmm.

Jon (16:34.414)
Well, and truthfully, like for you digging into that, even for the Firebase, for example, like, am I wrong in assuming that you go and look at Apple's or not Apple, Google's documentation and like they show you how to do the things that you want to do in Swift, right? And so it's, it's not, it's not like you have to know Swift, like you, you need to know enough to stumble through some copy and pasting and like massaging things a little bit, right? It's, it's not like it's, you know,

Learning everything about Swift like I don't know Swift, but I can I can do this

Allan Ritchie (17:04.02)
Exactly. Right. And the other big thing is I understood the API that I was about to consume. Right. So yeah, I could follow Google. Okay. This is the package you want us to use now. This is the dependencies. Oh, you want me to use Swift, the Swift package manager. That was, again, that was a big debate we had. And we started using it and that got us through a couple of issues. John's bringing up new info that had caused him some issues, which we'll have to see after he's bringing up new information in our podcast.

Jon (17:11.214)
Yeah.

Jon (17:26.51)
Mm -hmm.

Jon (17:31.118)
Yeah, I mean, not for Firebase per se, but like, yeah, it was a bit of a journey. And so like that's again, full disclosure. That's the hard part of this and why, why I really think there's value in having some of the patterns out there for the popular libraries, because you know, we can have people who know a little bit more about that area, figure out how to get that baseline established. And then from there, it's like, okay, if I don't have to figure out link or flags for how to consume this XC framework, because.

It's an XC framework, but really it's kind of a fake XC framework because it contains normal frameworks in it. And you need to know those linkers, like that's hard, right? But if we figured that out for you, yeah, then you're good.

Allan Ritchie (18:07.828)
Right, and that's what we spent.

We spent a lot of time with little flags. There's, you know, Xcode changes. It seems like we had to add a bunch of different flags for Xcode, for the Xcode build command line. So it was all fun. We got through it. We've got bindings that are working for a few of the Firebase libraries. But again, very, very standard. Those are more, they're not control based except for, I guess, add mobs a little bit, but.

Jon (18:30.83)
Mm -hmm.

Jon (18:38.286)
Yeah, but again, like that one, even if it's control based at the end of the day, again, same with the map. If, if all, if I have my simple API, my wrapper is just like, get the map view and it returns a UI view because the map view and the ad view of the banner view are all ultimately UI views, but we already know what a UI view is in the .net world. Creating that, that binding for that API is really trivial, right? It's a, cause it's, it's where you get into all the different.

Allan Ritchie (18:50.676)
Okay.

Jon (19:06.51)
hierarchy of types and kind of like delegates and completion handler stuff and all these things that that's where it becomes tricky for Sharpie to do the right thing. So, yeah.

Allan Ritchie (19:17.844)
Again, you're hoping the best for Sharpie. I guess I found for Firebase getting Sharpie was kind of in my way. Once you understand the true mapping and how you're doing it, I found that more comforting because Sharpie, I guess it's pick your poison, right? Sharpie will generate the world for you and then everything will be broken or there'll be tons of compiler errors. And then you got to go through and figure it out. Whereas if you, I don't know, the slim binding, I felt more comfortable starting from scratch and working out from there.

Jon (19:38.638)
Yeah.

Jon (19:43.82)
Yeah.

Allan Ritchie (19:47.444)
But, pick your poison.

Jon (19:47.662)
Yeah. And I mean, you, you know enough, I think about the bindings to do that. Like the, the thing that, that I kind of, the way I look at it is could we make it, you know, so that as long as you keep that wrapper, that API, you know, reasonably written, like Sharpies just going to work. Um, and, and it's close to that today. And that might be something that we take back to the team who maintains Sharpie and say, like, you know, for instance, it'll output, um, some like attributes that are like verify.

and they'll help maybe have a message and be like, are you sure you want this to be a property? Maybe you actually did want it to be a method because it's mapping to a selector that doesn't have the concept of like properties and methods really, right? It's a selector. Um, so like there's stuff like that, that like you're saying when you use Sharpie out of the box, it's not going to compile necessarily. So I think the goal would be to get to a point where, you know, that running the thing that generates that API,

definition and C sharp that binding just works every time. And so you could do it as a repeatable thing. That way when somebody comes in and says, I actually also need to use this method. So I'm going to go into the Swift code and I'm going to add myself, you know, one new method that returns a string and takes the integer or something like that. And it, and then calls the actual SDK thing. And it's easy. How do you know for that person? It's like, well, how do I get that into the binding part?

if they don't know how to write the API definition for these bindings, this is gonna be tricky, right? So I think that's part of the goal.

Allan Ritchie (21:20.82)
But really understand the API you're consuming, right? That's the key thing. And that's why I found it easier because you really, when you're doing a binding, you don't really have IntelliSense. There's no IntelliSense. You have to look at the raw code. So when you're working in Xcode or Android Studio, you can really kind of see the code. Like the IntelliSense is obviously going to work there. You're in a native language. And it's all working. And you understand, OK, this is what I got to do. This is what I got to call.

Jon (21:32.526)
Yeah. Mm -hmm.

Allan Ritchie (21:52.244)
Google's able to tell you these are the packages of the dependencies you need. Otherwise, they're not going to compile, right? Like you understand right there whether you've got a working product or not, right? And you can even do native tests to make sure that you still got a working product on that end and then bring it over the fence, do the binding. And the binding is actually fairly simple once you understand the dependencies that you're bringing over. I think the only thing we had is that we had to figure out the challenge of...

Jon (22:01.614)
Yeah.

Jon (22:05.996)
Mm -hmm.

Allan Ritchie (22:19.54)
making sure that there's not a duplicated dependency, right? So when we talk about something like, so the debate we originally had was, let's just, John wanted to ship the huge Firebase everything, Firebase the world, right? And I think that we kind of went back and forth like that, it'll make the binding easy, but then people complain about size and then we have to hope on the linker is going to do jobs and yada, yada, yada. Anyhow, we did end up finding that kind of a middle ground there where,

Jon (22:23.182)
Yeah, so that's a hard part.

Jon (22:42.318)
Mm -hmm.

Allan Ritchie (22:48.82)
It was like, okay, well really analytics is the core now, you know, so messaging will, there'll be a Nougat or a project, whatever we want to call it for analytics. That'll be the core messaging. We'll have a library. It'll reference that core. When it goes over to the bindings, it'll reference that core. Boom. It was working. We got that working. And now we're kind of bleeding that through into stuff like, I think I started to work on remote config. Same thing. Take that dependency. And now we're stopping that, that.

Jon (22:57.582)
Mm -hmm.

Allan Ritchie (23:18.828)
duplication of the resource, which was kind of causing issues for the compiler. It doesn't like seeing the same dependency twice.

Jon (23:24.494)
And it's still like the, the hard part of it too, is at the end of it, it's still going to potentially cause problems if there's other packages out there that ship, you know, those frameworks and stuff in them. Right. And there's not really a clean way to avoid that at this point. I know one of the conversations, this is we've had more for Android. I don't know if this would actually really work for iOS because there's no, like we talked about, there's, um, Coco pods, there's Kurtage, there's.

Swift package manager, you know downloading zips and stuff. There's so many ways to get these things But on the Android side, I know we talked about if we had to go back in time and do it all again maybe instead of Shipping like the AAR and jar files in a new get package or in a binding, you know, we should have actually articulated like what maven package this pertained to so that or even if we did ship them in the binding so that you could at least start to

reconciled during the build, like, oh, this thing brings in, you know, Android X, I don't know what's one of the libraries. Yeah. But, and so like it brings in this thing and even it might embed it. But maybe I only want to take, like, I want to start doing the rules of like this other one brings in a newer version. So we'll use that one instead. And then the build could actually sort itself out in terms of what dependencies to grab. But none of that exists today. And so at the end of the day, yeah, like,

Allan Ritchie (24:28.372)
one, two, three.

Jon (24:51.374)
there's going to be cases where maybe somebody decides, no, I'm going to ship my thing with all this and you want to use their NuGet and then you want to use this one and like, sorry, you kind of can't or maybe you can if you know how to like, you know, do the right MS build stuff in your project to tell it to remove things from item groups that got brought in from a NuGet. But that's not going to be an easy thing to do.

Allan Ritchie (25:14.452)
It's going to require understanding of why they're colliding. If you've been doing this long enough, you knew that this happened with Android. You'd be like, hey, this type is here, but it's also over here. And that would always be, it's damn support packages. I hate those things. You'd always see that. And it usually meant a support package. One of your support packages somewhere down the chain wasn't at the same version.

Jon (25:17.742)
Yeah, yeah, exactly. So, you know, I think...

Jon (25:23.104)
Yeah.

Jon (25:30.542)
Yeah, yeah.

Allan Ritchie (25:41.032)
Android X has supposedly improved that, that's still a debate that I'm willing to have.

Jon (25:44.398)
I mean, even in then I know that over time, like they've moved types between, you know, assemblies or like they're no jars or whatever. And if you have one thing asking for this version and other for that, like you might run into like, Oh, I thought this type was going to be here and it's not. And even in their own ecosystem, it's not perfect. So, um, but I wanted to back up a second, you know, we were talking about like the whole, on iOS, especially, you know, objective Sharpie ideally.

I could make changes to Swift and build everything and like all of that would just happen and to generate the binding, et cetera, for me. That might not be something we easily get to as much with Objective Sharpie, but one of the other cool things that's happening in .NET, and this is all happening out in the open, we'll put a link to it too, is there is work to make Swift interop -a -thing that is possible with .NET.

There's some, you know, early, early, early previews of like some tooling and stuff around it that support a very small subset of ways that you can interrupt with it. But Swift is a lot easier of a thing in a lot of ways to parse the, you know, the, the actual API out of a Swift package or library. And be able to like get that in a kind of.

really concise and consistent format such that you could try to generate a binding from it, right? Again, always the challenge with Objective -C is just that's not an easy problem to solve with that language. And so what they're trying to do is basically make it so they've got a tool to emit that interop code for you. And so I could foresee eventually once that gets mature enough, plugging that into here.

and being able to generate the interop directly into the Swift API wrapper that is the slim binding. So right now, once that code gets out there and you go look at it, we actually annotate all of the types and methods and stuff with that objective C attribute or annotation, right? And that tells Xcode to generate objective C headers that are actually the thing that we bind to. So we're kind of like going around.

Jon (27:58.222)
the long way to interrupt into this Swift code right now, but in the future we might have a more direct line that's more reliably, kind of just works for these simple cases.

Allan Ritchie (28:10.452)
sounds exciting. I took a look at the preview. It's marked as net nine. It's definitely still early stages like the bindings they're doing obviously very simple, you know, straightforward. Here's a Swift, you know, hello world. Here it is strongly typed in the dotnet world. It works. I'll be curious to see how they start to manage dependencies and you know, the Swift. Well, again, it's you still do Xcode, right? So you're still doing Swift and Xcode.

Jon (28:28.782)
Yep. Yeah.

Jon (28:38.414)
Yeah.

Allan Ritchie (28:40.104)
You're still doing the Swift package manager. I don't think you're going to see that. You're not going to see that in Visual Studio anytime soon. It's going to help, or it should help, or at least if anything else, it's going to be bindings to Swift as opposed to this kind of end around that you're talking about. Right?

Jon (28:43.054)
Yeah, they're not handling. No, no.

Jon (28:58.254)
Yeah, exactly. And hopefully as there's more like frameworks out there that are Swift only, like most of them seem to, you know, do the Objective -C header thing because they know people are still using Objective -C like crazy. But obviously we're getting more and more down the Swift path, right? So, you know, there's, there's going to be, and I know there's already some libraries and frameworks out there that are Swift only. And so either then you'd have to hope they're open source so that you can generate the Swift or the Objective -C headers.

you know, do that yourself. Otherwise, like, oh, sorry. So this should give us the avenue to support those as well when they get there.

Allan Ritchie (29:32.756)
Well, this is also a place to help kind of centralize things in a manner of speaking anyways, because now even if you take an objective C library or you're taking a Swift library, you're going to do slim bindings probably in Swift, right? It kind of equalizes the equation. So you can still have objective C, you can still have Swift, right? You can reference them. You can IntelliSense them in Xcode properly. Build your slim binding for what you need it to do.

Jon (29:54.028)
Mm -hmm.

Allan Ritchie (29:58.428)
and ship it over the fence. And now if we start treating everything like Swift, even if we're doing Objective -C kind of cheats in the meantime or wraparounds, or eventually moving off to the Swift binding thing, it'll be kind of the same game, right? It's just, we're dealing with Swift. We're just, at some point it's gonna get better.

Jon (30:21.294)
Yeah, exactly, exactly.

Allan Ritchie (30:23.892)
Now, do we get to talk about Android today? Do we get to talk about Android? Because Android's a bit more of an interesting piece for me, right?

Jon (30:28.366)
Yeah, I mean, so we mostly talk about.

Yeah, I mean, we talk about iOS mostly just because that I want to like, I don't want to say it's harder. It is. So, so there's a couple of reasons. Like, so one of the reasons is for one doing Android bindings in some ways can be easier than iOS. I'm not going to say that as a blanket statement because sometimes that's not the case at all. But in, in, well, in, in turn, no, but in terms of like,

Allan Ritchie (30:39.22)
That's where most of the noise is right now.

Allan Ritchie (30:58.098)
The debate is coming.

Jon (31:03.144)
maintaining bindings for like Google Firebase stuff. I would argue that Android is easier to do that with the way that bindings work today than iOS is. And so we see that more as something that we maintain. And the other part of that is like, Google has really blurred the lines of like what it means.

Allan Ritchie (31:08.244)
Yes.

Jon (31:29.262)
for something to be in the box on Android kind of thing, right? Like there's android .jar, which is like the whole set of default Android platform APIs. But they, over the years, did the support libraries and then now the AndroidX stuff. And so if you actually want to use many things on Android, like you have to use the AndroidX libraries. Arguably, you almost have to use the Google Play services stuff, right? We've talked about stuff like geolocation where...

the way to do it is Google Play services. We don't yet because we didn't want to take that dependency, but like the alternative is like just a way worse experience of getting that information than what Google provides you with Play services. So the argument can kind of be made that for us to support Android, we kind of have to support a lot of that ecosystem around it. Whereas the inverse is not really true on iOS.

Allan Ritchie (32:23.316)
minus the noise around the Firebase messaging, because people are using that. Right.

Jon (32:27.35)
right they're using it but but again like that's not part of ios that's that's another google thing right

Allan Ritchie (32:31.572)
No, exactly. Right. I get it. I get it. Now I will say though, going to the other side. So Android bindings notoriously have been easier in the past, but as we enter this Kotlin era, right. So again, I think this is a bit, some of the documentation is a little bit behind, right. Obviously on the Objective -C Swift, it's, it's, it's a little bit behind, but I think one of the key challenges that, especially that I've had, there's a couple of libraries I'm looking at in the Kotlin area.

for doing bindings right now stuff that they kind of you will give you kind of a good punch in the face or a realization that the Colin stuff is a bit behind is when you get to generics, right? It's just a big old fat Java Java Lang object. You can't really do much with like you can't really get data out of it, right? You really got to do something with it, right? You really got to get you got to throw something over the fence that that you can get because it's not there's nothing else in it.

Jon (33:13.26)
Mm -hmm.

Allan Ritchie (33:28.788)
You can't reflect any values out of it. It's basically dead data. Sure, it returns you something, but you can't cast it because it never bound that object. It's basically a useless object. The other problem is that right now when we look at Kotlin, a lot of things are becoming async just like the .NET world, just like Swift, everything's async. Even though the Kotlin base library is there, I forget what it's called.

Jon (33:50.188)
Mm -hmm.

Allan Ritchie (33:58.58)
I'm having a brain fart. The standard stuff.

Jon (33:59.022)
Yeah, Kotlin standard. Yeah, there's, there's all the, there's a bunch of them too, right? The dependency tree is ugly.

Allan Ritchie (34:05.108)
but there's nothing to actually do and await properly there. So that binding doesn't exist, right? You're probably not gonna wanna take the interface for the Kotlin async kind of handler and do it yourself because I think that's gonna be a rough experience. So again, this is where now we start to enter a slim binding. So what I've started to do, and this is that I've been talking to John about it for a while is the AndroidX Health, right? So obviously the...

Jon (34:32.59)
Mm -hmm.

Allan Ritchie (34:34.484)
the Microsoft team isn't going to take that on because it's marked as alpha. Why something that's being used actively in production from Google is marked as an alpha? Who knows? I don't think.

Jon (34:39.022)
Yeah.

Jon (34:43.469)
Yeah, that's a whole other can of worms that we've dealt with, right? Like it's like, yeah, why? Why? Anyway.

Allan Ritchie (34:48.852)
The brain surgeons in Google, I don't even think, no. Anyhow, they are actively advertising, use this alpha. And they're moving very slowly on it, even though health is very now active in Android 14. But the API, they've written exclusively in Kotlin, right? So I can't consume it properly because of async and because of generics. However, this is again where Swift, the slim bindings, I was gonna call them Swift bindings. That would have been a slip of the tongue, eh?

this is where the slim bindings can kind of help. Right now I'm not gonna, I'm not gonna do, I might do a get average heart rate or get by date, right? So I can throw an easy daytime over the fence, those bind easy, right? And instead of returning a generic list, I'm actually gonna return a, like a list or an array of a bound type, right? So the heart rate object will be fully understood. I'll have to bind it at both ends.

I'll have to define it. Maybe I might even define my own little small object of it, right? Because...

Jon (35:51.406)
I was going to say like, is that maybe the play to create your own class that, you know, is just super basic? No, no subclass, you know, we shenanigans going on.

Allan Ritchie (36:00.628)
Well, and I might because honestly, when you look at some of the health metrics that you can get out of it, right? It's like you can go into hospital level details right down to like, you know, all sorts of metrics. And sometimes when we're talking about like, what's the average heart rate, and I just want to get it from a health API, I don't want to write, I don't hook up to some sort of Bluetooth sensor, I don't want to do any just the metrics in an Apple health or it's in Google health. Right?

Jon (36:09.55)
Yeah.

Allan Ritchie (36:26.74)
just get it from there because they've got all these things and all those values around it. So it's very easy to kind of pull those, you know, just the base types that you want out of it. And again, if we're talking slim bindings, it's always easy to go in. If you've got to add something to it later, set it up, compile it, rebind it on the other end and off you go, right? So basically simplifying what I need out of it, we'll getting rid of the generic problem that I have that's a problem today with Kotlin and kind of the...

I was going to call it Xamarin. What are we calling it now? .NET MAUI. .NET for Android binding. Yeah, just .NET. Just .NET. I don't know the marketing scheme, so I just go with whatever works. Anyhow, it's a problem, right? So now I can just do the simple types in my slim binding, throw them across the fence. I don't want to do that long -term. I'm hoping there's a better Kotlin story in the future. But certainly, if I need something to get by, it is.

Jon (36:59.502)
Yeah, done it. Just dot what? Yeah, yeah, sure. Rolls off the tongue.

Jon (37:21.006)
Yeah, it is work, right?

Allan Ritchie (37:26.42)
It is there's something there's something that definitely will need to be figured out there at some point like doing async with Kotlin just like we can do a swift now kind of.

Jon (37:36.206)
Yeah, the tricky part with that, just to dig in to that a little bit, Kotlin is interesting because it is effectively it compiles down to bytecode, right? So it's no different in a sense like that at the end of it, you have this Java bytecode, even if you're using Kotlin. And so if you think of maybe a comparison would be like how .NET IL looks like.

for like async await stuff, right? There's like the state machine and all that kind of stuff. And if you disassemble, you know, the compiled version of what .NET looks like there, it's kind of hairy. Well, kind of the same thing on Android with Kotlin and the way that it supports those things, right? So the binding story there is hard because what you want is a binding to like a Kotlin -ism.

but we don't bind and interop at the Kotlin level, we interop at the bytecode level. And so that I'm sure there's, you know, smart people on the Android team. I know there are smart people on the Android team and they can probably figure out, you know, a nice way to deal with some of those patterns because obviously like the, the bytecode that it's going to admit for that type of pattern is probably going to be consistent, you know, for that, that example, right? So.

I'm sure there are things that they can do to improve it, but it's, it is kind of a weird, uh, interestingly unique problem because it's not because of how Kotlin effectively just compiles down a byte code. I guess is the point.

Allan Ritchie (39:12.628)
Right. But again, if we go back to the slim bindings, if I need to get around that in the meantime, it's easier to, it's just as easy to throw a callback across the pipe, right? Do the async in the Kotlin code. Then when the async completes, call the callback. Well, I can wrap that in a task completion source and the C sharp and do it myself in the meantime, right? So there's ways to get around it. And the slim bindings do help that. The one thing I will say about slim bindings too for Android is that,

Jon (39:24.142)
Yes.

Jon (39:34.414)
Yep. Yep, yeah, exactly.

Allan Ritchie (39:42.644)
It's kind of a weird situation. So if we take Sharpie out of the picture on Objective -C and kind of the iOS side, iOS is very much like a, like a white listing. You have to basically include what you want, right? Whereas the Android is the opposite. It tries to get everything out of the box and then you have, oh no, ignore that. Ignore that too. Oh, and that entire namespace. Yeah. I don't use any of that crap. Throw it all out. Right? So Android goes looking at the entire thing. You have to blacklist what you don't want.

Jon (39:54.318)
Yeah, they kind of go from opposite directions how they do it. Yeah.

Allan Ritchie (40:12.148)
or exclude what you don't want. It's kind of annoying, right? I guess I it depends on I think that's why I like the iOS portion of it better because I like to start with the minimum and work my way out as opposed to here's a massive list of errors have fun, right? But again, the slim binding is now just looks at that one little portion. So I've I've almost

Jon (40:27.822)
Yeah, I mean, you said to be fair.

Jon (40:34.072)
Yeah. And again, even with Android, you're going to have an easy time, it's just going to work, right? Because you've kept your API simple, that it's going to bind.

Allan Ritchie (40:43.284)
Right. And it just, it's very small. So the same thing comes across because it doesn't look at the dependencies. Thankfully, when you're doing it, it looks at your stuff, right? It doesn't look at your dependencies. So you still have to include the dependency in the box, right? Because your library's got a dependency on it. That's another challenge. It's not hard because you're already including your jar or your ARR or whatever, right? But...

Jon (40:55.086)
Yeah, exactly.

Which is, that's another challenge.

Jon (41:07.47)
Yeah, it's more when you get into libraries that have a really complex dependency graph too. Again, I'll go back to Mapbox as an example. They had a few things, one which was like, first if you wanted to get access to those binaries, they were in their own custom maven feed that required authentication. And so it's like, you can't just go download this set of things somewhere. You have to, so like the way to solve that eventually was basically getting into Android Studio, configuring a project to use,

Allan Ritchie (41:14.108)
Oh yeah.

Jon (41:36.802)
you know, their authenticated feed, having that resolve the dependencies down to like a, you know, one of the intermediary build folders, and then you could go grab them all from there. But part of the challenge there then becomes, okay, something like Mapbox, which is going to have views and things is probably using a bunch of Android X packages. And now you got to go figure out, okay, what ones do I pull over from, you know, Android Studio having pulled over that down that whole dependency chain, uh,

what ones do I leave out because I have a new get on my app that already pulls it in and makes, you know, I have to make sure it's the right version, all that kind of stuff. So it is still a challenge there.

Allan Ritchie (42:13.108)
Yeah, that's fair. That does become a challenge. I guess at some point you have to understand that again, it comes back to understanding what you're about to consume, right? So if I'm about to consume health, this health X, Android X, I forget what it's called. It's a stumbling name. But if I want to take that, I know what dependencies roughly it's pulling in. And if you go check Nougat, right, pretty much the Android team is bound almost everything, at least all the main stuff for Android X.

Jon (42:35.182)
Mm -hmm.

Allan Ritchie (42:43.22)
So it's usually pretty easy to go and find that equivalent dependency without having to pull it in. So when I'm doing my slim binding, I'm understanding, OK, I need my code, obviously. It has to come. I need the thing that I'm slim binding on because it doesn't exist. So I'm bringing that one as well. What dependencies are missing from that huge, that AndroidX guy I'm bringing in, right? So yeah, that can be challenging because it's not really easy to analyze that dependency tree.

Jon (43:12.046)
Yeah.

Allan Ritchie (43:12.626)
because you have to know what you're looking for there. And it's, you know, depending on the ID.

Jon (43:15.918)
Well, you can in Android Studio or with Gradle, right? There are ways you can print out the graph and everything, but that's not something everybody knows either.

Allan Ritchie (43:25.556)
Yes. Well, it's also CLI based, right? At least the one, the method that I use, right? Like in, in, if you're accustomed to visual studio, if I need to see a dependency tree for the most part, well, at least in terms of new gets, I can click, you know, click on the new get packages. Then I can click on the package. It can show me its dependencies and it'll dig all the way into the bowels of hell, right? To see all the package tree there. Like it's very, it's just the ID is better. I know I'm going to hate, hate for that. I think.

Jon (43:29.646)
Yeah.

Jon (43:53.934)
Yeah, exactly.

Allan Ritchie (43:55.316)
But you can see it all. So it's a little bit harder on the Android side. But again, if you understand what you're pulling in, you can usually get around it. Usually. It's not usually as bad as people think. But again, I think I found the extra code stuff was a little bit nicer for me.

Jon (44:10.446)
Yeah. And I mean, this is.

Jon (44:16.014)
I agree. I would be totally in agreement there. And I think ultimately, yes, in a perfect world, if you are building a mobile app and you want to use native libraries that add functionality and stuff to your app that aren't already bound for you, you got to roll up your sleeves a little bit. We want it to be easy for you, but at the same time, you're in a...

you're getting paid what you're getting paid to do what you need to do, right? So like go learn how to do some things. We'll give you some patterns to help make it as easy as possible. But there's always going to be some level of work and you've always got to understand some of the platforms. Like at the end of the day, you know, one thing maybe we don't tell people to do enough is like, I wonder if there'd be enough noise that people could generate with maybe not with Google, but like maybe with some other, you know,

Allan Ritchie (44:57.012)
Right.

Jon (45:12.556)
vendor that does a library. And I know we've got some actually that are now talking about like, oh, we want to do a Maui library for our platform or our SDK or whatever. And like, that's cool. Like that would be great if we had more vendors actually just supporting a way to use their stuff. So like that's always the rub, right? At the end, are we going to build you Firebase stuff? Right. And also like it's a weird like,

Allan Ritchie (45:33.524)
because they understand their API surface better than anybody.

Jon (45:40.034)
I mean, I don't want to get into politics of it, but like there is a bit of weird competitor, competitor competitiveness, um, where, you know, it's, it's hard to send. It's hard to do the work to like send you over to use a competing, you know, company services. Now, and I get it. There's not, you know, like Firebase is a great example that we don't really have an offering for all of those things to send people to. So yeah, you need something. And I get that people want to choose Firebase a lot for those things.

Allan Ritchie (45:46.484)
There you go.

Jon (46:09.998)
Um, totally understandable, but it like, you know, just to put it into perspective, it is a bit of a weird space because like, we're kind of battling between making you successful with it and pushing you to use, you know, alternative services from, from competition. So I don't know, it's a, it's a weird space, but ultimately I, you know, the, the making everyone successful is, is what we're trying to aim for. It's just, how is the best way that we can do that? How do we help you help yourself basically?

Allan Ritchie (46:39.508)
Well, and that's that's part of it, right? It's the ecosystem for all those that are concerned. You've heard it. We are working on kind of some bindings. We don't know if they're going to be new gets. They're certainly not. Well, I don't want to say that. I can't say they're they're going to be. They're not Microsoft hosted the way we're talking about it right now. So it'll be probably community. So it'll be open. It'll be there. People will be able to maintain it without kind of the red tape, hopefully.

Jon (46:57.71)
Yeah, I think it'll be a community -based effort.

Allan Ritchie (47:09.716)
And there'll be something out there that'll be community trusted and kind of get, like the Maui community, it's been great, right? They have people coming and going all the time and hopefully we can do the same with bindings as we go forward in this. But there's something coming, something coming, we're working on it.

Jon (47:26.318)
Yeah. So it's not close enough yet that I think we can call that the package plug -in or product of the week though. So what are we going to have stand in for it?

Allan Ritchie (47:34.172)
No.

So there is this plugin dot Firebase that's out there. I think a lot of people have been using that. And it's pretty much, I mean, I think it's like the fat Firebase. It does pretty much everything Firebase has to offer that I've seen. So it looks like it's getting a lot of hits. So go check it out.

Jon (47:49.582)
Yeah.

And it's a cross -platform abstraction, right? So it kind of gives you that one API to use everywhere.

Allan Ritchie (47:55.636)
Yeah.

Allan Ritchie (48:01.3)
Yeah, and like I said, it's pretty popular. I know, I think they're waiting for official bindings or something too. So yeah, it's coming. It's coming and it'll be great.

Jon (48:11.758)
Yeah, I think, you know, the, the, that one in particular, I know I've, I've thought of a bunch about this as we talk about slim bindings. Like I think actually they might be a very good candidate to, you know, one, hopefully, you know, you feel like they could contribute to the community effort around the slim bindings of these things that we're, we're working on. Um, but then to like, to kind of create their own destiny with that in terms of.

helping have the APIs that they need to fill the implementation of their own cross -platform API, right? So if you look at some of their interfaces and stuff, like it's a gorgeous project in that sense, the way they've done it, but none of the interfaces are like super difficult or hard. And they're already, because they're already doing this to make it cross -platform, they've already done kind of the work of simplifying the types and things that they use in that API layer, right? So like,

they're not using like weird platform specific things from the native library on iOS and exposing that in their own API, they're abstracting that with, you know, basic types and stuff. So at the end of the day, yeah, they probably can keep using the Android libraries to do their implementation for that side. But, you know, as we move kind of to this world for iOS, it might make a lot of sense for them to use just the...

the slim binding approach and kind of have their own abstraction that they can easily update as Firebase updates itself too.

Allan Ritchie (49:39.156)
So kind of a recap, slim, small, focused bindings, focused methods. It's not as hard as it sounds. It's just bad John marketing or something or somebody bad marketing something. Focused bindings. Let's rename it, redub it.

Jon (49:53.326)
The yes, exactly. And, and, and help yourself, right. And I think the fun part of it all is like, once we got the basics working, I think we both were kind of like, huh, that's actually really not hard. And it works really well. And it's quite pleasant of a workflow too, right? Cause like you said, you get to code in with IntelliSense with against the native stuff before you try and have to understand the API to do that. So.

Allan Ritchie (50:04.882)
Yeah.

Allan Ritchie (50:18.516)
Right? It was most of the hassle was around figuring out what Xcode wants us to compile with in the CLI. And now we got that.

Jon (50:24.654)
Exactly. And we have it and we can keep building from it. So, all right. I think that'll do it for this week. Um, stay tuned for those repos to drop in the meantime, while you're waiting, why don't you just take yourself over to the Apple podcasts app store or whatever, uh, and, and drop us a review. I think the more five star reviews that we, we get between now and, you know, when this thing's ready might be a good motivator to push it out the door. Don't you think?

Allan Ritchie (50:51.732)
Nice. Yeah, sure. Sure. Sounds great. Total marketing.

Jon (50:56.696)
I gotta try where I can, right?

And if you do have feedback, if you want to yell at me for that, you can visit us at gonemobile .io. Plenty of ways to get in touch with us there. I think we have some listener feedback that I have piled up that we want to address, maybe a future episode. But you know, leave it there, reach out to us one way or another and keep listening and we'll see you next time on Gone Mobile.

Allan Ritchie (51:23.828)
Thanks everybody.