Crash-Free Isn't Enough: Inside Tinder's War on App Hangs

Matt Klein: 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've transformed 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'm thrilled to have with us Aaron He, Engineering Director for the Client Platform team at Tinder, responsible for infrastructure, stability, and performance across all of Tinder's client apps. He joined Tinder nearly a decade ago as an Android engineer, initially focused on growth projects, before building out the Android and iOS platform teams. Aaron, welcome. Thank you for joining us.

Aaron He: Thank you for having me.

Matt Klein: I'd love to start with you. How did you get into mobile? What excites you about it? How did you end up choosing Android over iOS?

[00:01:30] FROM XAMARIN TO ANDROID

Aaron He: When I graduated from grad school, I got a job doing web CMS work for contractors, big clients like Samsung and NBC Universal. It was mostly about managing contract workers' time: clocking in, clocking out. A lot of our competitors were starting to build mobile apps, and we figured it would help, since it's a lot more convenient to clock in and out from your phone. So we started building a mobile app, including one for managers to approve time easily.

At the time we were basically a C# shop, this was around 2012, so I became a big proponent of Xamarin. We were a small company, and it would have been expensive to fund a dedicated mobile team with separate iOS and Android expertise. So we landed on Xamarin because we could share business logic with the back end and ship one app that worked on both platforms. That's how I got into mobile.

Funny enough, even though I started as an engineer at Tinder, I'd actually never owned an Android phone before that. I had a Windows Phone, because I was much more of a C# guy at the time, doing web services in C#. Before that, a BlackBerry.

Matt Klein: I also had a Windows Phone. You and I are probably two of the ten people who ever owned one.

Aaron He: Probably. Around the time the iPhone 4 came out, I was blown away by the Retina display, and that got me to switch to an iPhone as my daily driver. I actually wanted to focus on iOS at work. But my tech lead at the time had already claimed iOS, and since I was new, I got put on Android instead. I tried a couple more times to switch when the other iOS engineer left, but the tech lead said no, so I stayed on Android.

I ended up having a lot of fun with it. I had no idea how welcoming the open source community was at the time. We ported a lot of Java libraries into C#. I learned a lot comparing Java, which was still on Java 6 at the time, to C#, which already felt like a much more advanced language. I personally ported the TimesSquare library from Square, which rendered a calendar table view, into Xamarin. I was also trying to compare some performance to either any scroll hedges and stuff like that. That was pretty fun. I also collaborated with someone in the community on bringing an action bar implementation to Xamarin, though we didn't end up picking the one that later became the foundation of Google's AppCompat library. We went with a different one, but it was still fun porting it over.

Matt Klein: Did you ever find yourself porting so much code to C# that you questioned whether you should just be writing native apps in the first place?

Aaron He: That's a good question, and it's actually part of what got me into Kotlin. Android was stuck on Java 6 or Java 8 for a long time, and that's when I first heard about a project called Kotlin. It's the default language for Android today, but back then, twelve or thirteen years ago, it was still at milestone one or two. I remember Jake Wharton from Square giving a proposal in 2013 advocating for Kotlin adoption in their codebase, and that's when I really dug into it. I thought if it ever got officially supported, that would be huge.

[00:06:45] CROSS-PLATFORM VS. NATIVE

Matt Klein: It seems like the mobile industry keeps cycling through cross-platform approaches. You had Xamarin, now we have React Native and Flutter. I'm not a mobile developer myself, but it feels like the industry goes back and forth: cross-platform, then native, then web apps, then cross-platform again. I'd love to hear your thoughts.

Aaron He: I think it really depends on the use case. There's a well-known example of Airbnb writing publicly that they were no longer investing further in React Native. One of the engineers on my team moved to a small startup a couple of years ago that builds purely on React Native. When I talked to him recently, he said they weren't planning to move off it anytime soon, because they're still focused on finding product-market fit. When you're in that stage, prioritizing speed over platform-specific polish can make a lot of sense, even if you have strong native iOS and Android engineers on staff.

