Adobe (Reddit, 2):

For more than a decade, we’ve brought photographers hundreds of innovative features in Lightroom and Photoshop without changing the price of our photography plans. Today we’re announcing an update to these plans to better reflect the value that the apps deliver. These plan updates come into effect for new subscribers on January 15, 2025, and will become effective for existing members only when your plan next renews.

[…]

Photography Plan (20GB) — The pre-paid annual plan remains unchanged at $119.88/year (equivalent to $9.99/month). Monthly billing remains an option for existing members with an updated price of $14.99/month, with an annual commitment, effective at your next renewal. Existing members who pay monthly can switch to the pre-paid annual plan to maintain the $9.99/month price. We will continue to support this plan for existing customers, however this plan will no longer be available to new customers.

[…]

Lightroom (1TB) — The pre-paid annual plan remains unchanged at $119.88/year (equivalent to $9.99/month). Additionally, this plan is expanding to now include Lightroom Classic. The monthly plan is updating to $11.99/month, with an annual commitment, effective at your next renewal. Existing members who pay monthly can switch to the pre-paid annual plan to maintain the $9.99/month price.

Emphasis added. So there are a few weeks left if you want to sign up for the plan with both Lightroom and Photoshop.

Adobe:

If your Photography plan (20GB) is currently on an annual plan, paid monthly, you can switch your billing to annual plan, prepaid, by visiting your Adobe Account page and following these steps: Select the Manage Plan button, then the Update Subscription button.

That’s the plan I’m on, but there’s no Update Subscription button. I chatted with Adobe’s AI assistant, and then with a person who initially told me that I had to cancel my current plan and that the price would change. After 24 minutes, and re-entering my credit card information even though it was already current, I think they switched me over.

See also: The Lightroom Queen.

Previously:

• Why Is Lightroom Always Generating Thumbnails?
• Does Apple Smell Blood in the Water?
• Lightroom Classic 14
• U.S. Sues Adobe Over Subscriptions
• Adobe at 40
• Adobe Account Expiration

In the state of nature, if someone does you wrong, it’s up to you and your mates to deal with it. This often means violence.

For most of English history there was no police force. Republican Rome had no police. There was law, but it was often privately enforced and often families and friends would take vengeance for wrongs. This led to rather a lot of violence and death, as well as feuds, where violence would continue long beyond the original offense.

Private justice; private vengeance thus comes with huge downsides, so in many societies we give up our right to use violence to right wrongs. We give that right to government in some form, and we reap the benefits of safety and that, in principle, stronger groups can’t bully those who are too weak to obtain their own justice.

The benefits are huge and everyone with sense recognizes that going back to private justice, to saying “they did me or mine wrong, I should beat or kill them” will mean a huge loss of public safety.

But whenever there’s a situation where changing from the status quo entails a huge cost there will be those who say “in that margin, I can benefit. All I have to do is take just a little less than the cost of change.”

How many people does private insurance and denials of care kill? It’s certainly, at least, in the tens of thousands.

What happens is simple enough. Some people, rich and powerful, get the right to harm others for money: the government doesn’t go after them for killing or hurting people. This is true of private equity buying companies, larding them up with debt then running them into bankruptcy so that many of their employees wind up impoverishing and homeless, for example. It was true of bankers causing a financial crisis. It is true of pharma jacking up prices or bosses stealing employees wages and water companies in the UK dumping sewage into the river and giving the money intended to clean sewage to their executives and investors.

None of this is punished by the law, yet people suffer.

But the cost of going back to private justice is HIGH and the transition cost, where the police and courts will charge those who enforce private justice with crimes, while not charging those who kill thousands with crimes, is awful.

So the bet by those who commit what has come to be called “social murder” is that they can get away with it: the cost of private justice is too high.

Still, there’s always the temptation to take a little more, then a little more and then a little more. To think, “well, I’m so rich I can have bodyguards and travel by helicopter and private jet and armored limo. The peons can’t get to me.”

But slowly (then all at once) ordinary people realize it’s not a good deal for them. Americans come to realize that Putin and Xi aren’t their real enemies, because their real enemies are those who are actually going to kill them or make them homeless, and those people are the rich and powerful in their own country.

Elon Musk, right now, is trying to cut Social Security and Medicare. If he succeeds a lot of people will wind up in pain, homeless or dead who wouldn’t have otherwise. He’s a direct threat to many, many people.

Putin isn’t going to make you homeless or kill you or deny you health care.

And when this switch flips, well, perhaps people decide that the high cost of going back to private justice is worth it and that when they gave up their right to private justice, they gave up their power. It was a good deal, as long as they could keep control of government and use government to control the wealthy and powerful, but once government control was lost, well, the power they gave up was used against them.

And this is, maybe, where we are. If more and more executives, CEOs and politicians wind up targets of extra-judicial justice, we’ll know it’s happened.

This isn’t, of course, an endorsement. It’s analysis. It’s in no one’s interest for the situation to become so awful that ending the state monopoly on violent justice makes cold hard rational sense for millions of people.

But that appears to be where we’re heading, if we aren’t there already.

SUBSCRIBE OR DONATE

sunshine-tattoo:

left-reminders:

“Wealth isn’t "stuff”, its the social relationship of command.“

Oh fuck thats an amazing point.

Recently I’ve been thinking about how everything that happens in the terminal is some combination of:

1. Your operating system’s job
2. Your shell’s job
3. Your terminal emulator’s job
4. The job of whatever program you happen to be running (like top or vim or cat)

The first three (your operating system, shell, and terminal emulator) are all kind of known quantities – if you’re using bash in GNOME Terminal on Linux, you can more or less reason about how how all of those things interact, and some of their behaviour is standardized by POSIX.

But the fourth one (“whatever program you happen to be running”) feels like it could do ANYTHING. How are you supposed to know how a program is going to behave?

