There's certainly already Unity projects on the web in the space Flash used to occupy.
Also, HTML5's CANVAS tag, and modern web platform tools like WebGL, mean that you can do most of what Flash games did directly in HTML5 and JS. There's a growing number of 2D and 3D game libraries written entirely in JS or TS.
The biggest missing piece that made Flash so ubiquitous for early web games is the authoring experience. Unity is a lot more complicated than the Flash designer was. I've seen several game editors for HTML+JS libraries, but also nothing quite similar to how easy Flash was for early web designers. The codebase that inherits and succeeds the original Flash IDE lives on in a new name (Adobe Animate) and can directly target HTML+JS instead of Flash, but is a part of Adobe Creative Cloud and so too expensive for many of the hobbyist designers that made early web games what they were back when the DRM for the Flash IDE was a lot easier to crack than a cloud subscription.
FaceTime? It probably doesn't work at conference scale but it is E2E.
> We designed iMessage and FaceTime to use end-to-end encryption, so there’s no way for Apple to decrypt the content of your conversations when they are in transit between devices.
But that's a total lie, isn't it? They can just send your iPhone a public key owned by Apple. Or they can put a backdoor in the app and get you to install an upgrade.
As a user of macOS, I want developers who makes apps to use public APIs that will be supported so I don't get breakages on system upgrades or migrations.
It doesn't really matter if it's public or not. The fact is people are using those APIs and there's nothing that can be done about that. Nonchalantly breaking stuff and rejecting applications actively subtracts from the value of their platforms and could alienate developers.
Microsoft had private APIs and data structures too and it didn't stop developers from using them. However, their approach to that was different: they maintained bug compatibility with old software in order to keep stuff working. This is one of the main reasons why Windows remained relevant for so long.
The fact is Apple simply doesn't care about backwards compatibility. It's not just private APIs, public ones are also at risk:
> A lot of developers and engineers don’t agree with this way of working. If the application did something bad, or relied on some undocumented behavior, they think, it should just break when the OS gets upgraded.
> The developers of the Macintosh OS at Apple have always been in this camp. It’s why so few applications from the early days of the Macintosh still work.
> For example, a lot of developers used to try to make their Macintosh applications run faster by copying pointers out of the jump table and calling them directly instead of using the interrupt feature of the processor like they were supposed to.
> Even though somewhere in Inside Macintosh, Apple’s official Bible of Macintosh programming, there was a tech note saying “you can’t do this,” they did it, and it worked, and their programs ran faster... until the next version of the OS came out and they didn’t run at all.
As a user of macOS, why don't you put the onus on Apple to not artificially limit what developers can offer you without it breaking on upgrades and migrations?
Some of the private APIs being used have been stable for generations and are clear improvements in one way or another over the publicly available APIs (like CAContext stuff).
I mean a modern OS is not like a library you stick up on NPM and hope no one tries to use internal methods that you'll end up having to support. There are so many desperate teams working on OSX and the applications from Apple that use these APIs, it's not like backwards compatibility, documentation, and most of the issues public APIs face aren't already an issue that has to be tackled.
Apple uses these APIs to make features no one can fairly compete with, which is detrimental to you, as a user, and to external developers. Imagine if any app could use APIs like the ones that Apple Music uses to have tight integration with Siri, or that Apple Maps uses to show on your lockscreen.
> There are so many desperate teams working on OSX and the applications from Apple that use these APIs, it's not like backwards compatibility, documentation, and most of the issues public APIs face aren't already an issue that has to be tackled.
When push comes to shove, Apple can tell those teams to rewrite their code. It can't do that to the authors of, say, Firefox.
They literally do it regularly, public APIs get deprecated then removed and consumers have to rewrite their code.
This article is literally about Apple making 3rd parties rewrite their code just to access the app store.
And before you or someone else points out "Firefox is directly distributed", I say: Exactly. So they can use the internal APIs as they please, then Apple can remove then as they please and break Firrfox and... make Firefox rewrite their code.
Apple is not Microsoft. Apple does not work towards not breaking existing software, they actively break it with each macOS and iOS release, sometimes not even releasing the tools needed to fix them before general releases
Making an internal API people are already using public literally does nothing but optionally allow Apple to give a heads up about deprecation. Apple could literally slap "public" on every internal API, break them every release, and the result would be no different than the current status quo because of the overarching rule of App Store admissions... your app has to work, regardless of if an "internal" or "public" API is changed.
Honestly for most developers that wouldn't seem to different from the current situation: see iOS 13 where basic UILabel stuff was breaking.
And again, apps that don't use the App Store already use internal APIs and can already break all the time.
Apple often straight up breaks the implementations of public APIs leaving developers scrambling to fix them. See modals in iOS 13, or title bar styling.
I work at a development agency and on both macOS and iOS every release is a race to figure out which breaking changes have been sprung by Apple (including crashes caused by silent changes in behavior of existing APIs, people have had apps rejected for breaking on pre-general release OS versions when we didn't even have the tools to test them yet)
There is a difference between breaking a public API which is a defect and that’s done unintentionally - that happens with every operating system and framework - and depending on private methods to behave appropriately.
Decades ago, when Apple introduced 68040 Macs, a lot of programs broke because they were writing self modifying code and that didn’t work with the 68040 cache. Whose fault was that Apple’s or the developers?
It is not a defect. It is literally intentionally broken! Do you actually know this space?
The modal example, it's to support new design language Apple is pushing, straight up breaks modals designed a certain (valid) way.
Catalina removed XML exports used by music apps. There was no deprecation warning.
Apple's recommended fix? Don't update if you need one of those apps.
These are not defects, they are literally breaking changes intentionally made with no warning.
I don't understand why all of you seem to be operating underthe assumption apps using "public APIs" just work with each OS update. It just doesn't work like that. They break and crash not due to defects but due to intentional changes
It was part of the first beta release that the new iTunes wouldn't support XML exports. So there was warning that it wouldn't work. Public API's doesn't mean "something will never change". It should mean that API's won't change between minor version numbers. The entire purpose of semantic versioning is that there might be major breaking changing when there is a major release.
Apple did in fact provide a method to share music between apps and some apps do take advantage of it. Do you really think that Apple didn't need to do a major overhaul of iTunes?
Of course it's Apple's advice and common sense not to upgrade your OS until the apps you use are updated to support it.
This is all modern software engineering 101.
As a developer there are a few expectations.
- depending on private method may break your code with any point release. The vendor has no obligation not to break code if you depended on a private API.
- If your code breaks calling a public method during a point release, it is a bug and the vendor has an obligation not to break public API's when releasing a point release.
- If the vendor makes a breaking change during a major release (x.0.0). It's the vendor's responsible to communicate the breaking change and give enough notice to developers/users about breaking changes so that either the developer can fix their code, the user can find a replacement app, and/or the user not upgrade.
You spent so many words to latch onto a single part of my entire comment, construct a strawman around it, and burn it down.
But lo and behold something useful did come of it, I finally found the fundamental misunderstanding keeping you from understanding what the crux of the issue is.
> If your code breaks calling a public method during a point release, it is a bug and the vendor has an obligation not to break public API's when releasing a point release.
Not when the vendor is Apple.
This whole time you've been operating on the set of rules that apply when your vendor considers you a partner of sorts, maybe in the vaguest sense of the word, but a partner nonetheless.
iOS point releases break things literally all the time. Iirc we actually saw more fires on 13.1 than 13.0
This literally has nothing to do with semantic versioning or whatever else you want to confuse it with. It's a blatant disregard for developers that Apple has carried throughout it's operations, from APIs to app store rejections. If anything the only reason they get the slightest pass is they're not Google, who manages to make talking to a human, no matter how hard they stonewall you, a selling point in mobile developer relations now.
No one is going to argue that this entire release cycle hasn’t been a clusterfuck and the rapid release cycle of iOS/MacOS/watchOS this year is evidence of that.
But your argument has nothing to do with this submission - using private APIs.
At least one of your two examples - getting rid of XML exports - wasn’t about Apple breaking a public API during a point release. How is it a straw man refuting one of your major points? It was about Apple changing an API during a major release and letting developers know. This is how a vendor should behave.
Now whether they gave developers enough of a warning is a completely separate argument.
BTW: While it is a major change and no longer automatic. There is a manual workaround...
My point with that example was about how Apple doesn't treat developers as partners, something I said multiple times in my other comments is the crux of the issue, which this whole internal API in Electron rejection issue is simply a symptom of.
You ignored my perfectly good example of Apple breaking an API because you have nothing to say about it.
You ignored my comment you just replied to pointing out how irrelevant sem-ver is when your "vendor" doesn't care about you.
You are fixated on trying to nitpick the one tiny foothold you've found for your screed, one which only exists because you're ignoring the initial point I, not the article brought up, that this is an issue with Apple not caring about developers literally in the first comment you replied to.
Maybe spend more time reading and less time replying.
You gave two examples - the one I know about “broke” with a major version release, was known during the beta period and is exactly how a platform vendor should behave. The only thing in question was the beta period long enough. The other you didn’t say whether it was a point release or an iOS 13 change.
The electron rejection is not a symptom of Apple breaking a public API. It’s just the opposite. An API change didn’t break Electron apps - it was rejected for using a private API.
It’s not “nitpicking” to point out that your examples are completely irrelevant to the submitted article - Apple rejected an app that used private APIs. None of your examples have anything to do with the submitted post.
Would you also complain if you wrote a C program that depended on documented “undefined behavior”...
int b= a++ + ++a;
and it broke with the next version of the compiler or broke based on which optimizations were turned on? Yes I am sticking with examples of how irresponsible it is to depend on private APIs and undocumented behavior - something you advocated in other comments because that’s the entire point of the submitted article.
I said this internal API rejection situation of Apple not treating developers like partners
Like it's literally right there in the comment you replied to clear as day and yet you manage to muck it up then spend several more paragraphs on a new screed nitpicking your wrongly quoted text.
The internal API rejection is about not treating developers like “partners”. You aren’t their partner. Internal APIs are just that - for internal employees.
It’s dumb to use “internal”, private APIs. It always has been. It hurts your products stability, it hurts your customers, and it keeps the platform vendor from making rapid changes.
Microsoft never cared about you as a developer - they would just as easily run over you if it met their business objectives.
Ugh, I promised myself I'd stop replying, but I'll ignore most of this comment and correct some obvious misinformation for the benefit of other people who actually read comments.
Microsoft has a history from the earliest days of existence of bending over for developers.
Going as far as to literally to add a special case to their memory allocator to support explicit undefined behavior (reading memory after free) for when a specific game, Sim City.
They avoided writing more than 80 characters on any given line in system.ini, because one specific program would fail to read those lines correctly, then delete the system.ini when attempting to write it back
Microsoft is literally still packaging 16-bit subsystems with Windows 10
Anyone actually interested in learning more about it should read Raymond Chen's blog and learn about the truly insane lengths Microsoft goes to make sure they don't break what developers have done, no matter how wrong it is:
Honestly anyone who doesn't know the lengths Microsoft goes to treat developers as partners doesn't have the base knowledge for the conversation this thread has been about, but I digress.
I fail to see how this is anything but the perfect case for allowing internal API usage.
There was no other way to do what Unsafe did, so people used it for years.
A lot of people used it to do useful things in Java. So much stuff that this article is saying it literally became indispensable for much of what Java is used for. The ecosystem was better for it.
Sun says we want to remove it.
So Sun can provide alternatives that do the same job, or find that it generates so much value that it shouldn't be removed, or remove it and leave people literally exactly where they'd be if it never existed if there's no other way to do what it does. People would gnash their teeth, but the message sent is "Java was never the right tool for the job so we don't want you as a user."
And the article rightly points out, Sun was removing it for the sake of removing it. Having a bad engineering structure where that handwavy rant about Unsafe can justify removing a useful feature has nothing to do with internal vs public APIs.
The usage of Unsafe was never encouraged, it is a problem that Sun never provided a public API with similar features but relying on a private API is what caused the issue of breaking changes in the future, something that every Java developer was well aware that could happen.
Yes, I agree that the problem was that Sun didn't provide a public API for it, at the same time developers breaking the contract (instead of pushing for it to be moved to a `java.` namespace) shouldn't be excused and embraced, it causes bigger issues to the overall design of the platform when then you have to be maintaining an API for the sake of usage, the same cruft that Win32 suffers for its whole existence, and which made developing on Win32 a pain in the ass for a lot of people, for the sake of not breaking some twisted way that a major application used it.
> so I don't get breakages on system upgrades or migrations
This is hilarious, Apple breaks apps that only use public APIs on virtually every release they do, minor releases, security patches, you name it. Apple CONSTANTLY BREAKS THINGS.
Just because the States are kicking this off / working together doesn't mean that they will ultimately have jurisdiction over (most of) the charges they may want to pursue. Interstate commerce is an enumerated power in the Constitution so it may not be their call to make.
https://apolloapp.io/