Deconstructing Xcode with xTool with Kabir Oberai

Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
(00:00):
Hey, thank you for joining mefor today's episode with Kabir.
Before we begin, I wantedto let you know what's new.
Couple of things.
I released a new libraryto write Swift code.
So if you're somebody who's interestedin making mac macros or any sort
of dynamic code in Swift, you'lldefinitely wanna check out Syntax Kit.

(00:20):
The link to that will be in theshow notes you should consider.
Subscribing to the newsletter'cause that's free.
But you should alsoconsider being a Patreon.
It's like three bucks right now per month.
We already have the next episodeposted on Patreon with Rachel Brindle,
where we talk about Swift testing.
So if you want early access to thenext episode, you'll definitely

(00:42):
want to make sure you join thePatreon, patreon.com/bright digit.
And that's about it.
I hope you enjoy today's episode.
Welcome to anotherepisode of Empower Apps.
I'm your host, Leo dm. TodayI'm joined by Kabir Oberai.
Kabir Thank you so muchfor coming on the show.

(01:03):
Thank you for having me.
it's been a few excitingweeks 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 yougo ahead and introduce yourself.

(01:24):
Sorry.
So I am, or I was a studentat the University of Waloo.
And I, you know, I just graduated, witha 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.

(01:45):
just 'cause I wanted to makeapps, iOS apps seemed pretty cool.
And then I learned objective C and ayear later, Swift came out and I was
like, what did I do all of this for?
But, you know, it was pretty I'mglad I learned objective C and, I'm
glad that Swift came out as well.
And.
You know, I was A-W-W-D-C scholarin 2017 and I've developed some fun

(02:10):
projects over the years, which Ithink we will be talking about soon.
one other thing worthmentioning is I I've been in the
workforce in and out for a bit.
I was previously attexts.com, which is a startup.
I, we got acquired by Automatic, theguys behind WordPress and Tumblr.

(02:33):
And, then more recently I joined rampwhich is a FinTech based in New York.
Okay.
Awesome.
well, congratulations.
We're gonna talk about what cameoutta WWDC and stuff like that.
But we're also gonna talk about alittle tool you've, made called xTool.
Before we get into xTool, let it,let's jump back and do talk about wwdc.

(02:56):
What were some things that youwere particularly interested
in or what were things that youwere fascinated by, I guess.
That was a bit, that was quite a bit.
I think, you know, elephant inthe room, the liquid glass stuff
is, definitely very nice to see.
I love the luminess.

(03:18):
I, I love all the, you know, the.
The move towards sortof skim to an extent?
it's, yeah, it, it does definitely likemake designing harder in my opinion.
'Cause you know, I. There was thissweet spot of a few yours where you
could just like whiteboard anythingand like drop it in Figma and you'd

(03:42):
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 UIis also, pretty good approach to take.
I'm excited by I'm pretty excited bythe foundation model stuff as well.
You had a chance toplay around with it yet?

(04:04):
not exactly, so I actually, I was pokingaround 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?

(04:24):
Okay.
So that's when I pokedaround with it actually.
I think it was entitlementgated at that point.
Like I don't think itwas 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 tosomething interesting in 26.

(04:48):
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 isalso an interesting change.
It's definitely nice.
I can't wait to see, I mean, I'm.
The mess that's going to be createdwith the minor versioning though.

(05:09):
'cause like, you know, you've solvedthe, the major versioning, but,
What do you think they're gonnado with the minor versioning?
I mean, I would just assume thatwe'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?

(05:32):
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 togo with the calver approach, then
just like go all in, you know?
Yeah, yeah.
Yeah.
Actually it would be, 'causelike they do pretty much release
26.1 in January, more or less so.

(05:53):
It would kinda line up,
That's true.
That's true.
And you know, the way that they talkabout releases usually is like if you
look at some of the Swift internalsources, 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

(06:13):
not till late.
Yeah.
Cool.
So let's talk about xTool.
For those who don't know, I'll let yougo ahead and explain exactly what it is.
At the moment the main way to developiOS apps or apps for Apple platforms is
with Xcode, which is Apple's, IDE, and.

(06:37):
You know, there's, there's a lot ofbenefits to Xcode of course, and you
get your nice end-to-end verticalintegration across Apple Stack.
but there are issues with it, right?
And, you know, anytime you havea bug, it's not open source.
It's hard to fix any of that stuff.
And sometimes you just need somethingmore lightweight or sometimes

(06:57):
you want to use do developmenton other platforms than macOS.
And.
This is a problem thatxTool aims to solve.
And, in essence, xTool is are-implementation of a lot of what
Xcode does in a way that's fully opensource and works across platforms,

(07:19):
which means you can build iOS appson macOS, windows with Ws and Linux.
Can you build anything in theApple pla, any Apple platform?
So the foundations forthat are all in place.
At the moment I am like thebuilding step is primarily geared

(07:39):
towards iOS stuff, but we actuallydo build the macOS SDK as well.
And it, I don't think it wouldbe a stretch for us to support
building like Vision Os and,
If you have the SDK, that'swhat you need, right?
Exactly.
It's the bit that isn't done yet for,like macOS for example, is the macOS

(08:00):
app bundle structure is slightlydifferent 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 buildfor the simulator with xTool, which

(08:21):
is especially useful when you aredeveloping with xTool on macOS.
So what are some things that youhad to learn to get this going?
What are some fundamentalsfor getting Xcode working or
I guess the bill tools working
Yeah,
in another os.
I think, this really, really pushedmy, like, the extent of my knowledge

(08:46):
on iOS and also like, it's been anamazing learning experience for me.
So a little bit of historic context hereactually is, this started off as a project
that I started building in around 2017.
so, i, I was, you know, a, apart of the jailbreak community.

(09:09):
and in the jailbreak community wehad this build system called Theos.
And this was the build system thatallows you to build jailbreak tweaks.
Amongst other things.
And it was completely detached from Xcode.
It was based around GNU make which ifyou've ever used make you can imagine
is an absolute nightmare to deal with.

(09:32):
But the crux of it is somehow through alot of clue and, you know, batch work.
This build system supported buildingiOS 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

(09:53):
signing that you do with actual normaliOS apps that we weren't doing there.
So long story short, I eventually becameone of the core maintainers of Theos.
And I learned a lot abouthow the plumbing works.
I added Swift support to it.
I added a bunch of other things to it.
And then I. The one questionthat kept sort of ringing in the

(10:14):
back of my head was, why is thisnot accessible to more people?
You know, why, why is it thatonly people in the JFA community
have the fortune of being able todevelop iOS apps on any platform?
And around the same time I wasworking on this other project called
supercharge, which was basicallydesigned around side loading.

(10:37):
So being able to install iOS appswithout 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 itbecause I was just a bit worried about,
you know, legal factors and other things.

(10:59):
is, that is a consideration.
Yes.
it definitely is.
But, I learned a lot from superchargeas well, including, and, and I.
I developed a lot of code there that wasable to interact with Apple's developer
services and take any app and sign it, youknow, provision it, get those certificates

(11:19):
and profiles and all of those thingsthat you need, and then sign it and
then also install it onto your device.
And, some of the things I had tolearn along the way there, besides the
interacting with the developer APIs waslike to actually set to install it onto
your device, we had to emulate the sameprotocol that Xcode uses when you hit
Command R and you install over wifi.

(11:42):
So yeah, lots of, you know,lots of learning there for sure.
And, anyway.
Eventually I realized I hadthese two pieces that were great.
You know, you had this Theos thingthat was able to build iOS apps but not
install them onto a J non J broken device.
And then you had this superchargething that was able to.

(12:02):
Sign apps and installthem onto any device.
And I was like, I could take my learningsfrom here and I could take some of
the code from here even and sort ofcombine it into this one project.
The third piece and the finalpiece that really fit in place was
when Swift improved their supportfor cross compilation with Swift
Package Manager, Swift SDK support.

(12:25):
So this is something that didn't reallyland into Swift six one or six two even.
I was gonna ask.
Yeah.
It was just like last year basicallywhere, you know, this w of a dc in
fact, they, they made a big show ofhow you can now build web assembly
apps natively with Swift, right?
Even Android apps for that matter issomething you can build with Swift now.

(12:45):
And,
done an episode on.
Oh, you have, that's awesome.
But yeah, you know, so like all of thosepieces 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 iOSapps with Swift Package Manager.

(13:09):
And yeah.
So, you know, just combine all of thosepieces and you get this end-to-end
solution that can build, provision, signand install an iOS app from any platform.
So one of the things I think you mentionedwas that there was like an open source.
They had open source part of the build,Swift build, how it works with Xcode.

(13:32):
Is that correct or am I missing something?
So Swift Build actually came alongfairly late in this whole process.
And it's, it's confusing 'cause there'sSwift 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.

