Jed Bartausky:

Hey friends, it's Jed. Most of you know me as the assistant editor slash announcer guy for React Native Radio, but today I'm coming to you as Director of Operations. That's my day job here at Infinite Red. We're dropping a quick message to all of our listeners to say we're hiring. Now. I get to work with some amazing developers here, but the problem right now is Jamon keeps sending me projects and I'm running out of developers to put on them. I've tried cloning Mazen, it didn't work out well. So now we're here. Infinite Red is looking for Senior React native developers in the us and if that's you, take advantage of this rare opportunity and head over to Careers Infinite Red to apply. Thanks for listening. Now back to your regularly scheduled programming.

Jed Bartausky:

Welcome back to another episode of the React Native Radio Podcast, episode 3 34. React native Mac Os with sod, Najmi, me

Jamon Holmgren:

Mazen. And Robin, when did you first use a Mac Macintosh computer? A Mac of some sort. A lot of people didn't grow up with Macs actually, did

Robin Heinze:

You? Well, I actually did grow up with Macs.

Jamon Holmgren:

Okay. I was going to ask Robin, you seem like the type that would've grown up with a Mac.

Robin Heinze:

I mean, my brother, who was one of the co-founders of Vnt Red was a computer nerd from the eighties. And so my family always had Macintosh's growing up,

Jamon Holmgren:

Including

Robin Heinze:

A power pc, which is what it was like the family computer that I used in middle school. But then I moved to Windows for a very brief period of my life because I got my own computer in my room. I got a hand me down laptop for my brother or something, and then my dad bought me an old used Windows 98 computer, and that was the computer I used in high school was like I did a OL instant messaging and all that stuff on Windows. So there was this period of time where I was a Windows user and then I got a MacBook for college and then I was back as a Mac user until I went to the corporate world and then had to use Windows for a while. But now I'm Mac always all the time.

Jamon Holmgren:

When you worked for Dunder Mifflin, right,

Robin Heinze:

When I worked for Dunder Mifflin, the paper company and I had to use Windows, unfortunately

Jamon Holmgren:

Robin used to work for a paper company.

Robin Heinze:

I did work for a paper company. Yeah,

Mazen Chami:

That's pretty funny. How about you Maan? So growing up all throughout childhood, it was all Windows PCs up until, actually when I was 12, I worked at my cousin's computer shop where we built custom PCs for people and that was how I got into computers. But when I got to college, I built a custom Dell and kind of went through the website, got it all set up, and I was windows through and through up until 2009. So junior year right before finals, I was mad at I don't know what or who, so I threw my bag across the room and only to realize my laptop was in it shattered my screen. Oh no. Ran to the bookstore. They only had a Mac. I was like, sure, I guess I'll figure out how to use this. I need to write this

Robin Heinze:

Paper now. What arrow was this of Mac?

Mazen Chami:

I don't even remember. It was, it was the 2009. It was a thousand.

Jamon Holmgren:

The big MacBook Pros. It

Mazen Chami:

Was a huge one. Yeah, it

Jamon Holmgren:

Actually, I had

Mazen Chami:

To get a whole new sleeve. It didn't fit in the compartment from my bag Space Square. It was heavy. It was heavier than my Windows machine and I got the extended battery pack on my windows that Dell pc. Oddly enough, the bag kind just made it into my office. I have that PC sitting right next to me right now. Oh, that's funny. The one with the shattered screen. So anyways, after all that, I plug in the PC into my roommate's tv, finish out my paper, put it on a thumb drive, and then put it on this new Mac so I can take it to class and continue my paper and all that. So 2009 is when I got into Windows after I transferred that file over

Robin Heinze:

Into Mac. Into

Mazen Chami:

Mac, into Mac, sorry, into Mac. Once I transferred that thumb drive paper over to my Mac, I have not used a pc. And every time I see my brother's pc, I don't know how he uses it.

Robin Heinze:

I know I cry a little bit when I have to use my husband's computer. He's a gamer and also works in the corporate world. So he pretty much only uses Windows.

Mazen Chami:

I do miss the crazy sounds he used to make on booting.

Robin Heinze:

I know I When we're sitting here, spoiler alert, we're sitting here talking to someone who works at Microsoft.

Jamon Holmgren:

I know, that's the thing. Let's be a little bit nice. But the funny thing is Saad, I know that you use a Mac there, which is hilarious. Yes. So tell me your first Mac

Saad Najmi:

Story. Yeah, so I am pretty sure my first Mac was actually at Microsoft. That is irony of the highest degree.

Jamon Holmgren:

That's funny. So you used Windows before that?

Saad Najmi:

Yeah, I don't know. I feel like if you're in high school or in college, you just get the cheapest bang for Buck computer, which was usually not a MacBook. Also, I'm pretty sure I messed around with installing Arch Linux and all that stuff on my computer. There's one semester where we had 10 projects and every project I switched from Windows to Linux and I don't know how I lived that semester, but yeah, my first memory of using a Mac I think was actually my Microsoft internship and not the first one, but the second one where I ended up on the team that I'm at now and I'm like, oh, okay. We only do Apple development here. This is interesting. Not what expect people

Jamon Holmgren:

Don't realize this, but Microsoft has always been the biggest Mac developer outside of Apple by far. It's not even close.

Saad Najmi:

We didn't realize we were the biggest

Jamon Holmgren:

For software. What's

Saad Najmi:

That? I knew we were big, definitely top five. I didn't realize we were the biggest, but I totally believe that.

Jamon Holmgren:

I'm pretty sure you're the biggest software developer for Mac that as far as users, right? People using your software. There's

Robin Heinze:

People mean off of the office

Jamon Holmgren:

Products, we'll do that office and there was Skype and all this other stuff. So yeah, I think it's kind of funny because I mean all along there's sort of this Apple versus Microsoft thing, but Microsoft makes software for lots of different operating systems. So yeah,

Saad Najmi:

I think the Apple versus Microsoft thing, that might be true for operating systems, but office runs everywhere and we want it to run everywhere, so it has to be on everything. And so I do not feel the Apple versus Microsoft at all in my position. What I do, we work with without

Robin Heinze:

Lot. It's not like Nike versus Adidas where if you're caught wearing Adidas clothes at the Nike headquarters, they ask you to really, it's real problem. Yeah,

Jamon Holmgren:

Yeah. So I of course use, I'm old enough that we used Apple Twos in our computer lab in elementary school. We even had a Macintosh there I think in fifth grade we got a Macintosh that was a black and white thing. All I remember is playing a couple games on it, but it had the graphical user interface using a mouse, which I thought was ridiculous. Why wouldn't you just use a keyboard? And

Robin Heinze:

You still think that

Jamon Holmgren:

Mostly Actually I'm backsliding weirdly. I actually have two mice now. I have a track pad and a mouse that

Robin Heinze:

I use both. Same. I've got a track pad on the left and a mouse

Jamon Holmgren:

M Well, I got it from your brother. He told

Robin Heinze:

Me to do that try. I got it from my brother too. Like

Jamon Holmgren:

A track pad is magic. All I can,

Mazen Chami:

I don't blame you.

Jamon Holmgren:

Yeah,

Mazen Chami:

Wait, it is really good track pad and a mouse. Yes. Yeah,

Robin Heinze:

Yeah. I have a track pad for track paddy things and then I have a mouse for mouse things. Yeah, because the gestures on macOS are so useful. It's also, I only

Saad Najmi:

Use a track pad.

Robin Heinze:

Yeah,

Saad Najmi:

I mean that works too. I did that for a while, I'm pretty sure until I bought a gaming mouse and realized how good this is. But

Robin Heinze:

Yeah, the ergonomics prevent me from using the track bed for everything, get hand crampy if I'm trying to do a lot of micro stuff. But

Jamon Holmgren:

I used Windows computers for the most part. Well dos then Windows and just followed that along until one of my employees, Daniel Bur Compass actually was like, Hey, we should be using Max. They're really good for web development and things like that. And I'm like, really? And what sold me was he was like, yeah, they have basically a BSD core. And I didn't realize that. And I was like, oh, that's interesting. That's closer to our servers, which are Linux, that as a closer thing. And so I was like, oh, okay, that's interesting. And then I bought this Craigslist, MacBook Pro and then it died two weeks later. It had the problem where the GPUs, it was a 2008 or oh nine

Jed Bartausky:

Where

Jamon Holmgren:

The GPUs would unseat because of the heat and you could actually put the motherboard, or what do they call it, the logic board in the oven for 15 minutes and it would rese it and it worked. I did that and it worked for temperature. Wait,

Robin Heinze:

The actual oven in your house?

Jamon Holmgren:

It was like 3 75 for 10 minutes or something and it would just reset it. And I did that twice and then eventually I got really tired of it. I actually brought it into Apple Store and it was like, Hey, this thing is doing this thing. And they're like, well, they take it to the

Mazen Chami:

Break room in the back and pop in new. Have you been cooking it

Jamon Holmgren:

To reverse

Robin Heinze:

Xbox

Mazen Chami:

Bring of death,

Jamon Holmgren:

Right? Yeah. So they were like, no, this MacBook has a lot of issues. It has water damage, this has that. It's too old for us to do anything. But they treated me so well compared to any PC manufacturer I'd ever used that. I was like, okay, this is the company I want to go with. And I bought a brand new MacBook Air I think and haven't looked back. I actually do use Windows for gaming stuff. I use Mac of course for work and like you said, Saad. And I do want to bring this back to our episode here. Microsoft wants actually run things.

Robin Heinze:

We actually are doing a podcast here.

Jamon Holmgren:

We are doing a podcast, but I think that our podcast is probably going to be a little bit like this, but it's, Microsoft wants to run it everywhere and of course what's better for that than React native. But before we get into that, I do want to say this episode is sponsored by Infinite Red. Our company, infinite Red is a premier React native consultancy. We're located in the us we have about 30 people here, all senior level React native developers and a few support staff. We've been doing this for just about 10 years. So go to Infinite Red slash Radio and don't forget to mention that you heard about us through the React native of Radio Podcast. Saad, can you introduce yourself, what's your background and how did you land at Microsoft?

Saad Najmi:

My name is Saad nmi. I'm a software engineer at Microsoft. How did I get to Microsoft? I interviewed in college Career Fair and I had two internships with them, the second of which was for the Office on Apple team. And so I just kind of came back to that team. So I started out doing Native Macs development for my team. If you've ever used Microsoft Auto Update, which is this little app that updates your office apps, the UI for that was one of my first main projects. That was before we were on the app store. So now you can just download Office from the app

Robin Heinze:

Store, right?

Saad Najmi:

But yeah, so eventually at some point I realized that part of my team was working on React Native and I'm like, wait, what? How? And then they told me, yeah, we forked it from ACOs. I'm like, what really? And so that sounded pretty cool. Reorg later I ended up on a team that was doing open source UI frameworks for Office, which was what came out of that is Fluent UI Apple and Fluent UI React native fluent ui. Apple was mostly iOS controls, a mix of UI kit and Swift ui. And then Fluent Air React native is a bunch of React native controls mostly for Windows and Mac. So before I did actual React Native Mac development, I was using React Native Mac to write ui. And I think that's important because you'll meet people who work on a platform, but I've never used set platform to ship features, actually build an app.

So I'm pretty happy that I had that experience first. But as I gotten more and more into it, I was like, wait, I kind of just want to make things better in React Native Mac and not, I feel like there's a lot of opportunity here to make this library a lot more interesting. And so just as time went on, I kind of got more and more into that space. And so a couple of reorgs later, I'm one of the people who is the maintainers for React Native macOS. We're all very collaborative. We work with a lot of the React native Windows people. Yeah, so my full-time job is now working on reacting to fact, which is interesting, not what I thought I'd be doing at Microsoft when I joined, but I can't be happier.

Jamon Holmgren:

A lot of people get kind of, they're just a little bit surprised that Microsoft maintains that, but it makes a lot of sense. I mean, Microsoft relies very heavily on it. So my first question is, and I did a little poking around and also chatted with you a little bit about this, but I really want to know how React native Mac OS works because if you're looking at the source, you actually see a lot of UI kit APIs and the Mac OS version of that is actually AppKit and you should be seeing NS instead of UI everywhere. And NS of course, just a little tidbit stands for next step. It goes all the way back to Steve Jobs's next company way back in the nineties. But they folded that in when they made OS 10, which became Mac os. But UI kit was forked from that and is supposed to be for iOS. So how are you able to use Kit APIs in a Mac app?

Saad Najmi:

Yeah, so the short answer is a lot of if deaths, and then I'll explain why we went that way. As you said, AppKit is the older brother of UI kit. UI kit is the iOS framework that all of React native iOS is built off of. And a lot, most iOS apps are built off of, I don't know if it's mostly more now they have 50 I, which is their new thing. So UI kit takes a lot of its cues off of AppKit and it's kind of like where Apple learned how to do things better. So they'd have an API for, I dunno, making images and they're like this one thing was kind of not very ergonomic. So when they did it for iOS, they simplified the API or they added a feature. So the code looks very similar, but you still have NS image instead of UI image and they are subtle differences. And this is before my time I came into React Native Macs kind of after it was published and matured. So the decision to use if death was kind of already done,

