MaNaDr for Patient – AI Healthcare Ecosystem iOS App

#Overview

MaNaDr for Patient is the consumer-facing iOS app of the MaNaDr telemedicine ecosystem, connecting patients with over 1,000 qualified doctors worldwide for 24/7 virtual healthcare. Built by Mobile Health Pte Ltd, the platform enables secure chat and video consultations, appointment booking, home care services, and family healthcare management — all in one app.

As an iOS Engineer on this project, I worked on the appointment system, real-time tele-consultation features (chat and video calls), and the shared CocoaPods infrastructure that unified code across both the doctor and patient apps. The app maintains a 5.0 rating on the App Store with reviews highlighting its ease of use and reliability for video consultations.

#Screenshots

#What We Built

#Appointment Booking & Management

I implemented the patient-side appointment system, making it straightforward to find, book, and manage consultations:

• Doctor availability search — browse doctor schedules and select preferred time slots, with real-time availability reflecting bookings across the platform
• Appointment lifecycle — patients can view upcoming and past appointments, reschedule, and cancel with appropriate notice
• Reminders & notifications — push notifications remind patients ahead of scheduled consultations so they never miss a session
• Home care booking — extended booking flow for requesting in-home visits from doctors, nurses, or physiotherapists, including address input and confirmation tracking
• Family profile management — patients can add family members and book appointments on their behalf, with separate consultation histories per profile

The booking system had to coordinate in real time with the doctor app — a cancellation or rescheduling on one side needed to surface instantly on the other, which required careful state synchronization with the backend.

#Tele-Consultation: Chat & Video Calls

Real-time consultation is the platform's core value. I built and maintained both communication channels on the patient side:

Chat Consultations:

• Real-time messaging via PubNub with persistent conversation history
• Secure messaging with 256-bit SSL encryption, ensuring all clinical exchanges are confidential
• Typing indicators and read receipts providing the responsiveness patients expect from messaging
• Document and image sharing — patients can send photos of symptoms, prescriptions, and lab results directly in the chat

Video Consultations:

• HD video calls via Twilio, with adaptive bitrate to maintain quality on Southeast Asian mobile networks
• In-call experience: mute, camera flip, speaker/earpiece routing, and a visible session timer
• Smooth session entry and exit — minimizing the friction at the start and end of a consultation
• Post-call consultation summaries delivered in-app and optionally by email

Both channels are accessible on demand ("have a quick health concern?") and via scheduled appointments, covering the full spectrum of patient needs.

#Shared Code Architecture with CocoaPods

The patient and doctor apps share the same underlying platform — the same API, the same data models, and many of the same UI patterns. I helped build and maintain the shared CocoaPods layer that made this sustainable:

• Core networking pod — a single, tested API client used by both apps, ensuring request handling and authentication work identically regardless of which side of the platform you're on
• Shared domain models — common Appointment, User, ConsultationSession models prevent divergence between the two apps' understanding of platform data
• Reusable UI components — chat bubbles, video call overlays, and appointment cards are written once and adopted by both apps, keeping the UX consistent for patients and doctors interacting in the same session
• Versioned pod releases — semantic versioning ensured that shared pod updates were adopted deliberately, preventing unexpected regressions

This structure meant that a bug fix in the chat layer or appointment model was fixed once and deployed to both apps simultaneously.

#Fastlane CI/CD Integration

Both apps share Fastlane configuration, making the release process for the entire platform a single automated workflow:

• Unified signing with Match — certificates and provisioning profiles managed in one place, shared across both app targets
• Multi-app lanes — a single Fastlane command could build and distribute both the doctor and patient apps to TestFlight for coordinated QA
• App Store submission — automated metadata, screenshot, and binary submission reduced each release to a reviewed, one-command operation
• Release notes automation — changelog generation from git history, posted to Slack and included in TestFlight release notes

#Test Automation with XCUITest

I built UI tests covering the critical patient-facing journeys:

• Booking flow — searching for a doctor, selecting a time slot, and confirming an appointment
• Consultation entry — launching a chat or video session from a booked appointment
• Family management — adding a family member and booking on their behalf
• API stubbing — all UI tests run against stubbed API responses, making the suite fast, deterministic, and CI-safe

#Impact & Results

• 24/7 telemedicine access delivered to patients across Southeast Asia with high reliability
• 5.0 App Store rating across 20 reviews citing ease of use and reliable video consultations
• Shared CocoaPods infrastructure kept the patient and doctor apps in sync with a single source of truth for networking and UI components
• Fastlane automation enabled coordinated dual-app releases, cutting release time significantly and eliminating manual signing errors
• Family management reduced friction for caregivers managing health bookings for multiple family members
• 256-bit SSL across all communications met medical data confidentiality requirements

#Technical Highlights

Why CocoaPods for two apps? The patient and doctor apps are two sides of the same platform. Without a shared library strategy, every bug fix or feature would need to be implemented twice, with high risk of divergence. Private CocoaPods gave both apps a tested, versioned common foundation — changes flowed through a deliberate upgrade path rather than copy-paste.

Why PubNub for real-time messaging? For a telemedicine platform, message delivery is non-negotiable — a missed message between a patient and doctor is a clinical failure. PubNub's infrastructure handles message persistence, offline queuing, and global routing reliably, so the team could focus on building the medical UX rather than solving distributed messaging.

Why Twilio for video? Twilio's Video SDK provided a reliable, scalable infrastructure for real-time video with built-in adaptive bitrate, network traversal, and global media routing — a key requirement for serving patients across Southeast Asia where network conditions vary significantly. It also offloaded the complexity of media server management, letting the team focus on the clinical UX rather than video infrastructure.

Why Fastlane for both apps? Managing signing, builds, and App Store submissions for two apps in a small team without automation is a recipe for errors and slow releases. Fastlane unified the process, made any engineer capable of cutting a release, and enabled coordinated dual-app deployments where both sides of the platform go live together.