Dayforce Hub

The problem

Hub was buried behind a “More” tab and couldn’t host rich content — Dayforce’s most valuable employee surface, invisible to most users. The existing home screen was a fragmented entry point that didn’t surface the right information at the right time across a platform serving 3.2 million employees in regulated industries — payroll, time and attendance, workforce management.

Constraints

• Multi-tenant platform: a single codebase serves hundreds of enterprise clients with different feature sets, localisation requirements, and accessibility needs
• Regulated industries demand PII compliance and audit-ready data handling at every layer
• Feature flags and A/B experimentation had to be first-class, not bolted on
• Accessibility (VoiceOver, Dynamic Type, WCAG) was a hard requirement, not a nice-to-have
• CI/CD via Fastlane and GitHub Actions — every commit had to be shippable

Approach

Led the iOS rewrite in SwiftUI, promoted Hub to the landing tab, and built a multi-tab feed rendering rich text, images, video, action cards, and WidgetKit shortcuts. Led the Mobile HR team — 3 iOS engineers (including myself), 2 Android engineers, 2 QA, 1 backend engineer, and 1 PM — architecture proposal through production rollout.

Architecture. Clean Architecture layered over MVVM, with strict separation between domain logic and presentation. Swift Concurrency (async/await + Actors) throughout the data layer to eliminate race conditions without the callback pyramid of the previous codebase. Combine for reactive UI binding where SwiftUI’s native tools weren’t enough.

Modularisation. Feature delivered as a self-contained Tuist module — its own targets, dependencies, and test suite. Isolated from the monolith enough that a junior engineer can own a widget without touching the payment engine.

WidgetKit + App Intents. Extended Hub into the lock screen via WidgetKit — so the most time-sensitive employee data (next shift, pending approvals) is available without unlocking the device.

Localisation. Owned localisation for Hub from the iOS side — authored source strings in en_US.strings and managed handoff to the translation pipeline. Shipped in 39 languages at launch.

Accessibility. VoiceOver traversal order authored at design time, not patched post-review. Dynamic Type tested at all sizes. Contrast ratios met at every theme variant.

Quality. Shipped with XCTest + XCUITest coverage. Crash reporting via Sentry. Zero regressions in production since launch.

Outcome

• 3.2M total users globally at launch
• 1.2M daily active users — the highest-trafficked surface in the Dayforce iOS app
• 100% crash-free sessions in production (Crashlytics / Sentry)
• 39 languages supported at launch
• Adopted as the architectural reference implementation for subsequent iOS features at Dayforce

Learnings

Multi-tenancy at scale means your feature isn’t done when it works for one client — it’s done when it degrades gracefully for every edge case across every tenant configuration. Feature flags and defensive defaults are engineering discipline, not product overhead.