This is apple's modus operandi. Hobble competitors even if it's anti-customer. Fill the gap themselves for higher profits.
As pretext, you can say the competitor's app is doing something now considered insecure or not privacy-respecting, or is not compliant with some new user experience or quality curation that you do.
So if they detect a trend early enough, they implement it as first-party feature, dry out the existing competitors while restricting new competitors to enter based on the App Store Review...
"Apps that copy basic iPhone or iPad functionality (including but not limited to its UI, gestures, core features) will be rejected unless the app provides a clearly different purpose or adds unique functionality."
Note the "basic" line. And there are plenty of Photos, Notes, Streaming etc apps so not seeing where this is being used to exclude competitors.
Apple isn’t using that rule to take down alternate weather apps, despite them having their own native weather app. There’s still plenty of QR code scanning apps, despite that being built into default camera app.
I'm fairly sure "Only high quality apps should be available to users" was said more than once when the Apple AppStore first launched (together with the second or third iPhone I think?). Apple isn't really into the whole "users can choose what's best" thing, which once you understand this, a lot of their choices become understandable (albeit shitty none the less).
There's a lot of fair criticisms of Apple, but they don't have to be absolutely first at everything or never enter the market.
When Apple did offer Night Shift in iOS 9.3 it made the APIs to do this Apple-only, for ... reasons. As of today, no non-Apple app can modify color temperature of the display.
It was using private APIs.
This is never acceptable as it undermines the entire security architecture.
Private APIs for security reasons? Sure.
For this? Garbage. There is not a single cogent reason that a color temperature API is a security gate. Or if you think there is, what is it?
Those APIs are only there because they're needed by some higher-level system library that your app is actually allowed to use.
Sure, you could have all libraries be simple shims, all calls be interprocess, and all security be guaranteed by process boundaries, but that would kill performance.
If you only accept signed code and have W^X protections that apps aren't allowed to disable, this way is simpler, faster and just as secure.
Even innocuous apps like a calculator can, and do, use them for that purpose.
The App Store process automatically checks for them and blocks submission.
Curious how apps are bypassing this and not sure why they would be trying to prevent debugging when it's not possible to do this.
The actual reason behind F.lux for iOS being pulled - https://www.reddit.com/r/apple/comments/3smf15/the_actual_re...
> Sure, it uses private APIs, but thousands of popular projects on Github (like game simulators) or that Apple TV web browser project all use private APIs and they are just fine.
> The issue is F.lux for iOS is not a true source-available download. It includes a full app bundle with pre-compiled binary (which in a nutshell, is an extracted .IPA file) packed within Xcode to utilize Apple's new free signing policy.
> And to making things worse, the same F.lux Xcode project does not only allow side loading F.lux itself, but also any unsigned IPA file. The only thing a user needs is to extract an unsigned IPA and drag all resources into the project. This allows pirates to install any stolen app, without the need to buy a developer certificate. I have tested and believe this is the true reason for F.lux project being pulled.
Screen tinting like that is exactly the kind of thing that should be an OS-feature, not an app feature.
They are similarly quite restrictive on MacOS, with some system-impacting features being locked behind “accessibility” permissions. So that arbitrary apps can’t interact with other apps unless they are actually doing something that needs it like “being a screen reader”.
iOS doesn’t have the same sort of permissions. Apps can’t take over interactions with other apps, or change display settings, etc. This is a security boundary. And changing that specifically for “changing screen colors” seems unnecessary to me.
It seems that third-party software, even software with accessibility permissions, doesn't work on password screens (and probably in a few other similarly-secure places), and you need those to be accessible. Not to mention weird places like system recovery, which (for very obvious and understandable reasons) does not allow 3rd-party software at all.
I guess you could use a third-party SR for most of your system and then toggle VoiceOver on when accessing the secure parts, but that would get very annoying very quickly.
There's also no 3rd-party access to some speech-related features, like the higher-quality neural Siri voices. You'd also need APIs for things like automatically being informed of incoming system notifications to read them as they come in (which the first-party VoiceOver does), and those don't seem to be available at all.
https://www.theverge.com/2021/9/16/22676706/apple-watch-swip...
This is also one of the things that makes a big difference between Windows and macOS when getting a new install/machine set up to basic usability. With the former, before I can get anything done there’s a whole laundry list of things that need to be installed and removed (which admittedly is now easier now that winget comes preinstalled), while that list is much shorter on a Mac. For me personally getting through that phase takes at least 3-4x longer under Windows.
I enjoy apple devices but hate the walled garden.