Apple's been taking a number of steps over the last few months to show that they take Safari/WebKit development seriously. This is another positive step in the right direction. While I never agreed with the nonsensical "Safari is the New IE" meme that was going around, I did fear that Apple's tendency to develop things in a vacuum would continue to harm WebKit relative to Blink, Gecko, etc. But all signs are pointing to good things to come. Perhaps Apple's major open source initiative in the area of Swift language and the Swift ecosystem is also benefiting their approach to WebKit now as well.
>IE executed a "developer preview" strategy leading up to IE9 6 years ago. I should know, I was a PM on that team.
That (Safari adopting "developer previews" now) doesn't mean much regarding whether Safari is the new IE. When people say that phrase they don't mean their both trying (or having tried) developer previews. They mean whether Safari is as backwards and holding the web back as IE6 was for ages.
Which is not. IE9 was years behind Safari at the time you talk about (6 years ago) --and really first version of IE that started to really compete at all for the modern web--, while Safari was, and still is (the preview) at the top of the heap regarding ES6 compliance, etc.
And while much smaller in userbase, Safari grew along with the modern web, introducing major new features that IE hasn't done since 2000 or so (Canvas, CSS animations, etc), being the basis for Chrome, and getting the JIT treatment right along the 2 other modern browsers (Chrome, FF).
As for the mobile space, Safari has been lagging in some features (compared to desktop browsers), but was always ahead of the pack in lots of areas, to the point one cannot say mobile Chrome is that better. In fact, maybe the opposite:
>Safari is holding back the mobile web the exact same way IE held back the desktop web for the exact same reason: native apps.
That's a classic tinfoil theory, but with absolutely no substance.
First, Apple sells hardware, first and foremost, not apps (it's the inverse with Microsoft). Their app store profits are negligible compared to all else.
Second, Apple has consistently made the best mobile web browser for many years -- Android had the horrible crippled Android Browser which was not even competing, before Chrome became competitive there.
That's not what you do when you want to cripple mobile apps -- which few users care about anyway, the money (for developers) and the convenience (for users) are at native apps.
Do you see "mobile apps" thriving in Android or MS Phone compared to native apps? Because I do not.
>Lol? I know very few (none?) web developers who uses Safari as their primary target browser. ES6 support or not.
What Lol? Safari's engine is what Chrome has been based on, and for most of its life it has been one and the same codebase.
Developers just don't prefer Safari's developer tools compared to Chrome's -- and of course Chrome is more popular (and cross platform), so it makes sense to use what most users use. Back in the day all developers used FF and its dev tools too, for similar reasons.
If you think that consumers are purchasing iPhones so that they can rock out on Safari and Mail, you are mistaken. A year ago over the App Store hit 100B cumulative app downloads:
Native apps drive hardware purchase decisions for consumers. That's the lesson of Windows Phone.
> Safari's engine is what Chrome has been based on, and for most of its life it has been one and the same codebase.
You misunderstand how a browser is constructed. Browsers are much more than just a rendering engine like Webkit. Chrome and Safari have different JavaScript engines, support different web standards (no WebRTC for Safari!) and are architected in completely different ways. You might find this a helpful place to start:
What does "Primary target browser" even mean? Many (me included) prefer Chrome as a dev browser because the dev tools are better and many extensions are only available for chrome (react dev tools etc.). But at the end of the day, you need to support Safari (which usually isn't a problem).
Off topic tip: I've had success with the Safari dev tools on some issues that I couldn't debug on chrome. Sometimes it's worth trying both.
Despite the similar name, Safari Technology Preview is a very different product concept from the old IE9 Developer Previews. It's not a series of one-shot early betas, but rather a live evergreen view onto coming developments.
In that respect, it's much more like Chrome's Dev Channel or Canary, or Firefox's Developer Edition, then like these old preview builds.
Their time to fix bugs and regressions in iOS is 3 months!
Edit: Again, I write a very unpopular opinion. Yet there are hundreds of regressions that have bit developers. Some of those bugs require workarounds that would be otherwise unnecessary on any normal environment with rapid updates - like Chrome or Firefox. That increases developer effort, and there have been cases that Apple have entirely missed their update and so folks wait for 6 or more months for a fix!
People can be unhappy with my comment (the score is bouncing up and down like a yo-yo!), I really don't care - but having been one of quite a few website maintainers that have had to work around Apple's bugs, it's very frustrating for both the end user and the developer.
Downvoter here: I downvoted early on because you're making an argument that seems to me both not particularly good and off-topic to the post you replied to.
OP posited: “Apple's been taking a number of steps over the last few months to show that they take Safari/WebKit development seriously. This is another positive step in the right direction.”
You basically responded, “They're still not as good as I want them to be!” It's a point that has nothing to do with the original comment, which was about improvement, not perfection, and about how seriously they take Safari/Webkit development, not about their release process (which remains roughly the same as it has been for the past many years).
Additionally, regarding the workarounds you mention: they are unnecessary in a “normal environment with rapid updates” only when those developers decide to fix your bug. Again: rapid updates are only useful if your bug is being addressed. I've got workarounds in my code for issues in Firefox that probably won't be fixed anytime soon, and features that Firefox and Chrome support poorly that they won't support well for a while, etc, etc.
I'm not saying Apple couldn't be releasing bug fixes for Safari on any platform faster—they certainly could. But you made an unrelated complaint as a reply to a specific comment, and your argument seems suspect to boot.
The problem isn't necessarily Apple's laziness with updating Safari, I think it's more the fact that they insist on using their own JavaScript engine. They could very easily just use Blink and V8 which would significantly cut down the maintenance work in keeping Safari up to date as well as leveraging the work already done rather than trying to reinvent the wheel to nobody's benefit.
For example most ES2015 features have been available in Chrome, Edge and Firefox for over 6 months now, but Safari still doesn't support any of it (other than this tech preview) because it's development time is shared with the rest of Apple's ecosystem.
Unless Apple dedicates more resources to Safari in order to keep pace with the rest of the browsers, they'll be playing catch-up ad infinitum.
You realize that although WebKit supports 98%, Safari itself as of version 9 supports 53%. As is noted in your own link to the compatibility table. So, yes, keeping pace is a problem for Apple, since the other browsers are significantly ahead and the Safari 9 series was released half a year ago. Even Microsoft Edge has been doing better.
You might actually have a leg to stand on when Safari 9.1, released 10 days ago, gets its ES6 state tested and uploaded to the compatibility table. Or it might be more embarrassment about Apple's slow release cycle. It's also unclear as to whether Safari Tech Preview will contain the majority of ES6 code in Webkit or if it will be "curated" into a significantly less compliant and useful state. Once again, tests will tell. What is certain for now is that six months of Safari have left it at 53%, which, among many other examples, has been Safari dragging everyone else down.
Just because they have untested, unsupported code in a development branch doesn't mean that their main browser with a completely different name and a glacial release cycle gets a pass for holding up the class. The Tech Preview is a good starting step, but until these things have a clear release cycle that shows current WebKit ES6 feature support making its way into a release build before the end of the year, we'll continue to be upset at them with cause.
It's also unclear as to whether Safari Tech Preview will contain the majority of ES6 code in Webkit or if it will be "curated" into a significantly less compliant and useful state.
Apple has been clear from the moment they released Safari Technology Preview:
Get a preview of the latest advances in Safari web technologies, including HTML, JavaScript, and CSS. Safari Technology Preview includes the most recent version of WebKit, the rendering engine that powers Safari.
The most recent version of WebKit does not automatically mean that it's a scheduled build directly based off of their development branch. I agree that's the most reasonable way to do it, and it's what it implies. And it's easy to assume that's what they're doing. But they could just as easily be putting this in an intermediate tech preview branch and pulling individual commits.
The phrase "most recent version" could mean pulling from a dev branch, using the last successful build, pulling from a release branch, pulling from a testing branch, assigning arbitrary numbers and tags to commits and pulling from there, or even working from a staging repo where they cherrypick commits. These are all separate sources that could hve their own version series, and "most recent version" is a very relative statement. Anyone who's seen the divide between development and sales knows that phrase has enough wiggle room to fit a Challenger disaster inside, and marketing is Apple's specialty.
I really hope they start to pull the changes from WebKit. Safari sorely needs it. But Apple's not the kind of company you just take at their word unless it's independently verified. I get it if you want to believe. That's sweet. But I'd rather wait for the tests.
Even then, monthly builds are still not a public release schedule for Safari. It was six months with only minor fixes between 9.0 and 9.1. We're far more interested in a public stable release with usable ES6 support than builds with unstable features that won't be usable on sites this year. If preview builds were what would solve the problem, then the WebKit Nightlies would have been enough.
The JS engine is not the only reason for Safari/WebKit's superior battery life but it's definitely one contributing factor.
When loading webpages, one of the most important factors to saving power is reaching an idle state as quickly as possible. For many pages, that requires being fast at executing JS that runs only once or only a few times. Safari dominates on this, thanks to WebKit and JavaScriptCore. You can see this on JSBench, which runs JS modeled on real page loads and interactions: http://plg.uwaterloo.ca/~dynjs/jsbench/
I applaud Chrome's recent work on battery life. But I think it would be fair to say that safari is still the best in this area. And also that our excellent results have inspired Chrome and others to do better, much as in an earlier era Chrome inspired other browsers to get more serious about JS performance.
But given most JS code in the real-world is mostly dominated by DOM performance, and not JS engine performance. Certainly JSC's llint gives it a substantial benefit over V8 on cold code, but I'd be surprised if it accounted for even the majority of the battery life gain. I'm not questioning Safari's lead here, just how it's so much better. (I think the lead is clear, with perhaps only Edge getting close, but that's hard to compare.)
Like I said, the JS engine is likely not the main factor. But it does make a difference. I don't have a detailed breakdown to share but we do measure these things. :-) The prior poster was wrong to imply it's all down to the JS engine, but swapping WebKit for Blink would very likely hurt our battery life.
Windows itself has worse battery life than OS X on identical hardware, so it's hard to compare Mac browsers to Windows browsers. Safari on OS X is the best laptop browsing power efficiency you can get, and likely the best battery life barring laptops with super huge batteries.
Except the reason Blink forked from WebKit was all the Apple-specific code they could drop. Apple really focuses on hardware integration and getting maximum battery life out of their engine. I can't say the same about Chrome yet.
I don't care how much I've been downvoted, especially by someone who contributes their own comments so infrequently to HN, but it's funny how you only now decided to make a comment.
I personally feel that Apple are still not as good as not only I want them to be, but pretty much anyone who uses or develops for iOS. But yes, you categorize my comments and opinions well - Apple are indeed not very responsive, and yes Apple need to do a hell of a lot better. As I say, the votes are bouncing up and down, so I'm not the only one who has holds this opinion.
And no, it's not off-topic. As an end user, I now have to incorporate workarounds that no normal user should have to make to get around their issues - I'm literally running Charles proxy (until iOS 9.3 fixed their issue) and a rewrite rule to get around their ridiculous bug. And I had to run it for 3 months. Firefox and Chrome has an issue like this one fixed within their next cycle - in other words, in no time at all.
All of which means I'm not afraid, ashamed or worried about downvotes from folks like yourself. I've not said anything offensive, sexist, racist or even all that terribly controversial. You've finally come out of the woodwork to make your comment, which I appreciate. If only you had made it sooner, eh?
OK, and what about those who tell me that I'm off topic when I'm not? Or those who don't look at my wider point and accuse me of bad faith comments?
My only comment was that my score was going up and down like a yo-yo, and only because I was being accused of making off-topic comments. That's pretty tedious, no? Surely that's against HN guidelines?
IMHO, until they decide to provide proper HTML5 support - particularly access to the getUserMedia and general WebRTC APIs - or at least allow 3rd party vendors like Google and Mozilla to do so by themselves, this is not a believable sentiment.
Media Capture and WebRTC are in development in the public WebKit repository.
These features aren't really part of HTML5 though. And while some web apps really need these features, most would not use them at all. So I'm curious why this in particular is your litmus test.
I think an even wider range of web apps will benefit from our IndexedDB revamp, Shadow DOM, ES6, fast tap, font-feature-settings, picture element, CSS Variables, and other cool stuff we shipped recently or have in the works.
what steps? Any prove?
BTW here a good example how Chrome & Safari team cannot communicate and everyone of them implements their own HTML standards. Here gesture support (pinch and zoom, trackpad) on desktops https://bugs.chromium.org/p/chromium/issues/detail?id=596689 for what reason we have W3C/WHATWG etc. ?
https://webkit.org/status is one, this very article above is an other, the much more significant than usual mid-cycle Safari 9.1 is a third. These are 3 things which happened in the last 3 months or so and are more progress than Apple had shown in the last what, 3 or 4 years at least?
Safari has quirks that you cannot experience without using Safari itself, which you still cannot run without a Mac. When you've wasted hours trying to track down one of these issues and realise it's a Safari quirk you'll understand my annoyance.
> It's not Apple's task to package it nicely for you.
I'm not sure where you get this idea from given that it contradicts the article: "Safari Technology Preview is a standalone application that can be used side-by-side with Safari or other web browsers... It’s a great way to test upcoming WebKit features and give feedback to the people building them when it’s most useful." I'm pointing out my opinion that they cannot meaningfully achieve that result without a Windows implementation.
It would be nice if they did release even a developer-focused version of Safari for Windows to help with testing for devs that prefer Windows.
However, this same problem exists outside of just web browsers. I help create native Android apps in Java. I wish every hardware manufacturer created a nice emulator for me to test the specific kinks out on their device. If Google enforced this policy, even better.
But that's not happening.
I guess the question is: should we expect / demand it to happen?
To make software that runs well on an Android device, my best bet is to have that device in my hand, just like having a Mac in hand (or one into which you can remote) is the situation today. It's not great, but it's not isolated to Apple and Safari.
Thankfully both mobile devices and browsers have services online where we can get screenshots of an app or website running on a real device or driver, without us laying out cash to buy them all.
I don't understand your comment. I was responding to the parent stating: "Apple's been taking a number of steps over the last few months to show that they take Safari/WebKit development seriously." I'm annoyed because there are Safari-specific issues that as a Windows user I cannot debug, thus my comment that I cannot take Safari seriously. Like it or not, Windows is the dominant desktop platform.
I think what the parent is getting at, is that you've got the same problem regarding IE on Mac. There are IE specific issues that I as a OS X developer cannot debug.
At least Microsoft offers free VM images for precisely this purpose. Meanwhile, OS X barely works in a VM due to the lack of graphics acceleration (plus, running such a VM on a non-Mac is illegal).
Cross-platform means you have to test on multiple machines. A company that's taking web development seriously also needs Mac, iOS, and Android devices to test on. Or borrow them every now and then, or sometimes virtual machines will work.
(I do often skip testing on Windows and iOS for hobbyist stuff since I don't normally use them, but I don't blame other people for it.)
While it was pretty bad, I remember Safari for Windows rendering text much nicer than any Windows browser (or app) at the time - particularly, the font smoothing. I recall using Win Safari to take "marketing" screenshots of an web app.
As an end user it was pretty bad (with all the libraries they were using). It mainly seemed to exist so Windows only shops could develop/test their websites on iPhones and iPads without having to own that hardware.
As iPhones and iPads became ubiquitous (as well as the popularity of Macs with developers) that didn't seem to be enough reason to keep it going.
I don't think Apple ever intended to win the browser war, I assume it was a means to an end. Maybe I'm wrong and someone was somewhat delusional. As a Mac lover who had a strong PC at the time it was quite pokey to try to use.
Yep Safari for Windows was released at WWDC 2007 (~2 weeks before the iPhone went on sale), and I'm sure part of the rationale was for Windows developers to be able to test their web sites with it.
Also note that Google Chrome wasn't released until September 2008, so there was a year+ where Safari was the most prominent WebKit-based browser on Windows.
Programmatic cut and copy to the clipboard
It’s now possible to programmatically copy and cut text in response to a user gesture with document.execCommand('copy') and document.execCommand('cut'). Having this ability may eliminate some websites’ last need for the Flash plug-in.
Unfortunately as far as I know the text selection API is still broken on mobile Safari. At least as of a few weeks ago the JS events associated with force touch seem to randomly wipe out the text selection, so even if you can now theoretically copy stuff to the clipboard it's largely irrelevant if users can't actually select text in the first place.
The basic issue we were encountering is that when selecting text via force touching and then dragging the selection, the text selection object was empty. (Though you can still hit Copy in the Safari UI.)
There wasn't any issue when selecting text via regular press or long press.
Other browsers support the execCommand API as well. Adding a new, arguably cleaner API is a separate undertaking from removing the unnecessary limitation on the older API.
Clipboard events are already supported by safari (which the page you've linked to notes) and they've got nothing to do with execCommand, they are about hooking and reacting to user-triggered clipboard operations e.g. the user pastes (via contextual menu or shortcut), the software can know about it and alter the content before it's pasted.
execCommand is about programmatically triggering clipboard events e.g. the user clicks a button in the page and the application translates that to a copy or paste event.
Did you consider removing the first sentence of your post and it would have been less smug and taunting, leaving behind something that lifts up the conversation?
I wouldn't ever enable clipboard integration -- a malicious site could use it to collect data by using the paste command with execCommand -- they'd grab whatever was on my clipboard, which could include my banking password from my password manager app that I was just getting ready to use.
Firefox only makes execCommand("paste") available in trusted contexts aka extensions. You can't execCommand("paste") on a regular web page for fairly obvious security reasons.
I guess there's room for an attack of irritation where a user with something meaningful on their clipboard unwittingly triggers having it overwritten by some nonsense. (Most clipboards effectively being a single mutable item without history or stack/queue behaviour).
Speaking of clipboard shenanigans. Could be imagining it, but I seem to remember a while ago there being something certain websites were doing where if you selected and copied text from them, the text that ended up on your clipboard would have a synthesized paragraph about copyright/attribution appended to it.
Yeah, many tech news sites used to do this. I'm not positive, but I think TechCrunch did at one point, I could be wrong though. Absolutely hate it personally!
The problem is that Webkit nightlies are absolutely not evidence of what the future version of Safari will contain, webkit is the engine but features are added and removed before it becomes Safari.
That the STP bears the "Safari" name and will be updated through MAS[0] and is featured on their developer site and has access to all the cloud features and shit from standard Safari is a much, much stronger signal as to what future version of Safari will contain.
It looks very much like an apple-official dev channel (chrome) or developer edition (firefox) for Safari, TFA even claims an update frequency about halfway between the Chrome Dev Channel (0.5/1 week) and the Firefox Developer Edition (6 weeks)
True but they are kind of a pain. This will be a proper substitute for Safari as an everyday browser. Also, this seems to point to is decoupling safari releases more and more from OS releases, and that's a good thing.
As someone who's focus is on security rather than web development, I'm in no rush to have Safari support WebRTC. Would you mind to explain why you're a fan of WebRTC?
This is what sticks in my craw about Safari: it feels like they are intentionally dragging their feet on this because it would bring the Open Web to parity with Native Mobile and their App Store. At least IE never had a built-in conflict of interest in upgrading.
There are a ton of valid security, performance, and storage related reasons not to blindly support service workers on mobile. I'm sure they can be overcome, but I guarantee Apple won't be running to support SW until they figure out how to do so with the best result for users.
As an end user, I really don't want the result of following a link to a website (or 'web app' if you must, because app all the things) to be a progressive web app that a) consumes 100s of MB of my mobile device storage, b) runs in the background draining my battery and using my limited cell data plan, and c) send who know what information to god knows where. All because I clicked on a link and hit OK on an innocuous prompt...
Some of the capabilities presumed by service workers aren't even available to native apps on iOS because of these very same issues - why would Apple grant them to random websites?
Meanwhile they're pretty good at keeping up with simpler ways of blurring the lines between web sites and native apps, with APIs like AirPlay, Picture-in-Picture when you leave the browser, Force Touch...
I've always felt the WebKit/Safari team is just understaffed. IIRC there was graph posted here a while back showing the number of contributors on the major open source browser platforms and Google has a frightening amount of developers working on Chrome.
ESnext is lagging behind though (12% to >30% for Firefox and Chrome)
On the other hand, i18n API support: http://kangax.github.io/compat-table/esintl/ not done yet, but at >90% it's way better than Safari's 50% and most of the failures seem to be accepting values it should throw errors for in i18n API.
Menu bar says "safari tech preview" and not just safari like WebKit nightly. That is big for me. Does anyone know why WebKit nightly doesn't say WebKit nightly?
The Safari Tech Preview is a full-fledged copy of Safari that bundles its own WebKit frameworks rather than using the system frameworks. As it's a separate application it can have a different name, and use an independent copy of preferences, history, bookmarks, etc. from the system version of Safari.
WebKit nightly builds run your system version of Safari with an updated version of the WebKit frameworks. This means that the application you're running is your normal version of Safari. The WebKit nightlies do some shenanigans to convince the system to do things like display a different Dock icon, for instance, but for the most part they just let Safari be Safari.
I find Safari to be the nicest browser to use in general, but Chrome seems to have a leg up on performance in key areas like new tab creation especially when opening a link in a new tab.
It's weird lapse for Safari to lag in certain situations. I hope they continue to iteratively improve the performance of the general UI and improve the general behavior of the developer tools in addition to adding these new techs.
Like you, I’m constantly zooming in or out because there is so much variation in font sizes and layouts. I wonder if Safari could be programmed to automatically adjust the zoom level of every web page, based on my preferred viewing style. Safari would need to take into account things such as preferred font size, current window size, etc.
In my case, it lags (up to two-three seconds) even if I set new tabs to about:blank. Haven't been able to find a workaround, and it occurs infrequently.
You might want to try doing a SCM reset. I was having the same issue and did an SMC and noticed that opening a new tab went back to being instantaneous (also using about:blank).
Indeed – Chrome is notably faster on my Macbook. On the desktop with a 6700K and Samsung 950 Pro SSD the difference becomes meaningless and I prefer Keychain/Reading list/iCloud to their chrome equivalents.
Also, chrome gives you a 5px^2 area of "chrome" to drag the window around which is seriously annoying.
I love that they are supporting Shadow DOMs, but until the other browsers support it, the feature is dead in the water. I mean, it's a feature that you'd build a whole app around, but if IE and Firefox don't support it, I can't really do that.
Chrome already supports the v0 Shadow DOM spec, and will soon support v1.
Edge(nee IE) and Firefox are committed to support and active in the standards discussions, and I believe allocating people to work on it, if not working on it already. Support across all the major browsers will arrive before we know it.
The Shadow DOM polyfill is a bit slow, but soon it'll only be necessary on older browsers, so some properties might be able to adopt full Shadow DOM within the year.
If you use Polymer, we have a fast Shadow DOM-like shim called Shadey DOM, and you can pretty seamlessly opt-in to full Shadow DOM where available.
fetch("...");
Promise {status: "rejected", result: "Fetch is not yet implemented"} = $1
If you use a fetch polyfill, it won't install itself because there's a native fetch. But the native fetch is only there to tell you that it's not really there.
It's great to see Apple doing this on the desktop - I wonder if they have any similar plans for Mobile Safari? I would imagine they could do something similar to the process for iOS public betas: allow users to install a cert for Safari Technology Preview, keeping them on a parallel channel of updates.
It has somewhat more restrictive CORS requirements than other browsers which not every 360 player has addressed. There's also the issue that Safari on iPhone can't play 360 videos because of the media player taking over fullscreen playback.
Already in released versions of Chrome and Firefox. It'll be nice when it's in safari, though, because then it'll actually work on mobile. It seems that Safari isn't using the same API, though.
While I'd love to use this app, there's no way to transfer your current Safari config — including extensions and the last browser session — to the Tech Preview. Copying the files doesn't work.
Sorry to be obstinate, but then I'm not going to use it. Too much hassle. If it turns out that the Tech Preview is too buggy, I can't easily migrate back.
That makes me wonder whether Safari extensions can access iCloud Tabs. If so, it'd really come in handy to be able to do things like "move all these tabs from this device to this device". I accumulate tons of tabs on my mobile devices that I'd like to move to my Mac (or vice-versa, depending on circumstance) so I could just crank through them all at once.
[Edit: A brief look makes it appear that native OS X apps can, not sure about Safari extensions. But a native app could be sufficient.]
Where is Safari in terms of security? Speed, battery usage, and standards support are one thing, but as far as I know, neither Firefox nor Safari have the robust level of sandboxing and other Chrome security features.
See news links posted below. I (and thousands other people) have been unable to use a browser normally in our mobile phones for the past week. Since Apple forces everyone to use the same underlying webkit engine, all browsers are broken. It's quite frustrating to have your 800€ device unable to perform one of it's basic duties.
That a particular website can completely break the ability to open links in all applications on all websites just by listing too many URLs in a file, with the broken state persisting even after the original website fixed the file that caused it, is definitely Safari's fault.
The news he is referring to is that many developers improperly coded their app in regards to misusing universal links. Bookings.com already fixed the issue on their end so you can simply reinstall it. Apple is also working on a fix to handle apps that haven't fixed their issue yet: http://9to5mac.com/2016/03/29/apple-ios-9-crashing-bugs-when...
OK, so users with a particular app had Safari issues, the app got patched, and Apple's planning on fixing their end of the bug per http://techcrunch.com/2016/03/28/its-not-just-you-clicking-o.... "Booking.com associates its app with all sorts of domains — too many domains to be precise. With 2.4MB worth of domain-name-to-deep-link entries, Safari and other apps crash when iOS checks links against its Universal Link database because this database is too big."
Your criticism seems doubly odd now. Should Apple pause all Safari development whenever a bug is encountered? What are you proposing?
edit: Since I can't reply:
> Any app with a link association file that had too many links can cause Safari to totally stop working.
Yes, there's apparently a bug, triggered by the rare apps that pad out the file to enormous sizes. Not sure why you felt the need to spend ten minutes updating your post with every mention of it you could find (along with unrelated stuff from 2015).
> This has been discussed to death already, you are very late to the party here.
I'm extremely sorry I missed a bit of tech news about an edge-case bug that doesn't affect me. I'll try harder in the future.
> It's totally within the realms of possibility that Apple can do more frequent bug fixes and develop new features.
OK, but from the looks of the dates on those articles, this bug has been known about for about a week. Do you always fix every reported bug in a week or less, or do they sometimes take a little while to fix and QA? iOS has a bit of a larger user footprint to consider, too. Given there's a workaround - patch the apps with bloated link associations - I'm dubious of the need to rush an update here.
edit 2:
> edit: you can reply, press the link that takes you to my direct comme t and hit reply.
There is no workaround, patching the site association file only prevents the issue for new users. Everyone else still has a non-functional browser for a week - I'd say that warrants an urgent patch.
Except they didn't. Any app with a link association file that had too many links can cause Safari to totally stop working. Try to do your research before putting words in my mouth. This has been discussed to death already, you are very late to the party here.
I also never said that Apple should pause development. Not once. It's totally within the realms of possibility that Apple can do more frequent bug fixes and develop new features. I work on LibreOffice and have back ported bug fixes frequently into old versions. If LO can do it, then so can Apple.
Your assumption of bad faith reflects badly on you, not me.
edit: you can reply, press the link that takes you to my direct comment and hit reply.
I spent the time giving you so many links because I went to Google News and typed in "Safari link crashing Apple" and literally hundreds of news sites were reporting it. It would have taken you a few moments to check this yourself. You can't complain that I've provided lots of links to the issue. Now you know.
And yes, it is Apple's problem that Safari stops working because of a bug in their link association file processing. You state that it is caused "by the rare apps that pad out the file to enormous sizes", except that is a very popular app, so popular that there were so many users that got bitten by this bug that pretty much every news site on the planet reported the issue.
So it wasn't an "edge-case" bug that only affected a few people - it seems to have affected tens or hundreds of thousands of people. Possibly millions. And yes, if there was a security issue the fix would be fine pretty quickly. But you miss the point - even nasty non-security related issues are fixed quicker than a three month time frame. Normally within a month, month and a half. And we maintain at least two versions of LO, unlike Apple who only maintain one version of their OS at any point in time.
As for you putting words in my mouth, please stop doing that. Thanks.
Also: there's a chance you've been rate limited. That message indicates that. Email hn@ycombinator.com to request it be removed and have them explain why it occurred.
Edit 2: I've emailed to request your rate limit be removed - given it is as much my fault as anyone's this got do heated.
That's because it is nearly the same as WebKit Nightly but with a few things included that WebKit Nightly can't include such as iCloud sync. Apple already explained on the same page as the OP link:
> You may already be familiar with the WebKit Nightly, which serves a purpose similar to that of Safari Technology Preview. For most people, we think Safari Technology Preview is a more convenient and stable way to live on recent WebKit changes. Unlike the nightlies, Safari Technology Preview supports the full set of iCloud-based Safari features, including iCloud History and iCloud Tabs. And we’ll use the time between Safari Technology Preview releases to curate and test updates to a point where we think developers will find it practical to use as their primary browser.
It could be available as something of a public ad-hoc build, or as a sideload-able package since the iOS9 SDK added support for sideloading. OSX Safari is also built pretty deep into the OS.
So what is Apple going to do about fixing bugs in Safari in iOS quicker?
I shouldn't have to wait for 3 months for awful rendering issues that entirely prevent me from viewing important websites to be fixed!
Obviously it's unpopular to complain about Apple and their dreadful fix timeframes, but there are often thousands of affected websites and often Apple have a fix already checked in and tested. But Apple being Apple, they consider web rendering bugs to be part of their iOS update process, and not just an issue with an app so we all must wait for three months for them to roll it into a major update.
I'm seriously considering setting up a seperate website to track iOS bugs. Apple are hardly willing to be open and transparent about bugs, so perhaps it should be taken from their hands?
Are you saying this isn't a timely comment? Or relevant?
I'll keep commenting on their three month timeframe on relevant stories. I don't mind that you don't like me making the point that it's unreasonable. Especially as you agree!
Edit: I'll review my comment history:
* The comment you are responding to, I feel is relevant
Entirely relevant to that thread. It's funny watching my comment scores bounce up and down though. I'm not the only one annoyed with Apple I see, there appear to be as many people who agree with me as who are annoyed I point out Apple's Safari issues :-)
Don't assume that just because you think I'm unreasonable that I am unreasonable. My comments are downvoted and you are annoyed with my seeming unreasonableness, but plenty feel the opposite.
I don't think it's an unreasonable complaint, just that it seemed you were in a multi-day enraged frenzy with "3 FUCKIN' months" bouncing around your head :)
Then I guess you owe me an apology then, because I haven't been. It just so happens that I've been commenting on relevant stories about iOS Safari bugs.
Pretty horrid really that you assumed such bad faith. I've been commenting on plenty of stories lately, I've hardly been focussed on this one issue. And I've never used a swear word (well, I once used "bloody", but in my culture that's not a swear word).