Jamon Holmgren:

Can you explain what an if death is and what you mean by that?

Saad Najmi:

Yeah. Okay. So if deaf compiler looks at your code, turns it into binary, but before the compiler turns into code, you can do what are they called? Pre-con compiler macros.

Jamon Holmgren:

Yeah,

Saad Najmi:

So you can do like if

Jamon Holmgren:

Or compiler directive I guess is another. Yeah,

Saad Najmi:

You can do pound if target is iOS, let image equal UI image pound else, let UI image equal NS image or you can say pound define UI image Ns image. And then everywhere where you have the text UI image, it'll replace it with NS image one compiling for Mac.

Jamon Holmgren:

Yeah, it's like polyfill. That's how a JavaScript developer would think about it in some ways, right?

Saad Najmi:

I guess so since I started off as a native developer, I forget some of the JavaScript words are like, yeah, I guess that is a poly pill. I've never thought about it that way. I've always viewed it as text replacement because it's literally just changing the text. The compiler saves before it compiles your code.

Jamon Holmgren:

By the time it actually gets to the compiler part of it, it's not a UI image anymore, it's an NS image. But in your code you can write UI image and the benefit to that is you can have the same code for iOS and Mac, right? Generally

Saad Najmi:

Most of the same code. If the initializer for UI image takes three argument initializer NS image takes four, you still got to kind work around that and maybe make a helper function. And then the helper function has an if depth inside of it that calls one or the other based on the platform.

Jamon Holmgren:

Yeah,

Saad Najmi:

It would be great if these were not depths and these were all not involving replacing text for the compiler, but as

Jamon Holmgren:

Why is that? I'm really curious. Why would it be better to not have the IF depths,

Saad Najmi:

Okay, I kind of just feel like if depths are a little dirty, they feel like an old thing. They don't feel like a very new modern way of doing things, but are

Robin Heinze:

They particularly brittle? I think if you

Saad Najmi:

Have a lot of them, yeah.

Robin Heinze:

Yeah.

Mazen Chami:

Probably hard to follow the logic a little bit.

Saad Najmi:

Yeah,

Mazen Chami:

It gets muddied in that sense and you're not exactly sure you can't really follow it.

Saad Najmi:

Yeah, if you have one method, but then three if deaths inside of there, you just have to in your head block out, okay, if it's iOS, I ignore these parts of the code. If it's macros, I ignore these parts of the code. And invitation levels are kind of weird because you don't actually have to keep those consistent.

Jamon Holmgren:

Yeah, it makes the source just look a little weird. Sorry Saad, I have to stay on this for just a second because I know there are a lot of people who listen to this podcast who have never once written any native code that is wild. It's just JavaScript and just so that they can kind of understand what happens in JavaScript, especially with Metro and React native, here's a semi analog to what we're talking about. There is if under dev.

And so that right there is if you're bundling for development versus if you're bundling for production, what Metro will actually do is actually delete all the code that's inside of the IF dev block. And that means that you can put a bunch of code in there that would break or maybe just be slow if you're running in production that you don't want to run in production, but you need it for development. So not exactly the same thing, but in some ways it's similar because it's basically stripping all that stuff out before it compiles it into a bundle.

Mazen Chami:

And very similarly, we're kind of, we say this a lot, we're sping the React native sense, what SA just described is on the native layer, but before we even get there, we have file extensions. So web native

Metro strips those out before we even get down. That's another guard per se where you can say like, Hey, guard against, for example, I just did it on a project where we have web N native, but we know our API breaks on web because of the backend contract. So we have a web quote unquote polyfill that handles our fetcher going to web so that we can fix those network requests going through the web client. And that's just another way of guarding it on a higher level. And kind of like what you said, this is a cleaner way of doing it because the files are restricted, it's easier to read and understand what's happening versus when you get down to the native layer, just so many if or if depths kind of muddied all around that aren't tabbed. And I think we talk about all these tabs, we fight about tabs. When you get down to native and you don't have to worry about it, it changes the spectrum.

Saad Najmi:

And I think if you write code in Swift, they actually are a little bit better about the if depths where now they're actually in line and they do a little bit more type checking. But we did the IF depths because we want to be as close as possible to iOS React native exists in Facebook's repo. There's lots and lots of iOS engineers who will keep on writing iOS code and what's the best way to make sure that any new thing like new feature or bug fix that shows up in iOS code also shows up in macros. If we just wrote completely different files, let's say we forked the image component, which is RCT image. Cool, that fork lives in our repo, fast forward three versions, iOS adds, I dunno, 10 new props to image. We might not see that because when we do our GI merge, we had a different file, we don't really see what's happening in iOS. The if devs of mean that if the code gets updated, well now you have merge conflict, which is painful, but that's also right.

Robin Heinze:

It's painful, but it draws your attention. Yeah, yeah. It forces you to,

Saad Najmi:

It forces me to see all the changes that affect code that we might be around. And then in the merge we have to be like, okay, so they added this new prop accessibility language. Okay, is that also on macOS? Oh it is. Okay, so we can add an EF over here and then implement that or Oh, hey, this code actually just works because the letters and the code happen to be the same. Great, thank you Apple. It makes things slower, but it does force us to be as close to React native on iOS as possible, which I think is a better benefit. So that's kind of why we went with if devs, it was the best solution to our problem. There's other ways we could have done this and fabric makes it easier because a lot of code just moves to cross platform c plus plus. So there's less if depths to deal with. But yeah, that's how we use UI kit on MACIs by faking it with, if depths

Jamon Holmgren:

Kind of feel like the React native core could make your life a little easier by adding the IF DS and just having a placeholder for the Mac stuff where you have, if Ds the problem is there's a coordination problem there, making sure that everything is, as you make changes, then they'd have to make changes that don't even affect them. So yeah, that's tough.

Saad Najmi:

Yeah, so that's like this is a problem that has been talked about for many years of wouldn't it be nice if React native was just React native and Android and iOS were actually separate packages and then you just have this core that every platform implements. And I think actually with Fabric we're quite close to that because so much of the code has actually moved the cross platform c plus plus shadowed node layer that I am learning more and more about all the time. I thought I knew a lot about Fabric.

I went to a conference in Paris and then there were a couple of talk about fabric and I'm like, wow, I don't know any of that happened. So that was pretty cool. So yeah, if React Native Mac was owned by Facebook and in Facebook we wouldn't have that coordination problem. But because we're a separate company with our own release schedule and we're not every commit that goes into React native, it might take a month or two for us to get it to us. Coordination problem is really just, that's why we can't do that. Windows has the same problem and they don't have the benefit of forking all the Iowas code. They just have to go reimplement everything themselves. So I think out of three platforms, we'll just kind of have to always do it somewhat separately. Fabric does make it better, but yeah, it's ultimately a coordination problem.

Mazen Chami:

When looking at the docs, I noticed that a bunch of props that we would see the React native dev docs within the API of different components and whatnot are missing. And you kind of touched on that where it's probably because it's not available on Mac OS yet and you all are just trying to make sure to pipe it. I guess my main question here is your objective at the end of the day to come to full API parody with iOS and Android for React native, or is that not a feasible goal at the end of the day?

Saad Najmi:

So this is where I think Windows has recently done a better job than us, which is actually documenting which props work and don't work. The goal is to be as close to iOS as possible, which by extensions means being as close to Android as possible. I don't think we ever actually went and documented which props work and which ones don't. Outside of the TypeScript types, if somebody asks me, does this thing work on React native macOS, I usually just say, if it works on iOS, then it should, and if it doesn't, that's a bug, please open an issue and I'll look into it. That's

Jamon Holmgren:

Good to know.

Saad Najmi:

Yeah, there are some Iowa specific things that we probably don't want on React Native Mac plus. I can't think of one off the top of my head, but pull to refresh for scroll view, there is no pull to refresh for scroll views on desktop. That's mostly a mobile only thing. So everywhere there's a set to pull to refresh view components, I just if that out because there is nothing for me to do there

Mazen Chami:

Totally makes sense. And even something I don't think we really think about this much, but when you're looking at a Mac OS specific app, there's not navigation per se. You're not navigating swiping in and out screens. You might have the side tab, but all that side tab is just doing is just probably mounting a new view per se on the right hand panel because it's not really a navigation stack is what I'm trying to get at. So understanding the different differences in is also very important to that point.

Saad Najmi:

It's actually really interesting that you brought that up. I try to keep tabs on what are the big libraries that most people use, react navigation and React Native screens are obviously one of them. I've looked into either we should board React native screens to Mac Os or if that's already being done, I once and opened an issue and talked to the people who maintained React native screens, and I think they basically said, yeah, we looked into it, but there isn't really a navigation stack on Macas, so there's not really anything for us to port. So we can maybe make a minimal JS version where you don't need to write native code and you get your stack. But yeah, react native screen specifically is one where we thought about porting it to macOS and ultimately decided not to because it doesn't really make sense, which still kind of confuses me, but yeah, that's desktop versus mobile. Yeah, exactly.

Robin Heinze:

Speaking of libraries and their compatibility with Mac os, I mean people talk about the third party library support for Mac OS is lags pretty significantly behind obviously the main tree platforms, iOS, nand, Android, but also React native Windows just looking at the directory has 60 packages that have support for it and TV OS has 80 and then Mac has 33 or something like that. What's behind that? Is it an actual technical hurdle that it's harder to make these packages compatible? Is it like you said, just platform differences, things that just don't apply to macOS or is it just a demand issue? There's not people demanding these features for macOS.

Saad Najmi:

So the first thing I thought of when you said that was I should probably go through the directory and

Robin Heinze:

See if there's any more that need to just have the metadata updated.

Saad Najmi:

Yeah, because I would think that it's easier to add Mac support to a library than Windows support. So if there are actually more

Robin Heinze:

Yeah, I would think that too, honestly.

Saad Najmi:

Yeah, so I'm going to have to go look into that. That's kind of a surprise to me. I thought it'd be like the other way around,

Robin Heinze:

But like you said, it could just be a metadata issue. All open source

Saad Najmi:

Library

Robin Heinze:

Authors update their own stuff. So

Saad Najmi:

Yeah, last I checked through React native directory is like a giant JSON file, which was interesting. It is, yeah. But okay, so to add macros support to your library, if it's just a JS library, you probably don't need to do anything. If you've got native code, then you basically have to do two three things. One, update your pod spec to have Mac OS as one of the platforms. Two, go and update your code with if devs or add a separate Mac implementation. And then three go add a test app to your library so that you can test library in macOS. We have the library React native test app for doing that. I super love that library because it does kind of the whole continuous native generation thing for you so that you don't have to know how to make a macOS test app. You just have to add a pot file and it generates the MAC test app for you. So I've gone and updated a couple of libraries to have both Mac and Visionist apart because there's a whole era where we had to go get visionist working, but the process is actually not too bad. I would think that if Dev would be annoying and pretty hard, but there's a couple of libraries that once added, Mac will support themselves, namely there's reanimated, there's React, react Native SVG. We actually did that and WebView

Jamon Holmgren:

WebView,

Saad Najmi:

I don't remember if we did WebView or if it was already there, but most of that code is also just cross platform, so it's fine. I would've thought that more people would complain about, oh, I need to maintain all this macros code, but that's actually not the complaint that I've seen. The complaint has been more, Hey, macOS is one version behind, so I can't update the library. And so the thing that I've taken from that is to keep community libraries happy is I need to make sure that React native to Mac is more up to date, but the process of adding macco supports was actually not that bad.

Robin Heinze:

So there's probably a lot of libraries out there that don't support it that could very easily support it or maybe already support it and they just don't know because they've never tried.

Saad Najmi:

And I think it's mostly a demand thing. If somebody wants to use library and they find one, but it's only an iOS, if they file an issue on React Data Macs, I'll go tell them to file an issue on the actual library. But it's also good for me to know, hey, there is a library you want so that I know which libraries people are using. So maybe do both. I'm not really sure.

Robin Heinze:

Yeah, it's unfortunately a bit of a chicken and egg thing that starts to happen. People are like, oh, well there's not enough libraries supporting macOS. I was like, well, if more people were using macOS, there'd be more reason for these library authors too, add support for it.

Saad Najmi:

But I think a lot of the big ones are there. We have Gesture Handler, we have your animated Ski and web GPU both got macOS support recently,

Robin Heinze:

Right? Looking through the list of macOS ones, they're very much like the core packages,

Jamon Holmgren:

The big ones

Robin Heinze:

That you think of when you do reacting to development, which is awesome. It's the other 1300 random libraries that you probably don't need. And even if you do, it probably wouldn't actually be that hard to add macco support if you did need them.

Saad Najmi:

If there's library that people want macco support for, even if I don't have the bandwidth to go implement it, I'd love to know what those are. So I guess just go tell me on GitHub or Twitter or whatever. Should I be soliciting for lots of Twitter DM requests? Maybe not. I dunno. GI

