For context (and correct me if I have this wrong), f.lux was using a non-standard way to allow people to install the app on their phones (allowing them to install it using Xcode) and Apple banned that method. A few months later, Apple announced an iOS feature that does exactly what f.lux does.
Apple allows sideloading apps so that devs can work without the whole Apple deployment shenanigans. You write your app, sign it in Xcode, and load it onto your device.
This is allowed and encouraged.
F.lux did this to sign a compiled binary for their app. All good! Totally fine. The problem is that that they then distributed that compiled binary to people to sideload.
You're allowed to distribute source code and let people compile and sign it on their own Xcode – you are not allowed to distribute compiled code to sideload onto people's devices.
There are open source alternatives that now both predate and outlive flux on iOS, such as Gammathingy.
I don't like this characterization that you're "not allowed" to distribute compiled code to sideload. That act involves two parties: the people who made the app, and the person who installs it.
Apple decided to butt into this simple transaction and shut it down, despite the fact that they are not involved. But that's not so much "not allowed" as it is "displeases a big company that throws their weight around a bit too much."
They absolutely are involved. Apple views distribution of unknown compiled binaries as a serious security vulnerability, both because they can access private APIs that the App Store would otherwise block, and because Apple has no way to shut down an app distributed this way that turns out to be malware.
If the app is open source, you're free to compile it with Xcode and install it on your device. That's fine, because the open source nature means you can see everything the app is doing and verify that it isn't malware (and if not you personally, then someone can do it).
But for closed source distribution, barring enterprise distribution, it has to go through the App Store. Allowing anything else opens up Apple's customer base to malware.
> That's fine, because the open source nature means you can see everything the app is doing and verify that it isn't malware (and if not you personally, then someone can do it).
Closed source isn't a barrier to reverse engineering in any practical sense anymore. It's a post-IDA world.
IDA has been mainstream among reverse engineers for at least 15 years, and equivalents such as win32dasm existed before that, so there is not really a notion of a post-IDA world.
Closed source is very much a huge barrier in verifying what software is doing, just as much as it always has been. I say that as someone who has been reversing engineering professionally for much of that time.
The number of people with the expertise and access to IDA is a tiny subset of those who can just skim source code. And those who are competent reverse engineers take 10x-100x longer going that route. An even smaller subset of those have the inclination to even bother doing this for free in their spare time.
Apple doesn't become involved just because they're interested. It's a straightforward interaction between two parties, until Apple butts in.
Private APIs are a security vulnerability? Come on, you know
better than that. It's not like a malware author can't take five minutes to come up with a way to bypass the private API checker they run on App Store submissions. The prohibition on private API is purely about not breaking apps when Apple releases OS updates, or forcing Apple to maintain a private API they want to change or delete but can't because too many popular apps use it.
The Mac App Store has basically the same restrictions as the iOS App Store, but unlike iOS, OS X does not require that apps be installed via the Mac App Store.
I think the issue was that that app was using private API's, users may not be fully aware of the implications of this, install via the Xcode method and then end up with issues when/if Apple messes with the API. So although it might look like Apple preventing holding down competition there are very valid reasons for the original response. (Not 100% sure that's what you were implying).
More than that, they were distributing an Xcode project that was little more than a binary, using the recent changes to developer code signing in Xcode to get that binary on to user devices. I can see how that alone would provoke a reaction from Apple, private APIs or not.
After all, there are plenty of open source projects on Github that merely use private APIs, the browser for tvOS[0] for example.
I think it's more accurate to say that Apple asked them not to use that method, and they complied. Apple didn't employ any technical measures to prevent the method f.lux was using, you can still sideload apps. f.lux apparently decided it was more in their interest to comply than not to comply.
