New WebKit Features in Safari 13.1
webkit.org
webkit.org
This is probably also why clicking on any of the buttons causes the text to vanish during the click. It's turning white, because the default for an active button is `color: activebuttontext`.
The new hint values for the soft key enter is a small but very useful addition!
I would like more information about Safari being available on Apple Watch.
Normally I'd think it's inclusion was an accident or oversight, but it's mentioned at both the top and the bottom of the article.
> The implementation is available through the navigator.clipboard API which must be called within user gesture event handlers like pointerdown or pointerup, and only works for content served in a secure context (e.g. https://). Instead of a permissions-based model for reading from the clipboard, a native UI is displayed when the page calls into the clipboard API; the clipboard can only be accessed if the user then explicitly interacts with the platform UI.
that looks pretty cool... do other browsers implementation also work like ↑ that?
https://docs.house.gov/meetings/JU/JU05/20190716/109793/HHRG...
> WebRTC for videoconferencing is not supported for third-party browsers because Safari displays a prominent UI to make sure the user knows when a website is recording using the camera and microphone. Apple does not yet have a way to make this UI work in other WebKit clients.
That's a far cry from what you're insinuating.
Safari also doesn't support service workers or the fullscreen API.
And then they are stifling competition for their app - by “forcing” you to create an app that integrates with dialer and your call history?
Maybe your startup was “impacted” by not having the expertise or funding to create a native app like at least a dozen companies have done?
Facetime is a feature that helps sell their devices. If they don't ultimately make money from it, why did they spent money to create it?
They want a robust third party ecosystem.
Integrating with the iOS dialer and phone history means not implementing something else that would provide value across platforms.
FaceTime and Messages (blue bubbles) are the only strong lock-in Apple has beyond brand effect. People don't buy iPhones over Android for Maps or Mail: they do it for the camera, FaceTime, and the blue bubbles. See the comparative market irrelevance of iPads, Macs, and other Apple products.
> And then they are stifling competition for their app - by “forcing” you to create an app that integrates with dialer and your call history?
They force developers to choose / balance resources between iOS and the web. Because the desirable users are on iOS, resources must be wasted on proprietary native apps instead of cross-platform web apps that would theoretically work on any device/OS.
They specifically want to funnel apps through the App Store, so that they can gouge developers for 30%.
> Maybe your startup was “impacted” by not having the expertise or funding to create a native app like at least a dozen companies have done?
My case isn't representative: we did have the expertise and the funding, we built the native app, we found product-market-channel-model fit, and after I stepped away, they've expanded internationally and closed a Series A this year. For us, the impact was diverting tens of thousands of dollars to Swift development. At the time we saw this as merely technical reality: we also built an Android app for performance reasons.
That was years ago. By now, there should be many competitive video conferencing web apps that work across devices, and there aren't.
At this point Apple's anti-competitiveness has become undeniable. It looks like the Justice Dept is setting up to slam them for bundling/tying Safari to iOS as they did Microsoft with IE/Windows (the ruling that popped the dot com bubble).
So you think FaceTime and “green bubbles” is the only reason that people spend more than twice as much on iPhones than Androids - even though cross platform chat/video call apps like WhatsApp and Messenger are far more popular - even on iPhones?
iPads are the only tablets that actually sell worth anything and the average selling cost of Macs are twice that of the average PC.
Also, the personal computer isn’t nearly as relevant as it use to be. Apple alone sells more iPhones than all consumer PCs combined and it only has about a 13% worldwide market share.
My case isn't representative: we did have the expertise and the funding, we built the native app, we found product-market-channel-model fit, and after I stepped away, they've expanded internationally and closed a Series A this year. For us, the impact was diverting tens of thousands of dollars to Swift
So you built an iOS app because of Safari and Apple’s evil lock in but you ended up spending money on an Android app anyway. So it was irrelevant because you couldn’t go to market with just a web app anyway....
They force developers to choose / balance resources between iOS and the web. Because the desirable users are on iOS, resources must be wasted on proprietary native apps instead of cross-platform web apps that would theoretically work on any device/OS.
But you just admitted that you had to end up building an Android app anyway because the performance of the web app was unacceptable. So even though Chrome supported the standards you needed, the crappy hardware on most Android phones made you produce an Android app.
I’m sure the desirable users only choose iPhones because of a FaceTime and “green bubbles”...
They specifically want to funnel apps through the App Store, so that they can gouge developers for 30%.
Again there is an existence proof that isn’t true. Not only does Apple not force app developers to go through their store for subscriptions - there are plenty that don’t - you can’t pay for a subscription to Zoom for instance through the App Store.
At this point Apple's anti-competitiveness has become undeniable. It looks like the Justice Dept is setting up to slam them for bundling/tying Safari to iOS as they did Microsoft with IE/Windows (the ruling that popped the dot com bubble).
There is an existence proof that you are wrong about the Justice Department “forced” Microsoft to unbundle IE and Windows. IE is still bundled with Windows over 20 years later.
For us, the impact was diverting tens of thousands of dollars to Swift development. At the time we saw this as merely technical reality: we also built an Android app for performance reasons. That was years ago. By now, there should be many competitive video conferencing web apps that work across devices, and there aren't.
Swift wasn’t introduced until 2014. Any startup that was crazy enough to use Swift then was making a very bad decision. Also the performance and hardware of the average Android phone is still crappy.
The camera, blue bubbles, and FaceTime (audio as well as video). Brand and ecosystem are secondary, UI/UX are fleeting, and there seem early indications that iPhones may become seen as "grandma's phone" like Macs in the mid '90s. Scale effects and supply chain are contingent on demand.
> WhatsApp and Messenger are far more popular
Grandma only knows how to use FaceTime.
> iPads are the only tablets that actually sell
> Also, the personal computer isn’t nearly as relevant
Agreed, iPad and Mac sales are basically irrelevant compared to iPhone, because tablets and desktops and laptops are almost niche compared to the scale of mobile worldwide. No indication that any post-mobile devices (i.e. watches, glasses, goggles) will approach the size of the smartphone market.
> So you built an iOS app because of Safari and Apple’s evil lock in but you ended up spending money on an Android app anyway. So it was irrelevant because you couldn’t go to market with just a web app anyway....
Yeah, in 2016. We were contending with iPhone 4s and the first generation of Android phones that could reasonably perform browser-based video calls and overheating handsets and draining batteries after 20+ min video surveys and no WebRTC support from Apple yet and a bunch of 3G.
I didn't start thinking about Apple's potential antitrust violations ("evil lock in") until evaluating re-entering the video chat space in 2018.
In 2020, with contemporary hardware, one shouldn't still need to download some native app in order to perform a video call.
> Again there is an existence proof that isn’t true. Not only does Apple not force
I specifically said funnel, not force. The strategy is to get developers into the sale pipeline and on the radar for competitive analysis. Zoom has considered handling payments through the App Store, but decided against it because they support multiple platforms and have the resources to build their own subscription infrastructure.
> There is an existence proof that you are wrong about the Justice Department “forced” Microsoft to unbundle IE and Windows. IE is still bundled with Windows over 20 years later.
Hah, yes—but now you can delete it!
> Swift wasn’t introduced until 2014. Any startup that was crazy enough to use Swift then was making a very bad decision. Also the performance and hardware of the average Android phone is still crappy.
I should have said "native iOS development." Swift over Objective-C felt like a good decision, we worked with strong contractors who were motivated to use newer tech, perf was good, the code was clean and didn't require much ongoing maintenance, our CTO was able to jump in later and make changes efficiently. It was just a huge distraction to need to build an iOS app, go through the App Store, etc., but we wouldn't have been able to get traction without it.
So brand and ecosystem are “fleeting”. When are you predicting that the iPhone - which has been around and profitable since 2007 will fail? Better example is the Mac, while all other non Microsoft compatible operating systems have died, the Mac has been around for 35 years.
So you think all of the cool kids are going to use crappy $300 Android phones?
Grandma only knows how to use FaceTime.
So from what I see most older people are using cheap Android phones. Unless you believe that Apple’s 13% worldwide market share is only made up of grandma. If Google can’t make a decent video app after four failed attempts, whose fault is that? I thought Google was made up of all these “smart people” (tm).
Yeah, in 2016. We were contending with iPhone 4s and the first generation of Android phones that could reasonably perform browser-based video calls and overheating handsets and draining batteries after 20+ min video surveys and no WebRTC support from Apple yet and a bunch of 3G.
By 2016, the iPhone 4s was 5 years old. But you said you were forced to make an app for Android anyway. Also, 4G was ubiquitous on even low end phones by then. But as far as performance, even today most Android phones are crappy prepaid phones sold by second rate carriers like MetroPCS and Boost Mobile.
I specifically said funnel, not force. The strategy is to get developers into the sale pipeline and on the radar for competitive analysis. Zoom has considered handling payments through the App Store, but decided against it because they support multiple platforms and have the resources to build their own subscription infrastructure.
Do you realize how easy it is to build your own subscription infrastructure? ACloudGuru is definitely not a multi-billion dollar company and they have their own subscription infrastructure that you have to use - as does LinuxAcademy (now owned by ACG)
So you mean companies want to do things to funnel companies into their sales pipeline - I’m shocked - a customer acquisition strategy? How novel.
Hah, yes—but now you can delete it!
Just like you can “delete” Safari on iOS but the underlying rendering engine is still embedded in the OS - just like IE.
It was just a huge distraction to need to build an iOS app, go through the App Store, etc., but we wouldn't have been able to get traction without it.
But it wasn’t a huge distraction to build the Android app....
I said brand and ecosystem are secondary [to critical unique hardware/software features]. UI/UX are fleeting because they're ultimately a matter of style, which come in and out with the tide, to paraphrase Jefferson.
I don't see iPhones going anywhere. There are a lot of grandmas out there.
> So you think all of the cool kids are going to use crappy $300 Android phones?
The cool kids are tooling on cheap Linux devices like PinePhones which will form the basis of less general-purpose, more app/service-focused phones produced by other kinds of (not necessarily "tech") companies, for other purposes: think industrial phones from Honeywell for $200, luxury phones from Coach included in a $395 clutch, a free Tide phone with a monthly laundry detergent subscription, to the point of calculators: coveted objects in the '70s, given away as branded giveaways at Burger King and your local credit union by the '00s. Smartphones will get there.
> So from what I see most older people are using cheap Android phones. [...] If Google can’t make a decent video app[...]
Some grandmas use FaceTime, others use Skype.
As per Duo, Google blew it and no one will ever use their video chat apps again (unless under YouTube, that's their last shot).
> By 2016, the iPhone 4s was 5 years old. But you said you were forced to make an app for Android anyway. Also, 4G was ubiquitous on even low end phones by then.
Like Skype, our product internationalized well. We were doing video surveys all over North America, as well as surprisingly random European, Asian, and Australian locations by late 2016. South America and Africa in '17.
> But as far as performance, even today most Android phones are crappy prepaid phones sold by second rate carriers like MetroPCS and Boost Mobile.
Sounds true.
> Do you realize how easy it is to build your own subscription infrastructure?
Having a subscription flow doesn't mean people use it. I'm talking more about business models than technical feats. A passable video chat service + payment flow isn't so hard in the technical sense, for us the key was aligning with a viable pricing model for our customers, which sustained our development regardless of investment, which helped secure further investment.
We built a sweet automated transaction flow, and no service providers ever used it. Instead we emailed invoices and they always got paid. But we were transactional, selling to SMB/enterprise customers. Different story with different pricing models and customer base. I haven't done consumer subscriptions: that's where it seems that Apple wrings out developers, particularly game developers. Though I can see happily giving up 30% on virtual items with no marginal cost.
> Just like you can “delete” Safari on iOS but the underlying rendering engine is still embedded in the OS - just like IE.
You can run Chromium and Gecko on Windows and Mac. You can't run Chromium or Gecko on iOS.
> But it wasn’t a huge distraction to build the Android app....
If we were only targeting North America, it would probably have been a bigger distraction to build the Android app. The problems that necessitated a native app ended up seemingly being hardware deficiencies based on cost considerations. Booking rate for services after successful survey ended up being substantially lower in North America among Android app users, yet it was very high among Android users with devices capable of running the web app, which had motivated us to build the native app to support more Android users in the first place. Didn't really pan out on this continent.
Critical in Europe and Asia though.
I've stepped away but AFAIK they're still using it. It was expensive but worked with our business model ($20 for a successfully completed self-service video call between service provider and end customer, $50 to have the virtual survey performed/recorded by our trained video surveyors around the world, $90 to also have priced).
I'd compare TokBox, Twilio Video, and Jitsi.
The usual tools for cross-device/browser testing (e.g. BrowserStack) didn't work for video chat: we could simulate network disruptions but needed actual hardware for testing and debugging video/audio issues.
So we bought/pooled a ton of devices and had a QA team in our European office methodically test across devices and browsers.
We were also contending with provider (TokBox) issues early on in '15, which were mostly resolved by mid '16. Our business model, and pivots that focused our target market, didn't enable building out that level of infrastructure in-house, and I wouldn't recommend it if making any kind of vertical play, i.e. unless your customers are developers.
Their browser monopoly on ios can only last so long. The same strategy backfired horribly for ms in the ie6 days.
(And no, you can't install an alternate browser on ios. It's just a crippled "skinned" shell on top of safari)
> Changes in this [13.1] release of Safari were included in the following Safari Technology Preview releases: 90, 91, 92, 93, 94, 95, 96, 97, 98.
No fixes for SameSite Lax cookies under service worker routes.
No page lifecycle API so we better handle iOS PWAs.
Also, for the SameSite Lax thing, can you explain a bit more? That sounds like a bug. If you have a reproducible case, please file at bugs.webkit.org and let me know the Bug ID.
Also another bug, which is maybe related: https://rocky-fjord-97287.herokuapp.com
It solves really no problem (I mean, Python, Ruby and almost all other programming languages are doing fine without preventing against variable reassignment, and we can still reassign function parameters and object properties in JS).
So much brain power wasted on this useless thing.
Also using `const` everywhere is semantically misleading and ugly. It's not what you would expect in 99% of other programming languages out there.
- it has lexical scope instead var function scope
- it does not hoist like var
- it prevents accidental reassignment
I’ve always thought const was something of a mid feature, as it doesn’t generally do what people think. He’ll back when Opera was an actual browser engine it just used const as an alias for var.
I look at it as mostly a safety net: I'd rather use const by default, unless I have a good reason to be able to mutate the variable. (To flip it around: what problem does being mutable-by-default solve?) 9 times out of 10, I don't need to change the value for the lifecycle of the function; and often if I do, the code is cleaner anyway if I use an immutable pattern (such as `const foo = bar.map()` rather than `for(x in bar) foo.push()`). Thanks to the magic of Merkle trees, we can generally make fresh pointers without it costing much memory overhead.
const arr = ['foo'];
arr[0] = 'bar';
assert(arr[0] === 'bar'); // !!!
Something like that would make sense though IMHO:
const PHI = 1.618;
I don't get how JS is designed really, they try to solve a bad design (`var`) but they introduce another bad design (`const`) and they make things even messier. Many devs ship JavaScript thought TypeScript these days, so I hope Microsoft can clean this mess one day.
Personally, I default to const, and use it pretty much 99.9% of the time. I use `let` in the few cases where it's actually useful to have a block-scoped variable. Ironically, this probably does a better job of "communicating" intent than the ritualistic obsession with "immutability" does, simply because you know if you're deviating from the default, there is a good reason for it.
> they try to solve a bad design (`var`) but they introduce another bad design (`const`)
`let` is intended to be the actual `var` replacement, and it's okay for that. I think there's an argument that `const` is a bad design, in the sense that it's deceptive, under the not-that-uncommon case you describe. Still, I'd rather have it than not, and I personally still like defaulting to `const` and opting-in to `let` in the (rarer and rarer) event that it's needed. (I'm also on 100% TypeScript at this point, which doesn't remove the potential for problems, but does provide an extra layer of guard rails in general.)
Most of JavaScript devs do like you, they default to `const` and if they need to reassign the variable, they switch to `let`.
To me it feels more like a ceremony for declaring a variable than a rational and a useful practice. :)
https://twitter.com/dan_abramov/status/1208369896880558080 (React core team member)
https://twitter.com/littlecalculist/status/91787524189167616... (Ember creator)
performance-wise, const is also around 20% faster than var, and usually faster than let (you can test it yourself: https://jsperf.com/let-vs-var-performance/67).
Edit: I forgot (because I always just write `const` anyway), but TSLint/VScode also default to bothering you to use const if you define a let/var and never re-define it.
I can see the argument that using `const` over `let` doesn’t bring any huge benefits, but I don’t see what the harm is either. I never found it a waste of brainpower. At this point it’s idiomatic, so I think using `let` everywhere is more likely to have people confused.