Skip to content

Question: should iOS background location claims include UIBackgroundModes=location? #86217

Description

@jguida941

Summary

Static-analysis report, not a device-runtime repro: OpenClaw appears to have docs, runtime code, and plist copy for background location behavior when Always location permission is enabled, but the generated iOS background modes omit location.

I am filing this as an apparent docs/runtime/config mismatch and a maintainer-intent question, not as a confirmed end-to-end runtime bug.

Evidence I checked:

  • apps/ios/README.md has a Location Automation use case and asks QA to verify background location capability.
  • apps/ios/Sources/Model/NodeAppModel.swift handles backgrounded location.get requests, returns LOCATION_BACKGROUND_UNAVAILABLE unless the in-app mode is always, and requires authorizedAlways for background access.
  • apps/ios/project.yml and apps/ios/Sources/Info.plist say OpenClaw can share location in the background when Always is enabled.
  • UIBackgroundModes includes audio and remote-notification, but not location.

Semantic TDD Proof

Invariant used for the static proof:

If the iOS app claims background location support, the generated project/plist
configuration must include UIBackgroundModes=location.

Result:

openclaw/openclaw @ 367d584ee3bc563bfb74eee96f16017eceb6b41a
  RED: observed_project_background_modes=['audio', 'remote-notification']

local branch fix/ios-background-location-mode @ d1b1e37eec2e86e1ac06b93170026258b7b11cb8
  GREEN

Command used for the proof from the Semantic TDD repo:

examples/openclaw-background-location/run_live_repo.sh

Possible Repairs

If background location is intended, one alignment fix is to add location to UIBackgroundModes in both generated iOS proof surfaces:

UIBackgroundModes:
  - audio
+ - location
  - remote-notification

If background location is not intended for App Store/privacy/review reasons, the alternative valid repair is to remove or soften the background-location claims in README/plist copy and align the runtime behavior accordingly.

Scope

This proves one specific static docs/runtime/config/platform mismatch under the invariant above. It does not claim a full end-to-end device runtime failure or full OpenClaw CI verification.

Metadata

Metadata

Assignees

No one assigned

    Labels

    P2Normal backlog priority with limited blast radius.clawsweeper:fix-shape-clearClawSweeper found a clear likely implementation shape for this issue.clawsweeper:needs-maintainer-reviewClawSweeper marked this issue as needing maintainer review before automation.clawsweeper:needs-product-decisionClawSweeper marked this issue as needing a product or behavior decision.clawsweeper:needs-security-reviewClawSweeper marked this issue as needing security-sensitive review.clawsweeper:no-new-fix-prClawSweeper does not recommend queueing a new automated fix PR for this issue.clawsweeper:source-reproClawSweeper found a high-confidence source-level issue reproduction.impact:securitySecurity boundary, credential, authz, sandbox, or sensitive-data risk.issue-rating: 🦞 diamond lobsterVery strong issue quality with high-confidence source-level or clear reproduction.maturity:stableIssue affects a taxonomy feature currently scored M4/M5.

    Type

    No type

    Fields

    Priority

    None yet

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions