Introduction and Announcements
---

[00:00:00]

Leo Dion (host): Hey, thank you for joining me for today's episode with Kabir. Before we begin, I wanted to let you know what's new. Couple of things. I released a new library to write Swift code. So if you're somebody who's interested in making mac macros or any sort of dynamic code in Swift, you'll definitely wanna check out Syntax Kit.

The link to that will be in the show notes you should consider. Subscribing to the newsletter 'cause that's free. But you should also consider being a Patreon. It's like three bucks right now per month. We already have the next episode posted on Patreon with Rachel Brindle, where we talk about Swift testing.

So if you want early access to the next episode, you'll definitely want to make sure you join the Patreon, patreon.com/bright digit. And that's about it. I hope you enjoy today's episode.

Kabir Oberai and WWDC
---

Leo Dion (host): Welcome to another episode of Empower Apps. I'm your host, Leo dm. Today I'm joined by Kabir [00:01:00] Oberai. Kabir Thank you so much for coming on the show.

Kabir Oberai (guest): Thank you for having me.

Leo Dion (host): it's been a few exciting weeks for you, right?

So not only do we have WWDC week, but you graduated, is that correct?

Kabir Oberai (guest): That's good act last week.

Leo Dion (host): Congratulations. Welcome to the workforce in 2025. Yeah. So, ~ ~before we begin, I'll let you go ahead and introduce yourself.

Kabir Oberai (guest): Sorry. So I am, or I was a student at the University of Waloo. And ~ ~I, you know, I just graduated, with a degree in computer science and, I've been interested in iOS development for. As long as I can remember. I started iOS in like 2013. just 'cause I wanted to make apps, iOS apps seemed pretty cool.

And then I learned objective C and a year later, Swift came out and I was like, what did I do all of this for? But, you know, it was pretty I'm glad I [00:02:00] learned objective C and, I'm glad that Swift came out as well. And. You know, I was A-W-W-D-C scholar in 2017 and I've developed some fun projects over the years, which I think we will be talking about soon.

one other thing worth mentioning is I I've been in the workforce in and out for a bit. I was previously at texts.com, which is a startup. I, we got acquired by Automatic, the guys behind WordPress and Tumblr. And, then more recently I joined ramp which is a FinTech based in New York.

Leo Dion (host): Okay. Awesome. well, congratulations. We're gonna talk about what came outta WWDC and stuff like that. But we're also gonna talk about a little tool you've, made called xTool. Before we get into xTool, let it, let's jump back and do talk about wwdc. What were some things that you were [00:03:00] particularly interested in or what were things that you were fascinated by, I guess.

Kabir Oberai (guest): That was a bit, that was quite a bit. I think, you know, elephant in the room, the liquid glass stuff is, definitely very nice to see. I love the luminess. I, I love all the, you know, the. The move towards sort of skim to an extent? it's, yeah, it, it does definitely like make designing harder in my opinion.

'Cause you know, I. There was this sweet spot of a few yours where you could just like whiteboard anything and like drop it in Figma and you'd have like a really nice iOS design, but now you have to think about all of these little effects and stuff. I do hope that we get, some good tools for that.

But you know, designing it, Swift UI is also, pretty good approach to take. I'm excited by I'm pretty excited by the [00:04:00] foundation model stuff as well.

Leo Dion (host): You had a chance to play around with it yet?

Kabir Oberai (guest): not exactly, so I actually, I was poking around one of the excode betas a few months ago, so like, not the 26 cycle, but I think it was a 16 expert, 16 cycle.

And I noticed this generative macro in. one of the excode 16 vaers.

Leo Dion (host): really? Okay.

Kabir Oberai (guest): So that's when I poked around with it actually. I think it was entitlement gated at that point. Like I don't think it was like fully usable. 'cause it also like pulled in, it was just the macros that they accidentally included.

Leo Dion (host): right.

Kabir Oberai (guest): but, I was like, okay, this is. Definitely gonna lead to something interesting in 26.

Leo Dion (host): And, and, and we know that now. Yeah.