This post is kind of long so here’s a quick table of contents:

• programs behave surprisingly consistently
• these are meant to be descriptive, not prescriptive
• it’s not always obvious which “rules” are the program’s responsibility to implement
• rule 1: noninteractive programs should quit when you press Ctrl-C
• rule 2: TUIs should quit when you press q
• rule 3: REPLs should quit when you press Ctrl-D on an empty line
• rule 4: don’t use more than 16 colours
• rule 5: vaguely support readline keybindings
• rule 5.1: Ctrl-W should delete the last word
• rule 6: disable colours when writing to a pipe
• rule 7: - means stdin/stdout
• these “rules” take a long time to learn

programs behave surprisingly consistently

As far as I know, there are no real standards for how programs in the terminal should behave – the closest things I know of are:

• POSIX, which mostly dictates how your terminal emulator / OS / shell should work together. I think it does specify a few things about how core utilities like cp should work but AFAIK it doesn’t have anything to say about how for example htop should behave.
• these command line interface guidelines

But even though there are no standards, in my experience programs in the terminal behave in a pretty consistent way. So I wanted to write down a list of “rules” that in my experience programs mostly follow.

these are meant to be descriptive, not prescriptive

My goal here isn’t to convince authors of terminal programs that they should follow any of these rules. There are lots of exceptions to these and often there’s a good reason for those exceptions.

But it’s very useful for me to know what behaviour to expect from a random new terminal program that I’m using. Instead of “uh, programs could do literally anything”, it’s “ok, here are the basic rules I expect, and then I can keep a short mental list of exceptions”.

So I’m just writing down what I’ve observed about how programs behave in my 20 years of using the terminal, why I think they behave that way, and some examples of cases where that rule is “broken”.

it’s not always obvious which “rules” are the program’s responsibility to implement

There are a bunch of common conventions that I think are pretty clearly the program’s responsibility to implement, like:

• config files should go in ~/.BLAHrc or ~/.config/BLAH/FILE or /etc/BLAH/ or something
• --help should print help text
• programs should print “regular” output to stdout and errors to stderr

But in this post I’m going to focus on things that it’s not 100% obvious are the program’s responsibility. For example it feels to me like a “law of nature” that pressing Ctrl-D should quit a REPL, but programs often need to explicitly implement support for it – even though cat doesn’t need to implement Ctrl-D support, ipython does. (more about that in “rule 3” below)

Understanding which things are the program’s responsibility makes it much less surprising when different programs’ implementations are slightly different.

rule 1: noninteractive programs should quit when you press Ctrl-C

The main reason for this rule is that noninteractive programs will quit by default on Ctrl-C if they don’t set up a SIGINT signal handler, so this is kind of a “you should act like the default” rule.

Something that trips a lot of people up is that this doesn’t apply to interactive programs like python3 or bc or less. This is because in an interactive program, Ctrl-C has a different job – if the program is running an operation (like for example a search in less or some Python code in python3), then Ctrl-C will interrupt that operation but not stop the program.

As an example of how this works in an interactive program: here’s the code in prompt-toolkit (the library that iPython uses for handling input) that aborts a search when you press Ctrl-C.

rule 2: TUIs should quit when you press q

TUI programs (like less or htop) will usually quit when you press q.

This rule doesn’t apply to any program where pressing q to quit wouldn’t make sense, like tmux or text editors.

rule 3: REPLs should quit when you press Ctrl-D on an empty line

REPLs (like python3 or ed) will usually quit when you press Ctrl-D on an empty line. This rule is similar to the Ctrl-C rule – the reason for this is that by default if you’re running a program (like cat) in “cooked mode”, then the operating system will return an EOF when you press Ctrl-D on an empty line.

Most of the REPLs I use (sqlite3, python3, fish, bash, etc) don’t actually use cooked mode, but they all implement this keyboard shortcut anyway to mimic the default behaviour.

For example, here’s the code in prompt-toolkit that quits when you press Ctrl-D, and here’s the same code in readline.

I actually thought that this one was a “Law of Terminal Physics” until very recently because I’ve basically never seen it broken, but you can see that it’s just something that each individual input library has to implement in the links above.

Someone pointed out that the Erlang REPL does not quit when you press Ctrl-D, so I guess not every REPL follows this “rule”.

rule 4: don’t use more than 16 colours

Terminal programs rarely use colours other than the base 16 ANSI colours. This is because if you specify colours with a hex code, it’s very likely to clash with some users’ background colour. For example if I print out some text as #EEEEEE, it would be almost invisible on a white background, though it would look fine on a dark background.

But if you stick to the default 16 base colours, you have a much better chance that the user has configured those colours in their terminal emulator so that they work reasonably well with their background color. Another reason to stick to the default base 16 colours is that it makes less assumptions about what colours the terminal emulator supports.

The only programs I usually see breaking this “rule” are text editors, for example Helix by default will use a purple background which is not a default ANSI colour. It seems fine for Helix to break this rule since Helix isn’t a “core” program and I assume any Helix user who doesn’t like that colorscheme will just change the theme.

rule 5: vaguely support readline keybindings

Almost every program I use supports readline keybindings if it would make sense to do so. For example, here are a bunch of different programs and a link to where they define Ctrl-E to go to the end of the line:

• ipython (Ctrl-E defined here)
• atuin (Ctrl-E defined here)
• fzf (Ctrl-E defined here)
• zsh (Ctrl-E defined here)
• fish (Ctrl-E defined here)
• tmux’s command prompt (Ctrl-E defined here)

None of those programs actually uses readline directly, they just sort of mimic emacs/readline keybindings. They don’t always mimic them exactly: for example atuin seems to use Ctrl-A as a prefix, so Ctrl-A doesn’t go to the beginning of the line.

