Edovia (Mastodon):
We were encouraged to find that approximately 80% of respondents expressed a positive inclination towards adopting Screens 5 as the default [vnc: URL] handler. However, we also acknowledge and respect the opinions of the remaining 20% who expressed a preference for maintaining the existing setup.
[…]
Although APIs exist for setting default handlers at runtime, Apple has opted not to extend access to these APIs for sandboxed applications, a stipulation essential for approval on the Mac App Store.
[…]
So the solution we came up with is an app, called Default Handler. Given that this app operates outside the constraints of sandboxing, it can freely utilize the APIs mentioned earlier.
The URL handler settings are less potentially dangerous than other things that Apple has allowed in sandboxed apps and sometimes gated with TCC or an entitlement. So I don’t see why they aren’t allowed in the Mac App Store. Any API can be abused, and App Review should be able to do something if an app ends up misbehaving.
Another option would have been to provide an Internet Config–style system settings pane. It would be more reasonable to block this functionality from apps if there were a way for the user to set it on their own. This would also be useful in its own right, as users could see the settings and adjust them as needed all in one place.
Instead, Apple just blocked the API, so the user needs to download an app that’s totally unsandboxed. Edovia is a reputable developer, so I don’t have any qualms about Default Handler in particular, but the big picture of Apple’s decisions here makes little sense.
Previously:
Mac Mac App Mac App Store macOS 10.14 Mojave macOS 14 Sonoma Sandboxing Screens URL
Scam apps top the search results, but at least Apple is protecting us from links to Spotify’s Web site (MacRumors):
Spotify says Apple is stonewalling updates issued in compliance with that very ruling. In an email to the European Commission obtained by The Verge, Spotify writes that Apple has “neither acknowledged nor responded to Spotify’s submission” to bring subscription pricing information into the app, preventing it from updating the app at all for its users, even to put out fixes for bugs or add other features.
[…]
The company writes that this is “yet another example of how Apple if unchecked, will seek to circumvent and/or not comply with the Commission’s decision.” It also urges the European Commission to contact Apple and requires that it approve Spotify’s changes. “Given Apple’s track record, Spotify is concerned that Apple’s delay is intentional and is aimed at delaying or avoiding compliance altogether,” the email reads.
Maybe the 10-days-and-counting review time is just a coincidence, but, as Phil Schiller might say, Apple has a history of holding apps it doesn’t like in review purgatory. Maybe the European Commissions should ask for written assurance that it’s acting in good faith.
Previously:
Update (2024-03-17): Kyle Howells:
Apple’s App Review behaving just as designed I see…. allowing it avoid complying with court orders and laws it doesn’t like.
Update (2024-03-29): Gergely Orosz:
22 days later, Apple still not approving the Spotify update that adds pricing details.
Update (2024-04-26): Juli Clover:
Spotify has not been able to get Apple to approve an EU app update that added information on subscription pricing and links to the Spotify website, and it turns out that’s because Spotify has not agreed to the terms of Apple’s Music Streaming Services Entitlement.
[…]
Apple requires developers who use the entitlement to pay a 27 percent fee (reduced for subscriptions older than one year and for small businesses) on all website purchases referred by Apple. So if Spotify puts a link in its app and a user clicks it and subscribes, Spotify would owe Apple a 27 percent commission (three percent less than the App Store purchase fee).
Spotify does not currently pay Apple any money, and it does not want to.
I think Spotify was a bit deceptive in not telling us this when it complained about Apple’s stonewalling. On the other hand, Apple was also playing some sort of game by neither approving nor rejecting the app. I can’t imagine that the EU is OK with Apple’s ridiculous terms for using the entitlement.
Steve Troughton-Smith:
Apple got fined $2B for its illegal pre-DMA conduct on this issue, and still thinks it can withhold 'following the law’ until you sign up for an entitlement, a 27% Apple tax, and give Apple audit rights to your company. Which is all completely illegal under the DMA.
Antitrust App Review App Store European Union iOS iOS 17 iOS App Spotify
Even_Fan9110:
I got C$ 150k drained from my all my accounts right in front of my eyes after I put my seed phrase into this fake app from the apple Apple Store. I can’t believe apple lets apps like this on their App Store. Beware people don’t download this.
habeanf (via Maximiliano Firtman):
Earlier today I decided to switch my Android for an iPhone. After moving all my apps I decided to make the jump and move my bitcoin from the android wallet. I searched for ‘bitcoin wallet’ on the Apple App Store, installed the first app I saw (as far as I could tell, looks legit), transferred bitcoin, and it immediately got sent off. Turns out this app was previously reported at least 12 days ago as a scam but its still up there, #1 search result.
I get that I’ve failed to vet the app but honestly, how does a scam app become the #1 organic search result (not promoted) in the app store, topping binance, blockchain.com, and coinbase?
Previously:
App Store App Store Scams Bitcoin and Cryptocurrency iOS iOS 17 iOS App Search
Wade Tregaskis:
Apple’s new linker appears to be much more pedantic than the old one – it warns about a lot of things that the old one didn’t care about. One of these is missing platform load commands:
/Users/SadPanda/Documents/vmaf/libvmaf/ld:1:1: no platform load command found in 'src/libvmaf.a[62](cpuid.obj)', assuming: macOS
This doesn’t technically break anything – assuming it guessed the platform correctly, which I suspect it just takes as being the host’s platform – but it’s super annoying because it’s emitted for every afflicted object file the linker sees (that’s individual files, even if they’re buried in archive files – e.g. libfoo.a). You can have hundreds or even thousands of these warnings for a single library. Worse, they’re emitted when you link against the library, not just when you build it. And with nested static libraries they can propagate up a build chain endlessly.
I’ve been seeing this with the old eSellerate library, which fortunately I won’t need for much longer, as I don’t know how long the -Wl,-ld_classic workaround to use the old ld64 linker will last.
Previously:
Compiler eSellerate Mac macOS 14 Sonoma Programming Xcode
