Time Tracker: Replacing Manual Clock-Ins with GPS Location Data

The work-hour management challenge at a medical institution

Researchers at the medical institution work flexible hours, coming and going from the campus at irregular times. Traditional clock-ins or manual work-hour logging both add administrative burden and struggle to accurately reflect actual time spent on-site.

What the institution needed was an automated work-hour tracking solution that “doesn’t get in the way of the actual work.” Users just needed to carry their phone into the workplace, and data would be collected automatically — with management able to view aggregated statistics in real time.

---

Core design: automatic work-hour tracking via background GPS

How the full system works:

1. The user logs into the app
2. The app logs a GPS location in the background every 10 minutes
3. Data is uploaded to a designated database
4. An algorithm compares GPS coordinates against preset work locations, automatically calculating on-site work hours
5. The user’s app displays a 7-day work-hours bar chart; the admin back office can look up work-hour records for all staff

Notice something? The user doesn’t have to do anything manually! As long as the app’s background execution stays enabled, GPS data is automatically collected and calculated.

---

iOS background execution: the trickiest technical challenge

Background location collection on Android is relatively straightforward, but the iOS version ran into Apple’s strict system limits, becoming the project’s central engineering challenge.

Initial authorization requires guided onboarding

iOS doesn’t let an app automatically obtain “Always Allow” GPS permission right after installation — the user has to actively go into system settings to make that switch. To address this, we designed a complete guided flow inside the app, walking users step by step through:

1. Allowing push notifications for the app
2. Going into device settings to find location permissions
3. Switching from “While Using the App” to “Always”
4. Returning to the app to enable background execution

What was originally a setup flow of up to 12 steps was simplified through UI guidance, with a screenshot at every step, so even users unfamiliar with system settings could complete it smoothly.

Three scenarios that interrupt data collection

iOS’s background execution model means there are certain points where data collection is bound to be interrupted:

Interruption cause	Description
Manually swiping the app away	Swiped up from the multitasking switcher
Phone restart or shutdown	Includes automatic shutdown from a dead battery or a forced restart from a system update
Uninstalling the app	App removed

All three of these happen commonly in everyday life, and they’re limitations that any app requiring long-term iOS background execution has to contend with.

---

Disconnection-detection push mechanism: restart with a single tap

In earlier versions, restoring authorization was extremely cumbersome — users had to go into system settings themselves to manually adjust location permissions, then return to the app and walk through the entire onboarding flow again.

That was a high barrier for the average user, and it caused a fair amount of data loss.

The solution sounds simple, but it required careful design underneath: disconnection-detection push notifications.

The system continuously monitors each user’s data-upload status. The moment it detects an upload timeout, it immediately pushes a notification to that user. The user just taps the notification to reopen the app, authorization automatically restarts, and data collection resumes instantly — no system settings required.

Just sending a push notification — how hard can that be? The tricky part is exactly because everyone assumes it’s simple: we had to rigorously define what counts as “timeout,” balancing the client’s requirements against practical reality. We needed to avoid letting a disconnection run so long that even the push notification couldn’t restart it, while also avoiding sending notifications so frequently that they annoyed users. There was real design craft in finding that balance.

---

A scheduling assistant feature to boost adoption

Once GPS location data could be reliably captured, the next step was work-hour calculation — and for the client’s algorithm to run correctly, the “schedule” turned out to matter a great deal.

In an institution with highly variable work patterns, the user interface needed to be not just simple, but intuitively functional.

We referenced the design of various calendar apps to build a scheduling assistant feature tailored specifically to this project.

---

Phased acceptance, incremental refinement

The more complex a system, the more carefully it needs to be accepted — this project used a multi-phase acceptance model, delivered across three phases:

• Phase 1: app feature development, basic data collection, app store launch
• Phase 2: data collection stability optimization, refined background execution mechanism
• Phase 3: disconnection-push mechanism, passing information-security testing

At every acceptance milestone, the client had a clear picture of what was being delivered at that stage, and could see the system becoming more complete, building on the previous phase.

---

The core lesson from this project

“Keeping an app running in the background” is relatively easy to achieve on Android, but on iOS it’s a hurdle that requires careful design to clear. Apple’s restrictions exist for good reason — protecting battery life and user privacy — but for an application that needs to collect sensor data over the long term, that means finding a reliable way to operate within the system’s constraints.

This project’s solution wasn’t to work around the limitations — it was to accept them and design a matching fault-tolerance mechanism: when interruption is unavoidable, let the user recover at the lowest possible cost, minimizing the impact of any data gaps.