Also all of these programs seem to implement their own internal cut and paste buffers so you can delete a line with Ctrl-U and then paste it with Ctrl-Y.

The exceptions to this are:

• some programs (like git, cat, and nc) don’t have any line editing support at all (except for backspace, Ctrl-W, and Ctrl-U)
• as usual text editors are an exception, every text editor has its own approach to editing text

I wrote more about this “what keybindings does a program support?” question in entering text in the terminal is complicated.

rule 5.1: Ctrl-W should delete the last word

I’ve never seen a program (other than a text editor) where Ctrl-W doesn’t delete the last word. This is similar to the Ctrl-C rule – by default if a program is in “cooked mode”, the OS will delete the last word if you press Ctrl-W, and delete the whole line if you press Ctrl-U. So usually programs will imitate that behaviour.

I can’t think of any exceptions to this other than text editors but if there are I’d love to hear about them!

rule 6: disable colours when writing to a pipe

Most programs will disable colours when writing to a pipe. For example:

• rg blah will highlight all occurrences of blah in the output, but if the output is to a pipe or a file, it’ll turn off the highlighting.
• ls --color=auto will use colour when writing to a terminal, but not when writing to a pipe

Both of those programs will also format their output differently when writing to the terminal: ls will organize files into columns, and ripgrep will group matches with headings.

If you want to force the program to use colour (for example because you want to look at the colour), you can use unbuffer to force the program’s output to be a tty like this:

unbuffer rg blah |  less -R

I’m sure that there are some programs that “break” this rule but I can’t think of any examples right now. Some programs have an --color flag that you can use to force colour to be on, in the example above you could also do rg --color=always | less -R.

rule 7: - means stdin/stdout

Usually if you pass - to a program instead of a filename, it’ll read from stdin or write to stdout (whichever is appropriate). For example, if you want to format the Python code that’s on your clipboard with black and then copy it, you could run:

pbpaste | black - | pbcopy

(pbpaste is a Mac program, you can do something similar on Linux with xclip)

My impression is that most programs implement this if it would make sense and I can’t think of any exceptions right now, but I’m sure there are many exceptions.

these “rules” take a long time to learn

These rules took me a long time for me to learn because I had to:

1. learn that the rule applied anywhere at all ("Ctrl-C will exit programs")
2. notice some exceptions (“okay, Ctrl-C will exit find but not less”)
3. subconsciously figure out what the pattern is ("Ctrl-C will generally quit noninteractive programs, but in interactive programs it might interrupt the current operation instead of quitting the program")
4. eventually maybe formulate it into an explicit rule that I know

A lot of my understanding of the terminal is honestly still in the “subconscious pattern recognition” stage. The only reason I’ve been taking the time to make things explicit at all is because I’ve been trying to explain how it works to others. Hopefully writing down these “rules” explicitly will make learning some of this stuff a little bit faster for others.

I’ve been shipping apps to the App Store for well over fifteen years now, and although there are App Review horror stories aplenty, I’ve always hoped I’d never be in a position to write one myself. Fifteen years isn’t a bad run, at least.

Another post chock-full of technical snippets and stories from the app’s development over the past year is coming very soon, and will be a lot more positive than this one. I’m really proud of what we shipped, and this App Review experience doesn’t change any of that.

Alright, let’s dive in. They say a picture says a thousand words, so how about a picture of some words. Get those scrollin’ thumbs ready!

What you just scrolled past was the history of my (eventually successful) attempt to get the new Mac version of our app — Cascable Studio — approved for the Mac App Store. The entire process took nearly a month, and we had to push an emergency build through in the middle there with some features stripped out to get something approved for launch.

We’re at version 7.0 now, and the iOS version of this app has been on the App Store since 2015. Indeed, most of the app was fine — this ordeal was all about one particular feature.

A feature that’d already been approved and on the App Store since 2019 in a different app of ours.

---

Contents

• The Troublesome Feature
• A Core Part of the Mac Experience Meets the Mac App Store
• Coming Off The Rails
• Failure #1: Escalation Is Difficult and Slow
• Failure #2: App Review Appears To Be Missing Critical Information for Mac Submissions
• Failure #3: Rejection Communication is Often Missing Actionable Information
• Failure #4: There Are Frustratingly Few Technical People in App Review
• One Week Later: My Thoughts
• Silver Linings
• Ramifications for the Future

---

The Troublesome Feature

Our plan was to discontinue an old Mac app of ours called Cascable Transfer and replace it with the Mac version of Cascable Studio. Transfer was a simple but effective app, and Studio supersedes it entirely — it’s far more powerful. Transfer was originally approved for the Mac App Store in 2019.

As part of that work, we brought a Mac-specific feature over to Studio because, frankly, it’s a great feature, and quintessentially Mac: direct integration with other apps. Rather than copy images to a folder with our app then open them in another, why not pass the images directly to other apps?

Here’s how it works with the wonderful Retrobatch batch processing tool:

• Make a workflow in Retrobatch to, for example, make two versions of each image processed — one at 50% scale with a text overlay that goes into a “Previews” folder, and the other is a straight passthrough into an “Originals” folder.

• In Cascable Studio, connect to Retrobatch and point it at the workflow you just made.

At this point, you can now drag images from your camera to Retrobatch in Cascable Studio, and it’ll copy the images from the camera and pass them straight through to that Retrobatch workflow… and presto! You have a big pile of processed images.

However, where this feature gets really magic — and really into what makes the Mac great — is our app’s ability to build a pipeline for automatic transfers. Link your camera to Retrobatch in our app and suddenly every time you take a picture it’ll be transferred over to Retrobatch and processed. Point your Retrobatch workflow at a cloud-synced folder and bam! Shutter to cloud in, what, five seconds?

