bitdrift
PricingDocs

episode 13 | April 21 2026

JP Simard on Swift, Open Source, and Escaping the IDE

JP Simard on Swift, Open Source, and Escaping the IDE

JP Simard on Swift, Open Source, and Escaping the IDE

Beyond the Noise

About the episode

In this episode of Beyond the Noise, Matt sits down with JP Simard, a longtime iOS developer and open-source builder best known for projects like SwiftLint, and as the co-host of the Swift Unwrapped podcast. JP rewinds to the early 2010s “mobile gold rush,” explaining how the approachability of app development, compared to hardware and audio engineering, pulled him from electrical engineering into shipping apps, running an agency, and eventually joining a YC startup that became Realm.

From there, the conversation moves through JP’s time at Lyft, focusing on public transit (bikes and scooters) and multimodal trip planning. He then talks through how he ended up in his current role at Ramp, where he describes how a tiny mobile team can still deliver high-impact product work in a B2B environment with tight customer feedback loops. They debate iOS vs Android ecosystem dynamics (open vs closed tooling, SDK evolution, and IDE stagnation), then close with JP’s forward-looking take: the industry may not be headed toward “code once, run everywhere,” but it might be headed toward “architect once, implement everywhere," with modern coding assistants making cross-platform translation dramatically less painful.

[00:00:00]

Matt Klein: All right folks. Welcome to another episode of Beyond the Noise Signals, Stories, and Spicy Takes the show where we dig into the stories of the people shaping the future of app-based computing with a special focus on mobile. I'm your host, Matt Klein, co-founder and CTO of bitdrift, as well as the founder of Envoy Proxy.

Each episode we'll talk with engineers, founders, and technical leaders who transform the way their companies build and understand what's happening inside their systems. We'll dig into the challenges, the breakthroughs, the lessons learned, and we'll wrap it all up with their hottest takes. So let's dive in.

Today I am excited to have JP Simard with us, who is a mobile engineer at RAMP and a longtime iOS and Android developer. He's known for his work on open source tooling in the Swift ecosystem, [00:01:00] including Swift Flint, and for being co-host of the Swift Unwrapped. Podcast that ran from 2017 to 2021. Hello JP.

Thank you very much for joining us.

JP Simard: Hi Matt. Thank you so much for having me on. It's great to see you again.

Matt Klein: Yeah, and as you mentioned in the pre-show notes, we used to work together and it's, it's fun to connect back with people who we haven't seen in a long time. So it's great. Thank you again for coming.

JP Simard: Yeah. It's so great to reconnect with folks.

Matt Klein: Cool. So how I, I love to typically get started is, you know, would love to learn how you got into mobile. So, you know, you can take us just from your early career history, how you got into computing, what excited you about mobile. Um, so let's just start there.

Take us into it.

JP Simard: Yeah, I mean, we kind of have to rewind the clock, uh, 15 years or so. Back in, uh, around 2010, 2011, I just did my [00:02:00] bachelor's in electrical engineering and I thought that was really my calling. And so that's what I studied. And then it turns out after working in the industry, a few co-op terms that I really didn't like it.

And at that point, early 2010s, it was really kind of a mobile gold rush at that point, right? Everyone, was following very closely the new iPhones, new Android phones. Everyone needed an app, but a lot of companies didn't have that expertise. Everyone had an idea for an app, right? That it was the thing.

And so, I realized that there was something, there was an idea that I wanted to build, but I didn't have any software experience. I had didn't have the first idea for how you go and make these things. But, one of the things that really fascinated me about that space is that it all seemed so approachable compared to what I'd been studying at school.

And it's not to say that one is easier or harder, but even today, like you go and look and you see [00:03:00] tutorials of people saying like, hey, you can go from idea to thing running on your screen of some sort, right? Whether it's a website or an app, within a few minutes. You have someone holding your hand step by step, doing a thing.

Like imagine doing that with like a, a PCB or like an antenna design. It just, it's not the same level of approachability. So I was fascinated by that.

Matt Klein: And is that, is that why you decided that you didn't like electrical engineering? Was it, was it too slow? I mean, it's like, what, what was it about that field that, that took you elsewhere?

JP Simard: Yeah, part of it, part of it was the speed. So my, my real passion at the time, what got me into it was the music technology side of things.

Matt Klein: Mm-hmm.

JP Simard: Um, in high school I was very into understanding how, how audio engineering worked. Read, um, research books from the BBC on like acoustics research for how to best design a recording studio without standing waves and things like that.

And so that's what got me into the space. [00:04:00] And so my, my dream job, going into that was to work, at this microphone company out of Berlin that invented the condenser studio microphone called, Neuman. And so, went and worked for Neuman for an internship.

Matt Klein: Oh wow. Cool.

JP Simard: And then I realized that the peak of technological progress in that industry, or at least of like sound quality had really peaked in like the sixties and seventies.

And since then, the industry had just been chasing marginal improvements... reducing, reducing the analog signal chain as much as possible, right? Moving the analog digital converters directly into the microphone so it wouldn't have loss along the cables. And yeah, there was, there was some interesting work going on there, but, I kind of felt like the, the industry had really just been chasing these marginal returns for decades.

And so, yeah, in, in that very real sense, it felt, um, extremely slow.

Matt Klein: Hmm. Interesting. Cool. All right, so you decided to, to, to exit the [00:05:00] microphone space and now you're, now you're in the app, app era,

JP Simard: the, yeah, the electrical engineering space. And like many people, if you hang out with family members and you're technical over the holidays, they might say, oh, I have an idea for a thing,

right? And so I had an idea for a thing and, and it was gonna be a mobile app, but I didn't have the first idea for how to do this. But, turns out, you know, you just, you Google for things and, and there's tutorials and in, in many ways, and now more than ever, there's almost like too much material where it's kind of hard to know where to start.

But the, the reality is you can basically start anywhere. And so at that time, in, in my opinion, I mean in some ways we've sort of looped back to this, but in my opinion, it was kind of the best time to be learning this stuff from scratch because you really had this concept of progressive disclosure.

