> HTML5 (which is now called Progressive Web Apps / PWA)
This is clear gaslighting and is verifiably false. Progressive Web Apps is a Google thing, coined by a Google engineer[1] and promoted by Google[2]. The HTML living standard does not include a single mention of the term[3].
It's subtle misinformation that's designed to change how people unconsciously perceive PWAs. When people bring up PWAs, they commonly refer to a particular set of APIs which has a tendency of mainly being a Google-driven effort. GP is muddying the waters by instead framing it as the HTML spec itself and implying it's official.
If this isn't a clear case of gaslighting, I don't know what is.
I'd argue this is a lie and not an example of gaslighting.
A lie is simply stating something that is not true. In this case, stating that HTML5 is synonymous to PWAs.
Gaslighting is an attempt to undermine an individual's (or perhaps even a group's) certainty that they are able to perceive reality correctly. It's essentially an effort to make someone question their own sanity. Lying is a tool that may be used as part of this effort, but it is not the only method of gaslighting.
It's also possible to lie without gaslighting. Speaking mis-truths may happen accidentally. But trying to cause someone to believe something that isn't true, isn't necessarily or inherently an attack on their trust in their own ability to perceive the world.
In this case, I can't see any indication that the goal is to cause anyone to feel insane.
> Apple has has been recently been rolling out anti-PWA practices [1].
That article is from a year ago and the author's conclusion is more or less "no, Apple isn't trying to kill the web; it's reasonable to have some time limits in place." Safari clears some script-writable storage for a site after 7 days of Safari use without visiting that site, but home-screen installed webapps aren't affected.
- localStorage is broken in Safari 14.1 (the latest version) on macOS [1]
- Apple added support for blob.stream() in Safari 14.1 but calling the function causes a null pointer exception and crashes the renderer process [2]
- Read this summary of Safari changes in iOS 14.5 (released a few weeks ago, and without an official changelog for nearly a week) and tell me that Apple isn't trying to kill PWAs through neglect [3]
I have been pushing for Push notification should be part of HomeScreen WebApp and not on Safari itself. No one likes them on Website, which is a valid argument. But I dont think Safari team sees the need for it.
They do hold back PWA's though. They could offer opt-in push notifications for example. That's the only thing I miss as a solo web developer, and the only thing the users of my websites want (functional notifications of course, not marketing).
I'm not recreating my websites in app form just to have that. But Apple sure wants me to.
While I get the utility of push notifications and part of me likes the idea, it will get abused in the same way it was on desktop where every second website asks for permission to send you notifications or install a PWA to be able to do so.
I suspect Apple has internally discussed it and concluded that it would too likely be abused and result in a poor user experience.
Also, Apple deliberately does not like background connections for battery saving reasons which is why everyone is required to use their push service, meaning iOS maintains a single energy efficient connection instead of each app maintaining their own TCP connection which may have no regard for energy efficiency.
I acknowledge it's possible that they don't want to remove reasons for people to rather make native apps, but given the other reasons, it would not be my first guess.
So have a global switch to turn off the ability to even ask; hell: make it default disabled for all I care... solving your petty "I don't want to be bothered by pop-ups" issue isn't even remotely complicated, and that this is a continual refrain preventing the world from having fully-functional applications for software you apparently don't want to use anyway is not just ridiculous and demoralizing, it is shameful.
> it will get abused in the same way it was on desktop where every second website asks for permission to send you notifications
I really wish Google would crack down on this between the Googlebot and Chrome. There's zero valid reason for a website to send a notification request without user action to initiate it. The Googlebot could record any unsolicited notification requests and negatively impact the ranking of those sites, it's a decent indicator of scammy sites to begin with. Not to mention blacklisting those sites from making a notification request to Chrome.
Chrome could also just watch for notification requests no differently than how popups are blocked already. I'm sick of the hordes of websites constantly spamming those requests. What's sad is that I'll frequently see other users actually accepting those requests and getting a barrage of ads that they don't understand how to stop. This isn't rocket science to fix.
Browsers should again be user agents and just let me set a default. 'dont bother me with notification requests. ever.' is perfectly valid and implementable setting.
Of course, I agree! But your comment is assuming the platform offers notifications in the first place. Apple has decided here that you should not even have a choice.
I don't want a choice to accept or deny it. I am utterly fatigued of choice. I want no push notifications and no reminders that push notifications exist.
But a lot of applications ask to send notifications on iOS, doesn't solve the problem as that person seems to not wanting to even be asked about it anywhere.
You're correct, even iOS is not good enough. If an app asks and it's not a messaging app, I usually uninstall it.
I'd compromise on "Install" vs. "Install with Notifications" as two options when buying/downloading an app. But having to do any of the developer's administrative bullshit when I'm trying to use the app is disrepecting my time.
Otherwise I don't want to see that shit until I go into a "Settings -> Notification" menu and explicitly enable it. And never in a web browser.
I hear you. But I think you're in the wrong thread, we were specifically discussing how Apple is making PWAs different from normal apps _just because_.
Frame your argument differently than "you as a user have a choice" if you want to make that point.
The model of "user choice" has contributed more to the modern hostile computing environments of the past decade than maybe anything else. Users don't want choices, they want tools to help do what they want, not what mediatech/adtech/social garbage app firms think they should want. Mostly, users want their computers to shut the fuck up and get out of the way.
Then don't use it and deny the notification permission like you can for normal apps. But if the users wants that ability they should have the option to enable it.
I've made a messaging web application for my work, and notifications are important for a messaging app. Luckily it's a small business and everyone who needs to access it has an Android
It’s really not too difficult to build webview based wrapper app around your website. I’ve done it many times, and then you can have notifications or any other native features you might need.
It's not an issue of it being technically hard - it defeats the whole point of using a PWA. Your users now need to download the app from the App Store and you're subject to App Store review policies.
Their rationale for not allowing other browser engines is that allowing JIT (writable AND executable memory pages, in general) would make the hell break loose.
Well, if there is an RCE vulnerability, that would allow the user to run arbitrary code on their own device with the same permissions that the browser process has, which is clearly unacceptable in the iOS world.
On macOS you as the user already have complete and unrestricted access to your computer. You don't jailbreak your mac because it already comes with root and an unlocked bootloader. Mac apps also have much more access to the underlying system than iOS apps do, and this helps with better sandboxing, I presume.
This was a good argument in the past, because there were very few ios exploits and apple was proactive in hunting them down, to prevent jailbreaking. Not sure if it is a valid argument today.
Apple recently suggested [1] to Australian authorities that Apple can't possibly have a monopoly on app distribution since they have no restrictions against PWAs which "have the look, feel and functionality of a native app". But they fail to mention that they control exactly what functionality is actually available to PWAs. And right now it's A LOT less than what is available to native apps.
Also, most users are not aware that third-party iOS browsers like Chrome, Brave, and Firefox are actually just light UI "skins" on top of the Safari browser engine, Webkit. Apple refuses to allow third party browser engines on iOS.
So this means that it's not possible for users to just switch to another browser in order to use more powerful web apps. They're literally prevented from doing so by Apple's policy to ban browser competition on iOS.
> Also, most users are not aware that third-party iOS browsers like Chrome, Brave, and Firefox are actually just light UI "skins" on top of the Safari browser engine, Webkit. Apple refuses to allow third party browser engines on iOS.
IME even a lot of developers are unaware of this fact.
An added annoyance flowing from this is that Apple does not allow remote debugging for webviews, so any reasonable debugging flow for those browsers is blocked. Great fun when you have a bug in iOS Chrome only.
You can remote debug webviews (from Safari on a Mac), but only web views in apps signed with a development provisioning profile (1). So to debug web content in iOS Chrome you would have to build and install Chromium for iOS yourself, rather than use the Chrome App Store version.
My understanding is that third party engines are allowed. They just can’t JIT the JavaScript unless they use the builtin Safari one. So, if you want to have the same performance of the builtin Safari browser, you really need to be nothing more than a skin around it.
This is false too. "Nothing more than a skin" suggests you can't make a full-featured browser, with your own code, that you're just replacing the Safari UI. This is simply not true.
I literally said that they are allowed. They just can’t JIT the JavaScript, so performance suffers compared to Safari. So, if you don’t care about JS performance, then yes, you can make your own full browser with your own rendering code.
"Apple rolling out anti-PWA practices" refers to them clearing local state after 7 days of no use.
How is that going to stop anyone from having a PWA app? Web browsers have to prune their cache all the time, otherwise your entire phone would be just web cache.
Local storage is intended to be cache. Nothing more. If you have something worth preserving beyond 7 days of inactivity, put it on the damn server and reload it when you have to.
For the record, local storage is typically limited to 5MB. Users visit hundreds, often thousands of sites each month. They open links through social media to some random meme all the time. So we never clear those 5MB, what happens?
"Local storage is intended to be cache. Nothing more. If you have something worth preserving beyond 7 days of inactivity, put it on the damn server and reload it when you have to."
How about the idea that not everything must live in the cloud?
I like apps that keep my data on my phone.
Or when you use your phone in areas with bad connections?
Say an outdoor app, you have on your phone with lots of data you specifically wanted for this area. In case you need it. But now you have to remember to use it regulary, or you have to walk up an mountain to get parts of your old state again.
There is a difference between temporary cache and intentionally saved data. Even from webapps.
But this just means a further push to develope a "real app" inside apples walled garden, for a proper functioning app.
(assumed this auto delete of all pwa cache is actually the case, and it would be allright with me, if there are exceptions for "installed PWA's")
I like apps that act like apps, and sites that act like sites. There's a reason we don't drive-by install apps on our phone just by clicking a link. But you do drive-by install site local storage on your phone by clicking a link. So you need a way to clean those up at the very least.
> But this just means a further push to develope a "real app" inside apples walled garden, for a proper functioning app.
You can also wrap a page as an app on the App Store if that's what you want. And store infinite data for infinite time. So everything is already possible.
So you don't have to develop an app in the walled garden, you just have to submit it to the walled garden, and not do something horrible using the native APIs, and you're done.
The point of PWA'S are, that if I develope one, I don't have to go to Apples app store. I as a web developer don't know how it works and I don't want to have to know, how it works specifically. Neither do I want to target Microsoft's plattform nor Googles Playstore and figure them out.
I want to target the web.
So anyone with a decent browser can use my app.
PWA'S are not simple websites. They are more. A plattform independent application with web technology.
I do not want you, as a web developer to be able to target my device with an app when I visit your link. I don’t want to be forced to deny access to every service/feature on the device via pop-ups either. Until there’s a proper open standard for “web technology” apps that are opt-in and user initiated, and clearly separated (visually and technically) from web pages (which are documents) I feel like Apple are on my side here.
I want app developers to jump through more hoops than people making websites, and to need my express approval to run their app on my device. I absolutely do not want documents that “progressively” turn into apps. PWA is a bug not a feature.
Why would a document have access to your camera and microphone? I am 100% sure Apple would remove the camera and microphone API from iOS browsers if they could and the fanboys would defend it with "think about children and grandmas".
The Web has a portion that is more then documents, like music/video , games, simulations/animations. It makes sense from the POV of a greedy corporation to cripple say a web streaming app so you get a 30% cut of the subscriptions, or cripple video games 3d performance (with terrilble webgl) so you get 30% of those sweet lootboxes and gems.(BTW why is Apple not thinking at children with the lootboxes stuff?)
Lots of reasons a document might user my camera - to fill in a form, for example. Obviously there’s a blurry line between document and app, and for some use cases it makes sense to be more app-like.
I’m very fine with this blurry line, and using web tech for all these things, even full apps if you want, as long as you don’t expect access to intrusive or persistent features when I browse to your website, but only when I decide to install/allow your “app”.
Whether Apple is obliged to provide a platform in which web tech used in apps matches native performance and features… I don’t see why they should be, though it’d be nice.
I totally agree forcing all apps via the App Store is bad btw. Alternative app stores and side loading should probably be allowed, but that doesn’t mean the answer is more ways for websites to intrude and behave badly in the browser.
"I want app developers to jump through more hoops than people making websites"
It might be news to you, but webtechnologies have evolved a bit, from displaying static documents. Have you heard of wasm for example? Quite interesting, what you can do with that. And a bit more sophisticated, than scratching together some html markup.
But I very much agree, though, that I also don't want any website to have deeper access to my hardware, without explicit consent from myself.
"Until there’s a proper open standard for “web technology” apps that are opt-in and user initiated, and clearly separated (visually and technically) from web pages (which are documents) I feel like Apple are on my side here."
So yes, there is more work needed in that area to make that distinction more clear to the users.
But I don't see Apple is pushing in that direction. Rather the opposite. Pushing into their walled garden, they control. Otherwise they would be very free and able to polish their PWA permission dialogs, to protect their users, no?
> The point of PWA'S are, that if I develope one, I don't have to go to Apples app store. I as a web developer don't know how it works and I don't want to have to know
Unfortunately that's often what it comes down to. Developers who don't care about the devices they target and their software stack.
Developers should be open to learn new tech, before they reject it. Sure, go the web app route, but don't do it because you look at iOS and the App Store and you "don't know how it works and don't want to have to know".
To me it's not surprising Google wants everything to be a browser with rich permissions that easy to track, search index, put ads on and monetize. This is why they want powerful PWA. This is why Chromebooks are basically... a browser.
Apple on the other hand has crafted a platform optimized for their philosophy of UX and design. And which is often incompatible with these PWA standards that have emerged, which are often honestly sloppy and indiscriminate in wasting a user's power, bandwidth and leeching their private data.
Apple and Google have diametrically opposed goals here.
- Apple wants a free and powerful web, but not a web so powerful it takes over your entire phone, because let's face it, the web is a giant balls of kludges, it's a miracle they work at all.
- Apple wants to save battery, to value user's privacy, and to allow the device to use its full potential through native APIs that are integrated with hardware functions etc. but not abused (which happens without at least cursory review process).
- Google doesn't care about wasting power, doesn't care about privacy, they run an ad business and a search engine. They want three things:
1. Everything everywhere should be the web.
2. The web should have access to everything on your device.
So you are saying, that I as a Web developer should just become a native app developer?
Well no, thanks.
I know that native apps are superior in performance over web apps, sure. And I certainly won't say every app has to become a pwa.
But for most simple apps, webtechnologies as a plattform are mature and performant enough.
And if you never would want to install one - thats your decision. But my decision is, that I don't want to specifically target apple technology. Just like with Microsoft, Samsung, LG, Google or whoever wants to copy apples walled garden.
Sounds like an insult to me. Selfishness is regarded as a bad trait.
And I actually do care about other people beyond their money. Which is exactly the reason, why I did not decided to tend to the most lucrative market only: apples walled garden.
It came off as pretty insulting. You've also been presenting subjective opinion as objective truth when there are many Apple users and developers that disagree with what you're saying.
A more cynical take is that Apple want their cut of any revenue that goes through iOS and intentionally hamstrings PWAs at the expense of their users to achieve this. Either or neither could be true.
Of course Apple wants their cut, but you know offering services and getting paid is not a dirty thing, is it?
Everyone keeps talking about how they "intentionally hamstring PWAs". They kicked off HTML5, remember? They shipped the first real web browser on a phone, remember?
Now they chose to implement some Google-pioneered APIs selectively to preserve UX, performance and privacy and everyone is up in arms.
As a web developer I never felt Safari lacks something I really need. As an app developer, Swift is possibly the best dev experience I've ever had, next to C#.
All this is about letting people comfortable hacking everything in HTML to make "apps". Well I wish I could contribute to the Linux Kernel with my HTML apps, why not? Why is Linus hamstringing PWAs, ffs. /s
> Of course Apple wants their cut, but you know offering services and getting paid is not a dirty thing, is it?
I'd argue that forcing someone to use your service by preventing others from offering the functionality and handicapping your own implementation is in fact a dirty thing. They get their cut when someone purchases an iPhone.
> Everyone keeps talking about how they "intentionally hamstring PWAs". They kicked off HTML5, remember? They shipped the first real web browser on a phone, remember?
So what? They didn't launch with the app store, and since it was introduced they appear more and more hostile to the changes they helped kick off. According to others in the thread they won't even allow webapps to send notifications, a fairly basic/fundamental feature of mobile phones. Elsewhere people go into further detail on how Safari's storage APIs are released buggy and broken.
> All this is about letting people comfortable hacking everything in HTML to make "apps". Well I wish I could contribute to the Linux Kernel with my HTML apps, why not? Why is Linus hamstringing PWAs, ffs. /s
This is a total mischaracterisation of what people are asking for which is simply to allow applications delivered through a web browser greater parity with native applications.
I work on a b2b web application and being able to store larger amounts of data on the client with user permission would be fantastic for both performance and user convenience.
It would be fantastic for the user. But you can’t be bothered wrapping it in an app. I guess either it’s not fantastic enough, or we’re missing something.
Because you're not simply "wrapping it in an app". You're now paying rent to Apple for the privilege of wrapping your otherwise perfectly functional application in an app.
Android devices are actually quite locked down these days it's just that you CAN shut off security features.
For example I can't just download APKs in Firefox and install them without flipping a switch which triggers an explicit warning.
> You can also wrap a page as an app on the App Store if that's what you want. And store infinite data for infinite time. So everything is already possible.
Except now you're paying $100/year and giving up 30% of any revenue for the privilege of allowing your users to store data on their phone?
I think local storage could use some improvements, especially with regard to giving users more control over what is stored there, but it provides much more freedom than participating in Apple's app store.
The paradox is that you have far less control with an app, and most come with even more analytics than a webpage. Apps in the Play and App stores don't make me feel any better than PWAs, quite the contrary. I've a LineageOS phone and use apps from F-droid to have a modicum of control and privacy, coupled with an ability to have it be usable without network.
Local storage is persistent when you add a page / app to the home screen (ie take the step to install and enable it as an “app”) and only gets cleared after a while when the site is browsed as a website in Safari.
This, as a user and as a reasonable developer, seems exactly right. The “progressive” part happens when I want it to and initiated by me, so the developer can’t shove it down my throat or trick me into enabling their “app”.
So much of this argument is down to entitled web devs and companies that want to take advantage of the fact I’m reading their website to start installing software, sending notifications, reading from sensors etc. without permission.
> How about the idea that not everything must live in the cloud?
> I like apps that keep my data on my phone.
LocalStorage is simply not appropriate for this. The act of keeping persistent data should be transparent to the user, via "download" (save to disk) and "upload" (load from disk) workflows. This also allows the user to manage e.g. their own backups for this data, which they can't via localstorage.
> The act of keeping persistent data should be transparent to the user, via "download" (save to disk) and "upload" (load from disk) workflows.
That's horrible. If native apps would have to work like this to persist anything, instead of billions of users worldwide, they'd probably have 50-100x fewer users.
Except they already do, implicitly, at least for the download part.
Users actively go to their App Store and choose to download an app. They don’t just get something installed, or not, in some obscure part of their device’s storage, without ever knowing about it.
"They don’t just get something installed, or not, in some obscure part of their device’s storage, without ever knowing about it. "
Like I said in the originally statement: it would be allright for me, if apple and everyone else, regulary deletes all local storage of any pwa's that haven't been installed. And I have read nowhere here in this thread, that anyone is in favor of PWA's sneakily installing.
Yes, it should be very clear and visible, when you install something. But that is for the browser/OS makers to implement and not the issue here.
Perhaps I misread, but the parent seems horrified at the idea that users should get to know they are downloading something and that such knowledge would supposedly ruin native apps adoption.
I was merely pointing out that it already is, albeit partially, the case, and yet said apps are quite popular.
It doesn't stop you from having a PWA app, it just makes it less useful, harder to implement correctly, and overall a worse experience for both devs and users.
> If you have something worth preserving beyond 7 days of inactivity, put it on the damn server and reload it when you have to.
It could be also true about native apps, heck, why do we even have any storage option beyond 7 days except on servers? If what you said were true, why would they not have the same policy for native apps? It's just an excuse to cover up how they knee cap PWAs.
Their actions result in PWAs that can replace native apps even less often than today. PWAs had the potential to be free and platform independent, whereas Apple has much more control over their native apps. See your own example with the local storage: it doesn't make it completely impossible to make PWAs, it just makes it overall a worse option, for both devs and users, so it's easier to go ahead with the native app.
> "Apple rolling out anti-PWA practices" refers to them clearing local state after 7 days of no use.
If they actually did that, it'd be crippling installed PWAs compared to native apps, since you couldn't persist anything without an account.
However, from what I remember, they don't actually clear the state of installed PWAs for the primary domain, since the 7 days only count down if you actually open the app on that day.
The A in PWA stands for Apps. They’re specifically meant to be more than just websites and more like native apps that can be delivered and rendered by existing web tech.
Setting the same limitations as a website for a PWA defeats a major purpose for using them.
The essay rather suggests HTML5 as a better alternative to Flash for web development, not app development. Having said that, I haven't read the latest PWA situation on Apple platforms, maybe it is true that they are trying to prevent PWA from getting popular. If that is the case, I hope Google and Microsoft can take advantage of this shortcoming of Apple platforms.
When iOS (then known as iPhone OS) first launched, Apple were actively/publicly against opening up their devices to third-party native app development. They encouraged third-parties to use web technologies as an alternative[1][2].
However, iPhone OS 1.0 launched without encryption enabled (not sure why, iPhone OS 1.1 enabled it), so this made reverse engineering efforts a lot more straight forward. For end-users, jailbreaking was trivial, you'd literally visit jailbreakme.com and a TIFF exploit in Mobile Safari would automatically jailbreak your phone (or in my case, iPod Touch) and install Installer.app[3].
A reverse engineered SDK was used to write apps and made quite the splash. This encouraged Apple to make available an official SDK. I'm not sure whether it was public pressure, or just that Apple saw the ingenuity of what people were achieving with Apple devices. However, iPhone OS 2.0 introduced the App Store, and the rest is history.
I heard the explanation that iOS 1.0 ran everything as root and there was no sandboxing, and this was the only reason why there were no third-party apps.
It is true, but how could they take advantage of it? Your average person doesn’t care. I recently learned that more than 50% of phones in the USA are iPhones. How can Google and MS move anything forward on the mobile front unless Apple is on board? It’s not like you can run a different web rendering engine or JavaScript engine on an iPhone.
"Progressive Web Apps" means Chrome-only at this point. The framing of this discussion in terms of "Open Web Standards" vs "Apple's walled garden" is just hiding the fact that's Google who're paying the bills and calling the shots on the web "platform".
Sent from my notebook running Chromium (for webapps) alongside with FF for the extant web such as HN.
I'm on iOS now and have a few web apps installed as apps on the home screen the same as what I had on my previous Android phone. No difference for me as a user between the two. Both hide the browser UI and add some functions that a normal website doesn't seem to be able to access.
In that Chrome dictates future web standards, rushes ahead to implement whatever they want, and FF/Safari lag behind, to the point that some web apps will even say "runs on Chrome" only...
This is a statement with ill-defined semantics, because there is no such thing as a "PWA standard". "Supports PWA" means, in practice, that it supports whatever new API or feature Chrome introduced five days ago.
Wow. I wasn't aware that Steve Jobs wrote essays. Are there more?
I think this part is interesting, because it's still true:
> Our motivation is simple – we want to provide the most advanced and innovative platform to our developers, and we want them to stand directly on the shoulders of this platform and create the best apps the world has ever seen. We want to continually enhance the platform so developers can create even more amazing, powerful, fun and useful applications. Everyone wins – we sell more devices because we have the best apps, developers reach a wider and wider audience and customer base, and users are continually delighted by the best and broadest selection of apps on any platform.
I don't think this is as true as you think it is. If IBM locked down their PC platform in the 80s like Apple does now, then we wouldn't have Linux nor BSD and everyone would have lost.
Yeah, but Steve Jobs isn't responsible anymore for what Apple is doing today.
If he would have done much different, I don't know. I also guess his main concern with Flash was, that he couldn't control the proprietary plattform. The flash player could have been improved ... but Adobe would have been still in charge.
The problem was, essentially, a huge chunk of code in the middle of the browser experience that apple couldn't optimize for mobile CPUs, screens and batteries.
I know. Because Adobe could not bring themself to open the flash player (and still make money with selling their awesome tools). Thats why flash died, despite it was much more advanced than the web at that time.
The original IBM PC had pretty open hardware and software, both a little unintentional. Hardware-wise they published everything so add-in cards and more could be developed. Sofware-wise they didn't hold Microsoft to an exclusive agreement for PC-DOS so MS-DOS could come out.
Later they tried to close the barn door with very locked down hardware with the microchannel bus and IBM's own operating system OS/2. But it was too late...
I actually think Apple and their customers would be more successful with open hardware. When they went from powerpc to intel with more generally compatible hardware, I think that was great. Now they're reeling it back in, and I wonder if they'll be following the same path as IBM did...
Computer is always sort of open in that market segment. Apple ii, cpm and IBM PC. One can try (ps2) but all failed. Apple trying but still mac is sort of open and you can still run linux and windows on m1 sort of.
Phone ... smart phone opened? From Nokia, Newton, palmpilot, windows phone, ...
The question is whether the phone business model can bring it to desktop and conquer there. Wonder.
I like my phone is walled garden and I can take risk of my collections of pc.
I think 9to5 does a great job and few on twitter looking through every single detail of the released email in court with Epic vs Apple.
Those words of Steve might have been true back then. It is far from the truth today.
At least Apple no longer sees selling more devices as their primary motive. Remember when the App Store started, Steve thought it would be about the size of their iTunes Store.
> In the essay [0], Jobs suggested mobile app development on should focus on HTML5
I think you should read that essay again. In the context of the mobile web, it argues for HTML and against Flash. In the context of apps, it argues for native platform technology and against Flash. It doesn’t argue for using HTML for apps.
Edit: Quite confused about why this got downvoted. If you disagree with my reading of the article, could you explain what in the essay suggests focusing on HTML5 for mobile app development?
As others have said, Apple was strongly opposed to introducing support for native third party apps on the iPhone not long before this essay was written.
Apple's preferred approach was web apps that you could "install" to the home screen on the device.
While that functionality is still available, Apple has left that web app approach stagnant - not adding features that other platforms/browsers have, and reducing performance compared to running the same web page in Safari.
First, it’s not fair to say they “strongly opposed” native apps “not long before” the essay. Every iPhone model has supported native apps through the App Store. Yes, web apps was their original plan, but they announced their intention to launch a native SDK just three months after the original iPhone release. It took another thirty months before this essay was published, so in relative terms, at that time that original plan was nothing but a historical parenthetical.
Second, this is completely irrelevant to claiming that the essay in question suggests developing mobile apps with HTML5. That’s just flat-out incorrect.
>but they announced their intention to launch a native SDK just three months after the original iPhone release.
All thanks to Scott Forstall, he was the only one doing heated debate with Steve Jobs. And his word "HTML5 will never be as good as native apps" is still true today, whether it is on iOS or not.
Or maybe because PWA is a flawed concept? At least that's my take as a consumer and a developer. As the sibling commenter noted PWA is also a Google concept, with corporate strategic interests behind, it's not as simple as it appears.
A bit OT, but can anyone point me to a few PWAs that are worth looking at? I don't means those "these tings are possible in the browser" sites, but real, useful tools.
I just use one: "Brewfather", a fantastic home brewing (beer) app which can even use some Bluetooth API to communicate to local devices (Chrome-only of course). On my iPad, I'm using the app though.
Reading this essay again (via Wayback), I'm struck by Steve's clarity. His writing is concise and simple - my favourite bit:
> Everyone wins – we sell more devices because we have the best apps, developers reach a wider and wider audience and customer base, and users are continually delighted by the best and broadest selection of apps on any platform.
What strikes me is that he simply states Apple's goal - to sell more devices and make more money. He doesn't try and sugar coat it about serving some greater purpose, he just states what everyone knows to be true. It is refreshing, given how many business leaders seem reluctant to publicly admit that their goal is to make money.
Secondly, it clearly broadcasts what problems they are and are not trying to solve, and where their priorities lie. Love it.
I've yet to see an exec with such concise outside communication, from technical details up to the big picture, as Steve Jobs. Interviews with him are a master class in communication skills.
It is important to remember context. At the time, Apple was absolutely not a services company. In fact, their services were terrible (eg: MobileMe).
All of their revenue came from selling devices - the improvements year over year were more significant than they are today. Each year would bring new features that would open up entirely new market opportunities for developers and it was happening at such a pace that even Apple engineers could not keep up. Apple needed developers to sell devices much more than they do today.
Steve's argument that having an intermediary between Apple and developers would delay the implementation of new technologies and capabilities is entirely valid in that context. Of course, the context has now changed - Apple is increasingly a services-oriented company, and that means their objectives are to both sell more devices AND sell more services, which puts them at odds with developers who were typically responsible for providing the actual services that ran on top of the platform.
The 2010's was perhaps the single most transformational decade in technology, and while the shift from devices to services may be obvious now, it was far from obvious back then. Steve's clarity is even more impressive when you consider the era in which it was written.
And to add more context, those words were written when iPhone sold only ~10M per year. Now iPhone sell that many in a single weekend only bottlenecked by production and delivery.
Not to mentioned Steve was baffled by the App Economy. Unfortunately it didn't live long enough to see all the beauty and Chaos it brings.
Well, back then reality was much different. Just getting developers on board to begin with was difficult and users were reluctant to pay for apps and e-commerce in general.
Mobile devices sucked and applications sucked The promise of a phone with a little marketplace for little paid apps made by little developers empowered with good UI tools was utopian at the time. And it didn’t seem like a multi-billion dollar business until apps like Uber started proving that this was going to be a huge lifestyle change for everybody.
It really is a shame the guy is dead, I would be really curious how he would be tackling all of these issues today.
Ok, in the context of that time, that apples devices had the best hardware (and optimized drivers) - then yes, it makes some sense, that apple would have the best mobile apps, so win in that regard.
But since he clearly stated the goal as apple should have the best apps, I am not convinced, that he would have continued to push for a open technology, that would run well on any good hardware, whether apple or not.
And in 2010 the competing smartphones were already not that far behind.
I really don’t know how to count “best” either in hardware or software. Very difficult to define something like that. The promise of Apple apps early on was that they conformed to a particular UX style which definitely gave the user a feeling of safety.
The way I see it - his strategic decisions were based on all of the decades of experiences in the computer industry. The goal was to build a closed platform and to guard it by emphasizing quality as an ideal. And then to incentivize eager developers small and large to come to it and become dependent on it. I don’t think he would have pushed for “open technology” or running that software on anything but apple. It was the hallmark of his whole thing.
But he could have run and defended the whole thing in a completely different way. And this is why it would have been very interesting to see the guy live. Would he have enforced on all those quality related shortcomings that Apple stands accused for today? Would he have argued vehemently in their defense or would he respond differently? Or maybe perhaps he would have moved on to another “big thing” product-wise by now?
In terms of marketing, Steve didn't sugar coat but he did create the most intricately crafted of savoury dishes. These dishes were still far more appetising than the ingredients had any right to. I won't comment on their nutritional value though.
Adobe’s then-CTO Kevin Lynch was a staunch defender of Flash and argued here that Apple's approach to platforms was anti-competitive: https://youtu.be/Z512TwwyRWM. Years later he lead the original Apple Watch software project, and still does to this day.
I don't see any conspiracy behind this deletion. Steve Jobs talks strictly about videos and games embedded to "web pages", not "PWAs" (which didn't exist back then anyway). It was and is still compatible with Apple's walled garden approach. He even says:
> And the 250,000 apps on Apple’s App Store proves that Flash isn’t necessary for tens of thousands of developers to create graphically rich applications, including games.
"Standards aren't add-ons to the web. They are the web." - Apple's HTML5 Showcase, 2010
How far they have strayed from that visionary approach to the web. Apple used to lead the pack in promoting advanced web apps. These days they are holding the web hostage to protect their App Store business model.
My intuition is that the answer is "uhh, no." -- is there any secure way to run untrusted javascript on a page? So that we could have those awesome newgrounds style wildwest galleries where people upload their weirdsies again. I've seen some synthetic namespace shenanigans that I've had a hard time breaking out of, but nothing that makes me comfortable.
I know Flash never had a reputation for.. security, but Youtube-for-html5 games seems like it could never exist for my intuition. I'm sure you could get away with it on small scales, but anything beyond a person's ability to curate and we go backwards.
The iframe sandboxing feature is better suited for this. It puts the full strength of the same-origin security policies of the browser between third party content and first party content on a domain. It has “only” been around since IE 10 or so though so it wouldn’t cover all of the golden age of flash.
It’s worth noting that Flash was actually quite hard to contain from interfering with your origin, and the main defense against this was that there were no sensitive APIs, cookies, or local data on the domains the flash was hosted from anyway.
Ah yeah that's a good idea. Assuming there's no reasonable way to do an iframe breakout, that is.
I suspect any way I attempted to put this together, ner-do-wells would upload a game that adds upvote/like/subscribe/logout to every event handler. Now that I think about it, I can't remember any reason why I wouldn't be able to do that from inside actionscript.. I ran javascript from inside flash all the time..
The fact those flash sites didn't just unravel from shenanigans is pretty astounding in retrospect.
The thing that would guarantee this, isn’t limiting the runtime (because you’ll always miss something, or be incapable of fully masking out something), but rather static analysis of the code to ensure it doesn’t attempt to use any of the dangerous features in the first place.
It’s very hard to static-analyze JavaScript, of course, because it’s all late bound with a reflective runtime — you can get access to anything by building the right identifiers out of strings and then subscripting using them.
WASM doesn’t have that same problem, though. It’s very easy to static-analyze bytecode-encoded WASM (as long as you don’t want “requiring modules from external URLs” to be a part of your Newgrounds-alike platform’s runtime surface.)
It’d be pretty safe to have a site that hosts arbitrary untrusted static-analyzed-subset-of-WASM.
WASM doesn’t need any sort of “static analysis” to sandbox it in this way. WASM only gets to call the functions exposed by the script that loads the WASM, so if you don’t want it to access something you can simply not bother exposing it.
There are capabilities that you can only either expose to WASM or not, because they’re simple atomic functions in Javascript land. Dereferencing external Javascript-side objects by a passed-through key, for example.
You could in theory write a “fat ISA-op emulation-shim implementation” for that WASM-side operation that has a bunch of Javascript verification code that runs every time the WASM-side op is called, at runtime (like how the Ethereum VM has fat ISA-ops that spend gas/check remaining gas in their impls.) But the resulting runtime likely won’t be performant enough to be a good host for games, if the games make heavy use of that capability, rather than just using it as a one-off boot-time thing.
Remember, we want to mostly allow arbitrary code execution here—other than direct attacks on the user or the hosting infrastructure. That probably means that we want to allow the user of the WASM to require (a pre-approved set of) Javascript-side libraries and talk to them. For example, maybe the game wants to talk to Firebase using the Firebase SDK. It should be able to do that.
But how do you allow the game’s WASM to talk to the Firebase SDK, efficiently, without allowing the game’s WASM to manipulate the objects of the Firebase SDK into giving it ACE in the host JS environment, outside its sandbox?
Static analysis. For the case of a “dereference a key of an remote object” call, just validate that:
1. The string being used as the key in the dereference op is known at compile time (i.e. the dataflow digraph terminating in the WASM “syscall” to the runtime, begins with a load from the static data section of the WASM file;
2. The static-loaded string you discover through this method, isn’t on a blacklist of ECMAScript system properties. (If you want to do something that requires one of those, there’d have to be a separate, much-more-restricted syscall for that, maybe one that does have a fat impl.)
The nice thing about this approach, is that it’s the server backend, not the players, who feel the sting of the overhead of checking the file for safety; and then, only once per uploaded program. It’s like putting the uploaded games into a moderation queue, where the “moderator” is a robot with good eyes to spot evil code.
Last time I checked, all the abilities for directly manipulating JS reference types in WASM had yet to even be deployed outside of developer trials. So there’s a much simpler solution that (a) doesn’t depend on “just” statically analyzing the binary and (b) doesn’t use features that most browsers don’t support. Just expose precisely the Firebase or whatever functionality you wish to through normal WASM imports. No overhead of checking the file for safety at all (beyond the built-in WASM validation and translation of course). And binding the functions for e.g. WebGL directly with a lookup table for passed in object values is going to perform as well as anything else that is actually supported today (and it’s what game engines that support WASM currently use).
> Last time I checked, all the abilities for directly manipulating JS reference types in WASM had yet to even be deployed outside of developer trials.
Well, yeah, which means to me that we'd never try to do this today, but rather would do this once that sort of capability exists. (Just like the people who constantly propose multitenant Workers-like hosting within Erlang. Obviously it could work once sandboxing exists within the runtime, but that's not true today.)
Note that the whole point of Firebase as a service/library—I picked this example for a reason—is to have a local live Javascript object graph whose state is synchronized over the network to a database somewhere; where you can walk it and read it and change it by doing regular Javascript things to it, as if it were a pure in-memory data structure.
If you want to expose that in WASM, you basically need to expose it by exposing Javascript object manipulation semantics to WASM. (Not with WASM holding the objects itself, but rather like any "remote/distributed object" protocol, where WASM holds a handle that references an object, and makes syscalls for dereferencing-get, dereferencing-set, etc., passing that handle.) Without this, what you're exposing isn't really "Firebase" per se, but just a regular database that you send some sort of graph-manipulation queries to.
And this is just one example among many of the sorts of arcane Javascript things where, if the hosting platform didn't allow them, then devs would find the hosting platform worthless and never engage with it.
This is the whole point of the GGP poster's post. They weren't talking about sandboxing NaCl/ZeroVM-like "the code runs in a sealed ABI abstraction that only exposes the syscalls necessary to read the keyboard/mouse and draw to the screen" games. You can easily do that. It's been done. Developers didn't engage in any meaningful way—nothing like the takeup of Newgrounds.
(Heck, it's downright simple to do one of these services yourself: pick an old game console with an HTML5 emulator implementation, e.g. one of the ones used on https://archive.org/details/internetarcade, as your abstract-machine runtime. Games, then, are arbitrary homebrew ROMs. Let people upload them; give them a customizable page that embeds them; wrap it in a trailer + payment-wall page ala itch.io if you like. Do fingerprint analysis to reject commercial ROMs. Done. This service could be built for a hackathon. Would anyone care to develop novel games for it? Pretty doubtful.)
Instead, what the GGP was talking about sandboxing, is almost-but-not-quite arbitrary Turing machines. Because that's what the Flash games/apps posted to Newgrounds really were, and moreover what the modern track-every-click special-gatcha-for-the-thousandth-player-of-the-day variety always are. They use every capability a computer has, such that "sandboxing" in the sense of removing those capabilities doesn't make sense. You can't restrict what capabilities such programs have access to, without just denying the entire design the software is based around. You can only constrain how the game uses those capabilities.
To put that another way: an SMTP server that doesn't let you send mail to certain large email hosting providers is effectively useless. But an SMTP server that doesn't let outgoing messages contain certain words (i.e. has an outbound spam filter) is quite useful. Restricting the what will just turn people away. Restricting the how has no such problem, since certain patterns of data-flow have no other use than to be nefarious.
(If you're curious why I'm even talking about WASM at all, then, if I'm not proposing to take advantage of any of the sandboxing WASM offers: it's just because it's much easier to do your static analysis against a symbolic-execution implementation of bytecode VM for a bytecode ISA like WASM; than it is to do symbolic-execution of an interpreted language with complex syntax, like JS. But if you were willing to go down that route, you could totally static-analyze regular JS. Same safety guarantees, plus now the devs get to use regular JS and/or anything that interfaces with it—including the JS-subset textual form of WASM.)
If you want the ability to manipulate a serializable JavaScript object graph without escapes static analysis is still overkill: a simple wrapper that only allows accessing enumerable own properties in the desired object tree works fine and seems a lot easier to get right, without blacklisting a lot of commonly used words in the JS API to avoid escapes.
I’m really struggling to understand how making a sandboxed environment more “engaging” in a way that makes it more similar to Newgrounds-era flash that depends on this kind of thing at all. Newgrounds didn’t let you store data on their servers or anything. I suspect at the end of the day Flash had a good set of capabilities and a great authoring tool for making small games and animations, and there wasn’t anything more to it than that. I don’t remember any (non-malevolent) Newgrounds content that did anything more sophisticated with browser APIs than save stuff on local storage.
Oh God. I can't read HN comments on Apple anymore. It's mostly just two sides throwing well polished turds on each other. Of course it is better than throwing shit like on other sites but the end result is the same.
Way before this letter, many developers including myself asked Macromedia / Adobe to rather pushing Flash as web browser plugin on mobile, focus on apps with embedded runtime. They realized it too late with AIR framework, but it was too little too late.
It was a flaw with the vision Adobe had with Flash, and they missed an opportunity being leader in mobile development.
Now Apple is kind of doing same for web, they've quietly removed that letter, as it now conflicts with what they preached in past.
Conspiracy or not, can we all at least agree that the open web is still a wonderful thing for all involved?
As developers and technical leaders, it is incumbent upon us to ensure this ecosystem remains sound. The mobile business wants html5 dead yesterday because they can't be the middle man on access.
When someone comes to your desk with a new app idea, maybe steer them towards a website instead of native walled garden apps. Many businesses do not require the capabilities offered by native applications.
Can't wait for the day the DOM will run smoothly on any smartphone. I don't know a lot about webassembly, but I wish browsers are studying the possibility of letting WASM access the DOM.
Or at least, write some js lib that lets WASM have access to the DOM in some JS calls.
not a big deal. random page floating on a site that is clearly a main marketing vehicle. Not to mention Apple's increasing trajectory into being a media/services company and some of the text/concepts discussed in that post are a bit too 'open' for their liking these days.
Will always be available somewhere in an archive/wayback
Or Apple is backtracking because they want people to use their app store, not write HTML apps as the original said. Apple has done much to hamper PWA / webapps on iOS.
Setting aside the absurdity of the claim that Apple deleting a very famous web page could ever stop it from existing, you actually have no evidence that it was deleted from anywhere—only that it is no longer being served at its prior location.
That doesn’t seem plausible at all since the deletion of this page will direct more attention at this topic than just keeping it up.
I’m completely certain that there is some completely harmless explanation to this and I wouldn’t read anything at all into this (except that this post is very old and not a part of their website where they pay excessive attention as to whether old stuff is still up).
> That doesn’t seem plausible at all since the deletion of this page will direct more attention at this topic than just keeping it up.
You make the bold assumption managers are aware of the Streisand effect when they're about to trigger it. So far reality has shown even management in IT companies falls for this every time.
Apple is the origin of the modern mobile web. And you can publish a web app on the App Store if you want, and many do that. The rest is very much a matter of philosophy and design that goes well beyond "Apple wants to push the App Store".
The reason why Thoughts on Flash was removed is that... Flash literally doesn't exist anymore. It's not like the text is not preserved historically all over the web. I have a PDF of it even somewhere on my drive.
> The reason why Thoughts on Flash was removed is that... Flash literally doesn't exist anymore.
Please explain how that alone is a reason to make the richest corporation on the planet go through their whole online presence and remove a few kB of redundant text.
Nobody does that just because it's not needed anymore, it's more expensive to pay an employee for deleting this than just keeping it up for another decade. It's very obvious Apple wants to hide the fact Steve Jobs would disagree with their current way of doing things and fell for the Streisand effect as everyone does.
I don't think Steve Jobs would disagree with the current Apple way of doing things. My understanding of the guy is not that he was a strong ideologist.
I agree that this was a deliberate political move from Apple, but I call survivorship bias on the 'everyone falls for the Streisand effect'. Consider that you only hear about the ones the do get caught.
> Please explain how that alone is a reason to make the richest corporation on the planet go through their whole online presence and remove a few kB of redundant text.
Yes you're right. Only small companies can delete a page.
In the essay [0], Jobs suggested mobile app development on should focus on HTML5 (which is now called Progressive Web Apps / PWA)
Apple has has been recently been rolling out anti-PWA practices [1].
Probably to reinforce their "walled garden".
[0]: https://web.archive.org/web/20170615060422/https://www.apple...
[1]: https://ionicframework.com/blog/is-apple-trying-to-kill-pwas...