Cascable in the background is configured to automatically pass images from the EOS R5 storage location (a camera’s SD card) to the Retrobatch workflow in the middle, which scales them, adds a watermark, and saves them to the folder open in the foreground. The processed images land in the folder 3-4 seconds after the camera’s shutter button is pressed.

Forgive the sales pitch, but I love this feature and it’s why I love the Mac. This interoperability is a core part of the Mac experience and has been since at least the 1990s — well before Mac OS X.

This deep love of this sort of thing is why I fought so hard for this feature.

---

A Core Part of the Mac Experience Meets the Mac App Store

Alright, so it’s a great feature. Why was App Review so upset?

Part of why this ordeal was, well, an ordeal is that I was never actually explicitly got a straight answer on that. But we’ll get to that.

For an app to be on the iOS or Mac App Store, it has to be sandboxed. In its default configuration, the sandbox completely isolates an app from the outside world and other parts of the system. If you want to communicate outside the sandbox, you need to declare entitlements, which are specific doors in the sandbox that let you communicate with the outside world in that entitlement’s manner.

As some basic examples:

• To talk to the internet, you need the com.apple.security.network.client entitlement.
• Bluetooth is com.apple.security.device.bluetooth.
• Using the device’s camera needs com.apple.security.device.camera.

…and so on.

Some entitlements are so common (like the internet one) that they never really get questioned. Others, App Review will tend to want an explanation and/or demo of their use. This is all fair enough, I guess.

This whole ordeal was over some less common entitlements:

• To communicate with Retrobatch (and other apps), we use a technology called Apple Events. Apple Events underpin AppleScript as an Apple-provided technology for inter-app communication and scripting — it’s been around almost as long as the Mac has. To use Apple Events from the sandbox, you need to declare the com.apple.security.temporary-exception.apple-events entitlement along with a list of apps you want to communicate with.

• We also have an integration with an app called Capture One, which as a grossly simplified explanation is “like the Photos app, but for professionals”. With our integration, the user can add photos directly to their Capture One library. For various technical reasons, when attempting to export images to Capture One, the user would see a rather scary dialog about Capture One “accessing data of other applications”. To work around that, we used the com.apple.security.temporary-exception.files.home-relative-path.read-write entitlement to temporarily place exported images outside of our sandbox during the export so the user wouldn’t see that scary dialog.

This is a screenshot of what the relevant entitlements look like in Xcode:

---

Coming Off The Rails

Now I’m out the other side, I think what happened here were a combination of procedural failures — combined with some unfortunate timing — that coalesced into a nearly month-long review process. Rather than take you through the slog that I did, I’ll instead split out my experience into the explicit ways I think App Review failed here, and ways they should do better in the future.

We usually submit major updates well in advance of the planned launch date, because there’s always stuff to work through with App Review. This time, we submitted a little under three weeks before our target date of December 5th. As a quick timeline, a lot of which isn’t shown in that screenshot above:

November 16th	Initial submission.
November 17th	Initial rejection, flatly denying the use of all of the "less common" entitlements described above. I ask for a call from App Review.
November 25th	I received the call, and was advised to explain the entitlements to App Review but "not to expect any movement for a week due to Thanksgiving". I inferred that the Apple Events entitlements "should be" OK, but it'd need to be escalated.
November 29th	Got nervous about the lack of any movement, and pulled the build to resubmit with the feature stripped out.
November 30th	Rejected pending information for why we use the Bluetooth, Camera, and Location entitlements.
December 1st	Resubmitted.
December 1st	Rejected pending information for why we use the Network Server entitlement.
December 1st	The build with the feature stripped out was approved.
December 2nd	Re-submitted with the feature reinstated.
December 3rd	[Luck +10] I attended an App Review lab, and connected with a very nice App Review staff member that was able to look into what was going on for me. Said that it was being looked at in more detail.
December 4th	Rejected with an identical rejection to the one on November 17th and a weird additional rejection about our paywall. That same paywall was approved three days prior on both Mac and iOS.
December 4th	[Luck +10] Ripcord pulled: I managed to find a relevant person with decent seniority in the right department. I emailed that person and got a "We'll look into it" reply fairly quickly.
December 4th	I receive a notice that this is now being looked at by the appeals board.
December 4th	I receive a message from the appeals board asking for information on why we're using the less common entitlements identified above.
December 5th	Launch day! I launch with this feature missing from the Mac app.
December 9th	I receive a follow-up call from the staff member I met in the lab. We scheduled another call for a few days' time to see how the progress was going with the new submission.
December 10th	I receive an almost identical rejection to the ones on November 17th and December 4th, the message for which contradicts itself.
December 10th	I reply to the rejection pleading for a straight answer. I get told "We advise submitting a revised binary with your suggested changes for review."
December 10th	I resubmit without the com.apple.security.temporary-exception.files.home-relative-path.read-write entitlement.
December 11th	Rejected pending information for why we use the Bluetooth entitlement. My reply is… snippy.
December 11th	Approved!
December 13th	I receive a follow-up call from the staff member I met in the lab. We chatted about the past few weeks and I gave some feedback to hopefully pass along. There's still one outstanding question on whether App Review can see some details in the submission form.
December 16th	I receive a follow-up call from the staff member I met in the lab. We chat a bit more about that outstanding question and conclude the "incident ticket", as it were.

Yikes.

---

Failure #1: Escalation Is Difficult and Slow

When you get rejected by App Review, you’ll get a message about why and the ability to reply in text form. Sometimes, rejections are simply requests for information, but there’s always the ability to reply — even if the rejection wasn’t asking for information, a review can sometimes be turned around without re-submitting if you “Um, actually…” them if they got something wrong.