Kabir Oberai (guest): yeah. Yeah. well, not 26 at the time we, one thought it would be 17. The release numbering is also an [00:05:00] interesting change. It's definitely nice. I can't wait to see, I mean, I'm. The mess that's going to be created with the minor versioning though.

'cause like, you know, you've solved the, the major versioning, but,

Leo Dion (host): What do you think they're gonna do with the minor versioning? I mean, I would just assume that we're gonna see 26 1, 26 2, and it's still gonna go the way it was before. Right. As opposed to like months or something. That would be really confusing. I mean, I don't know. I guess that's kind of what, what like Ubuntu does that right?

So like it wouldn't be that

Kabir Oberai (guest): hot take, my hot take is that, months would've actually, would actually be a nice approach to take. 'Cause like if you're going to go with the calver approach, then just like go all in, you know?

Leo Dion (host): Yeah, yeah. Yeah. Actually it would be, 'cause like they do pretty much release 26.1 in January, more or less so. It would kinda line up,

Kabir Oberai (guest): That's true. That's true. And you know, the way that they talk about releases usually is like [00:06:00] if you look at some of the Swift internal sources, they talk about like the fall 2024 release or the spring 2024 release. So I do hope that they do that. If anyone from Apple is listening,

Leo Dion (host): Yeah, that actually

Kabir Oberai (guest): not till late.

Leo Dion (host): Yeah. Cool. So let's talk about xTool.

What is xTool
---

Leo Dion (host): For those who don't know, I'll let you go ahead and explain exactly what it is.

Kabir Oberai (guest): At the moment the main way to develop iOS apps or apps for Apple platforms is with Xcode, which is Apple's, IDE, and. You know, there's, there's a lot of benefits to Xcode of course, and you get your nice end-to-end vertical integration across Apple Stack. but there are issues with it, right?

And, you know, anytime you have a bug, it's not open source. It's hard to fix any of that stuff. And sometimes you just need something more lightweight or sometimes you want to use do [00:07:00] development on other platforms than macOS. And. This is a problem that xTool aims to solve. And, in essence, xTool is a re-implementation of a lot of what Xcode does in a way that's fully open source and works across platforms, which means you can build iOS apps on macOS, windows with Ws and Linux.

Leo Dion (host): Can you build anything in the Apple pla, any Apple platform?

Kabir Oberai (guest): So the foundations for that are all in place. At the moment I am like the building step is primarily geared towards iOS stuff, but we actually do build the macOS SDK as well. And it, I don't think it would be a stretch for us to support building like Vision Os and,

Leo Dion (host): If you have the SDK, that's what you need, right?

Kabir Oberai (guest): Exactly. It's the bit that isn't done yet for, like macOS for example, is [00:08:00] the macOS app bundle structure is slightly different from the iOS bundle structure. So for us to build Mac apps, we just have to like move some files around in different ways. But it's not, it's not too hard. It's not too hard.

I actually added, simulator support recently.

Leo Dion (host): That's

Kabir Oberai (guest): yeah, so you can, you can build for the simulator with xTool, which is especially useful when you are developing with xTool on macOS.

Leo Dion (host): So what are some things that you had to learn to get this going? What are some fundamentals for getting Xcode working or I guess the bill tools working

Kabir Oberai (guest): Yeah,

Leo Dion (host): in another os.

Kabir Oberai (guest): I think, this really, really pushed my, like, the extent of my knowledge on iOS and also like, it's been an amazing learning experience for me. So a little bit of historic context here actually is, this started off as a project that I started building in [00:09:00] around 2017. so, i, I was, you know, a, a part of the jailbreak community.

and in the jailbreak community we had this build system called Theos. And this was the build system that allows you to build jailbreak tweaks. Amongst other things. And it was completely detached from Xcode. It was based around GNU make which if you've ever used make you can imagine is an absolute nightmare to deal with.

But the crux of it is somehow through a lot of clue and, you know, batch work. This build system supported building iOS apps on any platform which is like. Even on like native windows. And on Linux. But it was specifically four J Big. 'Cause these apps weren't, you know, there's this important step of code signing that you do with actual normal iOS apps that we weren't doing there.

