# Some improvement requests

**URL:** <https://forum.safesky.app/t/some-improvement-requests/2096>\
**Category:** English\
**Created:** [August 8, 2025, 8:16am UTC](https://forum.safesky.app/t/some-improvement-requests/2096 "2025-08-08T08:16:13Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![Flyingfish](https://avatars.discourse-cdn.com/v4/letter/f/aeb1de/32.png) [@Flyingfish](https://forum.safesky.app/u/Flyingfish)\
**Post date:** [August 8, 2025, 8:16am UTC](https://forum.safesky.app/t/some-improvement-requests/2096/1 "2025-08-08T08:16:13Z")

</div>

Hello Safesky team.

Thank you for this clever solution and here my feedback after a few months of use,:

I fly a pressurized, high performance single engine, with every possible traffic avoidance solution on biard.

My avionics include a _dedicated_ iPad, with Garmin Pilot and Safesky in the background.

The iPad is permanently installed and powered and has its own LTE card. I use it alongside the certified avionics, which include ADSB in/out.

In my use case, Safesky provides an _additional_ layer of safety in low altitude situations, with the primary benefit of showing traffic that does not have Mode C, S or ADSB.

I use none of the other features - Safesky is a background app for me, and I would like it to be as robust, low workload and smart as possible in this role,

-Here my improvement suggestions:

1. Offer the possibility of starting Safesky automatically upon power on, in “ ground mode” and switching _automatically_ to Take-off once a plausible change in speed and altitude happens. Switch back to “ ground mode” once landing is detected. Make the “do you want to shut down Safesky” message optional for this use case.
2. Offer a parameter to disable the disclaimer.
3. Make the interface between Safesky and Garmin Pilot (and other such apps) as robust as possible, with a possibility of showing the state of Safesky in GP: is Safesky communicating? Is it getting data from the LTE link ?

As a summary, I’d like to see a version of Safesky that lives happily in the background.

And lastly, I think Safesky should be free or at least offer a stripped down no charge version.

Here is the reasoning:

1. aircraft operators who can afford traffic information are already using it, whether FLARM or mode C or more modern/ costly solutions.
2. The operators who balk at this expense are precisely the ones we want to add to our traffic detection capabilities. I am ok to pay for Safesky, but the pilot I am about to crash with may not, and I recognize and respect this limitation.
3. Since Safesky is an EASA project which complements existing solutions, EASA should do _everything in its power to get all traffic on board_. Duplicating existing capability has low added value in comparison

Thank you