Don't forget the classic "Oh, that 3rd party app/feature is so popular, I bet we could build a identical/slightly less useful thing ourselves so people don't have to use other things than Apple software ever"
Conveniently, Apple's App Store Review Guidelines also include several rules that restrict apps from duplicating features that the OS already provides.
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...
I’m pretty sure this rule is only there to stop the hundreds of “flashlight” apps that used to exist. (Although, they appear to still exist) There isn’t tons of innovation or competition in “flashlight app” other than adding advertisements. There used to be a bunch of them that would only get popular out of necessity. The ones I’m seeing now in the App Store do seem to have non-default behaviors like “strobe light” at least, so they aren’t true clones of native functionality.
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.
Flashlight apps were a 3rd party innovation. Apple didn't originally realize that the camera's light could be used that way. I wonder how many other useful features don't exist today because of Apple/Google's greed prevent a truly free smartphone market.
So what? Why not let there be flashlight apps if users find them useful? Apple doesn't have to recommend them in the app store and can sort them to the bottom of search results page. But why can't the exist. If people don't want them they will choose not to install them.
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).
And yet Apple has shown many times a willingness to use vague language of their rules to block apps they don't want. Past behavior can't predict future behavior.
"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.
Do you think Apple will describe how they’re using this to prevent competition in their guidelines? You’ll need to read third party developers’ accounts for that.
I've never understood this Apple criticism (scherlocking). Someone built a search for your files, so it's not right for Apple to build a pretty key feature into the OS?
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.
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".
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.
> 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.
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.
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).
The issue is that they don’t compete on equal footing, because they integrate whatever functionality they adapt with OS features and/or first-party apps in a way that third-party apps can’t. That’s anti-competitive and increases their moat.
It’s not exactly a new thing, either. Even back in the 80s and 90s, many times Apple either implemented obvious-in-retrospect functionality from popular freeware/shareware themselves or bought up the shareware and rolled it in.
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.
If necessary, you can even retroactively ban the competitor's app from the App Store that you control.
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.
I mean it’s also a lot more work to add all the features Pebble would need so it could simply be they don’t think it’s worth it (and it probably isn’t, given all the other broken stuff they need to fix).