(13:53):
And yeah, that, that has beenopen sourced fairly recently.
I actually built all of this waybefore Swift Build came around.
I. But I am looking into usingSwift build to streamline most of
this build process, and it's gonnahave a huge impact here for sure.
At some point.
It's actually like Swift Package Manageris currently working on integrating

(14:14):
Swift Build as their native build system.
And once that happens I am.
We are gonna have somebenefits from that immediately.
And then, you know, we are also gonna beable 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 betweenSwift Space build and Swift Build?

(14:37):
Swift space build is Swiftpackage managers build command.
Right?
And until last year it was entirely like.
Custom.
it did its own, you know, coordinationwith the underlying Swift compiler.
in fact, it now uses Swiftdashboard under the hood,

(15:01):
For starting with Swift 6.1,
Six two.
And I say it uses it, but that's withan asterisk where it's an option that
you can provide to make it use it.
That's good
Yeah, so you can actually like testit out now, but I think, it's probably
not going to be stable until I, Idon't know after this timelines here,

(15:25):
Right, right.
yeah.
It's funny you were mentioning,jailbreaking and stuff because I
recently read an article about theHack OSH community and how they're
kind of, now that we know, tahoe 26will be the last Intel supported Mac.
They're pretty much shutting down nowbecause that was a big opening was

(15:48):
to be able to build for Intel, right.
And do it on Intel.
So it's funny you'reimagining now we can do.
Build on Linux and Windows as well.
To me, like what really attractsme to xTool is the CI option.
If anybody knows it's cheaper to run aLinux vm, than it is to run a Mac vm.

(16:10):
And so being able to do that wouldbe absolutely, you know, fantastic
for the community just to getthe builds going and running.
I just wanna interject that realquick 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 isactually legal rather than technical.

(16:34):
Now that xTool exists, that isn't anytechnical 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

(16:58):
Windows, we support macOS.
But as far as the licenseagreement goes, it does say you
should be using Apple hardware.
So like, I've been using itwithin 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'mvery excited about with this dub.

(17:19):
But, you know, I've beenusing it in a VM as well.
There's like, the rest of it is kindof open to legal interpretation.
I'm not a lawyer yeah.
but it's very interesting andI have actually, I do actually
know that it is possible to usethis on CI on a Linux CI machine.

(17:41):
just gotta figure out whetherit, the law allows it.
right, right.
Exactly.
Exactly.
So how, what's the difference?
What goes into building an app, asopposed to like building a Swift
package where you just compile Swift?
What are the components of building anapp that are required or that you learned

(18:03):
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, youcan 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 macOSexecutable and you like declare your

(18:28):
main thing to be an app, like the appprotocol, you can build a macOS app.
You, you can turn any plainexecutable into a macOS app.
Yeah, so, so like the bare minimumthere is actually very little, like
you just, you know, need to importSwift ui or UI kit or app kit.

(18:49):
And then Mark the, either your appDelicate or your app protocol with admin.
The, the, the.
Bit that really matters afterthat is the bundling bit.
So once you have an executableyou can run it on macOS and you
can distribute a plain executable.
But that doesn't work on iOS, of course.

(19:11):
On iOS or if you wanna doanything fancy on macOS, right?
What you need is this bundle.
And if you, if you look@any.app underthe 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 fewdirectories inside it, and then
one of those files inside it isthat executable that you built.

(19:34):
Right.
and then the other things that are thereare, you have an info P list, which you.
Most people have seen as well is justlike, 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,

(19:57):
which is very easy to do.
On iOS you need to have like a validcode signature, which basically proves
that you are a specific developerand proves that Apple has given you
permission to run this app on your device.
So when you run an app and you runinto signing errors or you see that

(20:20):
your app is trying to be provisionedor like is generating certificates
or, you know, whatnot that's kind ofwhat's going on under the hood there.
So, in essence, The steps hereare basically you build your main
executable, and this can be donewith, you know, Swift Package Manager.
You just need to have yourtarget with at main in it.

(20:42):
And then you need to bundle it in thisfolder with the info p list next to it.
And, the other thing you needthat is you need, to generate your
provisioning profile, which is thesort of permission slip from Apple that
says this app can run on this device.
And you sign your app and youinclude that provisioning profile.

(21:04):
And then you've got afully functioning iOS app.
In fact that's a.app.
And then you also often distributeapps on IOS's IPA files.
And IPA file is actuallyjust a.app, but then.
Compressed as a
Yeah, exactly.
That makes sense.
What are, just before we touch ondebugging and deployment, I do wanna

