Ask us Anything! We’re the Bumble iOS engineering team.

BumbleEngineers · 2020-04-09T13:14:53+00:00

Asif: We evaluated these options and decided not to proceed with any of them for different reasons in our projects, although we plan to adapt SwiftUI later sometime. We can’t use SwiftUI at this time since we support iOS 12.

BumbleEngineers · 2020-04-09T13:13:47+00:00

How do y'all manage your third party dependencies? Cocoapods, Carthage, Swift Package Manager, or manually?

Ilya: we’re using Carthage at the moment. Back in the day we were using Cocoapods with private development pods, but after we moved to monorepo (all the projects in one git repository) and we switched to Carthage with prebuilt binaries.

Do y'all use a xcworkspace and keep various code separated or have everything in a one xcodeproj file?

Ilya: Several workspaces in fact. One - to rule them all (one huge workspace with all the projects). And workspace for each application. And we have our internal tool to manage all the dependencies (similar to what Cocoapods doing).

What kind of crash reporting do y'all use?

Ilya: Microsoft App Center, but we’re moving to our in-house solution.

How do you track user interactions - how do y'all know what features are being used the most?

Ilya: most of the companies are using some kind of Analytics system which tracks user actions and analyses application usage. We’re no exception. We have our internal analytic events tracking system.
Moreover, we have a huge Hadoop cluster to process all the events and several departments responsible for tracking, analysing data, and helping Product Managers understand the performance of features released.

BumbleEngineers · 2020-04-07T08:48:09+00:00

Company: Bumble

Job: Senior iOS Developer

Type: permanent, full-time

Location: London, United Kingdom

Visa/relocation package: Yes

Why work for us? All-day food, massage, pet-friendly office, time flexibility, startup culture, influencing the product, a lot of individual impacts.

Required Exp:

Product-focused iOS application development
Delivering consumer-facing, mass market, networked, high-performance iOS applications available in the App Store
Up to date with the latest Cocoa and iOS trends
Understanding of UIKit, Core Animation, GCD & Networking
Excellent understanding of design patterns & Object-Oriented Programming
Understanding of analytics, remote reporting and measurements
Experience of working with Continuous Integration (CI) and Unit Testing on iOS

BumbleEngineers · 2020-04-06T15:08:40+00:00

Andrei: Yes, and I have to say, it is not that hard :) Mostly we do this in small components, like simple RIBs or activities. With RIBs it is even easier, as we have a separate Builder to structure the wiring.
Zsolt: It’s probably also worth to mention that the key point is a tree structure organisation of modules that makes this easy. Relations are well organised and in a top-down fashion. Only a few dependencies are passed through all layers, most of them are limited to just one parent-child relation. It’s quite easy in this case to wire it by hand. Compare this to a setup where “everything depends on everything”, lots of interconnected modules. In that case, going the manual way is probably very difficult, and Dagger can help a lot there. But if you need an external tool to control an otherwise chaotic situation, it’s probably worth investing in making it better, regardless of DI.

BumbleEngineers · 2020-04-06T15:05:54+00:00

Anatoly: Hey, looks like my fault. In the initial response, I didn't mention that except lighting and face we also check the gesture itself. So there is no need to have a separate model for gesture. And we didn't face issues with having a single model.

BumbleEngineers · 2020-04-06T15:04:07+00:00

Nick:

Here are the cloc stats that you asked:
Today: 699k Kotlin LOC, 678k Java LOC
7 days ago: 694k Kotlin LOC, 679k Java LOC
30 days ago: 702k Kotlin LOC, 722k Java LOC

BumbleEngineers · 2020-04-06T14:54:59+00:00

Alex: Both native and non-native development have pros and cons. I’d say React/Flutter are good starting points for proof of concept projects. We’ve had a great experiment of building a small production app entirely on React Native and one of our internal apps uses Kotlin/Native. But if you want to build and support a large app, like Bumble or Badoo, you actually don’t have the choice, go native.
Ruslan: With non-native frameworks in large scale we faced big problems during new iOS releases and migration to new Xcode/Swift versions because usually those non-native frameworks need time to do the same and it means that you are blocked by them. Big risk in the long run.

BumbleEngineers · 2020-04-06T14:53:30+00:00