The first app that I made was on Android, and that was kind of terrible. Um, 'cause this was like 2010 Eclipse. It, it was really painful. And then, I, I then switched to [00:06:00] want to make an iPhone app. And at that point it was, it's kind of magical, right? Where you had only a single resolution for your screen.

So, if you had any sort of mockup, it could just be exported as an image. And that's what I did for my first few apps. You just export the whole screen as an image, draw transparent buttons in interface builder, and this, this sounds terrible, right? This is not at all what you would consider anywhere close to a reasonable engineering practice, but in terms of having an idea and wanting it in people's hands quickly, it was perfect for that.

It got the job done. And so from that, you could then start to understand, okay, well if I peel back the layers, like, this shortcut that I took, what's the right way to do it? What's the right way to do it this way and that way? And so it you, you end up having this very kind of clear on ramp into learning how to do things from complete hack to bit by bit

realizing what parts do you wanna dig in and better understand. And in so [00:07:00] many ways, it, it kind of feels like we have an opportunity to be there again, with these agentic coding tools where you can really go at it at a high level and say, you know, Hey, Claude, do this thing.

Matt Klein: Sure.

JP Simard: And then it'll output vibe, code, whatever, a bunch of gibberish that'll probably do somewhat of what you want.

It'll be, you know, terribly engineered. But, from there, you can, if you have the right personality, you can kind of be curious of, oh, what did it do? Why did it do this? Is there a better way? And you sort of pick and choose what aspects of that you wanna do.

Matt Klein: Yeah, I, I, I mean though, back then, when, when you're, I, I guess in the timeframe that you're talking about in like the 2010 era.

There also weren't, there weren't a lot of established patterns back then. Like, like you're saying. I mean, obviously people had been building apps for a few years. You know, I don't, I don't remember iPhone came out in 2006, 2007, but I think probably part of the gold rush is everyone just figuring out how, [00:08:00] how do you do this?

Like what is the right way, right?

JP Simard: Mm-hmm.

Matt Klein: Um. So, I don't know. I mean, it's, it's interesting because I can see the parallels to today with the AI coding tools, but to me it's, it's also slightly different in the sense that you have 20 years of established patterns and you almost have to map them back to the gibberish, as you say, that's, that's like being produced.

Um, but anyway, I dunno. It's a, it's

interesting.

JP Simard: Well, it's interesting that you say that because, um, you know what, what was interesting is that, a lot of the SDKs and, and the development patterns and languages were really kind of evolved step by step. And whether you look at the Android side with Java and Eclipse, right? These weren't new tools,

Matt Klein: right

JP Simard: um, and, and same thing goes for the Apple side of things with, with Cocoa and Objective-C. There were decades of established prior art there, and even those languages and those platforms... built on what came before.

Matt Klein: Sure, yeah.

JP Simard: And in a lot of ways it's, it's just [00:09:00] kind of every new generation, you just sort of have a rethinking of those levels of abstraction, of the, the tools that you're building on.

So, I'm not, I'm not sure, I, I agree in the, in the macro sense that people were learning as they went in terms of best practices for, building mobile apps, sure. But, uh, there were a lot of established practices when it

Matt Klein: Yeah. For sure

JP Simard: came to, you know, architectural patterns and, and programming, uh, best practices and things like that.

Matt Klein: Yeah. Alright. So you, so you made your apps and then what happened?

JP Simard: Yeah. Yeah, so I- I, I never ended up building the idea that I had for an app instead, sort of had to pay for rent. And so I just ended up building apps for people and then hiring, more programmers to help out. And then hiring designers and hiring people to do business development.

And that effectively turned into an agency. And so ran that for a few years, but by the end, I was, I was mostly just sort of running the [00:10:00] business and, I didn't feel like I was building anymore, right? I was, going to networking events, trying to find new clients. I was dealing with payroll and taxes and

Matt Klein: Yep.

JP Simard: It, it just wasn't, wasn't fun anymore. And so at that point, the agency basically disbanded. I did a little bit of contracting, and then there was an opportunity for me to join a Y Combinator stealth startup, in, in San Francisco. So moved from Ottawa, Canada to San Francisco.

And that company ended up becoming Realm, which people who've been doing mobile engineering for for a few years, may, may remember it. We had an alternative to SQLite as an embedded database, but instead of building an ORM on top of SQLite, we ended up building our own, from scratch database engine that was a little bit more modern, better suited for, smartphones, ARM for things like faster... you know, the fact that phones had SSDs, so slightly different

[00:11:00] memory mapping, uh, trade-offs that we could make. Everything was an object connected graph as well, as opposed to just sort of tabular tables. And, and that's just sort of scratching the surface, but, high level, you know, it was a database that you could use to, to build apps, in- for, for iOS and Android and that was a really fascinating

time to be doing that.

Matt Klein: Yeah. I

mean,

JP Simard: that company was eventually bought out by MongoDB.

Matt Klein: Yeah. I mean, it, it, it sounds super interesting just from my personal interest. Could, I don't know, could you take us into it a bit more? It's a, it's a really interesting space just in the sense that SQLite

as an embedded database is obviously deployed in so, so many places. So, I can, I can absolutely believe that something better could be built. It's also, it's a, it's a bold proposition to do that. To be fair, I am one that loves taking on bold propositions. But I, I don't know, I, I guess, you know, you can pick and choose, but would love to, to learn a little [00:12:00] more, I guess, about the interesting technical

JP Simard: mm-hmm

Matt Klein: trade offs while you were building that.

JP Simard: Yeah well for the most part, the goal wasn't so much to, to, to, to be competitive with SQLite because most people building iOS and Android apps, especially at the time, were more using ORMs. And so the, the goal was really more to have

Matt Klein: interesting

JP Simard: instead of

