Build a Starlink Dish Alignment Compass UI in SwiftUI

What a dish alignment compass does

Aiming a satellite dish comes down to two numbers: an azimuth, the compass bearing to point along the ground, and an elevation, how far to tilt up toward the sky. A dish alignment compass turns the phone into the instrument that finds both. You hold the phone where the dish will sit, and the app shows whether you are pointed at the target bearing and tilted to the right angle. Starlink makes this friendlier than older satellite TV because its constellation of more than 7,000 satellites means the dish self-orients to a patch of sky rather than a single fixed point, but a clear view in roughly the right direction still matters, and a compass UI is how you check it.

So the screen has one job: show the target azimuth and elevation, and show where the phone is pointed right now, so the gap between them is obvious.

The two sensors: heading and tilt

The build rests on two frameworks. Core Location gives you the device heading, the compass bearing the top of the phone points toward, which becomes your azimuth reading. Core Motion gives you the device attitude, and its pitch becomes your elevation reading as the user tilts the phone up. You compare both against the target: the target azimuth and elevation have to come from a real source, the dish’s own service or a satellite-position calculation for the user’s location, never an invented constant.

Heading also comes in two flavors, magnetic and true north, and they differ by the local magnetic declination. Aiming is usually specified in true north, so convert, or you send people a few degrees off without knowing why.

The compass dial and the elevation indicator

The UI makes the two numbers physical. A compass dial rotates so the target bearing sits at the top, with a needle or marker for the phone’s current heading, and the user turns until the two align. An elevation indicator, often a tilting horizon line or an arc, shows the current pitch against the target angle, and the user raises the phone until they match. A clear “aligned” state, a color change and a haptic when both azimuth and elevation are within tolerance, is what makes the tool feel decisive. An AR overlay that draws the target direction over the camera is a strong addition, and it is the same directional-compass pattern behind a Qibla AR compass and an AR object placement target.

Keep the tolerance honest. Too tight and the user can never get the green state; too loose and you call a bad aim good.

The honest limits: calibration and interference

A compass app is only as good as the magnetometer, and that is the part to be honest about. The sensor needs calibration, the figure-eight motion iOS prompts, and it reads wrong near metal, magnets, cars, and reinforced walls, exactly the rooftops and balconies where dishes go. So the UI should surface accuracy rather than hide it: show when the heading is low-confidence, prompt calibration, and warn that nearby metal can skew the reading. The same realism drives a route-finding overlay like AR smart-glasses navigation, where the heading is only as trustworthy as the environment allows.

Presenting a confident needle on an uncalibrated, interfered reading is the core dishonesty to avoid, because it sends someone onto a roof to aim at the wrong patch of sky.

Building it from a template

The dial, the needle, the elevation arc, the aligned state, and the calibration prompts are the same in every aiming compass, so they are worth starting from. A free VP0 design ships the compass dial, the elevation indicator, the aligned and low-accuracy states, and an AR overlay as a SwiftUI file with a machine-readable source page, so pasting the link into Claude Code or Cursor gives the agent the instrument UI to wire to real heading and elevation data. The agent fills in the sensor plumbing against a screen that already reads clearly.

Common mistakes building an alignment compass

The recurring ones are about trust and data. Inventing a target azimuth instead of deriving it from a real source aims people nowhere. Confusing magnetic and true north sends them a few degrees off. Hiding sensor accuracy presents a confident needle on a bad reading. Skipping the calibration prompt leaves the magnetometer uncalibrated and wrong. And setting the aligned tolerance with no thought makes the green state either impossible or meaningless.

Key takeaways: a dish alignment compass UI

• It shows two numbers. Azimuth from heading, elevation from tilt, against a real target.
• Two sensors drive it. Core Location for heading, Core Motion for pitch.
• Convert magnetic to true north. Aiming is specified in true north; declination matters.
• Be honest about the magnetometer. Calibrate, surface accuracy, and warn about metal interference.
• Start from a compass template. A free VP0 SwiftUI design gives an agent the dial, the elevation arc, and the states to wire to real data.

Frequently asked questions

How do I build a Starlink dish alignment compass UI in SwiftUI? Read the device heading from Core Location for the azimuth and the device pitch from Core Motion for the elevation, then compare both against a real target azimuth and elevation derived from the user’s location or the dish’s service. Show a compass dial that rotates the target bearing to the top with a needle for the current heading, an elevation indicator for the tilt, and an aligned state when both are within tolerance. Convert magnetic heading to true north, prompt calibration, and surface accuracy. A free compass template gives you the dial, the elevation arc, and the states to start from.

What is the safest way to build this with Claude Code or Cursor? Give the agent a compass template and feed it a real target rather than a constant. A free VP0 SwiftUI design has a machine-readable source page with the dial, the needle, the elevation indicator, the aligned and low-accuracy states, and an AR overlay, so Claude Code or Cursor wires real heading and elevation data into a working instrument. That avoids the common result where an AI tool shows a confident needle with no calibration, no accuracy warning, and an invented target.

Can VP0 provide a free SwiftUI template for an aiming or AR compass? Yes. VP0 has free compass designs in SwiftUI with the dial, the needle, the elevation indicator, the aligned state, and an AR overlay already built, each exposing an AI-readable source page. Because the instrument exists, your agent connects it to Core Location and Core Motion data and a real target instead of reinventing the dial math and the accuracy handling that usually trip up hand-built compass apps.

How accurate is a phone compass for aiming a dish? Accurate enough to get close, but only if the magnetometer is calibrated and away from interference. The sensor needs the figure-eight calibration iOS prompts, and it reads wrong near metal, magnets, and reinforced walls, which is exactly where dishes are often mounted. So treat the reading as a guide, surface its confidence in the UI, convert magnetic heading to true north, and warn users that nearby metal can skew it. For fine aiming, the dish’s own signal feedback is the final check.

What common errors happen when vibe coding a compass app? Inventing a target bearing instead of deriving it from a real source, confusing magnetic and true north, and hiding sensor accuracy behind a confident needle are the frequent ones. Skipping the calibration prompt leaves the magnetometer wrong, and a thoughtless aligned tolerance makes the green state either impossible or meaningless. Derive the target honestly, convert to true north, calibrate, surface confidence, and set a sensible tolerance.