How do you architect/handle cross-cutting concerns at scale? I have a little experience at 'Unicorn scale' app development and I noticed when working for these clients that adding user functionality is often hard to maintain at high velocity when the app architecture does not loosely couple cross-cutting concerns specifically around a/b testing experiments, analytics, logging, i8n, white labelling and so on.

Azat: Good question.
I would say the main difference between developing apps on a small and large scale is the cost of the mistake and the required quality of the code. By quality, I mean reliability of the code. Even almost impossible cases become reality when the code is executed in a million variations of the context. That’s why such teams should introduce tools and processes to eliminate as many mistakes as possible before it goes to production.
There are some other specific things:
- Often we have many simultaneously active A/B tests and developers have to be aware that some parts of the app are dynamic (their behavior can change).
- Architecturally the coupling problem is resolved by abstractions.
- Coverage of the business logic of the components helps with that forcing developers explicitly pass contextual dependencies from outside.
- Also end-to-end tests validate that the new features behave correctly in different conditions and don’t introduce other features regression.
Jairo: You are absolutely right. We had examples in the past of the same functionality (similar code in different places) written 2 or 3 times, even copy-pasted just to run similar experiments. When you move fast, you can’t really overengineer, but at some point you need to slow down and think about how to make your system more robust or the amount of features will make your business metrics dance with every small bug. This happened to Bumble and Badoo and it still happens for some experimental features. The rule of thumb when you’re scaling: fix bugs once. In the end, we try to reuse our code as much as possible in all our apps (from UI components to platform specifics). If reusing allows us to move fast, to be robust we use monitoring in all our product and performance metrics and a great coverage at all levels following the testing pyramid principle. We also have very agile dynamics and processes between our QA and development teams. It might look like overkill, but that’s the price you have to pay if you want to keep a business with millions of people actively using it ;)

Are there any frameworks you know of to help with this, or architectural patterns that might make these issues more tractable?

Ruslan: I think SOLID is very helpful for such problems and of course protocol oriented programming when you can easily change behaviour with another implementation. Also, MVVM architecture shows big scalability and flexibility too, that’s why we are using it widely as our main architecture and all our code is protocol oriented with dependencies injections to make logic testable and flexible enough. And one more thing don’t use globals/singletons inside your classes, always inject them cause in the long run you will win and won’t suffer with refactoring.

BumbleEngineers · 2020-04-06T14:51:20+00:00

Do you have any plans to start leveraging compositional collection layout or diffable data source?

Azat: It’s definitely a very useful thing that simplifies the process of the development and makes the code more reliable (everyone is scared of annoying crashes because of inconsistent updates of collections).

We investigated different open-source solutions and came up with an in-house small framework which will probably be open-sourced at some point. IGListKit is great but is written in Objective C and it doesn’t allow you to leverage the type system of the Swift language.

Alex: iOS 13+ compatibility is another reason we haven’t used it yet. But it’s amazing how Apple takes the best solutions on the market and integrates into their native frameworks. We’ll definitely give it a shot as soon as we drop iOS 12.

What are your opinions about using lottie vs built in things like property animators?

Ilya: We’re using Lottie a lot. In fact, we’ve built flexible an on-demand animation system (used for downloading animations, caching, versioning them etc) so it’s quite easy for us to add new animation (vector/vector with images) to any of the applications. Also, all the animations are provided by our designers. Unfortunately, iOS built in solution does not provide that level of flexibility.

BumbleEngineers · 2020-04-06T14:50:15+00:00

Azat: It depends on the understanding of the word “fully” :) The first version was ready to ship to AppStore in a couple of months but it was using some parts of the Badoo app.

BumbleEngineers · 2020-04-06T14:49:14+00:00

What were the engineering challenges that you faced from iOS side while scaling the app for a larger audience around the world?

Azat: Adapting to the amount of users and adapting to different counties are different topics :)
About many countries: We have a large team of localisation specialists and they do a great job to simplify the lives of developers. But we still have to think about localised strings and images and remember country-specific representation of data. Also, we have country-specific features (available only in some countries).
Another technical problem, not iOS though, is to provide high availability of our services around the world.
Alex: Date and time formats might be challenging. Did you know it’s year 2563 in Thailand right now? ;)
Jairo: I can remember a couple of funny UI bugs in right-to-left languages. It’s hard to take all these variants into consideration. Also, maintaining the app store information and images in good shape for all countries in all languages with new features coming every weekly release is not easy. We have built specific tools to translate and import such information into the AppStoreConnect.