So long story short, I [00:10:00] eventually became one of the core maintainers of Theos. And I learned a lot about how the plumbing works. I added Swift support to it. I added a bunch of other things to it. And then I. The one question that kept sort of ringing in the back of my head was, why is this not accessible to more people?

You know, why, why is it that only people in the JFA community have the fortune of being able to develop iOS apps on any platform? And around the same time I was working on this other project called supercharge, which was basically designed around side loading. So being able to install iOS apps without going through the App store.

and. Like this. So supercharge in the end there was, there were a lot of roadblocks and I kind of, decided to put a stop on it because I was just a bit worried about, you know, legal factors and other things.

Leo Dion (host): is, that is a [00:11:00] consideration. Yes.

Kabir Oberai (guest): it definitely is. But, I learned a lot from supercharge as well, including, and, and I.

I developed a lot of code there that was able to interact with Apple's developer services and take any app and sign it, you know, provision it, get those certificates and profiles and all of those things that you need, and then sign it and then also install it onto your device. And, some of the things I had to learn along the way there, besides the interacting with the developer APIs was like to actually set to install it onto your device, we had to emulate the same protocol that Xcode uses when you hit Command R and you install over wifi.

So yeah, lots of, you know, lots of learning there for sure. And, anyway. Eventually I realized I had these two pieces that were great. You know, you had this Theos thing that was able to build iOS apps but not install them onto a J non J broken device. [00:12:00] And then you had this supercharge thing that was able to.

Sign apps and install them onto any device. And I was like, I could take my learnings from here and I could take some of the code from here even and sort of combine it into this one project. The third piece and the final piece that really fit in place was when Swift improved their support for cross compilation with Swift Package Manager, Swift SDK support.

So this is something that didn't really land into Swift six one or six two even.

Leo Dion (host): I was gonna ask.

Kabir Oberai (guest): Yeah. It was just like last year basically where, ~so, ~you know, this w of a dc in fact, they, they made a big show of how you can now build web assembly apps natively with Swift, right? Even Android apps for that matter is something you can build with Swift now.

And,

Leo Dion (host): done an episode on.

Kabir Oberai (guest): Oh, you have, that's awesome. But yeah, you know, so like all of those pieces were incredibly relevant here because I was able to build a Swift SDK, [00:13:00] like we use for building Android apps. But, this one can build iOS apps with Swift Package Manager. And yeah. So, you know, just combine all of those pieces and you get this end-to-end solution that can build, provision, sign and install an iOS app from any platform.

Leo Dion (host): So one of the things I think you mentioned was that there was like an open source. They had open source part of the build, Swift build, how it works with Xcode. Is that correct or am I missing something?

Kabir Oberai (guest): So Swift Build actually came along fairly late in this whole process. And it's, it's confusing 'cause there's Swift build, which is like the Swift space build command that you use to build. With Swift Back

Leo Dion (host): It is

Kabir Oberai (guest): you have Swift Hyphen Build, right? So Swift Hyphen Build is the Excode thing. And yeah, that, that has been open sourced fairly recently.

I actually built all of this way before Swift Build came around. [00:14:00] I. But I am looking into using Swift build to streamline most of this build process, and it's gonna have a huge impact here for sure. At some point. It's actually like Swift Package Manager is currently working on integrating Swift Build as their native build system.

And once that happens I am. We are gonna have some benefits from that immediately. And then, you know, we are also gonna be able to probably use that with X two to remove some of the manual packaging code

Leo Dion (host): Right, right, right. So what's, what is the difference between Swift Space build and Swift Build?

Kabir Oberai (guest): Swift space build is Swift package managers build command. Right? And until last year it was entirely like. Custom. it did its own, you know, coordination with the underlying Swift compiler. in fact, it now uses Swift [00:15:00] dashboard under the hood,

Leo Dion (host): For starting with Swift 6.1,

Kabir Oberai (guest): Six two. And I say it uses it, but that's with an asterisk where it's an option that you can provide to make it use it.

Leo Dion (host): That's good

Kabir Oberai (guest): Yeah, so you can actually like test it out now, but I think, it's probably not going to be stable until I, I don't know after this timelines here,

