Mobile client for AOG-style rigs (iOS) — testers wanted

Software
1

Goal — a serious mobile “cab” client for the AgOpenGPS hardware ecosystem

I’m an iOS developer; we use AgOpenGPS-style equipment on the farm. Long term I want a phone/tablet client that can follow the same kind of ECU + network (UDP/NMEA) + NTRIP workflow people already run today — not a toy map, but something you can actually work with in the field.

North star (honest)

  • Work toward full parity with the core AOG on-tractor experience people rely on: mapping, guidance, application/coverage-style visualization, field/lines, and a clean link to the board/receiver (NTRIP on the phone relayed to the ECU, etc.).
  • “Fully clone” the Windows program in every detail is a huge surface area; I’m not claiming day-one equality — I am saying that is the direction of travel, and I want feedback so effort goes to what real operators need first.
  • Beyond parity, I’m interested in extra modes and workflows that make sense on mobile (e.g. faster setup, better outdoor UX, things that are awkward on a laptop in the cab) — specific list will be driven by field testing.

What exists today (iOS) — so expectations are clear

  • Map, vehicle position, implement width + multi-section logic, live swath / coverage-style fill while moving
  • AB line workflow and field boundary record/save
  • NTRIP on the iPhone with corrections forwarded to the ECU (typical tethering story)

What I need from the community

  • A small set of people with a real rig (board IP / UDP, typical NMEA path) who are willing to test early builds and be blunt: what’s missing for your operation, what breaks, and what you’d pay attention to in the cab every day.
  • If you have a “must have” list (guidance types, field ops, headlands, tramlines, data formats, etc.), reply with your use case — it directly orders the roadmap.

I’ll keep this thread as the home for mobile client progress so we don’t scatter the same update across multiple topics.

Mods: if this belongs in a different category, feel free to move it.

2
3

Small development update and clarification about direction.

Some people pointed me to the AgValoniaGPS project — I’m aware of it and it’s great to see more work happening in the mobile/cross-platform space.

My approach here is intentionally different: this client is being built as a fully native iOS app in Swift rather than a cross-platform UI. The main reason is reliability, performance, and better integration with iOS networking and hardware features, which matters when the device is actually used in the cab for hours in field conditions.

Current prototype status (tested on real hardware):

  • UDP/NMEA communication working with typical AOG-style ECU setups
  • NTRIP running directly on the iPhone with corrections forwarded to the ECU
  • Real-time position display with live swath/coverage fill
  • AB line workflow and field boundary recording functional
  • Multi-section logic working with implement width

This has been tested on real equipment, not just simulated data, and the focus right now is stability and usability rather than feature count.

Direction going forward:

The goal is not just to mirror the Windows interface, but to build workflows that make sense on a tablet/phone in real working conditions — faster setup, fewer taps, and better outdoor visibility.

Feature priorities I’m currently evaluating:

  • Additional guidance types (A+, curve, headlands, tramlines)
  • Field and job data handling
  • Performance optimization for long field sessions
  • Improving UI readability in sunlight and vibration conditions
  • Robust reconnect handling (Wi-Fi drop, NTRIP loss, etc.)

What would help most right now:

If you run real AOG-style rigs and are willing to test early builds, I’m especially interested in:

  • Your ECU/network setup (UDP layout, receiver type)
  • Which guidance modes you rely on daily
  • What features you consider mandatory before using a mobile client in production
  • Pain points from current laptop-based workflows

Real-world operator feedback is what will decide the feature order — not assumptions.

I’ll keep posting updates here as testing progresses.

4

Where is the repo link? I don’t see it here or on the AgroNavigator site.

5

At this stage, there is no public repository link.

This project is being developed as my own native iOS app, written from scratch in Swift. I’ve reviewed the AgOpenGPS repository and documentation to understand how typical AOG-style systems (UDP/NMEA/NTRIP workflows) communicate, mainly because we use similar autosteering equipment on our family farm. However, this app is not based on copying code or files from that project — it is an independent implementation designed to work with AOG-style equipment as well as other compatible configurations.

For now, I plan to keep the source code closed. The intention is to release the finished iOS app publicly later this year.

Right now, the main focus is real-world testing and usability on actual installations. As things stabilize and the feature set matures, I’ll share more details about distribution and availability.

If you’re interested in testing, feedback from real-world setups is the most valuable input at this stage.

6

The AgOpenGPS ethos is open source and sharing. Farmers helping farmers. If you are unwilling to do that I would not support this project. I would also strongly encourage others in the AgOpen community to do the same.

It would probably be good for you to not use AgOpen community resources like this Discourse for your project.

3 Likes
7

I completely understand the AgOpenGPS ethos and I respect what the community has built — it’s a genuinely impressive open system and it’s also the reason I started working in this space.

To clarify my position: I’m building an independent native iOS application from scratch in Swift. I’ve looked at AgOpenGPS documentation and behavior mainly to understand how AOG-style systems communicate (UDP/NMEA/NTRIP), because we use similar autosteering equipment on our family farm.

The goal is not to fork or replace AgOpenGPS, but to build a mobile-first client that works reliably in real field conditions on iOS, while staying compatible with existing AOG-style hardware and workflows.