As companies grow, code sharing becomes a bigger topic. We've had heavy internal debates about investing more in Kotlin Multiplatform. From a business perspective, there's never really a silver bullet. There are always tradeoffs. You might gain developer productivity by not maintaining two codebases, but there's a real cost too. I've heard stories of teams trying to get React Native to coexist with an existing native stack, and that migration alone can be a huge investment. My friend who still works in React Native gets frustrated with a middle layer that obscures where a bug is actually coming from. Those tradeoffs need to be carefully weighed before committing to a stack.

Matt Klein: It's a tough tradeoff. All things being equal, you'd rather not duplicate code across platforms. With LLMs now, porting code might not be as expensive as it used to be. On the client SDK side at bitdrift, we've gotten a lot of value out of writing shared logic in Rust, which lets us share code across platforms while still building native layers on top where it matters. Once you get into UI, though, it gets trickier, since there's so much that's platform-specific. It's always surprised me how many companies maintain separate giant teams for web, iOS, and Android, with a lot of duplicated feature work across all three.

Aaron He: I agree. Tinder is known for its swiping gesture, and that's a good example of where sharing gets difficult, because we're working with a lot of low-level animation APIs. We can abstract some of it, but especially on Android, the animation APIs have gone through so much evolution that building a shared abstraction layer that makes sense on both platforms takes real time and effort.

[00:11:48] TRUECAR AND THE DATABASE DOWNGRADE OUTAGE

Matt Klein: So you're at this small company doing Xamarin development. What happened next?

Aaron He: I moved to a company called TrueCar, which was trying to make car buying easier, since everyone hates going to the dealership. That was my first full-time job as an engineer, as opposed to doing a mix of full-stack web work. The interview process itself was memorable. I was given a take-home coding challenge to build an Android app, and I wrote a lot of unit tests. I passed, but during the onsite they pointed out that the app crashed when you rotated the screen. I didn't realize it, because in the Xamarin world things were abstracted well enough that I never hit that case. It turned out I'd only ever configured the app for portrait mode. Even so, they were impressed by the test coverage and hired me.

My first two days on the job, there had been an incident. A hotfix had shipped with a version code lower than the production version, a classic mistake, which caused the local database to downgrade. We hadn't handled database downgrades, so the app just crashed. This was around 2014, when Android tooling was much less mature. Most Android engineers were still using Eclipse, and we were using a Maven plugin, so getting instrumentation tests running required a lot of manual customization. My first task was writing a test that could reproduce that downgrade scenario and confirm it no longer crashed the app. It took a lot of digging through Maven plugin internals, and I had a lot of fun with it, even though a lot of people today would probably take that kind of tooling for granted.

Matt Klein: How did you actually fix the outage? If the database downgrade was crashing the app for everyone, how did you get people back up and running?

Aaron He: We shipped another hotfix that bumped the version code so it was correctly recognized as an upgrade. To prevent further crashes, we handled the downgrade case by recreating the database from scratch on the client. Fortunately, the database was local only, so once it recreated and re-synced with the server, everything came back. But because we hadn't handled that scenario originally, people couldn't use the app again until they reinstalled it.

Matt Klein: So people lost their local data.

Aaron He: Temporarily, yes, until it re-synced. Looking back, if that happened today with the scale we're at now, it would be a lot harder to recover from cleanly.

Matt Klein: That kind of bug can absolutely still happen today. It's a great example of how difficult mobile development is, since you end up with so many app versions in the wild that you can't fully control.

Aaron He: We actually had something similar a couple weeks ago. Some of our metrics started dropping, and it turned out to be a flag that only mattered for internal users. We'd migrated some backend infrastructure, and fetching that flag started hanging because the underlying service hadn't been updated to reflect the migration. Since we were still waiting on that flag before constructing certain analytics events, those events never got sent, and the flag never arrived. The app didn't crash or show any performance regression, it just quietly dropped data in the background. When the team asked if we could backfill it, we couldn't, because the events were never constructed in the first place. It's still very relevant today, unfortunately.

