🐞 App icon switches back to Dev icon after restart
Bug Description
When I change Loop's app icon in the settings, it reflects in the dock and the cmdtab menu.
However, after I:
- Quit Loop (cmdq), or
- Close the Loop window (cmdw), if "Show in dock" is disabled
and then reopen Loop, the icon switches back to the default Dev icon, despite showing the icon I selected in the Loop settings.
Steps To Reproduce
- Install a dev build of Loop
- Select any non-Dev app icon in the Loop settings
- Quit Loop (cmdq), or disable "Show in dock" and close the Loop window (cmdw)
- Launch Loop again
Expected Behavior
The selected app icon should persist.
Actual Behavior
The app icon switches back to the default Dev icon, despite showing the icon I selected in the Loop settings.
macOS Version
Sequoia 15.5
Loop Version
Version 🧪 1.3.0 (1515)
Final Checks
- [x] My issue is written in English
- [x] My issue title is descriptive
- [x] This is a single bug (multiple bugs should be reported individually)
- [ ] I can help with fixing or developing this issue (tick if you can help).
Hey @injust! I’m unfortunately not able to reproduce this on my side.
Could you help me debug it by running this Terminal command right after you change the icon in Loop?
defaults read com.MrKai77.Loop currentIcon
Here’s what I’m looking for:
- Run it right after changing the icon and tell me the value.
- Then quit Loop, run the command again, and tell me that value too.
- Finally, launch Loop again and run the command one more time, and send me that third value as well.
That’ll help pinpoint when (or if) Loop is resetting the icon during its lifetime.
I can't reproduce this on the dev build anymore, but was able to after I reinstalled Loop (brew uninstall loop then brew install loop), which installed Version 1.2.0 (1410).
In all situations, running that command outputs the value corresponding to the app icon I picked, even after I relaunch Loop and the default icon is showing (by default on the non-dev build, I mean the actual default).
Hey, so i think i know why this is being caused, when you FIRST update to the dev build, it will do a core refresh of the icon and set it to the dev icon. This isn't tracked in the state, which makes the icon system think we're still on a different loop icon, doing a refresh by pressing a different icon, and back to the icon you want, fixes this issue. It looks to be a state issue somewhere down the icon chain. I had the same issue on my end and doing an click off and on worked, so i can no longer repo your issue as i could before.
Hey, so i think i know why this is being caused, when you FIRST update to the dev build, it will do a core refresh of the icon and set it to the dev icon.
I concur that it's caused during the update to the dev build. Because after uninstalling, reinstalling the normal build, then updating to the dev build, my dev build is stuck on the default icon now, not the dev icon like before.
doing a refresh by pressing a different icon, and back to the icon you want, fixes this issue.
I've done this a few times and can still reproduce.
I grabbed a screen recording but GitHub is giving me an HTTP 422 (Unprocessable Content) when I try to upload it...guess I'll try again later.
You are also more than welcome to compress (zip) the file and then send it through like that instead as well!
Turns out there's a 10MB upload limit (I swear this is new). Let me compress the video... (since it's a video, zipping it didn't really do anything meaningful)
Zipping it, Kai and I can unzip it and view it ourselves via quicktime/quicklook, so it will still work to get the point across, it's just not embedded as a preview in gh.
https://github.com/user-attachments/assets/e591aacf-19c6-4606-8b7b-3faf81b22341
Zipping it turned the original 44 MB video into 41 MB (lol)
Used ffmpeg to convert to HEVC, brought it down to 3 MB (!!)
I love ffmpeg, such a good tool, you can use YAFW to use it via Raycast, and interesting for your issue, somethings playing up, what build is this, i assume the lastest dev release?
what build is this, i assume the lastest dev release?
Version 🧪 1.3.0 (1479) Matches the latest release on GitHub
Yep, so the newest, interesting, so something wrong with updating and icons... yay my two LEAST fav bugs to fix....
Found the issue 😭
GitHub Actions Loop builds (also known as dev builds) are built with the debug configuration, so Loop skips the icon setup at launch. The fix for this will be to switch the automated Loop builds over to a release configuration.
You've got to be kidding me... that will do it...
Closing this issue as this is now fixed! If it's not, please open up a new issue and link this one.
I can still reproduce the issue in the latest dev release (Version 🧪 1.3.0 (1528)). Could someone double check, just in case I'm missing something?
I don't think this was fixed? Will re-open, but not near my computer so cannot check the code-side of things at the moment.
I was under the assumption we fixed that, but no, I can still see the code line in the AppDelegate under the #if !DEBUG, so yeah, that needs removing and it should be fixed.
Should now be fixed with #810 :)
Just tested in Version 🧪 1.4.0 (1555). Unfortunately, this isn't entirely fixed 😦
The more accurate issue description is now: The app icon updates to the selected icon on startup, but closing or quitting the app will cause it to revert to the Dev icon.
Screen recording
The 1st and 2nd times I close Loop, I am doing cmdw with "Show in dock" disabled. The 3rd and 4th times I close Loop, I am doing cmdq.
https://github.com/user-attachments/assets/dcd4fc6e-d86b-47bd-b0db-019eca594461
The behavior you're experiencing is expected for development builds. Development builds share the same configuration as those used by Loop's developers on their local machines. To avoid codesigning issues that can arise when the app icon is modified during runtime, the app intentionally doesn't change its actual icon in development builds. A possible solution (which I'm thinking is the best solution) would be introducing a separate scheme for development builds, in addition to the existing release and debug schemes, which GitHub actions would use instead :)
same bug