Leo Dion (host): Right, right.

Kabir Oberai (guest): yeah.

Leo Dion (host): It's funny you were mentioning, jailbreaking and stuff because I recently read an article about the Hack OSH community and how they're kind of, now that we know, tahoe 26 will be the last Intel supported Mac. They're pretty much shutting down now because that was a big opening was to be able to build for Intel, right.

And do it on Intel. So it's funny you're imagining now we can do. Build on Linux and Windows as well. To me, like what [00:16:00] really attracts me to xTool is the CI option. If anybody knows it's cheaper to run a Linux vm, than it is to run a Mac vm. And so being able to do that would be absolutely, you know, fantastic for the community just to get the builds going and running.

Kabir Oberai (guest): ~Hundred percent. ~I just wanna interject that real quick and I do wanna mention that with regards to the CI option, that's something I have been doing a lot of research into recently. I think the main blocker that is actually legal rather than technical. Now that xTool exists, that isn't any technical blocker, but there might be a potential legal blocker, which is that, apple doesn't the, you know, the license agreement asks that you use macOS to

Leo Dion (host): Okay.

Kabir Oberai (guest): deploy apps.

So yeah, the way that, you know, I've been. Talking about xTool is, yeah, we support Linux, we support Windows, we support [00:17:00] macOS. But as far as the license agreement goes, it does say you should be using Apple hardware. So like, I've been using it within like, dock on macOS or even the new containerization stuff.

I actually wanna give that a spin soon. And that, that's another thing I'm very excited about with this dub. But, you know, I've been using it in a VM as well. There's like, the rest of it is kind of open to legal interpretation. I'm not a lawyer yeah. but it's very interesting and I have actually, I do actually know that it is possible to use this on CI on a Linux CI machine.

~Yeah,~ just gotta figure out whether it, the law allows it.

Leo Dion (host): right, right. Exactly. Exactly. So how, what's the difference? What goes into building an app, as opposed to like building a Swift package where you just compile Swift? What are the components of building an [00:18:00] app that are required or that you learned that is going on in the background?

When you build an Xcode, you build an iOS app.

Kabir Oberai (guest): So when you build an iOS app, in fact, ~ ~you can actually let's start with macros here. 'cause that's the easy option. If you build a macros executable, you know, these days you use like your admin to mark the entry point. If you import Swift UI in a macOS executable and you like declare your main thing to be an app, like the app protocol, you can build a macOS app.

You, you can turn any plain executable into a macOS app. Yeah, so, so like the bare minimum there is actually very little, like you just, you know, need to import Swift ui or UI kit or app kit. And then Mark the, either your app Delicate or your app protocol with admin. The, the, the.

Bit that really [00:19:00] matters after that is the bundling bit. So once you have an executable you can run it on macOS and you can distribute a plain executable. But that doesn't work on iOS, of course. On iOS or if you wanna do anything fancy on macOS, right? What you need is this bundle. And if you, if you look@any.app under the hood, like you go to any of the

Leo Dion (host): It's just basically a folder.

Kabir Oberai (guest): Exactly. It's a folder just called our app. And then it has like a few directories inside it, and then one of those files inside it is that executable that you built. Right. and then the other things that are there are, you have an info P list, which you. Most people have seen as well is just like, it declares important things that the system should know about the app.

Mastering iOS App Signing
---

Kabir Oberai (guest): And then you have your signing. And signing is actually the, the trickiest bit of this. When it comes to iOS on macOS, you can like pseudo sign, which is very easy to [00:20:00] do. On iOS you need to have like a valid code signature, which basically proves that you are a specific developer and proves that Apple has given you permission to run this app on your device.

So when you run an app and you run into signing errors or you see that your app is trying to be provisioned or like is generating certificates or, you know, whatnot that's kind of what's going on under the hood there. So, in essence, The steps here are basically you build your main executable, and this can be done with, you know, Swift Package Manager.

You just need to have your target with at main in it. And then you need to bundle it in this folder with the info p list next to it. And, the other thing you need that is you need, to generate your provisioning profile, which is the sort of permission slip from Apple that says this app can run on this [00:21:00] device.