Robin Heinze:

Issue about how about this? You all tell us. Yeah,

Jamon Holmgren:

We can

Robin Heinze:

Tell us in our community Slack or on Twitter and we'll triage and we'll tell that.

Jamon Holmgren:

So a couple of years ago I started to build this Mac app and I actually just ran with Mac Catalyst, which Mac Catalyst is where you literally build it for iOS and then the operating system actually has this compatibility layer of Mac catalyst and experience was pretty good actually. I felt like it actually went pretty well. Have you played around with Catalyst? Do you see what are the trade-offs there?

Saad Najmi:

Yeah, so Catalyst is super interesting. I think before talking about React Native with Mac Catalyst, I'll just talk about Mac Catalyst in general. So UI can not a difference. Most people are using UI kit. Apple is like how do we get more iOS developers to make Mac apps? So one made 50 y, which is their new thing that works on both, but they also went and made this thing called Mac Catalyst, which is effectively a new platform in the eyes of Xcode I guess. But it's basically just take your iOS app, all of its code and you can compile it for Macs and then you have a Mac app. The way they pitch it is bring your iPad app to desktop because iPad is at least closer to the screen resolution and everything. If you go and use some of the system tools like DY LD Info, you can kind of figure out if a system app is Mac Catalyst or Mac Os. And to my surprise, a bunch of the system apps are actually Mac Catalyst, the messages app is Mac Catalyst. Really? And that really surprised me. I was like, oh, maybe this is just a thing for developers to not need to write two apps, but Apple doesn't use it. But no, no, they use it too.

Jamon Holmgren:

They use it. Wow.

Saad Najmi:

So every person who has a MacBook is probably using a Mac Catalyst app at some point.

Jamon Holmgren:

Are there per performance implications?

Saad Najmi:

I haven't played around much with Mac Catalyst for one big reason, which is your entire app has to be Mac Catalyst and we mostly use React Native Mac in our big existing Mac app that is

Jamon Holmgren:

Like a Brownfield. Yeah, that makes

Saad Najmi:

Sense. Okay. So one React, native Mac predates Mac Catalyst, but two, even if it didn't, we'd still have to make React Native Mac because we're not rewriting all office in Mac Catalyst, we're taking the Mac app, we're adding a task pane or a floating window and floating React native in there. And you just can't do that with Catalyst. There's no way to embed a Catalyst instance inside your Mac app.

Jamon Holmgren:

Yeah, okay. That makes sense. So that's kind of the trade off. If you start from scratch, it's a viable solution and there may be, I don't know, I didn't get very far with that Mac app, so I don't know what all of the trade-offs that are right there, but yeah, that makes a lot of sense.

Saad Najmi:

It's also how much you care about if you don't want to write any code to take your iPad up to Mac and just have it work, it works. They all feel a bit like DPI. The DPI just feels a little bit off and I don't, this is weird because the Maca system apps feel great, but then I'll download, I have a calorie tracking app that is also on Mac Catalyst and I'll look at it, I'm like, yeah, this just feels a little bit off. I'm not really sure what it is, but I don't care because now I can do a thing on my Mac that couldn't do otherwise. Yeah, fair. There are a couple of Mac Catalyst apps I use that are fine and then there's at least one React native Mac Catalyst app that downloaded to see, oh, how does this feel? And it felt fine. It was interesting. So I think they're both options. It's kind of just do you want to be more desktop focused or do you want to just take your app that you already wrote and add a new platform for not much effort.

Mazen Chami:

Yeah. Awesome. I think we're getting towards the end of the episode, but I wanted to ask you last question as we're wrapping up here. In your opinion, what do you think React native Mac OS does well that people might not know about or just what does it do well in general? And conversely, what sucks about React native macOS and that it could improve in?

Saad Najmi:

I think what React Native macOS does well with is we're actually pretty good keeping up with the community. We pay attention to what's happening in iOS. We make sure that most of the new features with Metro or PERM or all that do work on macOS. As we talked about a little bit earlier, we're really good at the Brownfield approach. If you just want to have part of your app be React native, you can do that. And then if you've got a cross platform like Mac and Windows app, you can do the same thing with React native Windows and we've added hooks to Metro so that if you have React Native Macs and you have import React native and you're on a Macs file, it knows to replace out import React Native Macs. We have hooks to TypeScript to make sure that TypeScript type checks against the macOS types instead of the React native types.

There's a lot of implementation with the rest of the React native community that we've had to go solve. And that has just worked pretty well. And when I've talked to people who do use React Native Mac and I asked them, Hey, did you have problems with the library? What was missing for you? They usually say, oh no, the React Native Mac part actually just worked fine. Most of the things I wanted to do from React native just worked. That's awesome. That makes me happy. I'm always worried I just forgot about this entire component or prop or whatever. The part that I think we don't do well, it's kind of like community templates or marketing or starter guides.

Jamon Holmgren:

Yep. I was going to say this. If you didn't, sorry,

Robin Heinze:

That's we'll work with you. We can have Ignite Ignite for macOS.

Saad Najmi:

Yeah, I know. So I'm on the office team office is the one that funds and develops React native macOS because we want to use it for office that's different from React native Windows where the React native Windows org is in the Windows org and they want you to go write Windows apps. Office doesn't care if you write Macs apps. We want React Native Mac so we can make office better.

Jamon Holmgren:

Yeah, that makes sense.

Saad Najmi:

The goal is to make development for our app better, which means that we might not invest as much in the making your first Greenfield app from Scratch app better. You can kind of notice that in the docs I'm working on new docs, we'll all have that up soon.

Jamon Holmgren:

Yeah, awesome.

Saad Najmi:

And that's where I would love to see what people want and what we can help with. I can't always do everything, but I try to at least direct people. If there's some guy who really wants to do React native to Mac stuff or really wants to do React native to window stuff but doesn't know who to talk to or doesn't know where to start, I'm always willing to go and kind of help point them in the right direction. And also I've been super happy that Jam's been interested recently. He is been giving me lots of good pointers as well, so I appreciate it.

Jamon Holmgren:

Yeah, you bet. We have also Frank Kise on our team who's been pushing, he's a little bit more on the window side, but he is very interested in both. And Robin alluded to there we have some internal interest in building an Ignite desktop version, which would essentially really smooth out all that stuff because that's what we did in the very beginning with React native itself when it was even more,

Robin Heinze:

But it was not smooth,

Jamon Holmgren:

It was terrible. And we used Ignite as like, oh, you just start here with our experience, smoothed it out, our experience, we smooth out all the bumps and then you just get to build

Robin Heinze:

Stuff. Obviously React native itself along with Expo and everything have made the default experience a lot smoother, but we still love Ignite for many, many reasons.

Mazen Chami:

I just want to 0.1 thing, Kira Mooney posted an article just I want to say even less than a week ago from the Microsoft desktop team.

Saad Najmi:

That was like three days ago or something.

Mazen Chami:

Yeah, well three days ago from the recording May 9th. But it's how Office is modernizing their app suites UI using Windows app, SDK, and React native. I think it's a short article with, I posted it in the show notes. Everyone should be able to take a look at it. It's a good read if you want to learn more about the Windows SDK and how React Native helps it and also get to show that React Native isn't an app that you're using day to day.

Jamon Holmgren:

And the thing I want to point out right as we kind of close this down is the big question that we haven't talked about at all is why no expo support? And I think that while that would be awesome, it does. It's a bigger job than you think. Expo has done a ton of work for React Native iOS and Android and it's a significant investment for them to go make sure that macOS and Windows both work and maybe the macOS side wouldn't be so difficult. I don't know. But for sure the Windows side is a tremendous undertaken and you kind need to do both. So for right now, if you want to build an expo app expo like Mac app, you should use Mac Catalyst. That's actually what I did. I used Expo on Mac Catalyst and was able to build my app that way.

There are some trade-offs there. It's actually less native than what Sods team is working on, but you can get a Mac app up. So cool. Well, we got to wrap it up. Thanks so much, Asad. I know there's way more we could talk about because you and I have had tons of conversations at various conferences and just online and whatnot about all this stuff. There's so much more, but we are already way long, so got to wrap it up. Thanks so much for coming on, really appreciate it. Well, we will see you all next time. Bye.

Jed Bartausky:

As always, thanks to our editor, Todd Werth, our assistant editor, Jed Bartausky, our marketing and episode release coordinator, Justin Huskey and our guest coordinator, Mazen Chami. Our producers and hosts are Jamon Holmgren, Robin Hines and Mazen Chami. Thanks to our sponsor, Infinite Red. Check us out at infinite.red/radio. A special thanks to all of you listening today. Make sure to subscribe to React Native Radio on all the major podcasting platforms.