Matt Klein: Especially if you're driving business metrics off client-side events. There's a whole debate about deriving metrics from server-side events versus client-side ones. Presumably server-side is more reliable when it's possible, but there are things you can only know if they happen on the client.

Aaron He: That's been a recurring debate for us at Tinder too. Whether something can be derived or tracked reliably from the backend or data engineering side, versus whether we still need to send it from the client.

[00:20:16] JOINING TINDER AND BUILDING SHARED INFRASTRUCTURE

Matt Klein: Let's go back to your career. You were at TrueCar, and then what?

Aaron He: They laid off the entire mobile team. I still don't know exactly why. I believe TrueCar still has a mobile app today, and a few months after the layoffs they released a new app built purely on React Native, so maybe there's some personal bias in my views on React Native versus native because of that. That's when I started job hunting and landed at Tinder, where I've been for almost ten years now.

Matt Klein: You joined as a line-level Android engineer. Tell us about that journey to where you are now, managing people across multiple platforms.

Aaron He: I started on a couple of growth projects. One was around login. At the time Tinder only supported logging in through Facebook, so there was an obvious growth opportunity to open things up to people who preferred SMS login with just their phone number. The tricky part was that Facebook login gave us a lot of information up front that shortcut onboarding, so moving to phone-based login meant rethinking the entire onboarding flow when all we had was a phone number. That was close to a year-long project.

Around the same time, I noticed there wasn't much investment in shared frameworks that could improve engineering efficiency. Android had just introduced runtime permissions, I think this was around 2015 with Marshmallow, replacing the old model where all permissions were declared up front in the manifest and granted at install time. Now you had to request permissions contextually at runtime. We had several places in the app requesting access to photos, camera, and location, and I felt like if we built a good abstraction layer around when and how to request permissions, we wouldn't need to reinvent that logic in every feature.

That's really what excites me: building a strong abstraction layer that improves the whole team's productivity. Early in my career I always told my manager I didn't want to move into an EM role, I really enjoyed being an IC, and in some ways I still do. But when I saw this kind of infrastructure gap and nobody was raising it with leadership, I had a great manager and mentor, someone I still talk to almost every month even today, who told me to read a management book and start thinking seriously about how to build a team and make sure those gaps got addressed. That was a very different challenge than I expected, but my goal was really just to make sure we were investing in that area, so I took it on and started building out the team.

[00:25:50] TRUST, CREDIBILITY, AND AVOIDING ANALYSIS PARALYSIS

Matt Klein: I think our industry is genuinely bad at measuring whether things like shared abstraction layers actually save people time. We can fall into analysis paralysis, spending longer debating whether something is worth doing than it would take to just do it. So sometimes you have to trust your intuition. I'd love to hear how you thought about that as an IC pushing for developer efficiency work that's inherently hard to measure.

Aaron He: That's something I think about constantly. We're actually working on a tool right now to measure engineering productivity. But on the analysis paralysis point, I think it really comes down to trust with your manager. I worked on one infrastructure migration project on and off for almost two years. I had the initial API ready in about two weeks, but the full migration took much longer, and I wasn't dedicated to it full time throughout. To get a manager to fund something like that for two years takes a lot of trust. I didn't have to build a formal business case showing, this currently takes five days and will take one day after the migration. It came down to a cycle of saying what I'd deliver and then delivering it.

There's actually a funny story from that project. About six months in, my manager asked how much longer I thought it would take. I said maybe one more month. That kept happening for the next twelve months. I think he eventually gave up asking. But I think the trust came from him understanding the problem deeply and from us having worked together long enough that he knew I'd deliver, even if the estimate kept slipping because I wasn't fully dedicated to it.

Matt Klein: That mirrors my own experience. You build credibility on smaller projects first, ones with clear value, maybe you make another engineer's life noticeably better. Over time that expands into being trusted with larger projects based on intuition alone. That's generally how I've gotten out of analysis paralysis cycles myself. Once you've built that credibility, people start trusting your read on what will save time, even without hard data.