having that impedance mismatch between, okay, well you have an object, relational map or layer, and then that has to translate, and have a bunch of leaky abstractions under the hood to actually be backed by something like, like a SQL database. We said, well, why not just sort of collapse that so that you're directly, you're reducing those layers of abstraction as much as possible.

I mean that was,

Matt Klein: did it work?

JP Simard: Part of the- it did. Um,

Matt Klein: yeah,

JP Simard: it, and in many ways it, it was sort of ahead of its time and in many ways I, I obviously take this with a massive grain of salt, because I, I was there, but, the technical side [00:13:00] was unmatched. And in many ways I kind of feel like I had solved things that we're still, struggling to solve today, a decade plus later, where, things like the fact that the,

database write log, uh, the, the set of operations were all CRDT conflict free replicating data type.

Matt Klein: Yeah.

JP Simard: Meant that you could sync across threads, right?

Matt Klein: Oh, interesting.

Yeah.

JP Simard: And resolve conflicts that way, but also sync across machines,

Matt Klein: across devices,

JP Simard: in the same way, right? And, a lot of the things that we're doing now, like so much of even modern mobile engineering is just trying to reinvent the wheel on such basic things.

Matt Klein: Mm-hmm.

JP Simard: Like making sure that your server can talk to your client in the same language, with the same contract. And, think about, okay, well if this operation fails, how do I retry and how does that not invalidate? Or what parts should it invalidate of my local cache of what the server's seeing?

Matt Klein: Yeah.

JP Simard: All these

things are really, in my opinion, kind of working on the wrong abstraction [00:14:00] level because, if you can model these kinds of things as, as a semantic operations, you can really let the system try to resolve it the best way and you can sort of pick what semantics you want at the high level. But the, the cost of, of switching and, and fully embracing a model like this in a full stack capacity was just extremely high.

Matt Klein: Yeah.

JP Simard: Um, and one of the reasons why this, this didn't take off at the scale that, maybe, the venture capitalist- capitalists wanted it to.

Matt Klein: Right.

Yeah, it, it's a, it's a pretty interesting topic because, my experiences are probably biased and they, and they might be unique, but I feel like throughout my career, whenever I've tried to use an ORM and anything that I've built, it has gone just horribly wrong.

I mean, like wrong in the sense that... what happens is what you said, you end up leaking the abstractions from the underlying database through the ORM, and then you end up, even though [00:15:00] theoretically you're abstract from the underlying data story, you're not really, right? Because you're relying on specific functionality and then eventually you like escape to writing sql and it's just like a giant mess.

And what you're saying makes me wonder if... is, is it just that the database has to be written for the ORM, right? So that you're not kind of like writing, writing these things separately and then trying to jam them together? Um,

JP Simard: yeah.

Matt Klein: And I, I don't have any personal experience using Realm, but it, it does make me wonder, you know, if such a system were built where the two really went hand in hand.

Like, could it work better that way?

JP Simard: Well, in some ways, in some ways that was, what we ended up doing there there were, slightly different, layers of abstraction still when, when it came to, you know, the, the raw object storage and representation versus what were, was exposed in the API and, um, you had

multiple languages mixed in here, and we want it to be idiomatic on a per platform and per language basis. So the core was all C++, and then [00:16:00] there were wrappers, uh, C++, Objective-C++, uh, Objective-C and then Swift. So you, you have a lot of layers there.

Matt Klein: Yeah.

JP Simard: Um, this was, you know, decade before, C++ interop with Swift.

In fact, this was year- we were about to launch the SDK and then, we're like, well, WWC's in a few weeks. Let's wait to see. And then they announced Swift. And so we did a hard pivot to make sure that what we had worked with Swift and, and that, honestly, if, if, if we're still somewhat talking about my career, that propelled my career because it was an awesome opportunity to, to, to have a greenfield, um, set of projects of like, 'Hey, this language doesn't have a linter.

It doesn't have any tooling, it doesn't have a documentation generator.' And the documentation generator was the first thing that I went and built. Reverse engineering, some of the closed source, Xcode SDKs to write doc- HTML docs for, for the reference APIs for our SDK that we wanted to offer to people,

right? So this was somewhat aligned with what the company, [00:17:00] needed. And, and so that was, that was Jazzy, which is still around. People still use it in some cases.

Matt Klein: Yeah. I mean, I. I do wanna come back to this topic because you, you just said the magic words to me, which is reverse engineer, the closed source SDK.

Um, and, and, and I do wanna come back to this topic because I think it's really interesting. You said Ramp (*Realm) ended up getting acquired is the technology

JP Simard: Realm. This is

Matt Klein: still, still still used.

Oh, sorry, sorry, sorry. I apologize. Realm.

JP Simard: Yeah.

Matt Klein: Um, is, is the technology still used?

JP Simard: It's still used and still actively developed. Um,

Matt Klein: interesting.

Okay.

JP Simard: Yeah, I, I left the company in 2017. I joined Lyft where we overlapped, especially in the later years. Not, not in 2017, but later on. And then I forget when it was exactly 2018, 2019, something like that.

Um, Realm was acquired by MongoDB and, the, the Realm SDK continues to be actively developed. I don't know if it's still [00:18:00] called Realm or if they call it MongoDB something and

Matt Klein: interesting.

JP Simard: I, I'm sorry for, for everyone, uh, either using it or working there. I, I've sort of lost, uh, I, I haven't kept, track too much, but I know it's still actively developed and very much in active use.

Matt Klein: Interesting. Okay. Yeah, I mean, I'll have to j just again, just for my personal curiosity, I'll, I'll have to follow up on that, but to, but to come back. So you started getting involved in open source, and, and then is that how you wound up at Lyft? I, I mean j just in terms of getting involved in the Swift ecosystem or I, I guess like how, how did that leap go?

JP Simard: Yeah, that's, that's part of it. So at Realm, the SDK itself was open source, but I also had, the amazing opportunity to just go and travel a bunch and speak at a bunch of conferences- conferences, meetups, uh, Japan, Spain, France, like UK, even went to Belarus. Um, it was, it was an, an exciting time.