And you sign your app and you include that provisioning profile. And then you've got a fully functioning iOS app. In fact that's a.app. And then you also often distribute apps on IOS's IPA files. And IPA file is actually just a.app, but then. Compressed as a

Leo Dion (host): Yeah, exactly. That makes sense. What are, just before we touch on debugging and deployment, I do wanna see was there anything else that caught your interest, that you thought was interesting about the development process that you didn't, that you learned about? And in the process of making xTool.

Kabir Oberai (guest): I think, one of the other very interesting things. Is that, the app store connect API is a gem. And I found it

Leo Dion (host): You mean not related to Ruby? You just mean it's, you really like it, right?

Kabir Oberai (guest): yeah,

Leo Dion (host): Okay.

Kabir Oberai (guest): no, that was an unintentional pun, but I'm gonna pretend like I meant it. ~Yeah, no,~

Leo Dion (host): ~have you looked at, ~have you looked at [00:22:00] tools like Fastlane?

Kabir Oberai (guest): Yeah, I actually, so, so I did a talk about this about the sort of roots of this project two years ago at this, at Swift do.

Leo Dion (host): Okay.

Kabir Oberai (guest): and, that so that talk was just about like, here's the rudimentary things that we're working on. Here's a sneak peek into the future. It was a talk about iOS development or, or just like.

The life of Swift outside of Xcode, which included cross-platform things. It's amazing to see how things have matured over these two years. Also like, you know, some things are still holding us back, but, you know, there's, in, in general there's a lot of progress here. But, you know, so, so like.

I actually did speak to Josh Holtz at that, after that doc he was at Swift D and he's the maintainer, the Fastlane. And he was super excited about, everything that this could do for Fastlane. [00:23:00] So, you know, we have, we have an open GitHub issue on both xTool and on Fastlane. To Jack this, and I haven't quite figured out what this integration looks like yet.

And I haven't spoken to Josh about it recently, but, I would definitely love for that to happen at some point.

Leo Dion (host): It sounds like you're touching on some of the same stuff with signing and all that,

Kabir Oberai (guest): ~yeah. ~In fact, like there were a lot of times that I had like bugs that I was trying to solve and I would just pop up and fastly and be like, oh, so that's how they fix that.

Leo Dion (host): and they fixed a lot of bugs yeah. yeah. Very cool. So one of the, the other thing I wanted to mention was the way, so when I got started using xTool, there was a specific way. The project was set up. You don't have like an Xcode project.

And explain how that works exactly and why it's different from using just a regular Xcode project.

Kabir Oberai (guest): So there's a trend recently, and it's not just me doing this. There's a lot of folks who are starting to realize that like expert [00:24:00] projects have a host of issues. You know, like if you've ever had to deal with a merge conflict with an Xcode project it's a nightmare, right? You don't know what to do.

'Cause like it's all, the Xcode project is all XML and it's just a blob of like autogenerated stuff. so there's a lot of, there, there's this huge push that people are making towards declarative package management or declarative project management. And there's some other great you know, folks who are doing this.

If you've seen Xcode Gen or if you've seen tourist. Yes. I actually had a really nice conversation with the tourist, folks few weeks ago after ExTool. And we've also been talking about various ways that, you know, we can integrate things together.

Leo Dion (host): ~That would be great. ~As a big fan of xTool or tourist yeah, I would love for the things to kind of be on the same page 'cause I'm starting to move all my projects to tourist.

Kabir Oberai (guest): Yeah. Like that's, that's the dream, right? Ideally it would be [00:25:00] amazing if you could take it to its project and just build it with x.

Leo Dion (host): Yeah, exactly.

Kabir Oberai (guest): So yeah, the idea there is basically like, let's move away from having this expert project this massive expert project file as the source of truth and use declarative package management with like the Swift project manifest.

That's very similar to package Swift that you use for Swift packages, right? Kind of what you're adding on top of your package Swift is you're adding instructions on what the app looks like. Just for starters, you need a bundle ID for it, and you need to select a development team. And then there's a few other things there, like, different capabilities your app might have, you know, like background modes, or like entitlements, all of those things, right?