Aaron He: Starting small is definitely key. For that two-year project, I built the initial API design in a couple weeks with full test coverage. The public API has barely changed since then, the only real shift was moving from RxJava to Coroutines internally. That early version gave leadership enough confidence to start migrating a couple of teams, who immediately saw the benefit, and from there people understood it was just a matter of time before the rest of the app migrated. It let us avoid over-investing up front and getting stuck in a sunk cost situation.

I'd say the bigger challenge with analysis paralysis is when your management team doesn't see the problem the same way you do. I've hit that a lot, and honestly it's been a growth opportunity for me too, because it forced me to think about why they weren't seeing it the way I was. We're all engineers, but people look at problems from different angles, and a lot of it comes down to communication skills, explaining the problem in a way that's relevant from their perspective, not just yours.

One example I keep coming back to is when we wanted to consolidate our CI systems. Android was on one vendor, iOS on another, and the backend team had built something in-house on top of Jenkins. The backend team was pushing their own solution on us, and at the time I assumed it was obviously not a good fit for mobile. But convincing leadership of that meant I actually had to understand why the backend team had built their CI system the way they had. Backend teams often have fast rollback capabilities, so the urgency around catching issues before release isn't as high for them. On mobile, once you release, it's out there. If people are hitting crashes from something like that downgrade bug, they're stuck until a new release goes out.

Going through that process of understanding where the backend team was coming from taught me a lot about the actual differences between mobile and backend release models, and helped me communicate more effectively about why mobile needed to prioritize different things in its CI investment.

[00:36:51] STAYING CLOSE TO THE CODE

Matt Klein: I think that's sometimes called managing up, or managing sideways. One thing I wanted to ask, from both directions, having managed up and now managing others, is that as people move further from the code, it can get harder to empathize with what's actually happening day to day. If someone hasn't done line-level work in years, they might be out of touch with how things really work now. You've gone from line-level engineer to EM to managing multiple teams. How do you think about staying connected to that reality, both as someone who reports up and now as a manager yourself?

Aaron He: It comes back to trust again, and also empathy. My engineers are the ones deep in the infrastructure issues day to day, and I try not to just brush off what they're dealing with. I also try to make time to write code myself when I can, not on critical paths, but enough to try out new APIs and frameworks hands-on. That's very different from working in a demo app versus a legacy codebase with millions of lines and hundreds of contributors.

A recent example was that analytics reporting bug we discussed earlier. I got involved in reverting the fix myself, partly to understand the actual risk of a straight revert. It's still a career goal of mine to stay as close to the field as possible. I can see my own hands-on contribution has dropped a lot over the years, I think I only had fewer than ten PRs last year, but I still try to dig in when I can. One example was a large API migration my team designed that got a lot of pushback. I trust my team's judgment, but I also took the feedback seriously, so I worked through the migration myself. That helped me identify real room for improvement in the API design and made the transition smoother for everyone.

Matt Klein: I've seen people write that in the age of AI coding tools, it's gotten easier for managers to dip back into the code. Do you think that's true?

Aaron He: I do. I'm seeing even non-technical people, like product managers, using AI coding tools regularly now.

Matt Klein: What are the biggest challenges your team is facing right now, both within Tinder and in mobile more broadly?

[00:41:50] PERFORMANCE, APP HANGS, AND ANRS

Aaron He: The past couple quarters we've focused heavily on app performance. Crash rates have historically been solid, around 99.6 to 99.7 percent crash-free on iOS and 99.5 percent on Android, so we're happy with that. But app hangs and ANRs, Application Not Responding events, are a much bigger challenge, both detecting them early and finding the root cause quickly. Hangs and ANRs are similar to out-of-memory crashes in that the stack trace you get often doesn't point to the actual root cause. Figuring out how to surface useful signals before something ships, or before an experiment fully rolls out, is probably our biggest ongoing challenge. And it's not just for our team, since we're the ones focused on performance day to day, but for feature teams too, making those tools accessible so they're not always dependent on us to diagnose issues.