Matt Klein: [00:19:00] And,

JP Simard: yeah.

Matt Klein: Sorry, that was, that was part of your work at Realm or, or was that just something that you had been doing independently?

JP Simard: It's, it's a little bit of both. I mean, the folks at Realm were incredibly supportive so that when I had an idea to, you know, build this, this documentation generator, they're like, yeah, you know, do your thing.

Um... but my, my initial job when I joined the company was for developer evangelism. And then I ended up, leading the Apple platform development team and kind of l- learning more about the, the, the core product, helping build out the first version that people used, even though, there was a team that had built the core of the framework for years prior to that, the three years prior to that.

Matt Klein: Yep.

JP Simard: Um,

Matt Klein: right.

JP Simard: So yeah, the, the traveling, you know, conference circuit, uh, open source stuff was all something that was, was very encouraged by, by Realm, and it was also as a developer tool company, the goal is really to, to say, [00:20:00] well, hey, if we can convince, developers that we kind of know what we're doing, and that there's some advantages to, to at least, exploring using the products, that it could be, a good kind of marketing strategy.

But at the same time, it was just a great way to, uh, to contribute to the community at the same time.

Matt Klein: Yeah. So, so in terms of coming to Lyft, I know that Lyft was obviously also really early on in the, in the Swift train. So it, is that what drew you there or I, I, I, I guess tell us bit more

JP Simard: partly, yeah.

Matt Klein: About that transition.

JP Simard: So, the, the folks at Lyft, knew of me 'cause I had been running the Swift language user group in the Bay Area. And, from, from open source work and especially SwiftLint, which they were using, I mean, most companies doing Swift were, were using. And so that was, that was part of it where I had a foot in the door.

But the other part is, just the San Francisco scene being tight, I knew people there and I very much was looking forward to the [00:21:00] opportunity to get back to, to building more user facing products.

Matt Klein: Yeah.

JP Simard: And so that's when in 2017 I joined the, public transit team at Lyft. So really trying to push Lyft beyond rideshare.

And then public transit then became, bikes and scooters, TBS and transit bikes and scooters. So we ended up building, public transit directions and multimodal trip planning and scooter support, bike support, into, into the Lyft apps.

Matt Klein: I do wanna come back to, to what we were talking about before, uh, uh, about, you know, the reverse engineering of various Apple artifacts.

And one thing that I think is interesting is I've been lucky enough on the podcast so far to have some prominent folks in the Android community and I I would like to talk a bit more just about the differences in, in your, from your perception of the Android side of the house and the Apple side of the house.

Because as we know, or most people know, Android started as an open source project [00:22:00] and you know, to this day the majority of it is still open source. Apple obviously comes from a more traditional closed source background. My perception, which could be wrong, is that the Android community is, at least right now, is a bit healthier.

Like in terms of the conferences and the open source and meetups and those kinds of things. And, you know, you, you have spent a lot of time in this ecosystem. You've run podcasts, you've done all kinds of stuff, and I, I, I, I'd love to learn from you a bit more, you know, A, is that true? Is it not true? If it is true or not true,

why? So I guess just talk to us a bit a, about kind of the, the split difference between the Android side of the house and the Apple side of the house.

JP Simard: Yeah. Yeah. There's a lot to unwind there. I, I think there's, there's ways in which I would agree with that distinction that, the, the Android community seems, in some respects, healthier and some, some of the things that, I mean, there [00:23:00] are that, there just seems to be a lot more support from Google.

Google has their, I forget exactly what it's called, I, I think it's an Android developer expert program, but they tend to be, very hands-on in terms of promoting, community contributions, community events, things like, the, this Android expert program, uh, again, I forget the exact phrasing that they use, the exact name of the program.

And in recent years, I think Apple's gone a lot further in that direction as well, with sponsoring and even speaking at some community organized events.

The, the other thing about Android in particular is that, uh, there's... with, with iOS and with the Apple development community, there's really kind of Apple as first party, and then everyone else is kind of very far behind in terms of, I don't know, prominence in terms of contributions to, to the language and the ecosystem.

A large part of [00:24:00] that being that iOS is entirely closed or, you know, 99.9% closed source. On the Android side, you've got folks like JetBrains that are actually contributing the Kotlin language and the Android studio, and then they're collaborating with Google. And so it to, to that extent, you know, there's, there's more, collaboration sort of at the top from what I can tell.

But looking at the, at, at the Apple and iOS side, I think there's a very vibrant community there as well, and it's just shaped a little bit more differently where there's the Swift evolution, uh, forums where people, go and debate and argue for language improvements or modifications. That's done in a, I, I'd say kind of hybrid, closed, open way, but

but leaning more open. The language, much of the surrounding tooling is also open source. If we look at IDEs and SDKs, right? A- Android's studio, still like a closed source JetBrains slash Google [00:25:00] product. Xcode still closed source, although more and more of, the Xcode or, or build system is being unified into something called Swift Build.

And then of course, everything much lower than that with LLVM being all open source as well, just kind of from an earlier generation, it's still still very much there. So I, I, I'd say that the communities are just kind of shaped differently. From my perspective there's a lot more, and this was true

to a larger extent, even like 10 plus years ago, but there's a large contingent of kind of indie app makers that tend to be, a little bit more Apple centric, right? And this dates back to the two thousands with, with the Mac. And you had Mac developers that had this vibrant, um, indie app maker community that has persisted over the years, even to now.

But there was really a shift in 2014 '15 with Swift. Where the entire kinda Apple developer [00:26:00] community really shifted hard on the language more so than the high level, like how do you run a business as an app indie?

Matt Klein: Yeah.

JP Simard: We're

starting to see a resurgence of that now that the novelty of Swift is wearing off 10 years later.

Matt Klein: Yeah, I mean, I can see pros and cons

