# Bumble Tech We're the tech team behind social networking apps Bumble and Badoo. Our products help millions of people build meaningful connections around the world. - Medium This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## A Practical Loop for Optimizing GPU Inference Throughput DevFeed: [A Practical Loop for Optimizing GPU Inference Throughput]() Original publisher: [Read original article]() Author: Andrei Potapkin Published: 2026-05-01T17:57:59Z Content type: article Language: en Sources: [Bumble Tech]() Topics: [Inference](), [Optimization](), [GPU](), [Benchmark](), [TensorRT](), [onnx](), [Cloud](), [migration]() Tags: [benchmark](), [cloud](), [cloud-migration](), [gpu](), [inference](), [nvidia-nsight-systems](), [onnx](), [optimization](), [python](), [tensorrt]() ### AI overview This practical article describes a production-focused loop for optimizing GPU inference: benchmark under representative load, identify the current throughput bottleneck, fix it, and verify the operational outcome. In the described ML moderation service, TensorRT, BF16, and an attention-subgraph rewrite increased throughput from roughly 150 to roughly 1100 requests per second in the same saturated benchmark. ### Source excerpt A practical loop for optimizing GPU inference without guessing It wasn't an incident. That made it interesting. A few days after a cloud migration, one of our highest-traffic ML services looked healthy. Traffic was flowing. Latency was fine. The rollout had gone the way you want these things to go: boringly. And yet a Slack thread started anyway. Not because anything was broken. Because something had become easier to see. On-prem, GPU efficiency tends to get folded into bigger conversations: capacity planning, hardware timelines, headroom for the next model. In the cloud, the same question sharpens. Throughput, utilization, and cost sit much closer together. A service can be perfectly healthy and still look expensive. That was our situation. We had a frontend text moderation model based on mT5, served through NVIDIA Triton as a two-component ensemble: a Python tokenizer and a static ONNX model. The service was stable, but throughput per GPU was much lower than our back-of-the-envelope estimates suggested Moments like that attract the usual optimization advice: Batch more aggressively. Tune Triton. Rewrite the Python stages. Enable TensorRT. Drop precision. None of that advice is silly. Some of it is very good. The problem is that it usually arrives before the diagnosis. GPU systems are awkward that way. By the time you go hunting for "the optimization", you are often already asking the wrong question. There usually isn't one magical fix. There is a bottleneck somewhere in the stack, and then another one behind it, and usually another one behind that. The loop that kept us honest was simple: TL;DR Benchmark the system under production-shaped load. Find the bottleneck limiting throughput right now. Fix that bottleneck. Check whether the operational outcome changed. In our case, that loop took us from roughly 150 requests per second to roughly 1100 in the same saturated benchmark: a bit over 7x baseline. TensorRT delivered the first big jump. BF16 moved the ceiling aga ## Bumble chooses Tuist for iOS project scaling after comparing SPM and Bazel DevFeed: [Bumble chooses Tuist for iOS project scaling after comparing SPM and Bazel]() Original publisher: [Read original article]() Author: Jonathan Crooke Published: 2024-03-12T15:23:14Z Content type: comparison Language: en Sources: [Bumble Tech]() Topics: [Tuist](), [iOS development](), [bazel](), [swift-package-manager](), [Xcode]() Tags: [bazel](), [ios-development](), [swift-package-manager](), [tuist]() ### AI overview In the final part of Bumble's build and project-management overhaul, the team explains why it chose Tuist over Swift Package Manager and Bazel for its iOS project-scaling needs. It found SPM's Xcode integration too slow at its scale and considered Bazel powerful but costly to adopt and maintain. ### Source excerpt Scaling iOS at Bumble: Part 3/3 -- Results and Developer Quality of LifeRecap This is the third and final post in a series on our 2022 & 23 build and project management overhaul. We investigated whether one (or none!) of Swift Package Manager (SPM), Tuist or Bazel would be the tool to overcome our project scaling challenges. In the first post we explained the state-of-play coming into this project. In the second we discussed the results of our proofs of concept. In this post we will explain our conclusions, and talk about the migration project itself. The decisionWe chose Tuist It shouldn't be much surprise that we didn't choose SPM. In fact, we found it to be entirely unsuitable for our use case. This isn't to say that SPM is a poor tool in general -- far from it. Initially we would have preferred to adopt it, however we couldn't ignore the fact that, at least regarding its Xcode-integration, SPM exhibits unacceptably poor performance for our use case, and at our current scale; and this is before we consider our expected future scaling! For those starting new, or smaller projects, SPM seems to provide a nice user experience. However, it also deserves to be regarded as a "first-party CocoaPods". It serves a very similar use-case, and may lead to similar performance drawbacks. Bazel was a different matter. It is undoubtedly a powerful tool, but is a high-investment choice; compared to both SPM and Tuist it diverges much from the traditional iOS development experience, increasing disruption for developers. Also, since Bazel experience is still quite uncommon, this adds extra onboarding load for new team members. We also need to support and maintain infrastructure internally; we have small infrastructure teams and Bazel presents concerns about poor bus factor for a tool that is a single point of failure. During our proof of concept it became clear that in spite of its power, Bazel would be costly for us in the short term. In comparison, Tuist hit a sweet spot between the ## Refining Compose API for design systems DevFeed: [Refining Compose API for design systems]() Original publisher: [Read original article]() Author: Yury Published: 2024-02-21T11:10:51Z Content type: article Language: en Sources: [Bumble Tech]() Topics: [Design system](), [Jetpack Compose](), [User Interfaces](), [API](), [Material Design]() Tags: [android](), [api](), [compose](), [design-systems](), [jetpack-compose](), [kotlin](), [material-design](), [user-interfaces]() ### AI overview This article explains how to design custom Jetpack Compose components for internal design systems. It compares restrictive APIs, which enforce predefined usage but limit extensibility, with relaxed Slot APIs that accept lambda-generated content and support more flexible component variants. ### Source excerpt Jetpack Compose both makes it easier and promotes usage of an internal design system by creating custom Compose components. But how should we build these components? In this article, we will take a look at possible implementations of a design component, explore their API verbosity and extensibility, and how we can find a balance between these characteristics to make Compose components both easy to use, enforce design system guidelines and extendable on demand. Let's get started! Design System and Compose A design system is a comprehensive set of guidelines, components, and rules that help to build cohesive and consistent user interfaces. The most common design system for Android developers is Material Design 3 which is available for Compose too. Custom design systems might be built on top of existing systems like Material Design or can be created from scratch. Compose provides all the tools that are required for this process. Design System NavigationBar Let's take a look at NavigationBar. A usual NavigationBar that we can see almost in every app. The design system in this case defines the following properties: Margin between the component borders and the content. Margin between the left/middle/right content. Preferred style of the left/right icons. Text style of the title. Restrictive API Compose implementation of NavigationBar is pretty straightforward. @Composable fun NavigationBar( title: String, modifier: Modifier = Modifier, leftButton: IconButton? = null, rightButton: IconButton? = null, ) { Row(modifier) { ... } } @Immutable data class IconButton( val icon: Painter, val onClick: () -> Unit, ) An API that allows only particular use of NavigationBar is a restrictive API. Such API ensures that developers will be able to use the component only in the predefined way, leaving no space for possible mistakes and inconsistency. Great at first sight, but has a major restriction -- missing extensibility. As soon as we continue making our apps bigger, we will eventually f ## Scaling iOS at Bumble: Part 2/3 -- The Assessment DevFeed: [Scaling iOS at Bumble: Part 2/3 -- The Assessment]() Original publisher: [Read original article]() Author: Jonathan Crooke Published: 2024-02-15T13:49:17Z Content type: article Language: en Sources: [Bumble Tech]() Topics: [iOS](), [Tuist](), [swift-package-manager](), [bazel](), [toolchain](), [Xcode](), [Requirements](), [Testing]() Tags: [bazel](), [ios](), [ios-app-development](), [performance](), [requirements](), [swift](), [swift-package-manager](), [testing](), [toolchain](), [tuist](), [xcode]() ### AI overview This article recaps Bumble's assessment process for replacing parts of its iOS project and build toolchain. It describes onboarding, proof-of-concept work, full-app conversion, and assessment criteria for Swift Package Manager, Tuist, and Bazel, including blockers, user experience, and performance. ### Source excerpt Scaling iOS at Bumble: Part 2/3 -- The AssessmentRecap In our previous post we discussed how we came to be investigating project and build toolchain replacement solutions for our iOS codebase at Bumble Inc. We began executing proofs of concept for Swift Package Manager (SPM), Tuist and Bazel. The Process Our investigative process for each tool was performed in roughly the same manner: 1. Onboarding With the exception of some light use of SPM as a third-party dependency manager, no-one on the team was fully fluent with any of the tools. This meant that at first, we needed to learn the basics, which could be achieved by creating a minimum-viable manifest for one of our node modules. This would involve learning the manifest format and core commands for building, testing etc. 2. Medium-sized proof of concept Following on from the initial onboarding, we would then progress to converting parent modules, traversing the tree post-order. At each level we'd cover more of our core requirements and encounter edge-cases. Throughout, we noted learnings, limitations and fixes. 3. Full-app conversion At this stage, since our module tree exhibits a strong level of uniformity, we'd now have gathered enough experience to fully convert the app's child modules, and do so using automated tooling. How we achieved this will be discussed below. Unsurprisingly, the top-level app target was its own challenge, and required considerably handcrafting. We only aimed to achieve a minimum-viable conversion at this stage, and didn't expect tests to pass. That said, we'd usually have a fairly conformant conversion anyway, that would launch successfully to its home screen and usually plenty more. 4. Assessment With a converted app target in hand, we would now have a candidate for assessment. But what did we want to know? Our analysis looked at these areas: Blockers: simple enough, any limitations or issues in the tool's functionality whereby it was unable to serve our basic requirements Subjective user ## Crafting Android bytecode analysis tooling using a secret ingredient (Part 1) DevFeed: [Crafting Android bytecode analysis tooling using a secret ingredient (Part 1)]() Original publisher: [Read original article]() Author: Konstantin Zolotov Published: 2024-02-09T11:50:19Z Content type: tutorial Language: en Sources: [Bumble Tech]() Topics: [Android](), [Tooling](), [APK](), [obfuscation](), [R8](), [Kotlin](), [Java](), [Compiler]() Tags: [andriod-app-development](), [android](), [apk](), [bytecode](), [compilation](), [compiler](), [dagger](), [inlining](), [java](), [kotlin](), [obfuscation](), [optimization](), [r8](), [tooling]() ### AI overview This tutorial introduces Android bytecode analysis through DEX inspection and a tool for examining how source-code changes affect compiled binaries. It explains the Android compilation pipeline from Java or Kotlin source through JVM class files and D8-generated DEX files, then describes R8 obfuscation and optimization, including source maps, tree-shaking, inlining, and outlining. ### Source excerpt During the development process, we often focus on the source code but rarely inspect the compiled bytecode. This means we're missing out on a valuable source of information and data for analysis. How? Let's delve into Dex file inspection and build a tool that demonstrates how source code changes impact the compiled binary. Have you ever set R8 rules to obfuscate your app? Have you used an APK analyzer or a diffuse tool to understand how the code is compiled? Are you confident that debug code hasn't leaked into production? There's another potential pitfall: libraries may provide obfuscation rules (e.g., Gson) that merge with the ones in your project. This means third-party dependencies can alter configurations for the entire app. We often assume everything is fine and that we'll notice if something isn't right. But will we? Does this make you feel uneasy? Does it concern you? Because it certainly concerns me. Here, we'll attempt to enhance the situation and enable you to see precisely how your code changes impact the compiled binary. To better comprehend this, let's start with the code compilation process: It all begins with the Java and/or Kotlin source code, which is then compiled into JVM .class files. Note that at this stage, Java and Kotlin compilers can execute annotation processing tools (APT/KAPT) to generate source code (e.g., Dagger), and Kotlin compiler can run plugins to modify the internal code representation. Then, the D8 compiler takes these compiled classes, third-party libraries (JARs, AARs), and converts them into .dex files. However, if obfuscation and/or minification are enabled (which is almost always the case for release builds), R8 comes into play after D8. R8 obfuscates and optimises the bytecode, and additionally, R8 produces a source map file -- a special file listing all the changes and replacements. Obfuscation replaces human-readable names of various entities (classes, functions, fields, etc.) with very short, yet still unique names, for e ## Scaling iOS at Bumble: Part 1/3 -- The Challenges DevFeed: [Scaling iOS at Bumble: Part 1/3 -- The Challenges]() Original publisher: [Read original article]() Author: Jonathan Crooke Published: 2024-01-31T16:10:21Z Content type: article Language: en Sources: [Bumble Tech]() Topics: [iOS](), [iOS development](), [Swift](), [modules](), [Mobile](), [Tooling](), [Development]() Tags: [badoo](), [bff](), [code](), [development](), [ios](), [ios-development](), [modules](), [swift](), [tooling]() ### AI overview The first article in a three-part series explains the challenges of scaling iOS production apps at Bumble Inc. It introduces the company's medium-scale iOS development context, including dozens of engineers, hundreds of modules, more than 100 feature workspaces, millions of lines of Swift, and extensive custom tooling. ### Source excerpt Scaling iOS at Bumble: Part 1/3 -- The ChallengesIntroduction This article is the first in a series of three. We'll be presenting work undertaken during 2022 and 2023 aimed at tackling the challenges of scaling our iOS production apps. Who are we? Bumble Inc. is the parent company of Bumble, Badoo, Fruitz and Official. The Bumble platform enables people to build healthy and equitable relationships, through kind connections. Founded by CEO Whitney Wolfe Herd in 2014, Bumble was one of the first dating apps built with women at the centre and connects people across dating (Bumble Date), friendship (Bumble BFF) and professional networking (Bumble Bizz). Badoo, which was founded in 2006, is one of the pioneers of web and mobile dating products. Fruitz, founded in 2017, encourages open and honest communication of dating intentions through playful fruit metaphors. Official is an app for couples that promotes open and honest communication between partners and was founded in 2020. Who is this for? This blog post series is aimed squarely at teams operating at scales similar to ours. So what is our scale? Scale at Bumble Inc. iOS development at Bumble Inc. is certainly not small! We have: Dozens of engineers Hundreds of modules 100+ feature workspaces Millions of lines of Swift, with a dusting of ObjectiveC for old time's sake 🙃 Tens of thousands of lines of custom tooling code Lots of modularity, and of a quite high standard Just a tiny section of our module graph This might seem to readers as a pretty large scale. However in this article series we'll be considering Bumble Inc. as a medium scale team. So why is that? "Medium" sized teamsWe've chosen this medium terminology to emphasise the "in-between" state that teams can fall into in the iOS ecosystem. On one hand you have the small team; the startup, the individual Developer. Apple's Developer marketing often seems oddly focussed on these kinds of teams! They're very happy with the out-of-the-box Developer experience (and w ## Crash course on the Android UI layer | Part 2 DevFeed: [Crash course on the Android UI layer | Part 2]() Original publisher: [Read original article]() Author: Manuel Vivo Published: 2023-12-19T15:58:45Z Content type: tutorial Language: en Sources: [Bumble Tech]() Topics: [Android](), [ui](), [business logic](), [implementation](), [configuration](), [navigation](), [data](), [Requirements]() Tags: [android](), [android-app-development](), [apis](), [architecture](), [best-practices](), [business-logic](), [configuration](), [implementation](), [navigation](), [requirements](), [ui](), [viewmodel]() ### AI overview Part 2 of a series on the Android UI layer explains state holders, saving UI state, state hoisting, and the distinction between business logic and UI logic. It describes how these types of logic should respond to configuration changes. ### Source excerpt Crash Course on the Android UI Layer | Part 2State Holders and Saving State This blog post series aims to summarise the Android Developer guidance on the UI layer. We'll explore all the entities involved in it, understand the role each part plays, and discuss best practices. By the end of this series, you will have a general understanding of what happens on the UI layer and how to best handle state and logic within it, the various APIs involved, and how to use them. Additionally, we'll provide decision trees to assist you when you're in doubt. In part 1, we covered the UI and the UI state. You should already know the different entities present on the UI layer, and how to think about the UI and UI state effectively. Crash course on the Android UI layer | Part 1 Now it's time for Part 2! We'll cover state holders and other UI layer-related topics such as where to hoist state and save UI state on Android. If you prefer to consume this content in video format, check out the talk I delivered at Droidcon London 2023: Peeling Back the Layers: Unmasking the UI-nknown! State holders State holders simplify the UI by handling logic and/or exposing UI state. In this section, we'll see how to implement state holders and the implementation details to consider. To determine the implementation details, we first need to identify the types of logic commonly found in an Android app. Types of logic We have already discussed that business logic involves implementing the product requirements that specify how application data is created, stored, and modified. When business logic is present in the UI layer, it's recommended to manage this logic at the screen level. We'll see more of this later. Another type of logic is the UI logic. UI logic determines how to display state changes on the screen. While business logic dictates what to do with data, UI logic determines how to visually display it. The UI logic is dependent on the UI configuration. For instance, in a typical app, displaying a d ## Crash course on the Android UI layer | Part 1 DevFeed: [Crash course on the Android UI layer | Part 1]() Original publisher: [Read original article]() Author: Manuel Vivo Published: 2023-12-13T17:03:40Z Content type: tutorial Language: en Sources: [Bumble Tech]() Topics: [ui](), [Android](), [business logic](), [App]() Tags: [android](), [app-architecture](), [architecture](), [best-practices](), [business-logic](), [state-management](), [ui](), [viewmodel]() ### AI overview Part 1 of a series explains the Android UI layer, UI state, and the roles of the UI, data, and optional domain layers. It introduces separation of concerns, state holders, unidirectional data flow, and related best practices. ### Source excerpt Crash Course on the Android UI Layer | Part 1The UI and UI State This blog post series aims to summarise the Android Developer guidance on the UI layer. We'll explore all the entities involved in it, understand the role each part plays, and discuss best practices. By the end of this series, you will have a general understanding of what happens on the UI layer and how to best handle state and logic within it, the various APIs involved, and how to use them. Additionally, we'll provide decision trees to assist you when you're in doubt. This is part 1, where we're covering the UI and the UI state. Part 2 covers state holders and other UI layer-related topics such as where to hoist state and save state on Android. If you prefer to consume this content in video format, check out the talk I delivered at Droidcon London 2023: Peeling Back the Layers: Unmasking the UI-nknown! The UI layer in the grand scheme of things The UI layer isn't the only layer you can find in a typical app architecture. Alongside it, you can also find the data layer and sometimes, the domain layer. According to the Android Architecture documentation: The UI layer displays data on the screen. The data layer exposes application data and contains the vast majority of the business logic of the app. The domain layer is an optional layer that aims to 1) simplify and 2) reuse the potential business logic complexity of the UI layer. No less, no more. Note: The business logic is what gives value to your application. It's the implementation of product requirements that determines how your app fetches, stores, and modifies data.Architecture layers in a typical Android app: The UI, data, and domain layersEntities in the UI layer The UI layer consists of three distinct entities with clearly defined responsibilities. This distinction helps with separation of concerns, enhances testability, and promotes reusability. The UI, or UI elements, render data on the screen. The UI state describes the data to render on the ## Live Mosaic at Droidcon London 2023 DevFeed: [Live Mosaic at Droidcon London 2023]() Original publisher: [Read original article]() Author: Zsolt Kocsi Published: 2023-12-06T15:55:43Z Content type: article Language: en Sources: [Bumble Tech]() Topics: [compose-multiplatform](), [Compose](), [Library](), [multiplatform](), [Open Source](), [GitHub]() Tags: [android](), [androiddev](), [compose](), [compose-multiplatform](), [github](), [jetpack-compose](), [library](), [multiplatform](), [open-source](), [pull-request]() ### AI overview Bumble describes its Live Mosaic project for Droidcon London 2023, an open-source collaborative message wall and dynamic mosaic built with its Appyx library and Compose Multiplatform. Attendees could submit text, images, or custom composables through pull requests, with accepted entries appearing live and contributing to mosaics and a raffle. ### Source excerpt Bumble Inc.'s booth engagement project Intro Having a London office with lots of local colleagues and many more visiting from Barcelona, Droidcon London is always a fantastic opportunity for us at Bumble to meet the Android developer community as well as each other: Bumble Tech team at Droidcon London 2023 We usually have a booth presence too. Instead of coding challenges we did in the past, this year we tried something new -- We brought a big screen that attracted quite a crowd: Bumble booth at Droidcon London 2023 We were running a collaborative message board, live mosaics, and lots of custom animations we made using Appyx and Compose Multiplatform on the screen: Collaborative message wall Both to showcase our own in-house technologies and to have a lot of fun -- and indeed we had lots making this happen! But what is this project really about? Project & backing technologies We brought an open-source project backed by our own in house library, Appyx, running on Compose Multiplatform. Since it's multiplatform, it works on your mobile device too of course -- but it just looks gorgeous when launched on desktop, big screen, live! You can check out the project here: GitHub - bumble-tech/live-mosaic: Collaborative message board and dynamic image mosaic for #dcldn23 A collaborative message wall Our goal was to provide an engagement point with the crowd about our technologies in a fun, but low entry barrier way -- we created a collaborative message wall you could add entries to: We supported three types of entries: Text, Image, and even CustomComposable to unlock all your creative potential! All you needed to do was to add your entry to a list in a pull request, and if we merged it it would be featured on our screen live: Starfield As a default, we showed the entries in the "Starfield" visualisation shown above. Later we also enabled this other beautiful showcasing of the entries: Stack of messagesLive mosaic and raffle Every entry added to the message wall also automatically ## A clustering-based approach to create deep learning datasets in a day DevFeed: [A clustering-based approach to create deep learning datasets in a day]() Original publisher: [Read original article]() Author: Roland Meertens Published: 2023-11-28T17:33:30Z Content type: article Language: en Sources: [Bumble Tech]() Topics: [dataset](), [Computer vision](), [Deep learning](), [foundation-models](), [Fine-tuning](), [Inference]() Tags: [clustering](), [computer-vision](), [data-science](), [dataset](), [deep-learning](), [fine-tuning](), [inference](), [machine-learning](), [models](), [retrieval](), [zero-shot]() ### AI overview The article discusses the cost and time involved in creating labeled computer vision datasets. It considers zero-shot learning and foundational models such as GPT-3 and CLIP for data retrieval, while noting that some use cases still require fine-tuning on task-specific data. ### Source excerpt A clustering-based approach to create deep learning datasets in a day Introduction Understanding what's happening in an image is both an important task, as well as a costly one. In the last few years, the field of computer vision has greatly accelerated due to the advances in neural networks. At Bumble Inc., we see potential value in computer vision for a variety of use cases, such as improving the safety of our platform and providing our members with a better user experience. The most common way to train these neural networks is by showing it many images with the corresponding label. Unfortunately, this can be a costly task. Not only does one need to build and train the model, one also wants to do hyperparameter search over multiple configurations of possible networks, and -- of course -- one needs to find or build a dataset suitable for the task at hand. Building the dataset is both the most important task, as well as a very time consuming one. Gathering data, setting up labelling requirements, and of course the labelling itself all take a lot of time and money. This normally leads to trade-offs, by choosing either to build only a small dataset, or by trying to fit existing datasets into your specific use-case. One alternative is of course to not build a dataset at all, to instead use zero-shot learning for your use case. I argued in the past that this is unreasonably effective, and allows you to test your use-case before even training a model. When using zero-shot learning one predicts labels without explicitly training on the classes you are trying to learn. One example of this can be achieved by using the CLIP model, which is trained to have a strong association between text and images. By looking at the distance between the description of your class and the image you can run inference without training anything. However, there are some use cases where we need the strongest possible model by fine-tuning it to our specific data. Using foundational models for data s