So as a matter of fact you might have noticed recently that even Apple is moving in the same direction. Where if you look at Swift Playgrounds they actually did something very similar where they have this library called Apple [00:26:00] Product Types, and you can declare within your Swift package or dot iOS app, using Swift Playgrounds.

You know, I realized that this was the direction we were moving and this was the best direction to take xTool as well. For starters, at the moment, you have this, so, so an xTool project is basically a package Swift, you know, it's a General Swift package. And then the only thing you add to it is this xTool, YAML file.

And this just all you need to begin with is a bundle id. And, you know, when you run X to Dev, it figures out the rest. It takes your package, it tries to scan it for the iOS app target that it thinks will be the Root app project, the root app target. It'll build it for you and then it'll package it based on what you've given you, what you've given in, in the xTool Y file.

Leo Dion (host): How about things like the product type and things like that? That would just be done in the Swift [00:27:00] package.

Kabir Oberai (guest): So when you say product type, do you mean like ex app extensions or do you mean Okay. App

Leo Dion (host): type platform, things like that, that need to be set within a typical

Kabir Oberai (guest): Yeah. So some of these things we try to get outta the package at Swift. For example, like if you wanna select like a deployment target that is actually you, you just use the platform's field in package Swift it's, you know, we, we dump the package Swift, we scan it, and we figure out the right deployment target to use that.

But there's some things that, you can't quite do in Packet Swift. So like product types, right? There's no way to declare an like a keyboard extension or a share extension inside of a Swift package. and app extensions are one of the areas that we're actively working on right now.

There was actually someone from the community who contributed a PI for this, which is amazing to see. You know, this is just a few weeks into Swift, into being released. And someone built out. All of app extension support [00:28:00] for us. And I've been working with them on polishing that up and planning.

I'm planning to land that soon. But, yeah, this was, this is something that you add to your xTool YAML file where you say, here is the. Swift package product that corresponds to your main app. And here are the Swift package products that correspond to different app extensions. And that's basically all you need to do there.

And then when you do extra dev after that, it'll bundle all of those things together. It'll build all of those products and then better them for you.

Leo Dion (host): Okay. And then what did you say about what platforms? Does it just use deployment target for that or what?

Kabir Oberai (guest): So at the moment it's more like, it's based on what command line flags you pass to external dev.

Leo Dion (host): Oh, okay. There we go.

Kabir Oberai (guest): yeah, so, so right now it just assumes iOS by default. Like iPhoneOS SDK if you wanna build for the simulator, there's just a. Dash simulator flat that you [00:29:00] pass. And, I realized that's designing me into a corner when it comes to other simulator types or other platform types.

But, you know, right now we're just starting with iOS support to keep things simple. But you know, if we wanna do watchOS, visionOS, tvOS, macOS all of those things. You can, we'll probably just add a flag that you can pass in.

Leo Dion (host): that makes sense. One of the things that is really cool is so not only do you support not only do you support. Simulator, but you can build on device and deploy on device and debug on device, and it uses, remind me what the name of the tool is that you have to install.

Kabir Oberai (guest): So, there's a tool called Lib iMobile

Leo Dion (host): Yeah, so explain how like the whole USB thing works on Linux and how you're getting that to work. So you can debug an app on device.

Kabir Oberai (guest): ~Sorry. ~So I will add, just to preface that debugging in particular is [00:30:00] one of the trickier areas. There's actually been some major changes to Apple's debugging stack over the last one or two years. So as if iOS 17 it. Is something that doesn't work with xTool, but you can install apps, onto your device.

And before that up until I was 16, it's really possible to launch and debug apps as well. And again, this is something that we're working on, it's that there's other third party tools that have solved this. But to come back to, you know, the crux of this, which is how do we do installation in the first place?

Again, a huge part of this is basically emulating, what Xcode does. And when you connect your device via USB it actually opens up a port on your iOS device.

Leo Dion (host): That makes

Kabir Oberai (guest): and, it creates like this tunnel. And it basically talks to it over, you know, dCP. So there's this protocol called, lockdown D and the way the lockdown D works is you [00:31:00] send over from your Mac, you basically connect to this particular port on your device, and you send over this buddy, which is.