I have no insider information about how the review process works, just fifteen years of outside observation. From my observations, the reject-reply-action turnaround can be fast if the person reviewing the app has the power to continue the review with everything they then have (although it can still be a dice roll — “Will this be actioned in ten minutes or two days?” is still a thing). In my experience this doesn’t include anything regarding policy - i.e., if someone needs to take context into account to make a decision, you’re out of the “fast” queue.

My experience also supports the fast queue being somewhat international and running 24/7, but once you’re out of that you’re limited to progress being made in California business hours — and timescales start being measured in days and weeks.

In my instance here, I got rejected on November 17th, and I asked for an escalation and a follow-up call the next day. I got a reply a little over a day later confirming that the call would come in “3-5 business days”, and the call arrived on November 25th. The person on that call was basically collecting more information from me so the issue could then be escalated.

Unfortunately, this was Monday on the week of Thanksgiving, and I was told that realistically I wouldn’t be seeing any movement until the following week due to that.

Even ignoring the bad timing of Thanksgiving (and the fact that it seems the entire department shuts down for a whole week?), that’s a week between asking for an escalation and getting it. That’s a long time of nothing.

---

Failure #2: App Review Appears To Be Missing Critical Information for Mac Submissions

When you submit a Mac app, you get an extra section in the submission form entitled “App Sandbox Information”. In that section, you add all of the entitlements you’re using from a drop-down menu and explain exactly what you’re using each entitlement for. I made sure to fill out that section diligently, and here’s what ours looks like for Cascable Studio:

We got rejected or asked for missing entitlement information multiple times during this process — on November 30th (Bluetooth, Camera, and Location), December 1st (Network Server), December 4th (Apple Events and file access from the appeals board), and December 11th (Bluetooth, again). It wasn’t stated explicitly, but I was told that missing entitlement information was a factor in the initial rejection on November 17th, too.

In all of these cases, we had provided detailed information about why we’re using the entitlements in the mentioned section of the form. In all of these cases (bar one where the entitlement was included in error, and a more detailed explanation for the appeals board), I copy and pasted the information I’d already written from the form we submitted to App Review into the reply to App Review. The reviews then continued.

I must admit, I was particularly snippy about the second Bluetooth one:

We have already explained, in exquisite detail including with a demo video, why we use Bluetooth in this app earlier in this very same submission process. Please review the earlier correspondence for those details. If you are unable to scroll up far enough, I’ll repeat that information here:

You can also see that video here: https://www.youtube.com/watch?v=UVxAIF2eGUs

(Text explanation of what’s happening in the video)

In all of the “live” conversations I’ve had with actual Apple employees (three separate conversations with two separate people), they were not able to see this additional entitlement information. I was told that they don’t necessarily have the same tools the actual reviewers do, so what they see might not match.

This happened often enough that it goes beyond a simple oversight by an individual reviewer. Either they can’t see the provided information, or they’re not aware that it’s there.

Update after I wrote this but before I published it: I received a final follow-up call and I was told that for now, the advice is to duplicate entitlement information into the “Review Notes” field. There seem to be no straight answers to be found anywhere about whether App Review can see these additional fields, even internally.

Entitlement information is critical information to perform a review of an app. If App Review can’t actually see this information in Mac submissions, this is a serious failure of the tooling for this process. If the reviewers can’t see the information, how can they possibly review the app properly?

---

Failure #3: Rejection Communication is Often Missing Actionable Information

After weeks of back-and-forth and waiting, the final conclusion is that the problem was with the com.apple.security.temporary-exception.files.home-relative-path.read-write entitlement — the Apple Event ones all got approved once that was taken away.

However, that was never explicitly stated in my rejections. Even after going through the appeals board, I got this rejection:

Thank you for your patience.

Regarding 2.4.5, we found that the app may not use the following entitlements:

com.apple.security.temporary-exception.apple-events
(A list of all the Apple Events entitlements)

com.apple.security.temporary-exception.files.home-relative-path.read-write
/Library/Caches/Cascable Capture One Exports/

To resolve this issue, it would be appropriate to adhere to the following provided guidance:

When sending an AppleEvent with the proper types (e.g. typeFileURL), then the receiving application will be granted access to the specified data without having to move/copy the file to a shared location such as the cache.

If you continue to have issues with that mechanism, please submit a Radar against it.

If we boil this down, this message says:

You cannot use Apple Events. You cannot use the shared cache location. When sending an Apple Event with the proper types, you don’t need to use the shared cache location.

…which is a very contradictory trio of sentences. I asked for clarification:

…can you please make a clear judgement regarding Apple Events? Your message contradicts itself.

You wrote:

“We found that the app may not use the following entitlements: (list of Apple Events entitlements)”

Then you wrote:

“When sending an AppleEvent with the proper types…”

So, which is it? Are we not allowed to use the Apple Events entitlements, or is it just the cache directory usage that’s the problem?

I got the reply:

We advise submitting a revised binary with your suggested changes for review.

Would it kill them to give a straight answer? I get that they don’t want to put anything in writing because people like me publish blog posts like this one putting their words out for the entire world to see, but I really can’t possibly see how “If you take away this entitlement, these other ones are OK in your particular use case” is a damaging statement to make.

That information — that the Apple Events entitlement should be OK without the other one — did appear to be present internally almost from the beginning. It was implied on the call I received on November 25th, and if you read between the lines in that rejection above on December 10th it’s kinda-sorta there too.

However, I can’t run a business on inferring from indirect statements and reading between the lines. This process sits between my business and its revenue, and I need to be sure where we stand. I appreciate that they can’t pre-approve an app idea, but when we’re three weeks into a back-and-forth and we’re talking about a very specific feature in a very specific app submission, “we advise submitting a revised binary with your suggested changes for review” is kinda horseshit. So I get to spend engineering hours implementing something to find out if I’m reading between the lines correctly? Yuck.

---

Failure #4: There Are Frustratingly Few Technical People in App Review

