Jed Bartausky:

Welcome back to another episode of the React Native Radio Podcast, episode 3 27, automating app releases with Pratul Kalia.

Jamon Holmgren:

Hey everyone, I'm Jamon. She's Robin. Hes Mazen, and we are React Native Radio. Today we have Pratul Kalia from Tramline as our guest, and I swear we just had the most fun following him around his WeWork, which is completely empty right now. It's late at night where he is and he was trying to find a better place to record. How many steps did you get in? I am pretty sure you could close some rings or something. This should count as an exercise session.

Pratul Kalia:

It should count as an exercise session.

Jamon Holmgren:

I feel like it is,

Robin Heinze:

But we got to see WeWork India headquarters, which,

Jamon Holmgren:

Which by the way, it looks amazing. It looks

Robin Heinze:

Amazing.

Jamon Holmgren:

You said there's a gym there and everything you're, I've never been in a WeWork, so I don't know. I think there's one in Portland, but not where I am. I'm probably half hour away from it. Alright, well we're going to get into this pretty quickly, but before we get into that, let's talk about our sponsor, infinite Red. We are a premier React native consultancy located fully remote in the us. We're a team of, I think around 30. We're actually maybe a little bit more now senior. I mean it's only 30. It's not like we have 300, I should know the number right?

Is it 31? I think it's 31. Anyway, we're all senior React native developers. We have a few support staff, but mostly developers and have been doing this for almost a decade right now. If you're looking for React native expertise for your next project, hit us up at Infinite Red slash Radio and don't forget to mention that you heard about us through this podcast. So us three, continue to have jobs. Alright, let's continue into our topic for today. And what we're going to be talking about is really all around the app release cycle and automating and ci, cd and all the fun stuff that developers, of course would generally prefer not to think about too much in the course of building their apps, I think. But we do have to deal with it and so the easier we can make it, the better. So welcome. I really appreciate you coming on ul.

Pratul Kalia:

Thanks. Thanks a lot. It has been already been a lot of fun in the past 15 minutes. We should have recorded

Jamon Holmgren:

Now. I know. We should have been recording, right? Our audience will just have to imagine it. Alright, so you're one of the founders of Tramline. That is correct. Tell us the story of how you it and give us sort of a behind the scenes look of how that all came together and especially any stories that you haven't shared elsewhere. We'd love to hear anything.

Pratul Kalia:

Absolutely. So in the morning, I was actually going through the earliest documentation that I could find around tramline and stuff that I'd shared with friends and colleagues and things like that. And I found a keynote presentation. Thank you, iCloud. I found a keynote presentation from 2018 and 2018, early 2019, and in that presentation I have sort of spoken about a vast centralized release management operating system that is, well now after many years of trying to grow tramline and building tramline and selling Tramline reads like a overenthusiastic bad idea. But oh my God, even if I had all the budget in the world, I probably could not produce that software and if I somehow managed to produce it, no one would buy it ever.

But yeah, so 2018 is where at least I could found, I saw evidence. I have evidence for that, which is nice. But the reason this happened is because before tramline, I also ran an agency just like Infinite Red for about close to 10 years. And in the due course of running the agency and as the mobile market grew, explosively, I should say grew explosively in India, Southeast Asia, it gave me and my team and my colleagues and of course the mobile ecosystem around us. As it grew, it gave us a lot of perspective on what zero to one for apps looks like, which all of us were learning at that point. But as the ecosystem grew and as we got serious mobile first businesses in this part of the world as well where mobile is massive, I mean it's a huge penetration numbers across most of especially the East Asia, Southeast Asia, everywhere here I started over the years, I got this sense that, okay, it's fine to do zero to one, but now everyone's doing the one 200 or the one to 10

And the same app teams at these really mature companies doing e-commerce and logistics and food delivery and ride hailing and things like that. All of these large companies, their app teams have access to much worse tooling than their backend teams and frontend teams. It was quite obvious. It was also obvious because all of my friends who used to write any sort of backend or front and code, they just had a different class of problems altogether in comparison to US App folks. And so I being really excited when bit happened, I was very early, I discovered bit really early, I think 2016 I want to say, and I was really glad someone was doing CI just for app teams because it was such a huge pain to install the app tool chain and things like that. But those initial years, I think it's around that time when I had this sense that, okay, the landscape for a lot of the mobile tooling will look different. We will have to rethink some of these ideas that are well established in the backend end frontend world for the past 20, 25 years. All of the DevOps ideas, 12 factor applications, all of this stuff that it is considered to be great engineering practices needs to be aught. And that's sort of somewhere led to tramline me just thinking about those things.