of both models, right? Like, at least from a, from a theoretical perspective, Apple's control means that they can be, they can be opinionated and at least, like theoretically, they can have better APIs and a more consistent experience and all of those things. But the, but the flip side is, I guess the general story of open source is that, you know, when you have more people in, in the kitchen, you tend to have more ideas flourish and different things happen.

And I don't know, I mean, it's like you, you talk about IDEs and again, I I'm not a, I'm not a mobile developer, but it's like when I look today, and I do occasionally for the work that we do at bitdrift, I'll pop into Android studio or I'll pop into Xcode and it's like you look at Xcode in [00:27:00] 2025,

2026, and it's like, are you kidding me? Like, is this,

JP Simard: yeah.

Matt Klein: Is this for real? And, and it, it, it just, it just strikes me that maybe there's almost a lack of innovation happening, right? A- and again, like that's, that's kind of what I wanted to ask you is like

JP Simard: Yeah.

Matt Klein: Do you do, do you think now you know that the level of innovation between the two are the same, or is, is Apple almost constrained by its current situation?

JP Simard: Yeah, I mean there's, there's really different parts that you can, cut down there, break apart, right? There's, there's the language, there's the development, development and evolution of the language. There's the SDK, there's the platform, there's the final result, there's the IDE and the development experience.

Matt Klein: Yeah.

JP Simard: Um, on, on the developer experience. Yes, a hundred percent. I, I do feel like Apple has very much stagnated there. And I, I think they have, they have trade-offs, both like internally in their corporate structure and the way that they work, but [00:28:00] also in the, in the size and breadth of the landscape that they have to support that, does very much slow

slow them down there. For example, I, I, I think this initiative to shift and unify some of the Swift package manager and Xcode Build system work dates back years, right?

Matt Klein: Yeah.

JP Simard: And it's still very much in flux or, incomplete. Same thing for like the language server protocol that, I, I think like eight years ago, someone from the Swift team was on my podcast when that ran and said like, yeah, we're investing in LSP, which they have, but Xcode's still not broadly using it.

It's still using a, a lot of closed source things. And I'd say that, the, just seeing the way that the mobile development industry has evolved very rapidly in the last 12 months with the rise of agentic coding tools.

Matt Klein: Mm-hmm.

JP Simard: And, Cursor, Claude Code, Gemini, Codex, you name it.

Matt Klein: Sure.

JP Simard: People are more and more, letting go of the shackles of the IDE doing a lot of development, either strictly on the [00:29:00] command line or in

one of the many VS Code forks. And, perhaps they still have the IDE sort of sitting next to it where they can have a richer set of debugging tools and um, Xcode previews and better LLDB integration and things like that. Better, better ways to pick and select what simulator you're running on, things like that.

But that the bulk of development is increasingly moving out of the IDE, and that's just because both, honestly, Android Studio and Xcode have not been moving at the same speed as the rest of the industry.

Matt Klein: Well, and and that's, I I mean, again, we're, we're obviously going down the path talking about dev tools, but I do think it's, it's important and it does strike me that...

almost everyone that I know at this point, they basically run two IDEs typically, like, you know, sure maybe they use command line in Vim, but for people who use IDEs, typically they're using, they're writing their code in, as you say, one of the VS Code forks using [00:30:00] some, you know, copilot or agent tools or something like that.

And then they literally have Xcode open, you know, to compile the code and run it in the sim, like same for Android Studio. And it just seems like we've gone very wrong. Like from a developer productivity perspective, if that's, if that's how it's working today, at least from, from my perspective, it just seems a little backwards.

JP Simard: Yeah. Yeah, it is. And this has, uh, been a recurring theme in mobile development where you sort of are to some extent really beholden to the tools provided from above,

Matt Klein: right.

JP Simard: Um, the, the blessed path, right? And I've been talking about for years, how we actually have an opportunity to provide our own tools and, and fill, some of those gaps.

And in fact, SwiftLint sort of came out of like a demonstration talk in, in Berlin at UI Conf in I think 2016, where it was like... Apple has a tooling problem, but it's okay 'cause we can step up to the occasion, [00:31:00] right?

Matt Klein: Right.

JP Simard: Uh, as community members and, that seems, even more true today, where people are really, finding ways to reduce their reliance on, these closed source, provided from a blo- from above binary blobs of IDEs and other things.

And, trying to have a more flexible experience.

Matt Klein: Yeah. So when you were at Lyft, obviously you are on a product team. Did, did you continue to do open source work on the side or as part of your work at Lyft? Like how did that go?

JP Simard: Yeah, um, I mean this is, this is tricky for sure. I've continued contributing especially to SwiftLint, which is still very much an active use, for the last 10 years.

It's over 10 years old now. Just wild thinking about that. And it's been fascinating to see over time, members of the community step in and take more of a maintainership, role as well. Whenever I had moments where I couldn't contribute as much. I'd say for the last few years I really haven't [00:32:00] contributed as much.

Every now and again, I'll have like a few hours and I'll go and put up a bunch of PRs, and otherwise still maintain the CI infrastructure and stuff. But, over the years people have really stepped up, which is an interesting pattern just in software engineering altogether where, a lot of times people do step up when there's a vacuum in leadership or skillsets.

Matt Klein: Yeah,

JP Simard: right? And to to, to really find ways to encourage that in, engineering organizations.

Matt Klein: Yeah,

JP Simard: because it's tempting for, you know, the, the most knowledgeable person, you know, as a very senior person to jump on solving a problem 'cause they can do it quickly. But, we need an increasingly, with the shifting landscape, we need more opportunities for junior and mid-level people to gain that experience and, and learn by, trial and error that way.

Matt Klein: Yeah, for sure.

JP Simard: Um, so yeah, I continued contributing to, to open source, but, at various levels of, of time commitments over the years.

Matt Klein: Yeah. So, I would love to get into how you went to Ramp and, and and your current [00:33:00] work, but is there anything that you wanted to highlight from your, from your Lyft time that you wanna talk about?