Now. I will grant that Apple Events are a fairly low-level technology. It’s also a very old one — when looking up documentation for Apple Events to give to App Review to show it’s a public Apple technology, I found a document with this diagram in it:

It’s aged delightfully, but I figured showing App Review a diagram from the ’90s was unlikely to help the case that it belongs in the modern App Store.

Anyway, I must’ve explained what Apple Events are to three separate people throughout this process. This did eventually get to someone technical up at the appeals board, but nobody having any idea what an “Apple Event” is really cannot have helped.

It wouldn’t be a blog post without at least one meme.

I do understand that they don’t need to hire programmers to reject apps for bad screenshots or whatever, but if App Review can’t understand the technologies at play when they’re reviewing apps, how can they possibly review the app properly?

---

One Week Later: My Thoughts

This is now a story I’m writing a blog post about and not one I’m living. It was very stressful to live through — I’m sure I’ve lost some years from my life over all this, and Apple’s larger policy of “no communication until we feel like it” is extremely not helpful. Squeezing in a build with the feature stripped out so we could launch when planned did lessen the load a bit, but it meant that one of the release’s best features was completely absent from the launch’s press material — a huge blow to marketing visibility.

It’s a shame, too — this release was the result of more than a year of work and was the most ambitious launch in the history of the app. It should’ve been a momentous and happy day, but there was a huge cloud put over it because of all this. Alas, three weeks’ lead time on our App Store submission wasn’t enough. I hate to think how long it would’ve been (or if we’d have got an approval at all) if App Review didn’t happen to be hosting labs, and if I didn’t manage to find the contact details of someone to escalate to.

Now, I’m not one of those people that’s morally opposed to app review as a concept (as long as there are alternative distribution options, which is the case on the Mac, at least), but it has to function correctly.

I’m not even that upset about some of the rejections I got during this process. When App Review works well, the back-and-forth is fine. If we ignore the larger chaos here and look just at the rejection on December 11th:

9:23 am	Rejected needing information on why we use Bluetooth.
9:56 am	We reply with the requested information.
10:05 am	In review.
10:08 am	Approved.

That sort of back-and-forth with that sort of turnaround time is fine. They’ll sometimes genuinely need information, and taking that and immediately acting upon is a perfectly reasonable process - which also mitigates situations where they’re asking for information they already have.

What isn’t OK is:

• App Review not being able to see — or not being trained to look for — critical information for the review process.
• Turnaround times measured in weeks.
• The entire process shutting down for a whole week due to Thanksgiving.
• Never being able to get a straight answer, receiving conflicting information in a single message, and having to infer and read between the lines.
• Me having to schedule my big submissions around times when App Review happens to be hosting labs so I can actually get a human to speak to.
• Me having to desperately try to find contact details for someone I can escalate things through on any sort of reasonable timescale.

This has to be better. A lot of it points to a department that has to deal with millions of app developers and submissions without the resources to do so well when things fall out of the “optimised path” like this did. Of course, that defence immediately falls apart when you notice that Apple is one of the richest companies on the planet (not that you can throw buckets of money at every problem to make it disappear, but still).

---

Silver Linings

I do try to make an effort not to complain all the time, so let’s find some positives:

#1: The amount of support I got from the community really helped. Being an indie developer is a uniquely… er, unique? experience — especially on platforms with a monolithic gatekeeper like the App Store — and when things like this happen there’s a little pit of existential dread that forms while you feel like your business hangs on the whims of some people in a meeting room somewhere*. There’s only so much empathy most of my “IRL” friends and family can have for that, and having a big pile of peers cheering me on and otherwise sharing in my experience made things a lot easier to bear.

* Obviously this isn’t a rational reaction to what was happening here — the loss of that feature wouldn’t actually be a death knell for my business. Still, when you build a feature you’re excited about because it’s a great fit for the platform you’ve been using for 30 years, only get a flat Nope. from the gatekeeper without additional context, there’s suddenly a disconnect between what you thought the platform was about and what the gatekeeper thinks the platform is about. That’s not a nice feeling.

This particular little snippet from a community I’m in made me laugh a lot, so I thought I’d include it here (with permission):

#2: Connecting with an App Review staff member in the App Review labs was a godsend. They didn’t work directly on reviewing apps so it’s not like they could just go in and approve the app, but they were able to see things I couldn’t and ask questions internally that I couldn’t. Getting this additional context — and someone on the inside able to shout for me — at least kept hope alive when my “official” communication from App Review was so devoid of… well, anything. When they didn’t know an answer to a question they promised to find out and follow up with me, and they did so every time. They did an excellent job given the restrictions they had (i.e., not having a giant “Approve” lever they could pull).

Hopefully these App Review labs (which are listed here on the Apple developer site - search for “App Review”) are a continuing and consistent thing, because they offer a much-needed lifeline.

---

Ramifications for the Future

So, what now? While we do have the feature approved and in the App Store now, this ordeal has affected my outlook for the future quite significantly:

Cascable Studio

It’s likely that, even though the app is approved now, I’ll pull the Apple Event stuff out and into a separate downloadable component that’s outside of App Review’s purview. I’d like to integrate Cascable Studio with more and more apps in the future, and I very much don’t want to go through this argument again any time soon.

This solution is perfectly achievable with sandboxing intact and without any funny business that’d affect App Review, but it is a worse experience for the user and a lot more effort on our part. It sucks for everyone, but it’s better than doing this every time — or even having the shadow of this maybe happening again on every submission.

Our Other Apps

We have another Mac app — Cascable Pro Webcam — that’s currently being sold outside of the App Store. When I first made the app, virtual webcams were flat-out not allowed on the App Store, which to be honest was fair enough — the architecture for virtual webcams at the time was extremely not secure.