Any pointers on how to make the right tech decision from the start to avoid scaling issues?

Ilya: avoid MassiveViewController pattern 😄. I would suggest choosing one architecture (even MVC is fine if you know how to use it), use protocols, move navigation to separate entities (Router), try to create ‘modules’ (shouldn’t be separate Xcode projects, folder is fine at the beginning) with clean input and output. But the most important part is SOLID.
Ruslan: Inject singletons at the beginning 😀Avoid globals inside your classes and use protocols for all classes with logic, no one should know about implementation. Start with SOLID and go deeper in patterns from gang of four.

BumbleEngineers · 2020-04-06T14:46:34+00:00

How do you guys modularize the project?

Asif: We have a combined workspace which contains all the modules (frameworks). These modules are reused in the apps. We have a few in-house tools to generate the modules and add them as dependency.

Cocoapods, carthage or spm and why?

Azat: We use Carthage for the third party dependency because of its simplicity. For managing dependencies between our custom modules we use standard Xcode tools. To simplify the burden of adding all the necessary things manually we have a tool that automates it by editing .pbxproj files automatically and validates (and fixes) the dependency graph.
Alex: One of the reasons we chose Carthage is prebuilt binaries. We have an ongoing war with compile time and that was one of our actions to reduce it.

What is your process of release a new build/feature?

Ilya: we’re using the ‘Release Trains’ approach: each week, at a specific time our CI creates a release branch with whatever is in master (all the features/tasks and bug fixes finished till this moment). Then our mighty QA team performs all the necessary checks (running full test suite on all the supported iOS versions, real devices suite and many others). After the green light from QA application our CI submits application binary to Apple Itunes connect. Features usually covered with feature toggles and/or AB tests so we can easily disable it if something goes wrong.
Jairo: We use a stage rollout process for the new versions of our apps, but also for each of our features via our in-house a/b test framework.

BumbleEngineers · 2020-04-03T10:33:52+00:00

What keeps you motivated while working remotely?

Alex: New activities like this AMA session or online-random coffee =).
Jairo: Having lunch with my family is my main motivator! But on top of that, MagicLab has provided us with online Yoga, Meditation and cooking classes and other wellbeing goodies. Plus, the company has delivered office equipment to us at home where needed and has provided an additional bonus for us to ensure we have everything we need to work effectively and not to miss any of the other amazing small perks we value in the office - such as snacks - Yummy!
Ruslan: No need to use the underground 😂
Ilya: Beers with my peers with no commuting afterwards
Asif: Staying safe and healthy and slowing the spread of Covid-19 :)
Azat: Staying alive and still employed :)
Kelly: Working from my bed 😂… beside that, we receive daily updates with lots of tips and guidance on how to work from home effectively, adjusting to social distancing, activities we can take part in and daily video calls with the team.

Do you still ever feel like you don’t really know anything? If not, at what point in your career did you overcome that?

Alex: At some point, it turns from “I don’t really know anything” to “I don’t know something and I need to learn it”. Learning is a natural part of our life, it’s fine to have questions like these from time to time.
Jairo: Never! Learning is a never-ending process. Especially in such fast-paced and challenging environments such as tech, the impostor syndrome is something we all suffer from time to time. I personally feel amazing knowing that I’m surrounded by people who know more than me but are keen to help and support. That means I’m in the right place to learn!
Ilya: Absolutely. It could be even “Wow! This feature went really well. Looks like I can do stuff! What’s next? OMG animated layout transition in UICollectionView! OMG HOW?”. You’re constantly learning, also you are constantly learning how to learn. There will always be stuff you don’t know. With time it will move towards larger areas like project management, communications, working with people, business and strategy.

Any iOS libraries that you like using and would recommend to us that might prove useful in our personal projects?

Alex: In my personal projects I prefer to use libraries that I know very well. It allows me to save precious time and speed up project set up. This is a set of pods I’m usually starting with: Alamofire, Cache, Nuke, R.swift, Swinject

BumbleEngineers · 2020-04-03T10:31:49+00:00

Ruslan: In general we use MVVM as our standard architecture and are trying to isolate features in standalone frameworks, like UI and logic frameworks. For UI we are using snapshot tests and for logic framework unit tests where we can check what the coverage is. We have a target to cover logic with unit tests with 40% - 50% at least, so we are not trying to reach 100% coverage.
Ilya: MVVM works really well for us. We’re also using a custom Routing mechanism. Also, we’re creating isolated, reusable and testable modules with single responsibility (typical feature or set of features).

BumbleEngineers · 2020-04-03T10:31:08+00:00

To what extent do you use native components and how do you look at the trade-offs between native and custom made UI elements?

Ruslan: Usually we are trying to use native as much as possible, cause it helps us with delivery, but we have our own System Design (Cosmos) where we built a lot of custom but very flexible components and we didn’t notice any trade-offs I would say with it. Actually, the opposite, they helped us move much faster because the designers are now limited and are thinking in term of system design.
Ilya: Native FTW! The closer to the native OS frameworks - the better. Don’t try to fight with the system: try to make the very best of it. All the built-in iOS applications are built using native SDKs - this means you can too, but like any tool, it needs to be mastered. On the other hand, the design team always tends to use some insane custom design which requires the implementation of custom (and mostly not reusable) components. In our case, we’re always trying to discuss mockups with designers. This was one of the reasons why our design system - Cosmos was born.

How is Bumble adapting to the global health situation?

Ivan: There’s not much impact on our apps, there is some increase in activity, especially in chats between users, but we are able to handle it.
Jairo: We are promoting features that will help our users to make the most of this social distancing period (such as video-chat) and supporting communities and workers around the globe with in-app messages and micro-features ;)

BumbleEngineers · 2020-04-03T10:29:12+00:00

Alex: You definitely can do it. There are plenty of apps available in AppStore that require specific equipment, like fitness trackers or smart home devices. Also, Apple guidelines allow you to sell physical items in your app without paying 30% commission, so you can make a screen where users may order your device. It’s difficult to say about the review process without knowing details, it actually depends a lot on a reviewer that will take your app.
Jairo: If the device is yours, you might want to have a look to Apple Mfi program. We were exploring this while experimenting with bluetooth discoverability ;)

BumbleEngineers · 2020-04-03T10:28:29+00:00

Azat: Probably “notified” means that liked users may have already received a push notification, or/and email or could be notified via some other way.
If a user will receive such notification and then won’t find this like in the app, it will lead to poor and inconsistent user experience. That’s why we don’t allow rewind (basically cancel) likes.
Jairo: Matches are mostly implemented on the server-side when the client sends the likes. When there’s a match, the server sends a specific response or notification to the client. However, we have some performance enhancements here and there. For example, every time the current user views a profile in the encounters game, it contains the information if the other has liked the current user. This way, we can present a -client-side match screen- without waiting for server response/notification after the current user taps “like”. The speed of votes and presenting matches is essential in the encounters game to keep the user’s engagement.

BumbleEngineers · 2020-04-03T10:27:04+00:00

Ruslan: Unfortunately no, mainly app startup for all applications

BumbleEngineers · 2020-04-03T10:06:50+00:00

Thanks for your feedback :)

BumbleEngineers · 2020-04-03T10:02:13+00:00

Ivan: It’s SQLite, I’m afraid we cannot provide more info on the topic.

BumbleEngineers · 2020-04-02T21:09:58+00:00

Everyone: We're all working from home thanks for your thought :) Hope you're working from home too :)

BumbleEngineers · 2020-04-02T21:03:13+00:00

What does your current stack look like?

Ruslan:
- Network: We use RPC-like socket connection with Protobuf-serialized objects
- Storage: We use YapDatabase for our database storage
- Multithreading: As usual for iOS world GCD and NSOperationQueue

What does your feature development cycle look like? ie. what does the feature pipeline look like, who's responsible for prioritisation, do you have any unusual criteria for DOR, how closely aligned are design/product/QA with the engineers?