You ask it to open a service, and there's a list of services that, lockdown d supports. For example, there's a service called apple File Conduit A FC and that allows you to transfer files between your Mac and your phone. So, you know, we first open up an Apple file conduit service. We transferred over the, IPA file.

~And then ~there's another service called Installation Proxy. We open that up and then we point it to the file that we install, ~ ~that we just transferred over, and we say, install this. And, ~ ~that in, in the gist of it is. Basically what we do, there's a lot of other work that of course, in terms of pairing.

You know, there's like pairing is all SSL stuff. But, A lot of this work is handled by Lib I mobile device. And in fact, if [00:32:00] you have a Linux machine and, you ever connect your phone, your iPhone, to a Linux machine and you see like your phone pop up on that, the reason that your Linux machine can talk to your iPhone is because Lib I Mobile device is installed by default.

Leo Dion (host): Right. Okay.

Kabir Oberai (guest): so it's one of the, it is a very well maintained package and it's well tested. It is written in C which is unfortunate.

Leo Dion (host): What's most of this stuff written in? Is it written in c plus or what do you use or Swift or what

Kabir Oberai (guest): So Lib iMobile device, and some of the dependencies that we have are written in C but, all of, xTool itself is written in Swift, in fact, yeah. So it's like pure Swift and like a little bit of like c to bridge between some of these things.

Leo Dion (host): How has the bridging been between C and Swift? And is anything with like Xcode six two help or Xcode six two Swift [00:33:00] 6.2, has that helped at all?

Kabir Oberai (guest): do you mean the c plus ended up,

Leo Dion (host): Yeah, sorry, c plus and the fact that we now have in was it inline array and span and stuff?

Kabir Oberai (guest): Oh, right. I haven't used any of the new stuff, the inline and span stuff. 'cause we're still trying to support six one and six zero. For like building, but I am very excited about that. The bridging in general has been pretty nice actually. As part of ex two, the way that we talked it, the way that we interact with Lib iMobile device is I built this library called Swifty Mobile device.

And it's basically just a Swift apple around lib I mobile device. And you know, we have like some actors in there to allow for like nice skin currency stuff. ~ ~I think, one of the biggest nightmares for us, for me was really like when, Swift six came about and then Swift like had the whole strict concurrency mode.

And ~ ~just dealing with concurrency errors. And all of the trash [00:34:00] that's come around with, you know, like every single release. Having new concurrency errors to deal with has been a bit difficult, but, I have actually fixed some. Completely valid race conditions because of it. So I will say it, it's like you gotta eat your medicine to an extent that, that a ways the medicine could have been made nicer, but I think they're moving in the right direction now.

And with bridging in general, x ft. Mobile device was also treat to work on. ~In~ fact, ~ ~I released, I shared Swifty mobile device with some folks a while ago, and I believe at the moment it's currently used with, if you've seen, Gui Rambo's AirBuddy. ~ ~so that uses Swifty mobile device under the hood, or it used to for a bit at least.

And another really nice tool called re incubate camo. And, ~ ~ That is something that's existed for a few years and is, in fact, it was featured by Apple recently, which is awesome. So that also uses Swifty [00:35:00] mobile device. You know, it's, it's a, you know, validated library to that extent. And Bridging has been very nice to work with.

Leo Dion (host): So two things. One, have you ever, would there ever be a way to remote as, as a developer of a VM app, I should say bushel? ~ ~would there ever be a way to com do remote debugging from Mac to Mac?

Kabir Oberai (guest): Jim Mcac.

Leo Dion (host): We should talk about this offline then, that's something I would love to have. And secondly

Kabir Oberai (guest): I don't have an answer for you immediately on the Mac to

Leo Dion (host): Immediately, okay. Okay. Did you ever try debugging on a Apple Watch?

Kabir Oberai (guest): not yet. Not yet.

Leo Dion (host): it in any way, please? Because the

Kabir Oberai (guest): I hope so.

Leo Dion (host): is pretty bad. Okay. ~Okay. I just thought I'd ask those two~

