AppRun.c sets it up this way, doing a chdir(usr/).
Correct. But you don’t have to use this AppRun, you could also use your own script or even a link to your binary in its place. A safer method would be to find out the absolute path to your main executable, and calculate an absolute path to your data based on that, e.g., using the information from /proc/self/exe.

However the AppImage would then miss the --appimage-xyz options, that a user might know from different AppImages and expect to be present:

Well, the architectural question is what should be handled by AppRun (YOUR launcher that is supposed to also work outside of an AppImage, e.g., in a standalone AppDir) vs. AppImage’s runtime.c (common to all AppImages)… which already has some --appimage-... options.

My thoughts:

Are there any other benefits of using the provided AppRun binary?

Will there be further options in the future? Like the integration of the update mechanism directly into the AppImage?

Shouldn’t it be declared a best practice to always bundle the provided AppRun to guarantee a consistent behaviour across all AppImages?

AppDir (which imo should get its own wiki page describing its structure)

Thanks for the hint; added that page.

overheadhunter:

One of the questions that arise is, what is the benefit of the AppRun binary over just using a shell script or even a symlink to the application binary?

You can use a shell script or a symlink to the main executable, or the AppRun provided by AppImageKit. It really doesn’t matter as long as your AppRun file or symlink is capable of launching the main payload application correctly.

overheadhunter:

Are there any other benefits of using the provided AppRun binary?

Using the AppRun provided by AppImageKit takes care of launching the payload application for you in many cases, so it can save you from doing manual boilerplate code.

overheadhunter:

Will there be further options in the future? Like the integration of the update mechanism directly into the AppImage?

The AppRun file has nothing to do with the update mechanism. From our side we consider the AppRun provided by AppImageKit to be feature complete; if people have additional requirements they are welcome to write their own AppRun file (or extend the one in AppImageKit).

overheadhunter:

Shouldn’t it be declared a best practice to always bundle the provided AppRun to guarantee a consistent behaviour across all AppImages?

Not needed, since the only requirement of an AppRun file or symlink is to launch the main payload application. Every additional feature is a “specialty” of the respective AppImage and not something that all AppImages will (or should) support.

Code that should be common to all AppImages does not go into AppRun, but into runtime.c.

overheadhunter:

However the AppImage would then miss the --appimage-xyz options

These are not handled by AppRun but by runtime.c.

Remember that AppRun is an AppDir thing (predating AppImage and useable outside of AppImages) while runtime.c is an additional thing introduced by AppImage.