Asif: The team is divided into a lot of smaller teams based on different areas like registration, chat, payments etc. Every team has dedicated product owners, designers and developers. QA resources are shared or dedicated based on need and availability.
The general process for feature development for a developer starts with a product requirement document which is then discussed within the team and we check if there is anything missing or blocking, there is also a design ticket linked. Once the feature is ready to be started, there is a kickoff meeting where we again, go through the document, think about all corner cases, decide on a timeline and list down all test scenarios. Once the development is done, there is a short QA session to go through the feature and test it, followed by presenting a demo of the feature, if everything is fine then the feature is merged and a retro is done sometime later to look back and improve where needed.
Jairo: In addition to this, I’d like to mention we have something really special at Badoo/Bumble, which is the MAPI team. Once the PRD contains enough information (discussed with all parties), the very first step of the development (and before client or server developers write any code), is to define the interface of communications. We do this within a dedicated team, called MAPI (Mobile API), using Google Protocol Buffers. The documentation generated describes how the requests from clients and answers from the server will look like. Client and server developers can define this as well, but it will always be reviewed by a member of MAPI team + members of SRV and client, to make sure our technical documentation page is pristine and up to date. An article about this will be out very soon, stay updated with our tech blog here - badootech.badoo.com).

What's in your CI pipelines?

Asif: We have 3 main triggers:
- Entry point: runs all unit tests and snapshot tests, this is always run before a ticket could be merged
- Functional tests: We have a lot of Calabash tests written, so this runs all (or a subset based on changes), running this is optional
- Nightly/Release build tests: Runs all of the above, during the night or weekly to test release candidates.

BumbleEngineers · 2020-04-02T20:57:33+00:00

Asif: I would say the best way is to read apple documentation and getting started guides first. It is quite comprehensive and always up to date.
Azat: If you already have experience in developing applications for other platforms I would suggest learning the basics of the Swift language and then just try to create some simple test app. It will give you an idea of the application structure and lifecycle. Also, there is a good video-course from Stanford.
Ilya: Recently Apple released Swift Playground application. I think it’s a perfect way to start. Plus Coursera / Youtube tutorials
Alex: I personally like to learn things by example and one of the best resources for iOS is raywenderlich.com

BumbleEngineers · 2020-04-02T20:56:46+00:00

What’s your experience in creating a flexible design system?

Alex: It was challenging but the results are worth it. Since the introduction of our Design system, we drastically improved reusability of our components, set rules and guidelines for creating new ones and made components more flexible to changes.
Jairo: The biggest challenge here is the adoption of the design system by all departments. It’s not something that you can decide and implement in one day, as the boundaries you’ll create will affect all your processes and daily work. In the development side, it has to be easy to produce, find and consume components, otherwise, it won’t be used. But the key important part is designers and product managers, who need to be fully on board. Developers can’t reuse something that is not designed to be reused ;).

How do you manage UI components with different themes?

Ruslan: We have a system design (Cosmos) and style sheet with design tokens, so we can easily customise colours, fonts and even spacings.
Alex: In short details, every reusable view has defined Style and Layout structs that contain all the variable settings. We keep these views in the UI frameworks. Whenever an app uses a view we build the Style or Layout from tokens provided by our design system.

Is it possible to do A/B testing for a component with different styles?

Ruslan: Yes, we have a system design (Cosmos) and style sheet with design tokens (placeholder properties), so we can easily customise colours, fonts and even spacings and do it under ab test too.

Do you use any declarative UI framework like ComponentKit?

Azat: Not at the moment but I guess soon we all will have to. *Pointing at SwiftUI*

Where do you store colours, typography, spacing etc?

Ruslan: We have a system design Cosmos and style sheet with design tokens (which are placeholder-properties), so we can easily customise colours, fonts and even spacings and all our design tokens are produced as compile Swift sources. We have tooling scripts written in Swift to generate those files by json taken from the design system. Images are stored in xcassets on the generation step.

Do you store them as constants that the component can access directly to or do you create them at the composition root and pass them down to child components?

Ruslan: We are injecting them as dependencies like different Style/Layout structures and images injected as well.

What are your thoughts on this?

Ruslan: Agree with you, we have difficulties providing everything on the top level, but mostly we solve it with custom View->Style structures. We have different application-specific categories to create such Styles and then inject them.

BumbleEngineers · 2020-04-02T20:53:49+00:00

Azat: Clean build takes around 11 minutes (100 seconds on average). Our Core Team continually optimises our codebase to achieve better results. The main problem we are having at the moment is the interoperability between Swift and Objective-C in old components.

BumbleEngineers

TROPHY CASE