JP Simard: Yeah. A little bit. So, after being with the transit bikes and scooter side of things for a few years, Lyft had this initiative, among several to, invest more in kind of the lower level technologies. And that's where you and I overlapped

Matt Klein: Yep.

JP Simard: While we were there.

Matt Klein: Sure.

JP Simard: Right? Uh, and, and maybe you can actually give more of that kind of high level, overview of, of that time at Lyft and, and that sort of investment in, those level technologies, right? Whether it be debugging, or, observability tools to, lower level networking control. Yeah.

Matt Klein: Yeah. I, I, I mean we're, we're obviously going into some of the precursor history of bitdrift itself.

But, you know, I, I guess to your point, the 60 second version is I think like many companies, you know, li- Lyft had a good [00:34:00] understanding that Lyft was a mobile first company, right? I mean, it's like if people had a bad experience on the app, that was it. You know, they would leave and go to a competitor. And I think that

as, as you know, mobile development is very challenging. I mean, it's like, there are a lot of hard things going on, a lot of hard problems that don't really apply on server. Um, and I think Lyft, like many other companies at the time, was trying to invest in better observability of what customers were actually seeing.

A good understanding that networking was o- often a complexity. You know, that, that the people were facing, especially for Lyft, where, you know, things were in cars and going on all the time. That's the history.

Would love to hear your, your perspective both on, on just either that work, but more generally, um, mobile development is challenging. Like there, there are a lot of problems that, you know, engineers have to face. And this is actually related to our [00:35:00] previous conversation a bit, which is I do find it fascinating and this has come up in several podcast episodes where, you know, if you look at both Apple and Google, you know,

at least from my perspective, they're still focused on getting the most apps in the app store. At least that's, that's my perspective, right? It's like they want more apps in, in the app store, but I still feel like to this day there are a lot of foundational... problems that aren't well solved in the mobile e- ecosystem, whether like large scale builds or like better observability or all of those things.

And the big companies, Google and Apple at least so far have kind of ceded this either to open source or to startups or like those, those types of things. And that's partly why Lyft was working on this, obviously, because it wasn't well solved within the industry. You know, but, but would love to hear your perspective on that.

JP Simard: Yeah. I mean, it, [00:36:00] it, it was... I'm trying to, um, to, to pick what side that I wanna be here. 'cause there's parts of that that I very much agree with and, and parts that I agree a little bit less, I guess.

Matt Klein: Oh, that's fine.

If you don don't agree, then, then please, please tell us. Yeah,

JP Simard: yeah. The, the, the parts in which I agree are like the, the observability story is quite bad, even today.

And I, I do think that, you know, bitdrift is, doing a lot of good work in this space. But uh, if you look at a lot of, what is, some of the worst issues plaguing mobile apps and the mobile ecosystem today, a lot of it is privacy related and

Matt Klein: interesting.

JP Simard: Apples and Google's reluctance to offer robust privacy minded solutions when it comes to this has meant that, there's a lot of tracking in, especially in third party SDKs.

Um. That really are, leaking out, just a ton of [00:37:00] information, outside of the application provider, that makes the app that you want to use. Um, and that is a foundational issue that, uh, the OS can be extremely privacy minded, but if the apps that you're running are all talking to the Facebook SDK and reporting everything that it can, and it's just to pick one, right?

Then, then that really doesn't give you a ton. So, I agree there's some aspects that are really foundational that I'd like to see the first party vendors invest more in, and both Apple and Google have their solutions there. You know, Google has, has Firebase, but they are, very much bolted on.

And there's an opportunity, I think to, to really think about it at a fundamental level. Otherwise, I, I think a lot of the, a lot of the lower level, tooling or, or at least... yeah, support for mobile is quite robust. And in fact, one of the things that we saw, [00:38:00] bringing Envoy to mobile was that, the, the, the networking stack on iOS, is extremely robust.

Matt Klein: Yeah, for sure.

JP Simard: And it was extremely challenging to, to outperform it.

Matt Klein: Yep.

JP Simard: At least consistently, you know, there, there were times where we were able to sporadically, for very specific configurations or things like that.

Matt Klein: Yep.

JP Simard: Um, so I, I actually, I, I think that a lot of the foundational support is actually quite strong.

The, a lot of the issues are at larger scale, right? Large builds, uh, were just going worse and worse in that direction.

Matt Klein: Yeah.

JP Simard: I, I think the, the teams both at Google and JetBrains and Apple have solutions that they're chipping away at, but it's, it's very slow going.

Matt Klein: Yeah, for sure. I mean, that's probably a

good segue into Ramp, right? And I mean, I would imagine that you're working on some of these things at this point. Obviously, Ramp as a company has grown a lot, so I'm sure you're dealing with some of these scaling challenges. Tell us a bit j- just about how you wound up [00:39:00] there and the types of things that you're working on and the, and the challenges that you're facing.

JP Simard: Yeah, so one of the big differences with Ramp, at least from where I've worked before, is really this emphasis on, on B2B. Ramp is... we bill ourselves as the time and money company, but it's really about, saving customers, time in the very real sense of hours and money in the very real sense of, of dollars.

And the way that we do this is via so many things, but, we offer spend management solutions, so credit cards, budgeting, reimbursements, to things like treasury and bill pay and procurement, things like that. And it's really about offering, a lot of solutions to help people who run businesses or, or who work at businesses spend more time, on the thing that they're actually passionate about, right?

Running that bakery or that startup or that, large [00:40:00] company even. And that as an employee, you don't have to think about this stuff as much. So the fact that it, it was such a clear kind of business proposition meant that, you know, it's not so much a like... social mission in and of itself, right? Which is what drew me to Lyft of like reducing carbon footprint, bike scooters, public transit, things like that, right?

It's extremely kind of commercial, right? But in a very real sense also, just, just helps people focus on what truly matters. And so I, I really liked that aspect of Ramp and I still very much do. And what's been fascinating to see over the last two and a half years since I've been there is that, a lot of times companies are trying to stuff, LLMs and and AIs into their products in a way that it doesn't exactly make sense or there's bad trade-offs.

