Hacker News new | past | comments | ask | show | jobs | submit login

The key criticism is the final step. They don't only duplicate the functionality. They then ban the original implementation from their stores because it can create "customer confusion".



This has never happened.


Not explicitly (because that might be too openly anti-competitive even for Apple) but Apple refused to allow f.lux into the App Store, and it had to be sideloaded - and Apple leaned on them to stop offering that.

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.


A statement from f.lux about Apple's recent announcement - https://news.ycombinator.com/item?id=10904798 ( 366 points | Jan 14, 2016 | 193 comments )

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.


Not allowing third party apps to adjust screen colors seems like a reasonable security boundary to me. For the most part when you close an app on iOS, it gets closed. It doesnt get to keep changing system settings in the background. Would be awful if in addition to notifications, apps also got to adjust your colors.

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.


For context, as a software developer and Mac OS user who also happens to daily drive a screen reader, I seriously doubt whether you could implement a third-party SR on that platform.

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.


> Apple refused to allow f.lux into the App Store

It was using private APIs.

This is never acceptable as it undermines the entire security architecture.


> 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?


In Apple nomenclature, a private API is an API that your app is technically allowed to call, but that is subject to change at any moment and has 0 documentation and no backwards compatibility guarantees. If Apps were allowed to rely on those, they could just stop working across minor version upgrades or on new devices.

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.


No, all security-sensitive API surface requires being on the other side of a process boundary (and checks on who is allowed to talk to it). “Signed code” is not a thing given that you can just ship an app that can do anything and have its behavior change at runtime (that’s what an interpreter is!)


While this is true, many, many apps use private APIs. Even apps that don’t need them. One common use case is prevent an app from being debugged or run on certain devices - you can achieve that through private APIs.

Even innocuous apps like a calculator can, and do, use them for that purpose.


Which apps use private APIs ?

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.


Almost every major third party app is using some private API or the other. There is even an internal list that Apple keeps of apps that are allowed to do. It’s quite trivial to bypass the App Store checks (which are quite bad and sometimes even flag legitimate use of system APIs).


A counter-example: FlickType apple Watch keyboard

https://www.theverge.com/2021/9/16/22676706/apple-watch-swip...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: