Test iOS geographic distances and geofence boundaries on a cloud Mac

If a nearby store suddenly appears tens of thousands of kilometers away, the location service may not be at fault. Swapping latitude and longitude, subtracting coordinates directly across the antimeridian, or rounding a distance before checking whether it falls within a radius can all produce similar failures. On a GNUMac cloud Mac, first validate the calculation layer with fixed coordinates, then reconnect location inputs and device callbacks. That gives each failure a clear owner, instead of leaving you dragging the map around and guessing.

Define the coordinate and distance contract first

This article checks the “distance along the Earth’s surface between two coordinates.” That is neither a driving route’s length nor the distance a user has actually walked. Inputs use decimal degrees, with latitude first and longitude second. Internally, all distances are in meters; convert units only for display.

Latitude must be between −90 and +90 degrees, and longitude between −180 and +180 degrees. Reject non-finite numbers as well. Do not silently clamp invalid inputs to the nearest boundary: that turns corrupted upstream data into an apparently normal record.

Valid coordinates do not guarantee a trustworthy location. Zero latitude and zero longitude form a valid position and must not automatically mean “location not yet available.” Whether to accept that position depends on the data source’s contract.

On-screen map distances are not suitable expected values either. Projection, zoom, and device pixels affect the image, but they should not affect business calculations.

Run fixed test fixtures on a cloud Mac

Prepare a macOS environment with the intended development toolchain selected, then run xcrun swift --version to confirm that the compiler is available. Save the following as distance-check.swift. The script does not read the current location, request location permission, or access the network.

import Foundation
import CoreLocation

enum CoordinateError: Error {
    case invalid
}

func point(_ latitude: Double, _ longitude: Double) throws -> CLLocation {
    let coordinate = CLLocationCoordinate2D(
        latitude: latitude,
        longitude: longitude
    )
    guard latitude.isFinite,
          longitude.isFinite,
          CLLocationCoordinate2DIsValid(coordinate) else {
        throw CoordinateError.invalid
    }
    return CLLocation(latitude: latitude, longitude: longitude)
}

func rejects(_ latitude: Double, _ longitude: Double) -> Bool {
    do {
        _ = try point(latitude, longitude)
        return false
    } catch {
        return true
    }
}

let origin = try point(0, 0)
precondition(origin.distance(from: origin) == 0)

let east = try point(0, 179.9)
let west = try point(0, -179.9)
let crossing = east.distance(from: west)
precondition(crossing > 20_000 && crossing < 23_000)
precondition(abs(crossing - west.distance(from: east)) < 1)

let polarA = try point(89.9, 0)
let polarB = try point(89.9, 180)
let polarDistance = polarA.distance(from: polarB)
precondition(polarDistance > 20_000 && polarDistance < 23_000)

precondition(rejects(91, 0))
precondition(rejects(0, 181))
precondition(rejects(.nan, 0))
precondition(rejects(0, .infinity))

Run the command below. If every assertion passes, the script produces no output. A failure returns a nonzero exit status, making it suitable for use directly as a pipeline step.

xcrun swift distance-check.swift

These ranges are broad tolerances for the test fixtures, not performance measurements or promises of business-level accuracy. Points on opposite sides of the antimeridian are close together; near the poles, a large difference in longitude does not mean the points are half a world apart. Both cases catch the mistake of treating latitude and longitude as planar coordinates and simply subtracting them.

Isolate the geofence boundary rule in a pure function

Assume the business rule is “a distance less than or equal to the radius counts as inside.” Test the comparator with manually supplied distances first, then feed it the coordinate calculation results. This avoids debugging two layers at once. Append the following code to the same file and run it again.

func isInside(distance: Double, radius: Double) -> Bool {
    guard distance.isFinite, radius.isFinite,
          distance >= 0, radius >= 0 else {
        return false
    }
    return distance <= radius
}

precondition(isInside(distance: 499.9, radius: 500))
precondition(isInside(distance: 500, radius: 500))
precondition(!isInside(distance: 500.1, radius: 500))
precondition(!isInside(distance: .nan, radius: 500))
precondition(!isInside(distance: 0, radius: -1))

let meters = 1_250.0
precondition(meters / 1_000 == 1.25)

Boundary tests must include exact equality, not just values that are clearly inside or outside. Do not infer the result from a display string such as “0.5 km”: different raw distances can round to the same text.

If the product needs to reduce repeated switching near the boundary, define a hysteresis policy with different thresholds for entering and leaving. That introduces a state machine and requires additional tests using sequences of inputs. It is not a reason to add an arbitrary “close enough” constant to the comparator.

Keep location accuracy separate from calculation tolerance

Real location samples also include a timestamp and horizontal accuracy. The integration layer should explicitly reject stale samples and handle negative horizontal accuracy values. Valid coordinates with poor accuracy should not directly generate a “confirmed entry” event either.

One conservative, auditable rule is to let d be the distance, a the horizontal accuracy, and r the radius. Classify the position as definitely inside only when d+a≤r, and definitely outside only when d−a>r. Mark all other cases as uncertain. This is a conservative business decision, not an interpretation of the accuracy value as a guaranteed absolute error bound.

During testing, inject precise, imprecise, stale, and invalid samples separately. Check that the uncertain state is preserved and that the interface does not incorrectly present a definite conclusion. Do not loosen calculation assertions to hide location noise.

Preserve evidence and integrate with the iOS project

The script above is useful for quickly rechecking framework behavior. For production integration, place coordinate validation and the comparator in a testable module, and have the test target call the production implementation directly. Maintain only one version of the algorithm so that a correct script does not coexist with an app still using outdated logic.

For each run, retain the commit identifier, toolchain version, fixture coordinates, raw distances in meters, and failed assertions. After a system upgrade, first determine whether a failure concerns input validation, the distance range, or the state policy. Do not simply refresh all expected values.

Finally, retain a round of acceptance testing on a physical iOS device: region-monitoring events, background execution, and actual movement belong to a separate chain of behavior. Passing pure calculation tests proves only that fixed inputs produced results consistent with the contract. Recording that limit in the acceptance notes is more valuable than adding random coordinates.

Frequently asked questions