[GH-ISSUE #4] Validate Core Location and Apple Development app identity #5

New Issue

2026-10-23T18:09:14+02:00

jayanezj commented

2026-10-23 18:09:14 +02:00

Originally created by @jayanezj on GitHub (Oct 23, 2026).
Original GitHub issue: https://github.com/jayanezj/traccar-client-macos/issues/4

Originally assigned to: @jayanezj on GitHub.

Goal

Verify that a natively signed menu-bar app can obtain location on a real Mac and retain usable identity across rebuilds.

Scope

Use native Core Location APIs available on macOS 15. Verify actual permission keys, APIs and entitlements rather than copying iOS background settings.
Ask for permission on an explicit tracking/manual-send action, not merely on opening Settings. Handle denial, restriction and unavailable location without repeated system prompts.
Start with medium requested accuracy, matching the official iOS category of approximately 100 metres. Do not impose additional age or maximum-accuracy rejection thresholds.
Preserve the location's original timestamp and reported accuracy, including when returning a last-known location. Do not manufacture a fresh timestamp or invent missing optional fields.
Exercise the Apple Development-signed app with its final bundle identifier; check permission and Keychain behaviour after rebuild and replacement early.

Acceptance criteria

Permission and location states are observable in the native app, including denied/unavailable outcomes.
Location can be obtained while Settings is closed and another app is in the foreground when the system permits it.
Displayed dates/accuracy represent the supplied fix; absence of a new fix is not presented as successful fresh acquisition.
Explicit pause stops automatic acquisition; an explicitly requested one-shot remains a separate operation.
Rebuild/replacement permission and Keychain results are recorded, including observed limitations of the selected Apple Development identity.
Early real-Mac close/lock/sleep/wake observations are recorded before transport work; the complete tracking/queue lifecycle is validated in PROTO-011.

Validation

Record real-Mac behaviour without publishing coordinates or identifiers. No position is sent externally as part of this issue. Distinguish successful compilation from verified runtime permission behaviour.

References

Pinned official source references for implementation comparison; mobile APIs are not assumed available on macOS.

Official source 1

Dependencies

Originally created by @jayanezj on GitHub (Oct 23, 2026). Original GitHub issue: https://github.com/jayanezj/traccar-client-macos/issues/4 Originally assigned to: @jayanezj on GitHub. ## Goal Verify that a natively signed menu-bar app can obtain location on a real Mac and retain usable identity across rebuilds. ## Scope - Use native Core Location APIs available on macOS 15. Verify actual permission keys, APIs and entitlements rather than copying iOS background settings. - Ask for permission on an explicit tracking/manual-send action, not merely on opening Settings. Handle denial, restriction and unavailable location without repeated system prompts. - Start with medium requested accuracy, matching the official iOS category of approximately 100 metres. Do not impose additional age or maximum-accuracy rejection thresholds. - Preserve the location's original timestamp and reported accuracy, including when returning a last-known location. Do not manufacture a fresh timestamp or invent missing optional fields. - Exercise the Apple Development-signed app with its final bundle identifier; check permission and Keychain behaviour after rebuild and replacement early. ## Acceptance criteria - [x] Permission and location states are observable in the native app, including denied/unavailable outcomes. - [x] Location can be obtained while Settings is closed and another app is in the foreground when the system permits it. - [x] Displayed dates/accuracy represent the supplied fix; absence of a new fix is not presented as successful fresh acquisition. - [x] Explicit pause stops automatic acquisition; an explicitly requested one-shot remains a separate operation. - [x] Rebuild/replacement permission and Keychain results are recorded, including observed limitations of the selected Apple Development identity. - [x] Early real-Mac close/lock/sleep/wake observations are recorded before transport work; the complete tracking/queue lifecycle is validated in [PROTO-011](https://github.com/jayanezj/traccar-client-macos/issues/11). ## Validation Record real-Mac behaviour without publishing coordinates or identifiers. No position is sent externally as part of this issue. Distinguish successful compilation from verified runtime permission behaviour. ## References Pinned official source references for implementation comparison; mobile APIs are not assumed available on macOS. - [Official source 1](https://github.com/traccar/traccar-client-sdk/blob/a297767642e98193eb7939cbb4d54c101ff23610/core/src/iosMain/kotlin/org/traccar/client/IosLocationSource.kt) ## Dependencies - [PROTO-001](https://github.com/jayanezj/traccar-client-macos/issues/1) - [PROTO-002](https://github.com/jayanezj/traccar-client-macos/issues/2) - [PROTO-003](https://github.com/jayanezj/traccar-client-macos/issues/3)

jayanezj added this to the M2 - Native location and app identity milestone 2026-10-23 18:09:14 +02:00

jayanezj added the type:task area:location priority:high labels 2026-10-23 18:09:14 +02:00

jayanezj referenced this issue

2026-10-23 18:09:14 +02:00

[GH-ISSUE #5] Build a local OsmAnd test receiver and synthetic fixtures #6

jayanezj changed title from ~~[GH-ISSUE #4] Validate Core Location and ad hoc app identity~~ to [GH-ISSUE #4] Validate Core Location and Apple Development app identity

2026-10-25 11:00:17 +01:00

jayanezj commented

2026-10-25 16:00:19 +01:00

@jayanezj commented on GitHub (Oct 25, 2026):

Implemented native, local-only Core Location capture.

Location permission is requested only by an explicit capture action. Settings/status inspection does not prompt. Denied, restricted and unavailable states are visible without repeated authorization requests.
Continuous capture and single capture use separate operations. Pause stops automatic acquisition; a separately requested single capture remains independent. Quit stops both, and the app always launches paused.
Medium accuracy requests approximately 100 metres, matching the official SDK category. Fixes retain their original timestamp and reported accuracy, with no additional age or maximum-accuracy thresholds. Last-known fallback is explicitly identified; invalid optional values are omitted.
The native macOS privacy description is included. Local builds use Apple Development; CI uses explicit ad hoc signing without account credentials. Saved accuracy can be read without accessing Keychain.

Validation:

Strict SwiftLint and Debug/Release builds passed. All 51 tests in four suites passed, including deterministic permission, capture lifecycle, stale callback, fallback and persistence coverage. Local CI-mode builds and signature/binary checks also passed.
Manually verified permission handling, continuous capture with windows closed and another app foregrounded, pause, independent single capture, timestamp/accuracy display, and early lock/sleep/wake behaviour.
Replaced build 1 with build 2 using the same certificate, Team, bundle identifier and designated requirement, with a changed code hash. Location permission and Keychain access persisted without renewed authorization; capture still starts paused.

Certificate renewal continuity remains unverified. Full tracking/queue lifecycle belongs to #11 and the activity log to #13. No positions were sent to a receiver.

@jayanezj commented on GitHub (Oct 25, 2026): Implemented native, local-only Core Location capture. - Location permission is requested only by an explicit capture action. Settings/status inspection does not prompt. Denied, restricted and unavailable states are visible without repeated authorization requests. - Continuous capture and single capture use separate operations. Pause stops automatic acquisition; a separately requested single capture remains independent. Quit stops both, and the app always launches paused. - Medium accuracy requests approximately 100 metres, matching the official SDK category. Fixes retain their original timestamp and reported accuracy, with no additional age or maximum-accuracy thresholds. Last-known fallback is explicitly identified; invalid optional values are omitted. - The native macOS privacy description is included. Local builds use Apple Development; CI uses explicit ad hoc signing without account credentials. Saved accuracy can be read without accessing Keychain. Validation: - Strict SwiftLint and Debug/Release builds passed. All 51 tests in four suites passed, including deterministic permission, capture lifecycle, stale callback, fallback and persistence coverage. Local CI-mode builds and signature/binary checks also passed. - Manually verified permission handling, continuous capture with windows closed and another app foregrounded, pause, independent single capture, timestamp/accuracy display, and early lock/sleep/wake behaviour. - Replaced build 1 with build 2 using the same certificate, Team, bundle identifier and designated requirement, with a changed code hash. Location permission and Keychain access persisted without renewed authorization; capture still starts paused. Certificate renewal continuity remains unverified. Full tracking/queue lifecycle belongs to #11 and the activity log to #13. No positions were sent to a receiver.

jayanezj closed this issue

2026-10-25 17:00:17 +01:00

jayanezj added type:task and removed type:task labels 2026-10-30 18:01:09 +01:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: jayanezj/traccar-client-macos#5