New aprs.fi iOS app backend API in testing

33 views
Skip to first unread message

Heikki Hannikainen

unread,
Mar 20, 2026, 4:12:54 PMMar 20
to apr...@googlegroups.com

Hi,

I'm testing a new implementation of the backend API for the aprs.fi iOS
app right now. It's faster, more maintainable, shinier, and smells better.
The old one had a weird odour already.

It should be backwards compatible and the app should, hopefully, work just
as before. If anything seems weird (I mean, more weird than usually), let
me know. Just post in the thread here or something. I can switch back and
go back to the drawing table if necessary.

- Hessu, OH7LZB / AF5QT

Conrad Lara - KG6JEI

unread,
Mar 29, 2026, 5:11:59 PMMar 29
to aprs.fi
Unsure if this is related to the IOS backend changes or is caused by another issue, however it appears to have started around the time of your post.

I'm observing inconsistency in station locations based on the pages visited on APRS.fi

Searching for station: KI6RIXX-i 

https://aprs.fi/#!call=w%2F4016739840&timerange=3600&tail=3600
Shows last beacon time as 2026-03-28 14:55:28 (at time of writing) with the station location in a reasonable location for where it is expected to be at this time.

Visiting the info page https://aprs.fi/info/w/4016739840
Last position:

2026-03-19 23:11:27 PDT (8d 15h45m ago)

The location appears reasonable for 8 days prior which is not near the current expected location.

Addtionaly the APRS.fi REST API returns the 
2026-03-19 23:11:27 PDT location 

Similar also seen for KG6JEI-i

Both stations utilizing the APRS.fi app.

Best Regards,
Conrad Lara
KG6JEI

Heikki Hannikainen

unread,
Mar 29, 2026, 5:46:12 PMMar 29
to aprs.fi

Hi,

On Sat, 28 Mar 2026, Conrad Lara - KG6JEI wrote:

> I'm observing inconsistency in station locations based on the pages visited on APRS.fi
>
> Searching for station: KI6RIXX-i 
>
> https://aprs.fi/#!call=w%2F4016739840&timerange=3600&tail=3600
> Shows last beacon time as 2026-03-28 14:55:28 (at time of writing) with the station location in a reasonable location for where it is
> expected to be at this time.

Right, this was a bug in the new backend code, it was not updating a
cached record like it should for new positions.

That's now fixed, the data will be stored correctly when the next updated
position comes in.

Thank you for the bug report!

- Hessu
Reply all
Reply to author
Forward
0 new messages