tldr; Multi Monitor Wallpaper can give you the daytime images for your dynamic wallpaper even if you use dark mode.
One of the trickier things that Multi Monitor Wallpaper does is pull apart dynamic wallpapers so that it can build separate ones for each of your monitors. It then puts them back together again.
These dynamic wallpapers should change with the sun – but they don’t always.
Sometimes, it is just one of Apple’s many frustrating bugs* around wallpapers.
Sometimes it is something that looks like it was intended as a feature.
One of those is the feature where dynamic wallpapers can declare which images are suitable for dark mode. Sometimes, the operating system will honour that declaration. When you switch to dark mode, even in the middle of the day, it will show you an evening/night image.
I thought Big Sur had stopped doing this, but it turns out the behaviour is just intermittent. On my iMac right now, the Catalina wallpaper shows based on the current time whatever your mode. The Big Sur wallpaper switches to match the mode.
On my Macbook air, they were both switching earlier today – but now neither is switching.
I have no idea what is causing this inconsistent behaviour. I have pulled out the metadata and they both have the same structure.
However – I can fix it so that you can see all the images whatever your mode.
Multi Monitor Wallpaper now has a setting (enabled by default) which simply tells the operating system that every image is suitable for use at night. This is based on the fantastic work by Marcin Czachurski.
You can turn this off if you prefer. In that case, you’ll get Apple’s default and unpredictable behaviour. It might show dark images when you use dark mode. It might not!
*for example the popup display bug reported when Mojave was in beta here, or the bug I have reported where disconnecting and re-connecting screens can corrupt the wallpaper settings database, or the bug where picking a still desktop means that wallpapers set via the API are also stuck in still mode. I could go on…
tl;dr – Apple policy may now say they won’t hold up your urgent bugfix, but that doesn’t stop them holding it ‘in review’ for an unusually long time so that it is never actually released…
I have had plenty of ‘robust discussions’ with App Review. Sometimes they come round to my way of thinking – I have had several appeals approved. Sometimes Apple just isn’t budging. Until this occasion though they have always been polite and engaged in good faith. I have never felt that a reviewer was punishing me out of spite. This time, I feel like I really got a ‘Bad Apple’ at Apple.
This particular Apple Review nightmare kicked off when a reviewer decided that my bugfix release:
Enabled auto-launch without the user’s permission
Had an app preview video which breaks the rules
Convincing them that they were wrong about #1 was easy. I just had to show the screenshot where my app asks the user if they want to enable the recommended settings and explicitly lists ‘auto-launch’ as one that will be enabled.
Number 2 was harder. Here is the video causing the problem:
For context, this video has been in place for about 18 months, and has (successfully) gone through about 30 reviews so far. You can see it now in the app store listing.
Multi Monitor Wallpaper is an app that sets the wallpaper across multiple monitors. It really needs a way in the app preview to show the multiple monitors in action. So – it ‘zooms out’ allowing you to see the full effect.
This, my reviewer insists breaches the (unwritten) rule
Your app preview includes content that does not sufficiently reflect the app in use. Specifically, your preview:
– Includes device images and/or device frames.
I understand where the frames thing comes from. Apple don’t want a video of people using their Mac in the coffee shop with the app running. They want to see the app itself.
In my case though – the monitors (and frames) _are_ the app. I think that makes this a reasonable and honest app preview. The reviewers when I first submitted the preview 18 months ago obviously agree, and none of the 30ish reviews since then have had a problem with it.
Nonetheless, my reviewer wasn’t budging. They said:
We advise appeal this review by sending a request to the App Review Board. As you may be aware, the App Review Board was created for developers to appeal an app review they have concerns with. Once the App Review Board has completed their evaluation, they will contact you directly.
Recently, Apple published new guidelines which promised developers that
Bug Fix Submissions: For apps that are already on the App Store, bug fixes will no longer be delayed over guideline violations except for those related to legal issues.
https://developer.apple.com/news/?id=xqk627qu
I really like the new policy. It seems reasonable. This certainly was a bug fix submission. It fixes a crashing bug when users click on one of my image search providers (Unsplash)
I asked:
I did see your message suggesting that I should appeal to the app review board. I’m will do that today.
In the meantime, there is a significant bug which this version fixes (there is an immediate crash if you click to browse Unsplash). As per your press release, I understand that ‘bug fixes will no longer be delayed over guideline violations except for those related to legal issues.’, so would appreciate it if you could publish this update as soon as possible.
And, I submitted my appeal, and copied it into the resolution centre to keep my reviewer up to date.
Hello Rob,
At this time, you will need to follow the pending guidance from the App Review Board.
I explained that I wasn’t aware of any pending guidance and asked again
…
Bug Fix Submissions: For apps that are already on the App Store, bug fixes will no longer be delayed over guideline violations except for those related to legal issues.[…]
this is a bug fix submission. I haven’t changed the AppPreview video. I would like to take advantage of this process. I will address this issue in my next submission if my appeal is not supported by the Appeal Board
still ‘computer says no’
Hello Rob,
Thank you for your response.
To clarify, the App Review Board will be in contact with you, as you currently have a pending appeal.
Best regards,
I tried again
I’m happy for the review board to be in contact with me. As you say – I have a pending appeal (at your explicit suggestion)
Apple have communicated publicly (via press release and direct email) that ‘bug fixes will no longer be delayed over guideline violations except for those related to legal issues.’
If this is indeed a guideline violation, it certainly doesn’t relate to legal issues.
I’m asking you to honour that explicit public commitment.
that got me close to what I needed
Thank you for providing this information.
If this is a bug fix submission, you may elect to have it approved at this time.
If you would like to take advantage of this opportunity, please respond in Resolution Center to confirm that you can address these issues in your next submission. Additionally, please let us know if you have any questions about how to resolve these issues. If you believe this decision was made incorrectly, you may appeal your app rejection. You may also provide feedback on our review guidelines.
well – I must admit I thought the reviewer was just throwing up an extra step here to be annoying, but I confirmed. Shortly later, I got the promising response
Thank you for providing this information.
We will continue the review, and we will notify you if there are any further issues.
Now. We need a little diversion. How long does a review take? I have put quite a few updates on Multi Monitor Wallpaper.
This is how long the recent reviews took from the point where they moved to the ‘In Review’ status.
9-Sept, 5 mins
8 Sept, 16 mins
25 July, 20mins
23 July, 20 mins
21 July, 24 mins
16 July, 7 hrs
24 Jun, 1hr 40mins
11 Jun, 6hrs
Mostly about 20 mins. Sometimes 6 or 7 hours.
How long do you think it takes for a very simple bugfix with no changes to the overall app – where Apple is allowing it through because of their commitment ‘not to hold up bugfix releases’ ?
I don’t know the answer to that.
My app changed status to ‘In Review’ on the 11 Sep 2020 at 23:27
It has been over 60 hours so far and I am still waiting.
After 24 hours, I even submitted a request for an expedited review. That was granted – but nothing has happened yet.
Perhaps I have just been unlucky, and the reviewer who seemed to deliberately throw up steps to avoid allowing my bugfix until I asked whether Apple were good to their word; Perhaps that reviewer just had a family emergency and accidentally left my app in the queue.
I think they’re punishing me.
They’re also punishing our shared customers who currently have to use a crashing app.
I’ll keep this post updated.
Update. 68 hours after moving to ‘In Review’, Multi Monitor Wallpaper was finally approved.
Remember that this was the process to ‘not hold up an urgent bugfix release’
Note – quotes of discussions with App Review are fairly heavily edited for brevity, in that they don’t show everything said. Everything quoted is verbatim though.
If any press want full details, I’ll be happy to share the complete conversation.
Like many of my favourite apps – this one springs out of an annoyance that I wanted to fix.
If you have used windows, then you may well have used one of the many right click commands in the finder. Some of these are built in, and some are added by third party apps.
Two that I particularly miss are
‘Make untitled.txt here’
and ‘Open this directory in the terminal’
Mac OS has had the ability to use custom scripts as services – but they’re too far from the right click to be useful (right click, scroll down hover over services, skip right, find the command you need).
Finally – with the advent of Yosemite and finder extensions, Mac OS has an approved way for me to fix this.
Enter the Sandbox…
The app sandbox is designed to make sure that apps you download from the App Store can only interact with a limited selection of files (mostly within your own app sandbox).
The app I wanted to build lets you add, open or update files anywhere in the system.
If you want your app to be in the App Store – then it has to use the sandbox!
There is a (clunky) solution
Right click booster is a developer tool, and I wanted developers to be able to integrate their own scripts.
There is actually a way that Apple lets you do this.
Scripts can be run from the User Script Directory (every app has it’s own user script directory).
This seems like a great solution, but the app isn’t allowed to put scripts in that directory.
In my first submission, the app asks the user to open the directory – thus giving permission to the app to read and write files there. Apple didn’t like that.
In my next submission, I included the scripts in a .dmg file. My app can include the .dmg, open it and let the user drag scripts to the symbolic link to the user scripts file. Apple didn’t like that either.
In my final submission – the app takes you to my website where you can download the default scripts (as a dmg). Open that dmg, and install the scripts yourself.
There were many other issues along the way – but finally, Apple have allowed this solution.
Now you can run scripts with a right click
I use my app all the time!
The ones I use the most are Pod Update, and Update version (this runs ‘avgtool next-version -all’ which bumps the version number for all my targets in an xcode project)
My other favourites are the two I built the app for. ‘Open this directory in the terminal’ and ‘Create untitled.txt’ here.
Of course, other users will have other scripts and other ideas.
If they’re generally applicable, then I’ll add them to the default script list – so please do share them at the forum!