Jamon Holmgren:

Yeah, I love that. I mean, obviously having a big idea to shoot for and then kind of refining it down to something that actually makes sense that you can actually build into a real company. I mean, yeah, that's huge. I can't say that I ever had for Infinite Red, at least in the early days, the same massive vision. Well, my previous consultancy, which I ran for 10 years, I certainly didn't. I just needed a job in tech and I was the only one who would hire myself. So that was how that happened. But yeah, I mean, infinite Red obviously does have more of a vision little plug. If you go to building Infinite Red, you'll actually hear our podcast about that. Yeah, the big ideas are what to shoot for and then you refine as you go. It's interesting though, you built this app that was centered around, or sorry, this service that's centered around mobile, and I remember, I don't hear it quite as much anymore, but especially when you would've been starting this venture, I kept hearing mobile's dead mobile apps. Nobody's going to download. It's all PWAs, it's all mobile web. You're not going to need, why would you build an app? But you were betting on mobile.

Pratul Kalia:

What year are you referring to here?

Jamon Holmgren:

Well, I remember it being the most strong, probably 2015 to 2018 maybe. I don't know. That was just kind of my perception.

Pratul Kalia:

No, actually you're right, because my guess is that you're looking at it, your lens was a North American lens, and of course the mobile became big in the US and I guess in western Europe as well. I want to say five years before it happened in Southeast Asia, India. And so there is a bit of a lag, and it took us perhaps a couple of more years before things became big here. But of course, the big apps in this part of the world are really, really big because of course the usage numbers are insane. And

Mazen Chami:

So

Pratul Kalia:

Well, I mean, the usage numbers are way higher, which means that the software engineering is just so much harder because we see a very different kind of scale here.

Robin Heinze:

You have to scale instantly. It's like, yeah, yeah, you release it and youre immediately at scale. So yeah, you have to get there quickly.

Pratul Kalia:

Yeah. I should do a quick segue here. I actually spoke to someone day before yesterday, and they're going to launch somewhat something like a meditation app in about two days time. And they have a huge campaign, huge marketing campaign that has been building up to this. And the reason they were talking to me is because someone recommended that they just check with me once, get some advice on launch day practices and stuff like that because they're expecting a hundred million signups on first day and a hundred

Jamon Holmgren:

Million signups. How realistic is this? I've heard people talk about these numbers and then they get like 300.

Pratul Kalia:

It is reasonably realistic. He's going to do it. Okay. Oh man. Because this is not going to be just here in India. They are going to target an audience. They're going to target an audience, I guess, of Indians, but they're all over the place. So it's not just people from India. They're going to be people from across the world, but they're reasonably confident.

Jamon Holmgren:

What do you tell someone like that? I would be like, well, don't do that. Start with one country. That's insane. You're not. It's going to be so stressful.

Pratul Kalia:

Absolutely. I told them, don't use Firebase authentication, fire authentication. I mean, come on, none of these pre services, because in their load testing, that was one of the reasons they were talking to me because they did some load testing and they realized, Hey, Firebase, we are hitting rate limits. And I was like, you're hitting fire based rate limits. That's odd. What numbers are you looking at? And we're like, well, a million signups in a minute and then a million every minute.

Jamon Holmgren:

That feels not, yeah, that doesn't feel like a good idea.

Pratul Kalia:

Yeah.

Mazen Chami:

I think I kind of want to add something to what Pratul just said. So we said a hundred million signups in the first day. I think from my background, I think I mentioned on the podcast, grew up in Nigeria, families, Lebanese and Middle Eastern. A lot of the Lebanese population does not live in Lebanon. So for example, Brazil has five times, I believe the number could be completely off, but way more than the population in Lebanon. Every entrepreneur that I know from any Middle Eastern country has never targeted their country.

Mazen Chami:

They've

Mazen Chami:

Targeted the diaspora, and the diaspora is always so much larger than the country itself specifically. So like Lebanon, there's one guy that I'm mentoring right now out of Palestine that's also trying to target Lebanon and Palestine, and that's just a huge number of users outside of those two countries. So that is kind of the lens of, I feel like Middle East and then far east, where it's like, let's just target our entire