Kabir Oberai (guest): ~Yeah. ~Le mobile device supports, watch connectivity. I believe so. It's possible. I.

Leo Dion (host): Yeah, it's possible, but is it better than what we have? Okay.

Future Plans and Community Contributions
---

Leo Dion (host): a couple of things before we close out. I [00:36:00] wanted to know what's next for xTool?

Kabir Oberai (guest): sure. So I feel like, this is that there's so many, you know, so many requests that are open. There's currently like five different fis that are open, and I think we have, I. We, we touched upon some of my future plans here. You know, one of them is definitely to figure out the right way to go about CI support.

'cause yeah, I mean, in an ideal world, you could just take any iOS app and, switch your Mac Runner for Linux and just have it work. But, you know, more than that, i, I would also I'm just very excited about the educational opportunities. And that was really like why I created xTool to begin with was

Leo Dion (host): like all of us.

Kabir Oberai (guest): yes, you know, so many people like ~don't~ have, the tools to work with to build iOS apps and this gradually lower the value for them, right?

And, ~ ~you know, a big part of that would definitely be if we supported export project to, ~ ~[00:37:00] to a conversion. So that's something again, talking to the twist folks to see if we can use some of that technology for that.

Leo Dion (host): Yeah, that would be great.

Kabir Oberai (guest): That would be awesome. And then, you know, app extensions are another really cool thing that would, that I'd love to support.

Let's see. What else are we you know, again, there, there's actually one of, one of the limitations, is support from macros. So at the moment, One of the few things that doesn't work is some of the proprietary macros, like, some of the Swift UI stuff, like at entry. So I, I would say like at Observable works fine because that's open source and it's compiled into the LinuxTool chain.

But yeah, some of these macros don't, so I'm, I'm working on liability. Yeah, so I'm working on a library that re-implement like, at entry and at, at Animatable or whatever the new Swift UI macros are. So that's, that's one of the things that is coming [00:38:00] up. And yeah, just in general, you know, like having community contribution is always amazing.

So, I'm. I always open to fi there. There's a whole roadmap if you look at the project section on xTool And, you know, if anyone is interested in contributing that I always appreciate it. One other big thing actually is, support for alternative. Tools like flatter and React, native and Gotland multi-platform.

And, I, I was very surprised to see this, but like xTool has create, has generated a lot of traction in those communities. I.

Leo Dion (host): It kind of makes sense.

Kabir Oberai (guest): Yeah, I think I, I, my understanding is the reason for that is that, ~ ~a lot of people in those communities are the ones who currently build apps that they would like to support iOS and they'd like to test with iOS, but they can't because they don't have the tools to do it.

So yeah, you know, just, doing that sort of thing would be super awesome.[00:39:00]

Leo Dion (host): Well, Kabir, thank you so much for joining me today. Was ~there~ anything else you wanted to mention before we

Kabir Oberai (guest): I, I think, I think that's about it.

Leo Dion (host): Okay. where could people find you online?

Kabir Oberai (guest): You can find me on, Twitter at, Kabir, that's K-A-B-I-R-O-B-E-R-A-I, or for that matter, basically all of my other socials are just by name.

Leo Dion (host): And we'll put links in the show notes. Of course.

Kabir Oberai (guest): Yeah. And, ~you know, I, I, ~you can also check out my website at ro vi.com. Has not been updated since 2019, but have links in that

Leo Dion (host): It never, it never quarantined. Wow. Well thank you so much, Kabir, for coming on. and congratulations to your, your degree. This is awesome.

Kabir Oberai (guest): thank you so much for having me.

Leo Dion (host): People can find me, at bright digit.com is my company's website. And I'm on social media, Leo g Dion, check all the socials there and the links below. If you really enjoyed this [00:40:00] episode, please think about, subscribing.

And we also have a Patreon. Thank you to all Patreons for supporting this program. And if you have an idea about something you wanna talk about on the show, please reach out to me and let me know. And if you're listening to this on a podcast player, of course, please ~like,~ and ~like,~ and subscribe ~there~ as well.

Thank you for joining me, and I look forward to talking to you again. Bye everybody.