(21:26):
see was there anything else that caughtyour interest, that you thought was
interesting about the development processthat you didn't, that you learned about?
And in the process of making xTool.
I think, one of the othervery interesting things.
Is that, the app storeconnect API is a gem.

(21:48):
And I found it
You mean not related to Ruby?
You just mean it's, youreally 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 dida talk about this about the sort
of roots of this project twoyears ago at this, at Swift do.

(22:13):
Okay.
and, that so that talk was justabout like, here's the rudimentary
things that we're working on.
Here's a sneak peek into the future.
It was a talk about iOSdevelopment or, or just like.
The life of Swift outside of Xcode,which included cross-platform things.
It's amazing to see how thingshave matured over these two years.

(22:34):
Also like, you know, some thingsare still holding us back, but,
you know, there's, in, in generalthere's a lot of progress here.
But, you know, so, so like.
I actually did speak to Josh Holtz atthat, after that doc he was at Swift D
and he's the maintainer, the Fastlane.
And he was super excited about, everythingthat this could do for Fastlane.

(22:59):
So, you know, we have, wehave an open GitHub issue on
both xTool and on Fastlane.
To Jack this, and I haven't quite figuredout what this integration looks like yet.
And I haven't spoken to Josh aboutit recently, but, I would definitely
love for that to happen at some point.
It sounds like you're touching on some ofthe same stuff with signing and all that,

(23:22):
In fact, like there were a lot oftimes that I had like bugs that
I was trying to solve and I wouldjust 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 tomention was the way, so when I got started
using xTool, there was a specific way.

(23:43):
The project was set up.
You don't have like an Xcode project.
And explain how that works exactlyand 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 arestarting to realize that like expert
projects have a host of issues.
You know, like if you've ever had todeal with a merge conflict with an

(24:05):
Xcode project it's a nightmare, right?
You don't know what to do.
'Cause like it's all, the Xcodeproject is all XML and it's just a
blob of like autogenerated stuff.
so there's a lot of, there, there'sthis huge push that people are making
towards declarative package managementor declarative project management.
And there's some other great youknow, folks who are doing this.

(24:28):
If you've seen Xcode Genor if you've seen tourist.
Yes.
I actually had a really niceconversation with the tourist,
folks few weeks ago after ExTool.
And we've also been talking aboutvarious 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

(24:52):
be on the same page 'cause I'm startingto move all my projects to tourist.
Yeah.
Like that's, that's the dream, right?
Ideally it would be amazingif you could take it to its
project and just build it with x.
Yeah, exactly.
So yeah, the idea there is basicallylike, let's move away from having this
expert project this massive expertproject file as the source of truth

(25:14):
and use declarative package managementwith like the Swift project manifest.
That's very similar to package Swiftthat you use for Swift packages, right?
Kind of what you're adding on top ofyour package Swift is you're adding
instructions on what the app looks like.
Just for starters, you need abundle ID for it, and you need
to select a development team.

(25:36):
And then there's a few other thingsthere, like, different capabilities
your app might have, you know, likebackground modes, or like entitlements,
all of those things, right?
So as a matter of fact you mighthave noticed recently that even Apple
is moving in the same direction.
Where if you look at Swift Playgroundsthey actually did something very

(25:56):
similar where they have this librarycalled Apple Product Types, and you can
declare within your Swift package ordot iOS app, using Swift Playgrounds.
You know, I realized that this was thedirection we were moving and this was
the best direction to take xTool as well.
For starters, at the moment, youhave this, so, so an xTool project

(26:20):
is basically a package Swift, youknow, it's a General Swift package.
And then the only thing you addto it is this xTool, YAML file.
And this just all you needto begin with is a bundle id.
And, you know, when you run Xto Dev, it figures out the rest.
It takes your package, it triesto scan it for the iOS app target

(26:42):
that it thinks will be the Rootapp project, the root app target.
It'll build it for you and then it'llpackage it based on what you've given you,
what you've given in, in the xTool Y file.
How about things like the producttype and things like that?
That would just be donein the Swift package.
So when you say producttype, do you mean like ex app

(27:03):
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 toget outta the package at Swift.
For example, like if you wanna selectlike a deployment target that is
actually you, you just use the platform'sfield in package Swift it's, you