Mazen Chami:

People.

Mazen Chami:

And most of our people aren't in one spot, which in the US you're like, oh, let's target American Market, just the us and you focus on smaller subsets of it. So I kind of see where you're going with that.

Pratul Kalia:

Absolutely.

Jamon Holmgren:

I know that Blue Sky, when they launched, they had an invite system that can work as well because you sort of have a natural cap. You're like, okay, everybody gets a certain number of invites, but then their invites get fewer and their invites get fewer, and you can then roll out invites a little bit more as time goes on, and they become a little bit more sought after. If it's a good thing and people are evangelizing each other, you should get on here. Okay, do you have an invite?

Robin Heinze:

It's a really smart way to do a social media platform too, which is completely dependent on you having your network

Jamon Holmgren:

That's

Robin Heinze:

On the site. That's true.

Jamon Holmgren:

You don't want random people. You want your friends,

Robin Heinze:

You want your friends. So having invite codes makes a lot of sense.

Jamon Holmgren:

I don't know. Anyway, we're getting sidetracked here. We need to talk a little more about, I mean, certainly if you're going out there and you're going to be rolling something out, you need to have I, you need to have really easy deployments. You need to have really easy ability to validate everything before you send it out into the world. And that's really where Tramline is. And while you're on here, we want to talk about the topic in general, but I think Tramline is a good example of how to do this.

Robin Heinze:

That was a great segue. Jamon, I got to say.

Jamon Holmgren:

Yes. Yeah.

Mazen Chami:

So yeah, thanks for setting me up on that. But the obvious elephant in the room is when it comes to React native, which we are is Expo, right? You mentioned Bit Rise earlier, but I kind of want to bring it back to how does Tramline stack up against Expo EAS service? Whenever we talk to a client first thing, it's like, oh yeah, let's use Expo application services for our entire pipeline. How do you all stack up against them and what is the advantage from your perspective?

Pratul Kalia:

So I want to start out by, I mean, I should say this because I'm a huge fan of Expo. I think the Oh my God's just the quality of the tooling and the documentation and the community, and I mean just the difficulty level of what they've pulled off is mind boggling to me. And I love that. I mean, I love a good platform. We have stolen some ideas from Expo, but that being said, I think Expo and Tramline are, at the moment, they're targeting different ends, or I should say different sides of the market. Tramline does have a bunch of customers that use React native applications, and so we do have some things that are special for cross-platform applications. We, of course, from our perspective as a release platform, native and Flutter look the same because they're both being deployed to the Android store,

Robin Heinze:

Right? By the time you get to Tramline, it doesn't really matter how they were built. You're talking about an executable that's going to run on an iPhone or an Android phone.

Mazen Chami:

Exactly. I might ask the editors to just edit the React native and Flutter look the same. Sorry,

Robin Heinze:

Flutter is the F word on this podcast.

Jamon Holmgren:

Why am I not

Pratul Kalia:

Surprised? I don't think

Jamon Holmgren:

I've heard.

Pratul Kalia:

That's funny. That's a good line. That's a good line.

Jamon Holmgren:

That is a good line.

Pratul Kalia:

Yeah. So I think what Expo does really well is do the job for most of the, I would say the small, medium-sized market. I think the place where we have seen Expo become tricky to use is because for larger customers or for enterprise customers, they already have significant investments in their own CI pipelines. They often cannot or do not want to foot the bill of what expo would cost at their scale. And I think that's fair. I mean, it is expensive for large companies. I guess, and I have heard this from people, but I guess from tramline perspective, our tooling is designed as a result of our own experiences of working on large scale applications. So a lot of the things that tramline has is for large teams to the point that I think for a small team, tramline is almost overkill. When actually, if I look at Expo, I think it's great for starting off just from Day Zero itself, because right from the very first step where you create Expo app all the way to, of course, ES build, which requires you to not write any CI pipelines now, you don't need to get your hands dirty with GitHub actions Arbitrize all the way to submitting it to the store.

It is including doing the annoying bits like managing key store and certificates and stuff. I think that's fabulous. I think that's great. It's such a phenomenal first time experience that both Apple and Google have failed to provide their communities. I think Expo is doing the best job out there. But yeah, of course. On the contrary, what Tramline does really well is that, okay, I have a team. I have an app. This app is a decade old. We have huge investments in GitLab, ci, arbitrize. We of course send builds to App store and play store, but we also send them to Firebase app testing. We deploy a copy of our Build to S3, and then we notify these people in Slack here, and these groups here get this. So usually for us, the ideal cross-platform use case or tramline is a more mature customer, a bigger customer.

Mazen Chami:

I could see that. I see that with our clients sometimes too, where I was talking earlier, working with mentoring some people and getting them started Expo and EAS pipeline is great because it's quick, easy, and like you mentioned, good documentation. And for the beginners who don't want to go through the complexity of key stores and certificates and UU IDs and all that crazy stuff, that's the best path. But then when you get to the larger enterprise who for the most part have a large security team that do handle that stuff, ES might be a barrier to entry for them because it's like, well, my security team needs to go through this process for us to make sure that we're good to go to the market. So that's great advice there.

Jamon Holmgren:

I have a question for you, ul.

Pratul Kalia:

Yeah, go ahead.

Jamon Holmgren:

Who's more annoying to work with? Google Play Store or Apple App Store?

Pratul Kalia:

Oh my god. My CTO should have been here. I would say the app store, because their APIs are, in our experience, their APIs are more flaky. Interesting. I've heard this before. It's impressive how often Apple's APIs are down given the number of zeros in their balance sheet, right? Yes.

Jamon Holmgren:

I've always said they're really good at on device, well, certainly hardware, and then some types of on-device software that's getting less.

Robin Heinze:

They have ones that they randomly neglect and are

Jamon Holmgren:

Really bad. Yeah, QuickTime. Yeah, we were just talking about that. But also then anything to do with the internet, they just don't seem to be very good

Pratul Kalia:

At it. I would love to know the story behind Apple invites. I have no idea how that has happened. It just was so out of the blue

Jamon Holmgren:

Apple invites.

Pratul Kalia:

Yeah. Oh

Jamon Holmgren:

Yeah.

Robin Heinze:

Did you miss this? They just released this. It's like a replacement for Evite. So you can send invitations to events, to your iMessage contacts.

Pratul Kalia:

Have you used Paperless Post or No Party? Full Party Full guys? I love them. Party. No,

Robin Heinze:

We always use Evite for my kids parties and

Mazen Chami:

Stuff. Literally, it's funny you say that pr, we sent out a paperless post invite for my son's birthday party, which is this weekend,

Robin Heinze:

And

Mazen Chami:

Literally the next day they come out with it. I'm like, whoa, where was this yesterday? I could have used this.

Robin Heinze:

Thank you. I literally texted my kids' friends', parents one at a time with a,

Jamon Holmgren:

Does everybody have to have an Apple device or how does this work?

Pratul Kalia:

It works even without an Apple device. You do need an iCloud account, I believe. I'm not sure, but it's just odd. It made me think what was happening, who decided? Yeah, right. That we wanted the invitation app. This the app we need for

Mazen Chami:

Parties. They needed to have an internal party. They didn't have an app for it. They built it and the Apple Pizza Party happened.

Jamon Holmgren:

Yeah, you know what? That's actually how I build all my small apps that I release. I'm like, I need something. I do a quick Google search, it doesn't exist, and then I have cursor build it for me. Alright. So I actually want to ask you about Rail Deck because I saw that on your website and it seems like an interesting thing. You have this metric, it's R-E-L-D-E-X. It's a metric for release efficiency, and I think it comes from some other index that is out there. So how'd you come up with this concept? What other similar scoring systems are there? How does that even work?

Pratul Kalia:

So you're right about it coming from a different place. The inspiration for the name comes from aptex, which is Application performance index. I believe New Relic came up with Apex the first. They were the first ones. It's a Portland area

Jamon Holmgren:

Company.

Pratul Kalia:

Oh, sweet. And what Apex is popular for is to be able to look at the user experience. How effectively is the user experiencing our app? Are they able to use the app and are the latencies fine? And things like that. So it was like from New Relic's perspective as a monitoring platform, it was a single number that let teams understand that, okay, our Apex is 0.9. Sorry, just to clarify. For those who don't know, apex goes from, I believe, zero to one. That's the range for Apex. It boils down to zero to one. It's just a single number. So it makes it really easy to know that, hey, my application, my users are experiencing the application. Well, our latencies are good, our throughputs are good, our APIs are performing well, et cetera. Now of course, the users could be unhappy with a well performing application, which app text does not concern itself.