However, since then Apple has shipped a new architecture for virtual webcams that Pro Webcam implemented immediately. Now it’s allowed, I was planning on moving Pro Webcam to the App Store with its next major update in the new year — we’re currently using Paddle, and I’m not very happy with them. However, it also uses a “non-standard” entitlement (com.apple.developer.system-extension.install), and after my experience here I’m seriously reconsidering that plan.

Further Into The Future

This ordeal has rekindled my uneasiness of being reliant on a single gatekeeper for my company’s survival. Yes, we can ship on the Mac outside the App Store, but still.

Being multi-platform has been at the back of my mind for a long time, and at the beginning of the year I did a decently-involved investigation into using Swift on Windows. I find my desire to return to that suddenly getting stronger, for some reason.

---

A huge congratulations to Manja Ristić, who appears on this chart three times, twice with collaborators and once solo.  We believe that this is the first time such an event has taken place; and these were not the artist’s only albums in 2024!  A pair of labels are represented twice, one artist finds her dream come true and the scene receives a definitive creature compilation.

This has been a banner year for field recording and soundscape work, which is all the more relevant as habitats are threatened and/or destroyed in the name of progress.  The work of these sound artists not only celebrates the sounds of the natural (and unnatural) world, but the importance of preservation.  We are indebted to them for their dedication to opening our eyes as well as our ears.

Alëna Korolëva ~ premonitions (forms of minutiae)
“Whenever I go, I can’t help but notice signs of a looming change,” writes Alëna Korolëva; “dark clouds gather, winds are shifting course.”  These premonitions were transferred to this long-form piece, which addresses the extinctions not only of species, but of societies.  The piece shifts subtly from beauty to foreboding and back again, the human element more threatening than the actual storm.  Through it all, the artist injects a hint of humor, an essential element that keeps the brain from paralysis.  Since March, when this album was released, the clouds continued to darken, but every effort of conservation provided a glimmer of light.  (Richard Allen)

Original Review

Bohdan Stupak ~ air raid siren is over
Much has been made of the use of air raid sirens in music. In the immediate aftermath of the Russian full-scale invasion, this sound became ubiquitous. As raw field recordings, they gave an insight into the changed sonic landscape of everyday life in the country to an international audience. Electronic music artists used them to galvanise the audience. Air raid sirens started appearing in jazz live sets and contemporary-classical musical alike. Composers used them to solicit pathos or appropriated them in such a way as to diffuse their threatening impact by turning them into plaintive drones. As sirens became so embedded into the fabric of daily life, they became something one had to come to terms with in ways that minimise their impact.

Producers like Lugovskiy released “Sirens of Kyiv” in two different versions, downtempo and unadorned, inviting the listeners to give their own interpretations and with the disclaimer, “I recorded the sirens in Kyiv last night and made it less depressing. You could download the original record and give it your vision.” In October 2022, Natalia Tsupryk created the track “Kyiv” from sounds she recorded in the capital of Ukraine on 24 August, Ukraine’s Independence Day. As she put it, “It is a dark and droney track that, with some elements of the cello and Moog Mother-32, reflects the uneasy mood of the city and the whole country during the past seven months.” Gradually, the use of air-raid sirens in music of any genre has become triggering to the point that even historical compositions like Varese’s Ionisation (1929-1931) are now approached with caution.

Bohdan Stupak steps into the fray with “air raid siren is over”, a track containing multiple field recordings such as the composer and his colleagues ignoring occasional air raid alerts or the composer speculating with his son that air raids and explosions are over. While the sound of the siren is still recognisable it is treated with detachment even when it forms an intrusive background noise to everyday activity. Conversations might be fractured and interrupted, but the disruptive power of sirens is neutralised by the casual acceptance they induce in people for whom they have become a daily occurrence. Speech is deconstructed, treated as timbre and reconfigured only to regain its intelligibility towards the end.

The key to this piece is that the sound of air raid sirens is never normalised. The profound alterations to the acoustic ecology of Ukraine with the devastating introduction of the belliphonic is highlighted in the way it impacts the rhythm of life and reverberates through the psyche. Air raid sirens inhabit both the public and private space erasing any notion of the personal. While the enforced cohabitation is not treated as invalidating, Stupak makes the point that to understand war is to understand that any conflict is about the people involved, not just about some numbers or news headlines. (Gianmarco Del Re)

Ukrainian Field Notes XXXVII

David Vélez ~ Comfort Food (Flaming Pines)
The charmingly cute drawings of Comfort Foods’ cover art belie the seriousness with which field recordist David Vélez approaches his sonic research into listening to edible plants. Given the range of moods suggested by the facial expressions of these cartoon veggies, one might not be surprised to find the concept treated with humor. Somewhere between the conceptual seriousness of Matthew Herbert’s One Pig and playful absurdity of Matmos’ Ultimate Care II,  Velez’s sonic diary of cultivating, nurturing, and being nourished by his plants remains a compelling listen even if one doesn’t pursue the record’s more philosophical considerations that ground the project. But if you are interested in ecological horticulture, coevolutive practices, and the aesthetic and moral philosophy of interspecies coexistence, then you will surely find these comforting soundscapes even more wholesome. (Joseph Sannicandro)

Original Review

Izabela Dłużyk ~ The Amazon – Where the Moon Wept (LOM)
The backstory to this album is just as compelling as the album itself. After recording the soundscape of primeval forests in her native Poland in Soundscapes of Summer (2016) and Soundscapes of Spring (2017) Izabela Dłużyk was able to achieve her life’s ambition and dream of traveling to the Amazon, thanks in no small part to a fundraiser from the Slovak label LOM.