(27:25):
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, youcan't quite do in Packet Swift.
So like product types, right?
There's no way to declare an likea keyboard extension or a share
extension inside of a Swift package.
and app extensions are one of the areasthat we're actively working on right now.

(27:47):
There was actually someone fromthe community who contributed a PI
for this, which is amazing to see.
You know, this is just a few weeksinto Swift, into being released.
And someone built out.
All of app extension support for us.
And I've been working with themon polishing that up and planning.
I'm planning to land that soon.
But, yeah, this was, this is somethingthat you add to your xTool YAML

(28:10):
file where you say, here is the.
Swift package product thatcorresponds to your main app.
And here are the Swift packageproducts that correspond to
different app extensions.
And that's basically allyou 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 productsand then better them for you.

(28:32):
Okay.
And then what did yousay about what platforms?
Does it just use deploymenttarget 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 itjust assumes iOS by default.
Like iPhoneOS SDK if you wanna buildfor the simulator, there's just a.

(28:57):
Dash simulator flat that you pass.
And, I realized that's designing meinto a corner when it comes to other
simulator types or other platform types.
But, you know, right nowwe'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.

(29:20):
You can, we'll probably justadd a flag that you can pass in.
that makes sense.
One of the things that is reallycool is so not only do you
support not only do you support.
Simulator, but you can build on deviceand deploy on device and debug on device,
and it uses, remind me what the name ofthe tool is that you have to install.

(29:44):
So, there's a tool called Lib iMobile
Yeah, so explain how like thewhole 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 prefacethat debugging in particular
is one of the trickier areas.
There's actually been some majorchanges to Apple's debugging stack

(30:05):
over the last one or two years.
So as if iOS 17 it.
Is something that doesn'twork with xTool, but you can
install apps, onto your device.
And before that up until I was16, it's really possible to
launch and debug apps as well.
And again, this is something that we'reworking on, it's that there's other

(30:25):
third party tools that have solved this.
But to come back to, you know, thecrux of this, which is how do we
do installation in the first place?
Again, a huge part of this isbasically emulating, what Xcode does.
And when you connect your devicevia USB it actually opens up
a port on your iOS device.
That makes
and, it creates like this tunnel.

(30:48):
And it basically talks toit over, you know, dCP.
So there's this protocol called,lockdown D and the way the lockdown
D works is you send over from yourMac, you basically connect to this
particular port on your device, andyou send over this buddy, which is.

(31:09):
You ask it to open a service,and there's a list of services
that, lockdown d supports.
For example, there's a servicecalled apple File Conduit A FC and
that allows you to transfer filesbetween your Mac and your phone.
So, you know, we first open upan Apple file conduit service.

(31:30):
We transferred over the, IPA file.
there's another servicecalled Installation Proxy.
We open that up and then wepoint it to the file that we
install, that we just transferredover, and we say, install this.
And, that in, in the gist of it is.
Basically what we do, there'sa lot of other work that of
course, in terms of pairing.

(31:50):
You know, there's likepairing is all SSL stuff.
But, A lot of this work ishandled by Lib I mobile device.
And in fact, if you have a Linux machineand, you ever connect your phone, your
iPhone, to a Linux machine and yousee like your phone pop up on that,
the reason that your Linux machine cantalk to your iPhone is because Lib I

(32:12):
Mobile device is installed by default.
Right.
Okay.
so it's one of the, it is a very wellmaintained 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 whatdo you use or Swift or what
So Lib iMobile device, and some ofthe dependencies that we have are

(32:35):
written in C but, all of, xTool itselfis written in Swift, in fact, yeah.
So it's like pure Swift and likea little bit of like c to bridge
between some of these things.
How has the bridgingbeen between C and Swift?
And is anything with like Xcodesix two help or Xcode six two

(32:58):
Swift 6.2, has that helped at all?
do you mean the c plus ended up,
Yeah, sorry, c plus and thefact that we now have in was it
inline array and span and stuff?
Oh, right.
I haven't used any of the newstuff, the inline and span stuff.
'cause we're still trying tosupport six one and six zero.
For like building, but Iam very excited about that.

(33:21):
The bridging in general hasbeen pretty nice actually.
As part of ex two, the way that wetalked it, the way that we interact
with Lib iMobile device is I built thislibrary called Swifty Mobile device.
And it's basically just a Swiftapple around lib I mobile device.
And you know, we have like someactors in there to allow for
like nice skin currency stuff.

(33:43):
I think, one of the biggest nightmaresfor us, for me was really like when,
Swift six came about and then Swift likehad the whole strict concurrency mode.
And just dealing with concurrency errors.
And all of the trash that's come aroundwith, you know, like every single release.

(34:03):
Having new concurrency errors todeal with has been a bit difficult,
but, I have actually fixed some.
Completely valid raceconditions because of it.
So I will say it, it's like you gottaeat your medicine to an extent that,
that a ways the medicine could havebeen made nicer, but I think they're
moving in the right direction now.

(34:24):
And with bridging in general, x ft.Mobile device was also treat to work on.
fact, I released, I shared Swiftymobile device with some folks a
while ago, and I believe at themoment it's currently used with, if
you've seen, Gui Rambo's AirBuddy.
so that uses Swifty mobiledevice under the hood, or it

(34:45):
used to for a bit at least.
And another really nice toolcalled re incubate camo.
And, That is something that'sexisted for a few years and
is, in fact, it was featured byApple 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.

(35:06):
And Bridging has beenvery nice to work with.
So two things.
One, have you ever, would there everbe a way to remote as, as a developer
of a VM app, I should say bushel?
would there ever be a way to com doremote debugging from Mac to Mac?
Jim Mcac.
We should talk about this offline then,that's something I would love to have.

(35:29):
And secondly
I don't have an answer foryou immediately on the Mac to
Immediately, okay.
Okay.
Did you ever try debuggingon 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.

(35:50):
I believe so.
It's possible.
I.
Yeah, it's possible, but isit 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 thatthere's so many, you know, so
many requests that are open.
There's currently like fivedifferent fis that are open, and

(36:12):
I think we have, I. We, we touchedupon some of my future plans here.
You know, one of them isdefinitely to figure out the
right way to go about CI support.
'cause yeah, I mean, in an idealworld, you could just take any iOS
app and, switch your Mac Runnerfor Linux and just have it work.
But, you know, more than that, i,I would also I'm just very excited

(36:35):
about the educational opportunities.
And that was really like why Icreated xTool to begin with was
like all of us.
yes, you know, so many people likehave, the tools to work with to
build iOS apps and this graduallylower the value for them, right?
And, you know, a big part of thatwould definitely be if we supported

(36:58):
export project to, to a conversion.
So that's something again, talkingto 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 extensionsare 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

(37:20):
limitations, is support from macros.
So at the moment, One of the fewthings that doesn't work is some of
the proprietary macros, like, someof the Swift UI stuff, like at entry.
So I, I would say like at Observableworks fine because that's open source and
it's compiled into the LinuxTool chain.

(37:40):
But yeah, some of these macros don't,so I'm, I'm working on liability.
Yeah, so I'm working on a librarythat re-implement like, at entry
and at, at Animatable or whateverthe new Swift UI macros are.
So that's, that's one of thethings that is coming up.
And yeah, just in general, youknow, like having community

(38:02):
contribution is always amazing.
So, I'm.
I always open to fi there.
There's a whole roadmap if you lookat the project section on xTool And,
you know, if anyone is interested incontributing that I always appreciate it.
One other big thing actuallyis, support for alternative.

(38:23):
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 isthe reason for that is that, a lot of

(38:44):
people in those communities are the oneswho currently build apps that they would
like to support iOS and they'd like totest with iOS, but they can't because
they don't have the tools to do it.
So yeah, you know, just, doing thatsort of thing would be super awesome.
Well, Kabir, thank you somuch for joining me today.
Was anything else youwanted to mention before we

(39:05):
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 ofmy other socials are just by name.
And we'll put links in the show notes.
Of course.
Yeah.
And, you can also check outmy website at ro vi.com.

(39:30):
Has not been updated since2019, 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 brightdigit.com is my company's website.

(39:52):
And I'm on social media, Leo g Dion, checkall 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 Patreonsfor supporting this program.
And if you have an idea about somethingyou wanna talk about on the show,

(40:13):
please reach out to me and let me know.
And if you're listening to thison a podcast player, of course,
please and and subscribe as well.
Thank you for joining me, and I lookforward to talking to you again.
Bye everybody.

All Episodes

Episode Transcript

Popular Podcasts

United States of Kennedy

Stuff You Should Know

Dateline NBC

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

.css-14f5ked{margin:0;word-break:break-word;display:-webkit-box;-webkit-box-orient:vertical;box-orient:vertical;-webkit-line-clamp:2;overflow:hidden;}Deconstructing Xcode with xTool with Kabir Oberai