So similar to this, the idea for relx, I believe the initial idea came from one of our customers who had a score similar to this, but my co-founder, ahe, he fleshed this out and he was the one who took the inspiration from Aptex. So what rydex does is in a very similarly inspired way, gives you a score from between zero to one to measure how well do we do releases? Are we doing releases well? So we take a bunch of things into account. When we calculate the score, we look at how long did you take or how long are you taking to do releases? How many fixes on your release branch is it taking to get to production? How many builds are you making inside a specific release cycle? Did you do, I believe one of the metrics is one of the scores that goes into it is did you do, how many production releases did you have to do before you closed this release cycle?

So you release the after 20% and then you realize something was broken and you had to swap it out at 20% with a new build. So that reduces your index score, which gives teams, and especially from our experience now I can say this, engineering managers, a lot of folks from the platform teams, especially at big companies, they look at the score and they're able to see that, okay, hey, you know what? We're doing fine. We're kind of in the green or that, hey, those two releases are really bad because we had a game breaking bug and we had to do four fixes or whatever. That's where it comes from.

Jamon Holmgren:

Yeah, that makes sense. And how do you avoid being in that, how you start measuring something and then people start optimizing for the thing you're measuring and then they kind of lose sight of the end goal and everything's green, but people are unhappy. How do you avoid that?

Pratul Kalia:

So

One of the ways we avoid that is we try to not be prescriptive about Rex. So when someone onboards streamline and they're going through the trial, we make it very clear to them that, listen, this is a number to define, which is an indicator of your process, and we have some defaults. But what you want is to look at the defaults and match it to how your team domain business actually does in the real world. Because it's possible that if you're a 10 person team, building a podcasting app, perhaps doing zero hot fixes is our benchmark. And even one is a bad thing.

But I would imagine that if I was, I don't know, WhatsApp or Uber at that scale, the probability that something would go wrong and would require me to swap a build in production seems it would probably be higher. So at that point, I would probably increase my thresholds there. So we like to look at it as a check engine light, right? It's not an answer. It is an indicator that, hey, something's up, but now you should look at the light, figure out that something is up and now you investigate why is something up, where are we going wrong?

Jamon Holmgren:

I like that analogy. Yeah. Yeah. It's much less a like let's optimize for this thing and more. Yeah, I like the check engine light. That's a good,

Robin Heinze:

It's like it might be your cash cap or your engine might need to be rebuilt. You don't know.

Jamon Holmgren:

Correct. I've had both of those happen on the same vehicle. So earlier you mentioned you do some cool stuff with the cross platform like React native Flutter, et cetera. And I saw a little bit in your docs about things like synchronizing the two releases. You can kind of see 'em side by side and things like that. But can you talk to me a little bit more detail about what do you do for React Native and other cross-platform apps?

Pratul Kalia:

Yeah, I mean, I'm glad you looked at the documentation because that synchronized things is for sure one of the really fun things. I enjoy that a lot. Teams really like that because that's something that they do in their heads and they've never really seen it on a dashboard.

Jamon Holmgren:

I know. It is so cool. You literally see it side by on your screen. You see them side by side kind of almost like they're racing, like they're racing toward the end.

Pratul Kalia:

So that is actually how teams use it. So they don't use it as a race. But so okay, one step back. Synchronized cross platform releases from Tramlines perspective is very, very straightforward From the outside, from the outside, all it does is make it clear that your code base is the same. You're using a cross platform framework for your iPhone app and your Android app, and everything's the same. So the only thing that's actually different is how they reach the end user. Of course, your same React native app will reach your Android user differently from, of course how it reaches the iPhone user, but also they're tested differently. So for instance, of course some teams use open beta on the play console. Some of them will use Firebase, some of them will just dump Android birds in Slack. Quite a common thing to do. But of course on the iOS world,

Robin Heinze:

That's so Android.

Pratul Kalia:

On the iOS world, of course we have test light everywhere and more test lights. So we just have a bunch of different groups. So what tramline does, it lets you codify both your Android and iOS process separately as it does for native apps, but then you get to run it together, which means that of course you can see them on the screen, same screen, but you can also act on it at the same time. So as an example, if you land, let's say you notice a bug on the Android side of things and iOS, your iOS build has already been approved by Apple Review. Now we know that, and teams know this, that if you change your iOS build under review, sometimes it takes 12, 24 hours, 36 hours to get that review sign off from Apple again, right before it goes to production. So we have customers who will land a commit and then decide that, hey, you know what?

