The first third party iPhone apps existed before the SDK existed. iPhone OS was jailbroken pretty quickly and apps emerged fast. SDKs are nice references and tools but the're not the only way to skin a cat.
If you think the header files are the thing that Apple thinks is worth of a cut of app revenue, I think you're way off base. It's the technology, whether you access it with permission or not.
This seems like a very large and unfounded assumption on your part, particularly in a world where we no longer pay for Apple operating systems or their updates.
That's your claim. Neither Apple nor the EU appear to agree. Nor do US courts appear to agree in the Epic v. Apple trial.
Apple itself has to pay license fees for some technologies in iPhone, and those licenses do not automatically extend to third-party developers via the consumer. It's not a license agreement with the consumer.
When you said, "there's no way to signal to Apple that you have opted out of using their SDK and have the fee waived", which fee did you mean exactly? The quote in your comment refers to the Core Technology Commission, which is a percentage of app revenue. There's also the $99 developer program fee, which all App Store developers pay.
I know that some developers are annoyed by the $99 fee, but for professional iOS developers, $99 is a drop in the bucket, and the revenue % cut is the vastly larger and more important thing. So if by "the SDK" you mean only the header files and such, that seems like mostly a red herring to me, and if you were allowed to use the technology for free, then there wouldn't be much reason for Apple to charge for the SDK. And indeed, Xcode has always been available for free. https://apps.apple.com/app/xcode/id497799835?mt=12
This point was never raised in any of those cases. Apple just did aome hand-waving "IP compensation" justification and everyone just went along with it, because the case wasn't about that particular point.
> Apple itself has to pay license fees for some technologies in iPhone
And such costs are more than made up for by hardware sales. The only reason this persists is because of greed, not because it's essential to profitability.
> and those licenses do not automatically extend to third-party developers via the consumer. It's not a license agreement with the consumer.
They don't need to extend them because the consumer is already entitled to use those technologies merely by having purchased the device. That entitlement comes from the fact that they get legal copies of the technologies when they take posession of the hardware. IP rights regulate distribution, not consumption.
As for the rest of your comment, the overall problem is the requiremet to deal with Apple at all, the $99 fee and the 5% commission are just the cherry on top.
I strongly disagree with your interpretation. IP compensation was essential in both of these cases, and everyone went along with it because they didn't dispute Apple's rights.
> IP rights regulate distribution, not consumption.
It's all about distribution.
A consumer can download Xcode, build their own app, install the app on their own device, and use Apple API, all for free. What they can't do is distribute that app to other consumers.
The developer tools are relatively unimportant, which is why Apple gives them away. Distribution is everything.
> As for the rest of your comment, the overall problem is the requiremet to deal with Apple at all, the $99 fee and the 5% commission are just the cherry on top.
This doesn't answer my question. I asked which fee needed to be waived. There is no fee to get Xcode, so there's nothing to be waived by opting out.
I was referring to the distribution of the licensed technologies by Apple to the hardware purchasers. Returning to your own interpretation though, the hypothetical community SDK wouldn't contain proprietary code, so the distribution aspect is solved there. It's the same principle by which homebrew game console scenes work, or how you can build Windows software on Linux without touching any Microsoft code.
> This doesn't answer my question. I asked which fee needed to be waived. There is no fee to get Xcode, so there's nothing to be waived by opting out.
The waiver scenario is meant in the context of Apple using the 5% and $99 fees as payment for the maintenance/R&D of the official dev experience. The fees would be waived because the dev isn't making any use of those tools in a hypothetical FOSS SDK.
I know. My point was that distribution of the licensed technology by Apple to iPhone purchasers does not thereby allow third-party iPhone app developers to distribute their iPhone app executables to other iPhone purchasers.
> Returning to your own interpretation though, the hypothetical community SDK wouldn't contain proprietary code, so the distribution aspect is solved there. It's the same principle by which homebrew game console scenes work, or how you can build Windows software on Linux without touching any Microsoft code.
You appear to be focused on the building of iPhone apps. I'm focused on the distribution of built iPhone apps. This is why I said, "The developer tools are relatively unimportant, which is why Apple gives them away. Distribution is everything."
In general, consumers are unwilling or unable to build their own apps. They need precompiled executables, distributed by third parties, to easily install on their devices. The hypothetical FOSS SDK is a red herring. I don't see how the consumer's right to use the iPhone automatically grants a legal right for third-party developers to distribute executables using Apple's licensed technology. There are other consumer products that allow personal use but don't allow redistribution.
Unfortunately when it comes to technology licensing, it is rarely successful to say you should pay less because you purposely made your job harder.
I don't intend to insult you, but as an iOS developer myself I have serious doubts about whether you have any expertise in the subject you're talking about here.
That's not really the issue. LLM participation is a red herring. The issue is "replicates the original's functionality".
It's you who has started to argue by replying to my comment in the first place.
Your answer seemed nonsensical to me.
What I meant, though, is that I'm not going to argue about a specific point, the viability of "some FOSS SDK that perfectly replicates the original's functionality." If you don't even have any experience with iOS development, then you have no basis for making any claims about that subject, and thus I'm not going to bother explaining "What would be so outlandish about that?"
In any case, most iOS devs don't want to opt out of using the SDK. That would not be a particularly attractive route for making iOS apps. What I want as an iOS dev is the same freedom of software distribution that we have on macOS.
The basis for my claims about the subject is my knowledge of computing and development in general. I dipped my toes into iOS dev a few times and there's nothing that seemed to set it apart from any other SDK situation beyond Apple's restrictions, at least nothing that would make my claim outlandish.
Core device apis yes, everything else, maybe not?
I think we could roll our own UI - I think we can roll our own payment systems - I think we could roll our own media display.
For the primary iOS app I work on I need vulkan, gps, touches camera, sound, and phone rotation. (And standard os services)
I don’t need anything else.
Basically enough to render inputs to a gpu accelerated surface.
And I'd argue that this is a core OS feature that you expect on any modern OS.
> Basically enough to render inputs to a gpu accelerated surface.
I suspect it uses much more so that it can support
- audio
- file I/O
- accessibility
- …