The v1.0.13 release notes list download assets that either don't exist or are packaged in a way that breaks a normal install.
New users are likely to hit a wall on this and abandon the app without ever using it, rather than investing the time to debug and repair the installation manually, just to see what the app is like.
1. Release notes reference assets that were never uploaded
The notes list:
macOS: musly-macos.dmg
Windows: musly-setup.exe
Neither exists in the actual release assets. The only real downloads are musly-macos.zip and musly-windows.zip. This sends users hunting for files that aren't there.
2. macOS zip strips the executable bit, so the app won't launch
Shipping the macOS build as a .zip (instead of the promised .dmg) drops the execute permission on the inner binary. After extracting and moving to /Applications, launching fails with:
RBSRequestErrorDomain Code=5 "Launch failed."
NSPOSIXErrorDomain Code=111 "Launchd job spawn failed"
The Finder dialog just says "the application can't be opened," which gives users nothing to go on.
Required manual fix & for those who need it temporarily:
chmod +x /Applications/musly.app/Contents/MacOS/musly
codesign --force -s - /Applications/musly.app
xattr -dr com.apple.quarantine /Applications/musly.app
Shipping a complete .dmg (as the notes already promise) preserves permissions and avoids this entirely.
3. Windows is portable-only, despite notes promising an installer listed as musly-setup.exe, but the file is not provided.
This leaves the only option of using the portable zip.
Having the portable is fine and portable is ok if you are just wanting to see if it is something you want to invest the additional time in debugging the installation process and repeating that each time an update arrives, but the notes should match reality so users know to keep the whole folder together rather than copying the .exe alone.
Suggested fixes:
Upload the assets the notes actually reference (real .dmg, real .exe installer), or update the notes to match what's shipped.
For macOS specifically, a .dmg (or a notarized build) would remove the single biggest barrier to first-run and new users that want to see what the app is like without all the installation friction.
Impact: Unnecessary onboarding friction, lower adoption.
Each of these are small & can be corrected, then incorporated into the pre-flight workflow.
Together they make a working install feel broken out of the box & perplexing at a minimum.
Many new users won't invest the time in running chmod/codesign to recover, etc. (or know to do so), let alone, just to try out a new client app.
They are more likely to waste some time trying to figure things out, give up and move along to another, less-promising app.
For the new users that realize what's wrong, take the time to fix it and get things installed properly, it's still not a good look and is easily avoidable.
The v1.0.13 release notes list download assets that either don't exist or are packaged in a way that breaks a normal install.
New users are likely to hit a wall on this and abandon the app without ever using it, rather than investing the time to debug and repair the installation manually, just to see what the app is like.
1. Release notes reference assets that were never uploaded
The notes list:
macOS: musly-macos.dmg
Windows: musly-setup.exe
Neither exists in the actual release assets. The only real downloads are musly-macos.zip and musly-windows.zip. This sends users hunting for files that aren't there.
2. macOS zip strips the executable bit, so the app won't launch
Shipping the macOS build as a .zip (instead of the promised .dmg) drops the execute permission on the inner binary. After extracting and moving to /Applications, launching fails with:
RBSRequestErrorDomain Code=5 "Launch failed."
NSPOSIXErrorDomain Code=111 "Launchd job spawn failed"
The Finder dialog just says "the application can't be opened," which gives users nothing to go on.
Required manual fix & for those who need it temporarily:
chmod +x /Applications/musly.app/Contents/MacOS/musly
codesign --force -s - /Applications/musly.app
xattr -dr com.apple.quarantine /Applications/musly.app
Shipping a complete .dmg (as the notes already promise) preserves permissions and avoids this entirely.
3. Windows is portable-only, despite notes promising an installer listed as musly-setup.exe, but the file is not provided.
This leaves the only option of using the portable zip.
Having the portable is fine and portable is ok if you are just wanting to see if it is something you want to invest the additional time in debugging the installation process and repeating that each time an update arrives, but the notes should match reality so users know to keep the whole folder together rather than copying the .exe alone.
Suggested fixes:
Upload the assets the notes actually reference (real .dmg, real .exe installer), or update the notes to match what's shipped.
For macOS specifically, a .dmg (or a notarized build) would remove the single biggest barrier to first-run and new users that want to see what the app is like without all the installation friction.
Impact: Unnecessary onboarding friction, lower adoption.
Each of these are small & can be corrected, then incorporated into the pre-flight workflow.
Together they make a working install feel broken out of the box & perplexing at a minimum.
Many new users won't invest the time in running chmod/codesign to recover, etc. (or know to do so), let alone, just to try out a new client app.
They are more likely to waste some time trying to figure things out, give up and move along to another, less-promising app.
For the new users that realize what's wrong, take the time to fix it and get things installed properly, it's still not a good look and is easily avoidable.