Coming several years after the release of her previous album, The Amazon – Where the Moon Wept was worth the wait. Izabela Dłużyk gives us a full immersive experience of the Peruvian rainforest in a thoughtfully edited and expansive collection of tracks. Her ability to thumbnail sounds ensures the listener is able to make the most of what could otherwise be an overwhelming aural journey. She goes for awareness rather than simple exposure. There are sound marks for different bird songs, as well as different times of the day and weather conditions in the belief that to listen to a sound is to listen to the entire body of the sound world in micro-detail. And yet, The Amazon – Where the Moon Wept never feels didactic. The emphasis is always on the lush sonic environment, devoid of any tangible human practice. (Gianmarco Del Re)

Original Review

Kate Carr ~ Midsummer, London (Persistence of Sound)
Full disclaimer, as friends and neighbours, Kate and I used to go on weekly walks in our neighbourhood, a habit we first got into during the pandemic. Both dedicated walkers (or flaneurs to use a more literary term), we used to discuss our respective projects on our morning urban explorations. Kate used to be on the lookout for garbage she picked up for her musical duo Rubbish Music and took occasional photos she would then sometimes use as album covers for Atmospheric Densities, her podcast on Resonance Extra. This goes to show how her surroundings inform her practice.

Midsummer, London is the perfect example of how Carr repurposes the familiar to create alternative narratives. The journey begins on the 35 bus to Clapham Junction, a bus ride I have taken many times before, but deprived of its functionality, it becomes a new sensorial experience that never translates into “audio guide speak”. Midsummer, London is not designed to illustrate sonically a specific itinerary with its meandering quality, and yet it still gives clear aural markers, enough to make one retain their bearings. This is locational listening punctuated by snippets of dialogue, barking dogs, birdsong, and public announcements but what should be mundane sounds, and all too annoying at that, like roadworks or bins being emptied, become at times disembodied ghostly presences delicately balanced on slowly flowing drones. One feels the movable geography and the passage of time while remaining in a haze of sonic stimuli that never feels overwhelming as one would expect in a city of 9 million people. Each sound is given its own weight and dignity even when captured fleetingly. The one constant presence is that of water, which sometimes remains “off screen”, so to speak, but is always there in the background. Listening to Midsummer London transported me back to what I called home, for 30 years, giving me at the same time a fresh listening experience and making me rediscover a sonic landscape I grew accustomed to. (Gianmarco Del Re)

Original Review

Manja Ristić ~ Ma (LINE)
Serbian artist Manja Ristić appears on this chart three times, but could have easily appeared more, as other albums also received votes.  The rare artist whose prolific output remains of high quality, Ristić also has much to teach.  Ma is perhaps the most restrained of all her recordings, urging the listener to lean in to appreciate the inner workings of quiet sounds and the soft hum of the nearly forgotten.  While the line stretches from anthills to outer space, the most appealing sound, due to its personal nature, is “Dad’s boiler,” a reminder that there’s no place like home.  (Richard Allen)

Original Review

Manja Ristić & murmer ~ The Scaffold (Unfathomless)
A pandemic file exchange started this collaborative effort at just the right time, a welcome respite from the distractions of crumbling societies and ineffective governments.  The singing scaffold of Estonia is the most distinct sound and the Gregorian chants of Dubrovnik the most metaphorical, offering peace in the midst of chaos, a modicum of hope among the bustle of tourism, a hint of the divine embedded in the secular.  The entire project is an expression of friendship across borders, two artists finding common ground through sound.  (Richard Allen)

Original Review

Manja Ristić and Tomáš Šenkyřík ~ Vstal (Skupina)
Vstal is a dialogue between two field recordists and their home soundscapes, between life on the aquatic shores of the Adriatic and the old growth forests of Czechia. Manja Ristić’s hydrophone recordings and domestic mundanity as counterpoint to Tomáš Šenkyřík’s trees overlaid with extraterrestrial communications. Even without the occasional vocals, violin improvisation and vintage synthesizer, Vstal’s soundscapes are deeply musical. As field recordists and listeners alike know, listening is itself a compositional practice. As with so many of the most moving field recordings, Vstal captures something profound about the relationship between humans and our environments, and the interconnectedness of the physical and spiritual. (Joseph Sannicandro)

Original Review

Masayuki Imanishi ~ Asphalt/Concrete (Unfathomless)
In one of my favourite poems, “Memories of Earth”, Edwin Morgan imagines futuristic observers shrinking to enter a stone, as “the landscape / explodes upwards” to meet them. We get a similar astonishment from Masayuki Imanishi’s asphalt and concrete. These soundscapes enlarge forgettable background noise into monolithic structures of detailed sound. The two tracks are immersive and otherworldly, locating distinct sonic realities hidden in the everyday world of Osaka. (Samuel Rogers)

Original Review

V/A ~ harkening critters (forms of minutiae)
Our label of the year only released four records this year, but this sprawling compilation alone may well have earned that title. In just a few short years, forms of minutiae have established themselves as one of the premier publishing platforms for sonic ecologies, field recordings, and electroacoustic music, and harkening critters is the kind of project that defines the genre. Curated by Pablo Diserens, the label’s second non-profit collection of field recordings and soundscape compositions presents the remarkable diversity of animal signals. These “critters” come from all over the globe, with recordings spanning various approaches, species, continents, ecologies, seasons, and times of day. The 4-hour, 33 track triple album comes with ample documentation in the form of a 76-page booklet of photographs and descriptions. Decidedly lowercase, harkening critters is slow paced yet rich with sonic events and near silence. Despite being drawn from natural sounds, the inherent (often noisy) musicality of the world may be disorienting, with contrapuntal rhythms and rich acoustic environments often times more interesting than anything an expensive modular synthesizer can generate. To harken is to have regard for, to listen to and hear. Rather than hail or interpellate (let alone interpolate), the titular critters take center stage, situated within their particular ecological (and acoustical) environments. (Joseph Sannicandro)

Original Review