This is a fix just on the Android side of things. I don't want to touch that iOS bill that's been reviewed and it's ready to go to production. The second I click the button. So on tramline, this neat little sort of shows up when you land a commit on your release branch and you're farther into the release, which just tells you that, Hey, do you actually want us to re-trigger your iOS CI? Because this, as you can see here, the review is already green. This is nearly, it is just one click away from production. And so people will sometimes just apply the commit on one side and they will not trigger the build for iOS at all. And the reason I like to call this out is because this is annoyingly difficult to build inside CI because you have to sit outside of ci. So a person has to do this, usually an engineering manager or I guess in the case of bigger teams, someone from the platform team or a release manager has to do this or has to take this decision manually. With tramline, it just becomes easier, it gets recorded in the system, and you just have this cute little pathway that shows up because at the end, once the commit is in your repo anyway, it doesn't matter the next release, it'll go to iOS. Anyway, this is one of those examples of stuff that we do on cross-platform stuff.

Jamon Holmgren:

Yeah, it's super cool. There's a blog post about it when you released it. We'll link to that in the show notes. That has a cool screenshot of at least the state of it when you did that, and I don't know, I love this sort of stuff. These sort of dashboards are just so much fun, and I understand in order to make a kind of simple dashboard, it takes a tremendous amount of work. Gosh, on the backend.

Robin Heinze:

Absolutely.

Jamon Holmgren:

Yeah,

Robin Heinze:

It's true. There's always complexity behind simplicity. I feel like I have to ask because it seems like every single product and service out there is starting to add this, but how are you leveraging ai, if at all, and how did you make that decision? And was it sort of like, oh, we got to get on this bandwagon, or how did that happen

Pratul Kalia:

To people? Definitely. That's a question we get asked often. Very little AI externally at the moment. We do have some ideas I think, which are fairly the first ideas that one would think of, especially around understanding reviews of a particular release. Being able to, here is a dump of the 60 reviews I've received for this particular release that you're releasing

Robin Heinze:

Like, oh, hey, we think there might be an issue. We're seeing a trend in these. Yeah, that makes sense.

Jamon Holmgren:

Like user sentiment, sentiment, not sentiment. That would be a little bit different. Not user sentiment. Yeah, they're bad reviews.

Pratul Kalia:

You can call them sediments. Yes, exactly

Robin Heinze:

Right. Not completely dissimilar.

Pratul Kalia:

No, I guess not. Yeah, and we've been doing this stuff, right? I've heard of products through sentiment analysis for the app store and Google Play reviews. It's just so much easier to do this with LLMs and the OpenAI and Gemini APIs. That's some of the easy stuff. We definitely looked a little bit at agents and how would this new world where everyone's talking about agents and people are doing these things, I'm interested in seeing how that would, if there is something that I can do there to simplify a lot of, I guess the manual coordination, a lot of the manual work that goes into doing a confident app release. Not sure. Not sure yet. No early signs yet.

Jamon Holmgren:

Yeah, it does seem like there's some opportunities there, but yeah, you have to do it the right way, for

Robin Heinze:

Sure. Right. You don't want to sort of force it in. Yeah,

Pratul Kalia:

It's also a sensitive path. Yeah.

Robin Heinze:

Just because it just because hot right now.

Pratul Kalia:

Yeah, yeah. Absolutely. But also from our perspective and from our customer's perspective, it is app releases are sensitive. We know they are a single shot, very little room for failure here. Critical paths, critical path in the organizations' business.

Robin Heinze:

Our clients are definitely the most anxious and stressed out and needy about app releases, and I get it. I get it. It's a big deal.

Pratul Kalia:

I don't think we want to take that responsibility lightly. We of course, don't take that lightly, especially with stuff like ai, which can be hit or miss, but also that means our customers don't particularly care about the latest and greatest stuff happening on their app release dashboard. They just want confident, regular, high quality releases. That's what they want.

Jamon Holmgren:

Yeah. I see it probably as being something that's simply more informational, where it just gives you more data, more targeted data in the right places, maybe more natural data where it can actually analyze multiple things at once and give you a recap that then allows you to dig in deeper sort of, I guess, an augmentation to the rail decks that you have. Well, we do need to wrap up unfortunately here. It's been a lot of fun. I appreciate having you on here. I'm going to ask you one last question and then we will wrap it up. So do you ever code yourself personally anymore? I know you were a software engineer back in the day.