But for something like Ramp where an LLM can read your expense policy. And probably apply it more consistently than any one human [00:41:00] whose job isn't to like fully understand that space. The fact that we have, you know, credit card data, coming in real time for those transactions, we, you know, see all the receipts, like all of that sort of fits together so that yeah, actually a machine should probably be doing this and not humans.

Matt Klein: Yeah.

JP Simard: And so that aspect, it, it has been refreshing. And, and then we sort of get to, okay, well what does building user interfaces at a time where we want to offload as much of the cognitive load to automation, what does that even look like? Right? Because there's still times where you want human oversight.

You want a human in the loop, you want to, imbue human values in a way that maybe isn't directly embedded in your expense policy document. And so how do you build UIs that way, that engage at, at just the right time, just the right level. So that, that's been what drew me to Ramp in large part and why I'm still there.

Matt Klein: There's a, there's a couple of things to, to unpack a bit that I'd love to learn [00:42:00] more about. One, I would imagine that working on a financial app, like just from a reliability perspective, I mean, there's, there's stuff that applies there that, yes, of course with Lyft you would like it to be reliable and people can get their rides, but I, I would argue that as you move into financials, um, you know, the, the reliability

goals are probably even higher. So would love to learn a bit about that just in terms of, you know, what it's like to work in that type of space. Like, is there any difference? And then also j- just from an engineering perspective, would love to dig in a bit more. Like obviously the, the product goals make sense.

Would love to learn just from a mobile engineering perspective, like what are the hard challenges that you're facing trying to make that happen?

JP Simard: Yeah. So on, on the first point of reliability, and especially in the financial space, you, you're absolutely right, the reliability is, is critical. However, client side networking, [00:43:00] is, notoriously unreliable, right?

Especially if you want very hard guarantees

Matt Klein: Yep.

JP Simard: Uh, of certain things e- either in time SLA or deliver exactly once or, mutating operations, things like that. So, in large part, much of the critical backbone is, is actually not via the mobile apps at all. So things like, credit card transactions have, a much more robust backbone than the cellular connectivity that you might have on your phone.

So, so a lot of those critical operations are really, outside of the, the mobile app per se. Some of the things that you can do when- within the app are things like u- uploading your receipt or setting a, a memo or tweaking maybe some of the automation rules, seeing your transactions.

Those don't quite have the same reliability requirements. But there are some interesting engineering challenges. Namely, one of which, we want the app to have access to as little sensitive data as possible. And so one of the things that we do, for example, [00:44:00] are to not return, any of the sensitive credit card data directly in our APIs, we render those out of process in an embedded, web browsing window that's completely ephemeral and completely sandboxed.

Matt Klein: Right

JP Simard: so that even if we wanted to go and poke at, you know, things like credit card numbers from the app, you, you broadly couldn't.

Matt Klein: Yeah.

JP Simard: Um, so there's like engineering challenges and, and, decisions that you can make there. And then, I think the most interesting challenges are actually more kind of organizationally and architecturally, where, we have an extremely lean mobile engineering team, anywhere from two to four people per platform.

Matt Klein: Oh, wow. That's still

quite

small. Yeah. Wow.

JP Simard: Yeah, exactly. So

Matt Klein: interesting.

JP Simard: You know, you contrast that with Lyft where we had hundreds of mobile developers.

Matt Klein: Yes.

Ab- absolutely. Yeah. Wow.

JP Simard: The kinds of things that are worth investing in are very different at that level. Also the nature of the [00:45:00] apps being, so B2B, it means that we have very strong touch points with effectively every customer that we have.

There's an account manager, and so e- even if there's something that's only impacting one customer, there's still an escalation there that

Matt Klein: Yeah.

JP Simard: Loops in en- engineering. And so it really contrasts that with something like Lyft where you can't have a relationship that's that hands on with every single user.

Matt Klein: Of

course. Yeah.

JP Simard: Um, so you sort of rely on a really broad metrics to give you any sort of signal of what's going on versus, we can rely and, and lean a lot more on, on individual relationships that we have and, and the whole machine of making sure that our customers are happy that exist between product, engineering, and the customer.

Matt Klein: How do you, how do you think you've been able to do it so far with so few devs? I, I mean that, it's actually really surprising to me, just, just based on the size of the teams that I know of other, I would say comparable companies.

JP Simard: Right.

Matt Klein: So would love to learn more about how, how that [00:46:00] works, because that's very impressive.

JP Simard: Yeah, it's, it, it's been one of the most rewarding aspects, honestly, is that a lot of the people who come and work at Ramp in general, but on mobile team this applies very strongly, are people who are self-starters. They're, very strong coders, no, no matter sort of where on the, career ladder they are, if they're early career or late career, they're all very strong coders.

Everyone has a strong sense of like product ownership and agency. And, we keep an extremely close eye on things like, just app store ratings and play store ratings. And like I mentioned, every time that there's a customer that is hitting a rough edge, even if it's not necessarily a bug, it's kind of a paper cut in the UX or it's a design decision, there's an escalation path there.

And so just the, the organization is really set up in a way where people can have maximal impact. There's a lot of dogfooding of the product as well, right? Where people, whenever they travel for work, they're using the, the product [00:47:00] for, to book travel, to manage their flights, to manage their spend and their budget and book hotels while they're there.

Or, you know, as, as managers in the company we get to approve and review our direct reports, transactions, and, and things like that when, when they need approval. So, there's a lot of dogfooding of the product, and there's a lot of just ownership.

Matt Klein: Yeah. Cool. Wow. So, as we get to the end of the episode, would love to learn more about what excites you currently, but bonus points if it's not AI related, but you're happy to talk.

Yeah, we can, we, we can talk about AI as well, but I think my new rule on the podcast is I'd love to have one thing that excites you about the future, that is not AI. Even if you also talk about AI.

JP Simard: Yeah. So I, I, I'm still gonna answer this because it's... AI's secondary to this.

