Václav Slavík

@vslavik
33 Followers
126 Following
27 Posts
Indie developer behind Poedit and multiple other Open Source projects.
Homehttps://slavik.io
Poedit Apphttps://poedit.net
Dictionaries Apphttps://dictionaries.io
GitHubhttps://github.com/vslavik

My first encounter with vibe-coded “SaaS” slop: http://weeklyseo.io :
- “personal guarantee”… by anonymous “CEO” 🤦‍♂️
- lies about “500+ customers"
- ...but domain created a month ago
- mail server doesn’t even exist
- “AI” = wraps some mediocre static analyzer

Fun times ahead.

WeeklySEO - AI-Powered SEO Suggestions Every Week

Get 3 actionable SEO fixes every week. No expertise needed. Our AI analyzes your site and tells you exactly what to fix. Start free, no credit card required.

WeeklySEO
@keka @siracusa It can! I completely missed the flag my first time around, but there’s ASSETCATALOG_OTHER_FLAGS. Passing the undocumented flag plus --include-all-app-icons and having same-named AppIcon in Assets.xcassets seems sufficient and is much simpler. I updated the example repo. /cc @mjtsai
@mjtsai @siracusa It wasn’t… I didn’t touch it since the initial push.

I had to modify @vslavik's solution a bit because App Store Connect rejects such builds due to missing icon resources.

I changed the "actool" command line in the custom build phase to include the Assets.xcassets file path as the first argument (right before the existing .icon path argument) and then added the --include-all-app-icons option. That seemed to satisfy App Store Connect while still showing the pre-Tahoe icon on pre-Tahoe versions of macOS and the Tahoe icon on Tahoe.

@siracusa For MAS submission or just notarization?
@siracusa There's an undocumented setting that helps: https://mas.to/@avidrissman/114989207727177911 — and I *think* it still works in b5, although it's more than a bit hacky: https://github.com/vslavik/TahoeIconsTests
Avi Drissman :vm: (@[email protected])

@[email protected] By default, yes, `actool` will ignore .xcassets compatibility bitmaps that match the name of your app icon, and will instead substitute its own. However, if you use the super duper secret undocumented `--enable-icon-stack-fallback-generation=disabled` flag, it won’t. See https://source.chromium.org/chromium/chromium/src/+/cb9d61c26abea51d2ab51412352581a34574c8f9:tools/mac/icons/compile_car.py;l=154-164 . This worked as of db4; I really hope they didn’t break it in db5.

mas.to
@siracusa I just spent a few hours trying to reproduce in a new project, no luck. Or in a clean build. Must have been some caching, stale assets file or another form of PEBKAC :( There's apparently something special about app icons stored in Assets.car, it's not just the name, and that's what is throwing a wrench into things.
@mjtsai @avidrissman Seems to work for me - does this test project work for you: https://github.com/vslavik/TahoeIconsTests ?
@siracusa I only tried with app icon in Assets.xcassets so far, didn’t try external file. I think you may be getting another copy generated into the asset catalog, make sure to have ASSETCATALOG_COMPILER_APPICON_NAME unset in the project and ASSETCATALOG_COMPILER_INCLUDE_ALL_APPICON_ASSETS=YES (although that shouldn’t be needed for non-catalog icon…).