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.
Welcome to another episode of Empower Apps.
I'm your host, Leo dm. Today I'm joined by Kabir Oberai.
Kabir Thank you so much for coming on the show.
Thank you for having me.
it's been a few exciting weeks for you, right?
So not only do we have WWDC week, but you graduated, is that correct?
That's good act last week.
Congratulations.
Welcome to the workforce in 2025.
Yeah.
So, before we begin, I'll let you go ahead and introduce yourself.
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 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.
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 particularly interested
in or what were things that you were fascinated by, I guess.
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 foundation model stuff as well.
You had a chance to play around with it yet?
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.
really?
Okay.
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.
right.
but, I was like, okay, this is.
Definitely gonna lead to something interesting in 26.
And, and, and we know that now.
Yeah.
yeah.
Yeah.
well, not 26 at the time we, one thought it would be 17.
The release numbering is also an 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,
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
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?
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,
That's true.
And you know, the way that they talk about releases usually is like 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,
Yeah, that actually
not till late.
Yeah.
Cool.
So let's talk about xTool.
For those who don't know, I'll let you go ahead and explain exactly what it is.
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 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.
Can you build anything in the Apple pla, any Apple platform?
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,
If you have the SDK, that's what you need, right?
Exactly.
It's the bit that isn't done yet for, like macOS for example, is 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.
That's
yeah, so you can, you can build for the simulator with xTool, which
is especially useful when you are developing with xTool on macOS.
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
Yeah,
in another os.
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 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 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.
is, that is a consideration.
Yes.
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.
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.
I was gonna ask.
Yeah.
It was just like last year basically where, 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,
done an episode on.
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, 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.
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?
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
It is
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.
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
Right, right, right.
So what's, what is the difference between Swift Space build and Swift Build?
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 dashboard under the hood,
For starting with Swift 6.1,
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.
That's good
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,
Right, right.
yeah.
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 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.
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
Okay.
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 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.
just gotta figure out whether it, the law allows it.
right, right.
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 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.
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 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
It's just basically a folder.
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.
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 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 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
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.
I think, one of the other very interesting things.
Is that, the app store connect API is a gem.
And I found it
You mean not related to Ruby?
You just mean it's, you really like it, right?
yeah,
Okay.
no, that was an unintentional pun, but I'm gonna pretend like I meant it.
have you looked at tools like Fastlane?
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.
Okay.
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.
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.
It sounds like you're touching on some of the same stuff with signing and all that,
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.
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.
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
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.
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.
Yeah.
Like that's, that's the dream, right?
Ideally it would be amazing if you could take it to its
project and just build it with x.
Yeah, exactly.
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 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.
How about things like the product type and things like that?
That would just be done in the Swift package.
So when you say product type, do you mean like ex app
extensions or do you mean Okay.
App
type platform, things like that, that need to be set within a typical
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 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.
Okay.
And then what did you say about what platforms?
Does it just use deployment target for that or what?
So at the moment it's more like, it's based on what command line
flags you pass to external dev.
Oh, okay.
There we go.
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 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.
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.
So, there's a tool called Lib iMobile
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.
So I will add, just to preface that debugging in particular
is 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.
That makes
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 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.
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 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.
Right.
Okay.
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.
What's most of this stuff written in?
Is it written in c plus or what do you use or Swift or what
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.
How has the bridging been between C and Swift?
And is anything with like Xcode six two help or Xcode six two
Swift 6.2, has that helped at all?
do you mean the c plus ended up,
Yeah, sorry, c plus and the fact that we now have in was it
inline array and span and stuff?
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 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.
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 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.
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?
Jim Mcac.
We should talk about this offline then, that's something I would love to have.
And secondly
I don't have an answer for you immediately on the Mac to
Immediately, okay.
Okay.
Did you ever try debugging on a Apple Watch?
not yet.
Not yet.
it in any way, please?
Because the
I hope so.
is pretty bad.
Okay.
Le mobile device supports, watch connectivity.
I believe so.
It's possible.
I.
Yeah, it's possible, but is it better than what we have?
Okay.
a couple of things before we close out.
I wanted to know what's next for xTool?
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
like all of us.
yes, you know, so many people like 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, 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.
Yeah, that would be great.
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 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.
It kind of makes sense.
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.
Well, Kabir, thank you so much for joining me today.
Was anything else you wanted to mention before we
I, I think, I think that's about it.
Okay.
where could people find you online?
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.
And we'll put links in the show notes.
Of course.
Yeah.
And, you can also check out my website at ro vi.com.
Has not been updated since 2019, but have links in that
It never, it never quarantined.
Wow.
Well thank you so much, Kabir, for coming on.
and congratulations to your, your degree.
This is awesome.
thank you so much for having me.
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 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 and and subscribe as well.
Thank you for joining me, and I look forward to talking to you again.
Bye everybody.