All apps
Yol Arkadaşım app icon

Yol Arkadaşım

A ride app that matches people heading the same way and splits the cost of a taxi, Uber or TAG ride between them.

  • iOS
  • Android
  • 2025
  • My own product
App Store · on hold Google Play · on hold

Screenshots

Click an image to enlarge it.

About the app

Getting around the city — taxis and Uber especially — has stopped being affordable for most people when they travel alone. That is where Yol Arkadaşım came from: bringing together people heading the same way so they can share the same vehicle and split the fare fifty-fifty, or at whatever ratio the two sides agree on.

There were two ways to use it. Someone driving their own car could post a listing, find a travel companion and share the cost. Someone without a car could pick their destination, see the estimated fare for a taxi, Uber or TAG, then find people going along the same route and split the cost with them.

The most common question about the app was "does it work like Uber?" and the answer was no. The app did not carry passengers and did not sell transport services; it matched two people who were going to share a ride that was happening anyway. That distinction mattered both for how the product was positioned and for its legal side, so the interface spelled it out clearly.

The hard part technically was the matching. A listing carried more than just "from where to where": it also carried when (right now or a future date), which type of vehicle, and which people, matching which criteria, were allowed to see it. So the query had to work in both directions: the searcher's filters and the listing owner's visibility criteria had to hold at the same time. Add location proximity and a time window on top of that, and matching became far more than a simple "same destination" query.

On the pricing side the app was not a taxi meter; it calculated an estimated amount from distance and duration, and the listing owner stated how much of that amount they could cover as a lower–upper range. That way both sides knew who would pay what before getting into the vehicle — which is exactly where disputes tend to start in a shared ride.

Getting into the same car with a stranger was the real trust problem the product had to solve. That is why I put messaging and video calling before the ride; people could see who they were dealing with before heading to the meeting point. Letting the listing owner set gender and age range criteria came out of the same need. I still think this idea is a problem worth solving.

The app is not in the app stores right now — I put the project on hold for a while; I did not shut it down. I paused the release because I prioritised other products; the matching logic and the data model are still intact and I plan to keep developing it.

Key features

  • Two ride modes: sharing your own car, or sharing a commercial ride (taxi, Uber, TAG)
  • Route-based matching: finding people heading the same way by origin, destination and time window
  • Estimated fare calculation: showing the ride cost up front based on distance and duration
  • Sharing range: the listing owner states the amount they can cover as a lower–upper bound
  • Criteria-based listing visibility: only users within the chosen gender and age range see the listing
  • Scheduled listings: planning a ride for "right now" or for a chosen date and time
  • Video calling before the ride plus messaging — getting to know each other before meeting
  • Listing discovery on the map: showing users along the route on a map
  • Quick filters: "recommended for you", "very urgent" and all listings
  • Discovery by interest: finding a travel companion through shared interests
  • Favourites and similar listings — saving a listing and seeing alternative suggestions

Technologies used

116 technologies · 12 categories

Languages and Platform

  • Swift
  • Kotlin
  • Java
  • iOS SDK
  • Android SDK
  • Native dual-platform development

UI and Application Layer

  • UIKit / SwiftUI
  • XML Layout / Jetpack Compose
  • UITableView / UICollectionView
  • RecyclerView (Android)
  • Date and time pickers
  • Filter and search interfaces
  • Form validation

Backend and Data

  • Firebase Firestore
  • Firestore data modelling
  • Composite index and query design
  • Firestore security rules
  • Firebase Storage
  • Cloud Functions
  • Firebase Authentication
  • Pagination and query optimisation
  • Firestore offline cache
  • Batch write
  • Cursor-based pagination
  • Denormalisation
  • Counter fields
  • Cloud Functions triggers
  • Scheduled jobs
  • Data migration

Location and Maps

  • MapKit (iOS)
  • Google Maps SDK (Android)
  • Core Location (iOS)
  • FusedLocationProvider (Android)
  • Location permissions
  • Route and distance API
  • Geocoding and address search
  • Polylines and map markers

Real Time and Media

  • JitsiMeet SDK (self-hosted)
  • WebRTC-based video calling
  • AVFoundation (iOS)
  • Camera and microphone permissions
  • Firestore real-time listeners
  • APNs (iOS)
  • Firebase Cloud Messaging
  • PHPicker / Android media picker
  • STUN / TURN configuration
  • Audio routing (speaker / earpiece)
  • Keeping calls alive in the background
  • Reconnecting after network drops
  • Call state synchronisation
  • Server resource and scale monitoring

Matching and Discovery Logic

  • Route-based matching
  • Geospatial proximity queries (geohash)
  • Time window filtering
  • Fare estimation from distance and duration
  • Criteria-based listing visibility
  • Interest matching
  • Favourites and similar listing suggestions

Architecture and Patterns

  • MVVM / MVC
  • Repository and service layer
  • Asynchronous programming (async/await, Coroutines)
  • URLSession (iOS)
  • Android HTTP client
  • JSON parsing (Codable)
  • Dates, time zones and localisation
  • App lifecycle and state management

Networking and Data Transfer

  • HTTP client (Android)
  • Retry and timeout handling
  • Offline state management
  • Image caching
  • Download and upload queue
  • Multipart file upload
  • Bandwidth-aware quality

Security and Privacy

  • Keychain (iOS)
  • EncryptedSharedPreferences (Android)
  • HTTPS and ATS
  • Authentication token management
  • Session refresh
  • Permission rationale copy
  • Account deletion flow
  • Server-side authorisation checks
  • Sensitive data masking

UI States and Accessibility

  • Dark theme support
  • Dynamic Type
  • Safe area handling
  • Empty / loading / error states
  • Skeleton loading
  • Pull to refresh
  • Keyboard and focus management
  • Deep linking (Universal Links)
  • VoiceOver / TalkBack labels

Testing, Debugging and Measurement

  • Xcode Instruments
  • Android Profiler
  • LLDB
  • Logcat
  • Memory leak tracking
  • Network traffic inspection
  • Reading crash reports
  • Testing on real devices
  • Testing across screen sizes

Tools and Release Process

  • Xcode
  • Android Studio
  • App Store Connect
  • Google Play Console
  • CocoaPods
  • Gradle
  • Git
  • DigitalOcean server management
  • TestFlight
  • Play Console internal testing
  • Version and build numbering
  • Signing and provisioning profiles
  • App Store review process
  • App Privacy / Data Safety form
  • Store assets and ASO copy
  • App size optimisation
Solo work

Idea, design, interface, code, app store release and post-release maintenance — I ran the whole process end to end on my own. No team, no agency, no outsourcing.

Development notes

  • Languages and approachThe iOS side was written in Swift and the Android side in Java and Kotlin. No cross-platform framework was used; both apps were built with their own platform's native tooling. I have been doing mobile development since 2020.
  • No AI assistanceAll of the code was written by hand. This project was built before AI coding tools such as Claude Code and Codex became widespread — no such tool existed at the time.
  • DependenciesA large number of open source GitHub libraries and CocoaPods packages were used. Dependency management was handled with CocoaPods on iOS and Gradle on Android.
  • Video call infrastructureJitsiMeet was self-hosted on my own server rather than used as a managed service (DigitalOcean). Server setup, media streaming and scaling were all on me.
  • Trust and safetyMessaging and video calling before getting into a car with a stranger, plus the ability for the listing owner to decide who gets to see their listing.
  • Testing and debuggingTested on real devices, across different screen sizes and under poor network conditions. After release I read crash reports and shipped fixes version by version.
  • Release processI handled the review process for both stores on my own: App Store Connect and Google Play Console setup, the privacy declaration (App Privacy / Data Safety), release notes, store assets and fixes in response to rejection reasons.
  • Product ownershipIdea, design, development, backend, app store release and post-release maintenance — I ran the entire process on my own.

Let's talk about Yol Arkadaşım

I'm happy to walk through the technical details, the problems I ran into and how I solved them.