Matt Klein: I'm obviously biased here, since we built an entire company around the idea that for most teams, crashes aren't actually the biggest problem. How do you approach actually improving performance? Measuring it consistently, establishing a baseline, all of that is genuinely hard, and we've talked about how that can slide into analysis paralysis. But for these kinds of changes you do need to run real experiments and confirm you're not making things worse.

Aaron He: Some performance problems are more tractable than others. Startup time is a good example. It sounds simple: start a timer when the icon is tapped, stop it when content appears, but getting that measurement right is genuinely tricky, with all sorts of platform and OS-version quirks you don't fully control. We used to rely on third-party vendors to track it. When we brought it in-house, we wanted to correlate it with our experimentation platform, since we run about a hundred experiments a day and need to know whether any of them are regressing performance. Weekly client releases are one release cadence to manage, but experiments rolling out in between releases are often the bigger source of performance and crash regressions we need to catch.

That's part of the challenge of working on a larger mobile team: you can't personally review every change anymore. I used to review every PR on the Android team when I first started at Tinder. I stopped doing that a few years ago because it wasn't sustainable, and it didn't actually prevent regressions from happening anyway. So instead we've focused on building tooling that attributes performance regressions to the right team and experiment, and surfaces the top crashes or hangs associated with a given experiment compared to its control group. Once a team gets past the initial pushback, the feature is probably fine, they usually want to know how to fix it and what the root cause is. Giving them tooling to identify likely signals, especially for hangs and ANRs, has helped a lot.

[00:47:21] TEAM ATTRIBUTION FOR PERFORMANCE ISSUES

Matt Klein: Team attribution still feels like a largely unsolved problem industry-wide. People lean on heuristics, screen-based attribution being the most common one I hear about, but it's obviously imperfect. Any advice for teams trying to tackle that?

Aaron He: It's still largely unsolved, honestly. A single screen is often composed of multiple smaller views owned by different teams, so even screen-based attribution has real gaps. Our strategy is still to start attribution at the screen level, because that's usually where the team's investigation naturally begins. Even if a hang happened well before that screen rendered, the metric that team cares about, like a conversion rate, is what actually got impacted, so it makes sense for them to start there. Ownership on mobile can get blurry in a way that's different from backend, where a team clearly owns a given microservice. On mobile, when a screen is composed of multiple views working together, who's actually responsible for the interaction between them isn't always clear.

Matt Klein: Really interesting topic, we're almost out of time though. Any other big focus areas for your team right now?

Aaron He: That's probably the number one thing. As the team's grown, performance had been somewhat overlooked for years, so we spent a lot of time firefighting to get to a good baseline. The next stage is making sure that once we're out of firefighting mode, we have frameworks and guardrails in place to catch these issues as early as possible, ideally at the coding stage itself. That's been our focus for the past quarter, and probably most of this year.

[00:50:07] AI, LEARNING, AND WRAPPING UP

Matt Klein: It's refreshing to hear you say the focus isn't primarily AI.

Aaron He: I do think about AI, but more from the angle of learning. It's a bit like the old Stack Overflow copy-paste problem: some engineers just copy code that works and ship it without really understanding it. If you're focused on learning, AI can get you there faster, but the question is whether you're actually learning from it. I've heard people talk about writing something three times: once with AI to move fast, once yourself to actually learn it, and a third time to get the architecture right. How we use AI to still promote real learning, as engineers grow from junior to senior, is something I think about a lot.

Matt Klein: That's a great place to end it. I think we could do a whole episode just on that topic. It's something I think about constantly too, especially over the last six months, since I'm writing most of my own code with AI tools now and genuinely wonder how we train the next generation of engineers who need to understand how all of this actually works. Thank you so much for joining us, Aaron. This was a fantastic conversation.

Aaron He: Thank you so much.

Matt Klein: That's a wrap for this episode of Beyond the Noise: Signals, Stories, and Spicy Takes. Huge thanks to Aaron for joining and sharing his story. You can find this episode and all past ones on the bitdrift YouTube channel. And if you had fun, drop us a review, tell your friends, or yell your favorite hot take into the void, and make sure to tag us. I'm Matt Klein, and I'll see you next time.