Matt Klein: Okay.

JP Simard: The, the primary thing is, people, in, in software, have always wanted these write once and build everywhere type [00:48:00] solutions, right?

And which is why, React Native is seeing such

Matt Klein: Yeah, sure.

JP Simard: Uh, a resurgence really. And things like Electron on, on desktop and things like that. And the reality of those is you can actually build a fantastic app using those types of tools. They have very interesting sets of trade-offs. I, I think the gold standard that comes to mind is really the Shopify mobile apps, which are extremely polished.

They're, they're, they're very strong and, and they're mostly built primarily with technologies like React Native. However, the size of team that you need to support an operation like that, I- is much larger than you would actually think, from the get go because you need to invest in tooling that

goes off the beaten path or goes off the, the golden path, rather that, Google and Apple are providing. You need to invest in strong ways and strong culture for people to actually test across multiple [00:49:00] operating systems. And then you also need to invest all of the domain knowledge and taste of like making an idiomatic app when it, it follows the right UI conventions and the look and feel of that platform doesn't feel bolted on.

So there's actually, there's a ton

Matt Klein: interesting

JP Simard: of overhead to go from like, yeah, it runs to, it is a polished app. And what I found really fascinating over the last 12 months is seeing how AI, I'm gonna mention it, is really shifting the calculus there where one of these, these tools are terrible at so many things, but one of the things that they're actually incredibly well suited is just translating languages, right?

Matt Klein: Yeah.

JP Simard: Whether it's human language or whether it's, uh, programming languages. And so, when you have a team, and I think this has been key to the velocity, that we've been able to have in Ramp's mobile engineering team is when you can say, 'Hey, my iOS counterpart just did [00:50:00] this feature, here's the pr you have access to my code base.'

And, and then you can have it take a lot of the hard things, which isn't syntax, it's not Jetpack Compose versus Swift UI. It's, it, it's a lot of the, okay, well what's the domain like knowledge that you need to really do this effectively?

Matt Klein: Right.

JP Simard: What are some of the edge cases? What's the right way to abstract this?

Those things, if you've done a good job on, on one platform, and that could be web as well, you can then fairly quickly go and apply it to uh,

Matt Klein: interesting

JP Simard: different platform, different code base, different language. And so that's one of the things that excites me the most about the future of mobile engineering is finding ways for people to be more effective with

the platform native technologies, with more of a like architect once and run everywhere, kind of mindset than, you know, code once run everywhere.

Matt Klein: Yeah, I mean, that, that's super interesting. And as a, as a non-primary [00:51:00] mobile developer, I, I just, I am fascinated by, I feel like in the very beginning, you know, I don't know, like a lot of apps were built on,

we're built on web views and then, you know, people wanted speed, I guess, so they went to native and then now they're coming back to, as you say, like React Native or Flutter. And it, it almost makes me wonder in the long term, is are things gonna come full circle? Like, are apps just gonna be web views

again? I, I mean. I don't know.

JP Simard: It's a great

question.

Matt Klein: Yeah,

JP Simard: it's a great question. And I, I don't know. We are seeing that, and unfortunately again here, you're, you're really limited by what, the OS provider does, right?

Matt Klein: Right.

JP Simard: And so I, I actually would... i, I have the same dilemma or same question of what if, right?

What if Apple had gone all in on what they initially called their suite solution of letting you build web apps and, and have that be prior to the app store, right? The first [00:52:00] way that you could build iPhone apps. What if they had just invested everything that they invested in, native SDKs and, and really, put that energy towards web and I think we'd be in a very different place now.

Matt Klein: Hmm.

JP Simard: Um, and, and it's, it's the kind of thing that is hard to say in retrospect or even

Matt Klein: Yeah, of course.

JP Simard: In the future,

Matt Klein: yeah.

JP Simard: If we'd be better off or not, but I think it's a really interesting thought exercise and I, there's some days where, where, I, I wonder and, and you don't have to throw the baby out with the bath water either.

You could lean further in that direction,

Matt Klein: agree

JP Simard: without going a hundred percent. So it's, it's a fascinating question and one that I don't have the answer to.

Matt Klein: I, I completely agree that the AI tools are excellent at what, at what you said, but at the same time, I think we would both agree that one code base is better than two,

right? It's like even if you have a tool that that can translate to both. I mean, it would probably better if you had one. [00:53:00] And, I don't know. I, I just think it's super interesting that as an industry we seem to go back and forth on some of these decisions and with the tools that we have now, and maybe it is easier to maintain multiple code bases.

It'll be interesting to see how things evolve. So anyway, this was a great conversation. Any parting thoughts before we leave?

JP Simard: Just wanna say that, yeah, like the, the Ramp mobile team has been extremely lean and, it's something that, that we want to start shifting a little bit. So if you're interested in doing this kind of, engineering work,

Matt Klein: okay, great.

Absolutely. Yeah.

JP Simard: Take a look at ramp.com careers.

Matt Klein: Awesome. Well on that note, thank you JP. This was, a great conversation. I certainly learned a lot. I think people out there did as well. So that's a wrap for this episode of Beyond the Noise: Signals, Stories, and Spicy Takes. Huge thanks to JP for joining and sharing his story.

You can find this episode and all past ones on the bitdrift YouTube channel. If you had fun, drop us a [00:54:00] review, tell your friends or yell your favorite hot take into the void and just make sure to tag us. I'm Matt Klein, and I'll see you next time.

Matt and Ty chatting

Scaling Mobile at Uber: Ty Smith on Community, Toolchains, and the Next Dev Productivity Wave

January 12 2026

60 mins

Matt Klein and Jesse Wilson discussing open source, mobile engineering, and WebAssembly

Jesse Wilson: From SourceForge to OkHttp, and Why WebAssembly Beats the AI Hype

February 24 2026

60 mins

Subscribe for new episode announcements


© 2023-2026 bitdrift, Inc. All rights reserved.

SOC 2 Type II Compliant