# Best Practice for AppImage Distribution

**URL:** https://discourse.appimage.org/t/best-practice-for-appimage-distribution/314
**Category:** Creating AppImages
**Created:** [March 28, 2018, 8:30am UTC](https://discourse.appimage.org/t/best-practice-for-appimage-distribution/314 "2018-03-28T08:30:42Z")
**Posts on this page:** 1
**Showing post:** 3

<div class="post-metadata">

### Author: ![overheadhunter](https://yyz1.discourse-cdn.com/flex027/user_avatar/discourse.appimage.org/overheadhunter/32/128_2.png) [@overheadhunter](https://discourse.appimage.org/u/overheadhunter)
#### Post date: [March 28, 2018, 1:15pm UTC](https://discourse.appimage.org/t/best-practice-for-appimage-distribution/314/3 "2018-03-28T13:15:36Z")

</div>

Having the AppImages on the PATH is for sure an advantage. But `~/.local/bin` is hidden from GUI-only users. Ideally we need a place that satisfies both.

> [@juanma1980](#):
>
> a simple script that downloads the appimage, chmod to exec and adds a desktop

I already thought about adding a single-line copy-paste install script that you can just paste into your terminal, just like [Homebrew](https://brew.sh/) does. The downside is, that this trains users to blindly execute any potentially malicious terminal commands they find in the internet.

I will for sure recommend also installing appimaged. Let’s hope for it to be [included in many distributions](https://discourse.appimage.org/t/native-appimaged-distribution-packages-debian-fedora-opensuse-etc/144) as soon as possible. But I like the fact that it is not strictly required. This is the main benefit over snap or flatpak.

If AppImageHub or AppImageUpdater (or other services) don’t extract version information or other metadata from GitHub Releases, we will stick with Bintray for now.

---

_[View the full topic](https://discourse.appimage.org/t/best-practice-for-appimage-distribution/314)._
