Behind the simplicity of every match, we think deeply about human relationships, behavioral science, network economics, AI and ML, online and real-world safety, cultural nuances, loneliness, love, sex, and more.
Tinder's iOS team decomposed a large Swift monolith by using the Swift compiler to generate a file-level dependency graph, extracting leaf nodes into Swift modules in phased pull requests and automating the file-move and refactor steps. The automation converted an estimated ~12-year manual effort into a sub-6-month project, extracting ~1000 files, reducing monolith build time by ~78%, and removing the ability to add new files to the monolith.
Tinder’s AI Photo Selector is an on-device pipeline that detects and normalizes faces, verifies identity, scores images for likely engagement, and performs moderation before recommending photos. Face detection and landmarking use Apple’s Vision APIs, followed by an affine "normalized crop" aligning facial landmarks into a 112×112 reference. State orchestration relies on Combine with a centralized @Published State and Node-based navigation, while concurrent image processing is implemented with an OperationQueue (tuned to 8 concurrent operations), timeouts, and cancellability. Face verification uses a third-party FaceMeSDK and Tinder’s TensorFlow Lite models for like-probability scoring; a separate TFLite moderation model assesses the top candidates. Analytics are captured deterministically via a dedicated DispatchQueue and DispatchGroup to ensure accurate counts across concurrent operations.
Tinder migrated its Recommendations Elasticsearch clusters from ES6 to ES8 using Elastic Cloud on Kubernetes (ECK) integrated with the in-house Scaffold IaC. They built a repeatable migration framework with stages for write-path data consistency (Kafka-based backfill and esreindexjob), offline event-based replay evaluation, and online A/B rollout. The migration enabled vector/kNN search and ML features (embeddings, two‑tower models), improved performance and stability, and created a standardized Elasticsearch platform for the company with minimal user impact and measurable business gains.
Tinder reduced iOS localization bundle size by collapsing per-target locale .strings/.stringsdict files into a single file per language using Bazel Starlark rules (namespacing + merging) and then compressing values with Emerge's SmallStrings (LZFSE). They ported Ruby tooling to Swift, used C for compression code, and relied on Bazel caching/hermetic sandboxing. The change cut ~10.7MB from download size and ~51.3MB from install size.
Tinder describes the design and implementation of several open‑source iOS libraries: the Nodes Architecture Framework, the Layout DSL, and CombineUI. Nodes is a plugin‑based mobile architecture using builder factories, context objects as interactors, listener delegates, and flow routers with explicit lifecycle management to control memory. Layout is a high‑fidelity result‑builder DSL wrapping Auto Layout for UIKit that yields concise, declarative‑style layout code and integrates with Xcode templates. CombineUI provides Combine‑based property wrappers and bindings for UI controls, and the post notes a hybrid approach that incrementally adopts SwiftUI alongside UIKit.
Tinder built Ignis (a golang CLI) to let developers run a single service locally while routing traffic through a shared k8s development cluster. Ignis swaps in a proxy container, connects a local dev container to cluster routing via a service mesh and API gateway, and uses a Smart Router (k8s informer-based grpc/http proxy) to dynamically route traffic to developer proxy pods. The tool integrates with metrics/logging, supports CRDs and remote IDEs in v2, and reduced staging environments and cloud spend while increasing developer velocity.
Tinder's API Style Guide — Part 1 explains challenges from inconsistent APIs across domain teams (errors, schema drift, versioning, unclear URIs) and defines standards for RESTful APIs: a recommended URI pattern, path-prefix versioning semantics and when to bump versions, path/resource naming rules (plural, kebab-case, nouns), guidance on path vs query parameters, rules and exceptions for HTTP method usage (e.g., POST with /query or /deletion suffix for special cases), custom header naming (X-Tinder- prefix), and request-tracing practices using a Tracer module with MDC and the in-house logging library. Part 2 will cover request/response bodies, status codes, and enforcement tools.
Tinder Security Labs analyzed how GitHub Actions' OIDC integration with AWS can be misconfigured such that external repositories can assume IAM roles. The post explains the OIDC/JWT flow, common trust-policy mistakes (e.g., missing sub validation), case studies including vulnerable AWS repositories, detection via CloudTrail, mitigation recommendations (tighten aud/sub checks), and publishes a black-box scanner (oidc-scanner-aws) to identify vulnerable roles.
Tinder built Obsidian, a cross-platform design system of standardized design tokens, reusable UI components, documentation and tooling to unify styling across iOS, Android and Web. Designers author tokens in Figma (Tokens Studio), Style Dictionary transforms tokens into platform-specific artifacts, Atomizer generates web styles, Zeroheight hosts docs, and internal tools (token lookup, publish scripts) help migrate existing code. The system improves consistency, theming (dark mode), accessibility, and speed of shipping features.
Tinder Security Labs describes how sensitive invitation/magic links (file-sharing links, SaaS invitation/signup links, ticketing invites, SSO registration links) were discoverable in urlscan.io indexes due to misconfigured API/integrations (often via email/security vendors). The post gives examples of impacted services (Google Drive, Office 365, Slack, Workday, Jira, Confluence, GitHub Pages), explains domain-allowlist and multi-tenant behaviors that enable abuse, and recommends mitigations: report indexed links to urlscan for removal, set scan visibility to private/unlisted, and review vendor API/reporting flows.
Tinder built TAG — a JVM-based API gateway framework on Spring Cloud Gateway — to centralize external-facing APIs for 500+ microservices. TAG is configuration-driven (Route-as-Config), provides pre-built and custom/global filters, integrates with Envoy/service-mesh and Kubernetes, and includes built-in security features (auth, session management, RGIL, request/response scanning using Amazon MSK). It was developed for consistent routing, security, extensibility, and developer velocity.
An Android engineer's guide to performing due diligence on third-party SDKs. The post outlines five categories to evaluate — Security, Documentation, Customization, Integration, and Performance — and lists concrete checks such as SOC2/PCI/PII vetting, documentation and licensing review, UI/localization/accessibility concerns, integration details (min SDK, permissions, Proguard), and performance metrics (APK/app bundle size, startup time, memory, network, battery).
Tinder describes architecture decisions for the Inception Service, an event-driven pipeline (Kafka) that renders and transcodes personalized videos for Swipe Night. They faced scale and cost constraints (thousands of consumer pods, compute-hour budgeting, and a 10-minute end-to-end requirement) and solved them via heartbeat-based fail-fast behavior, a stateful microservice to avoid duplicate renders, pre-processing vs real-time worker scaling, and a secondary consumer group for different traffic patterns.
Tinder's Android team describes how they experimented with and integrated Jetpack Compose into their large codebase: forming a working group, running alpha/beta experiments to understand build and dependency impacts (Kotlin compiler plugin, AGP, AndroidX), shipping a non-critical Licenses screen as the first production Compose surface, and adopting a Compose-first design system with view interop wrappers and best-practice guidance.
Tinder Security Labs describes common misconfigurations in GitHub Actions that enable remote code execution and secret exfiltration (unsafe user inputs in run scripts, misuse of pull_request_target). They open-sourced a scanner (Workflow Auditor) to detect vulnerable workflows, demonstrated exploit examples (curl/wget, Makefile/test script replacement) and recommend mitigations such as scoping github token permissions and sanitizing inputs. They also reported a vulnerability in Elastic's Logstash during testing.
There are internships and then there’s the Tindership program. Our interns spend their summer as part of our team, making a real impact on our business of ke...
Making connections works best when you can be your true self. Chris Tirabassi, Senior Product Designer at Tinder, shares how Tinder provided him with a place...
Tinder's iOS Developer Experience team migrated their iOS build and tooling stack to a hermetic Bazel-based toolchain. They created a Swift-built tooling repo, a YAML DSL and xc-cli code generator to keep Bazel and Cocoapods synchronized, used bazel-diff/Tulsi/remote archives, removed Homebrew as an external source, improved determinism and caching, migrated CI/CD (Jenkins) and release processes into code, and successfully produced Bazel-built IPAs with improved size and launch performance.
Up next on the Machine Learning team is anti-abuse analyst, Carlos Gutierrez. Joining Tinder nearly three years ago, he uses his knowledge to sequence stream...