This project is currently not open-source. At the same time, I’m very interested in interoperability and I want it to remain compatible with the broader AOG ecosystem. I also plan to continue sharing testing progress and gathering feedback from real-world setups here.

My intention is practical: to improve usability in the cab for mobile users, based on real field testing rather than simulation.

8

You should probably establish your own resources; Discourse, Telegram, etc for your project and not use the ones for AgOpen. Don’t want confuse folks this is an official AgOpen project.

Copying is not limited to code. It covers ideas, methods and processes.

9

Thanks for the follow-up, and I want to address both points directly.

On the “official” concern — to be absolutely clear, I have never presented this project as an official AgOpenGPS app, and I don’t intend to. It is an independent iOS client. If any of my wording in this thread has been read that way, I’m happy to edit it and to add an explicit disclaimer to my posts stating that the project is not affiliated with or endorsed by AgOpenGPS. That’s a fair point and an easy fix.

On the broader point about using this Discourse — I posted here because I’m an operator on AOG-style equipment myself and I was asking real users what they actually need in the cab. I’m not promoting a product, linking to a store, or trying to divert the community. If the moderators feel this topic doesn’t belong here I’ll of course respect that, and I’m already planning my own channels for project-specific discussion going forward.

On “copying is not limited to code — it covers ideas, methods and processes” — I want to push back on this respectfully, because I think it’s important for the conversation.

I’m a technical specialist who has been working around autosteering and guidance systems for more than 15 years. Every serious autosteering system I have ever worked with — proprietary and open — is built on the same underlying foundation: GNSS positioning, pure-pursuit / Stanley-style path tracking, AB and curve geometry, section control logic, NMEA for position, NTRIP for corrections, UDP for ECU comms. These are not AgOpenGPS inventions. They are standard, published, decades-old techniques in agricultural guidance and mobile robotics. AgOpenGPS does an excellent job of packaging them into an open system, and that is exactly why the community deserves credit. But the geometry and the GUI patterns underneath are general engineering knowledge, not proprietary ideas that belong to any one project.

What I am building is my own Swift implementation, written from scratch, using that general body of knowledge — the same way anyone writing a new guidance app today would. I haven’t taken files, assets, data formats, protocols-as-defined-by-AOG, artwork, documentation, or UI layouts from the project. If at any point something I build does depend on an AOG-specific protocol detail, I will document the interoperability clearly and credit the source.

My goal here is genuinely to build a polished product that is useful to this community of farmers, not to compete with AOG.

10

This has the markers of being a commercial venture or aspirations of being one. The AgOpen community was built on the idea of getting away from closed commercial solutions. An invite posted once in the sales or commercial sections to your own resources is not an issue, IMHO. Starting a thread for your own closed project on an open source projects resources is bad form.

If you really are a specialist with 15 years of autosteer and guidance knowledge, why not contribute to one of the AgOpen official projects? Or request this project be added to the AgOpen-Official repo? If you are using AgOpen today, why not give back to the community that created that for you?

1 Like
11

Fair questions. Let me address both at once.

Regarding the commercial aspect: this may become a commercial product in the future — I won’t pretend otherwise. I also understand that AOG was created as a deliberate alternative to closed commercial systems, and I respect that. The existence of an optional iOS app, alongside AOG and AgValoniaGPS, in no way diminishes what the community already has; it simply adds another option for operators who prefer this particular approach.

Forum etiquette: noted. I will stop using this thread to post news about the project. Any future mentions here will be one-time notifications in the appropriate category, and everything else will move to my own channels.

To the question “why not contribute to AOG-Official instead” — the honest answer:

I can’t provide meaningful help to AgValoniaGPS because I’ve never written in .NET or C#. The Avalonia cross-platform stack is an engineering challenge distinct from native Swift — I would be a weak contributor there. Where I’m truly useful is in aspects specific to iOS: background operation, network stability, map rendering, sunlight readability, and Apple’s signing and distribution model. That’s where my time and effort yield the best results.

It’s also worth noting that we’re talking about the Apple ecosystem specifically. Unlike Android or desktop, a regular user can’t just download source code and install the app on their iPhone — the binary has to be signed by a developer with a paid Apple Developer account ($99/year), and without that the build simply won’t run, or will stop working after a few days. That’s the main reason you see so few open-source iOS apps in practice: even if the code is public, the end user still needs someone with a paid account to ship a working build to them. Putting a properly signed app in the App Store is, in that sense, one of the more useful things an iOS developer can actually do for non-technical users.

A request to add the app itself to AgOpen-Official would mean making it open-source, and I’m not ready to make that decision — this project is a continuation of what my father and I have been building as a family, and we’re keeping the option of a future product open. I prefer to be upfront about this.

But I would also like to be useful to the community and interact more with all of you in the future, so I plan to:

  • Provide an open, documented specification for the AOG ↔ iOS interaction layer, so that the AgValoniaGPS iOS target and any future mobile client can benefit from it — useful for anyone building a native Swift client.
  • Open-source parts of the compact steer-ready board my father and I are developing.
  • Reach out to the AOG founders directly, not just as a promise on the forum.
1 Like
12

Fair enough. Best of luck in your endeavor. Though I would suggest being more up front on the commercial aspect. It shouldn’t take 20 questions to get to the answer.

2 Likes