Pratul Kalia:

Not on Tramline actually,

Jamon Holmgren:

They won't let you touch the code base.

Pratul Kalia:

This is sort of like what happens with me. No, I don't think it's that they don't. I think more than that, I've built apps for so long that I think I would not be very productive at writing code on a complex workflow orchestration platform.

Jamon Holmgren:

Right, right. Yeah. It's a very different type of code. Absolutely. But that perspective coming from the app developer perspective is huge because if you came at it from a platform perspective, it's going to leak through. We see this all the time where you'll have these platform devs who build things that all of the things make sense based on the internals, but as you said, you do a bunch of back end work in order to make the front end look really friendly and simple, but that can't leak through. It can't be all of the internals just coming at you.

Pratul Kalia:

Yeah. You're

Robin Heinze:

Basically, you bring a user perspective to

Pratul Kalia:

Product

Robin Heinze:

Development.

Pratul Kalia:

That makes sense. Huge sense. I'm the one who's suffering.

Robin Heinze:

You're not building it, you're the audience.

Pratul Kalia:

Right, exactly. I am tempted though to write code because it is open source, and I do feel that often that, Hey, I want to do something here because I see it's so easy to see what's happening and people talk about that stuff that, Hey, we saw you're working this thing.

Jamon Holmgren:

Yeah, yeah. Totally more useful I think would be if you had a little side project that's an app and you're using tramline to deploy it, we do. Because then you're going to start feeling the pain and you're going to come in and be like, why does it work like this? This is stupid. I'm getting really annoyed by it.

Robin Heinze:

Absolutely. That's exactly what Jamon does to our open source product.

Jamon Holmgren:

Yeah,

Robin Heinze:

Sometimes.

Pratul Kalia:

Totally. We do actually have a small app that we use to dog food that's also open source, and it's super fun because all it does is list the stations of the Yama OTE line in the Tokyo Metro system along with all the audio recordings from the station that you can play, but that's built in the other cross-platform thing.

Robin Heinze:

Oh, the one that we're not allowed to talk about the F word.

Pratul Kalia:

Yeah, so sorry. Oops. Yeah.

Robin Heinze:

Well, as Jamon well knows Flutters better than React native in all the ways that don't matter.

Jamon Holmgren:

I wrote an article with that title. Oh, I'm

Robin Heinze:

Sure it's fun. Flutter is

Jamon Holmgren:

Better than, it's

Robin Heinze:

Very fun to write

Jamon Holmgren:

In all the ways that don't matter. It's actually a fairly nuanced article. In some ways it's probably more complimentary to Flutter than React Native developers would've liked me to be. I actually think there's a lot of good there, but that's a different episode. We did do an episode on that

Robin Heinze:

Several, I think.

Jamon Holmgren:

Alright, well thanks a lot. That was so much fun. I really appreciate having you on ul. And where can people find you on social media and whatnot?

Pratul Kalia:

You can find me on LinkedIn. I guess we can leave a link to my profile in the show notes and Twitter.

Jamon Holmgren:

Perfect. And I think your Twitter handle is P-R-X-T-L-P-R-X-T-L. That is correct. Yeah. P-R-X-T-L. You can find us of course. On Twitter, I'm at Jamon Holmgren. Mazen is at Mazen Chami and Robin is at Robin Heinze with an E. No underscore anymore though.

Robin Heinze:

I got rid of the underscore right before I started using Blue Sky.

Jamon Holmgren:

Now you're using Blue Sky, so you can find her on Blue Sky as well. What is that? It's, it's

Robin Heinze:

Just Robin Heinz dot. It's my Robin Hez

Jamon Holmgren:

Dev. I'm on Blue Sky as well. I need to post there more often. Jama Dev and I dunno, Zen. You on Mazen Char Dev?

Pratul Kalia:

Yep.

Jamon Holmgren:

Oh, okay.

Pratul Kalia:

I'm also on blue sky rael.net.

Robin Heinze:

Oh, there you go. Perfect. There you go.

Jamon Holmgren:

Yeah,

Robin Heinze:

I love that feature of Blue

Jamon Holmgren:

Sky. It's so cool. Nice. Thanks so much and we'll see you all next time. Bye. Thank you.

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 Heinze and Mazen Chami. Thanks to our sponsor, Infinite Red. Check us out at https://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.