Archive for September 18, 2020

Friday, September 18, 2020

Safari 14

Juli Clover:

Safari 14 brings improved performance, customizable start pages, a Privacy Report to see which cross-site trackers are being blocked, and a new tab bar design that provides tab previews so you can see what you have open at a glance. Today’s update also removes Adobe Flash.

I’m seeing a bug [Update (2020-09-19): fix] that affects sending the selected text to a system service or Quick Action.

Simo Ahava:

For the first time, WebKit’s tracking prevention measures are exposed to the user (beyond enabling the Intelligent Tracking Prevention debug mode).

[…]

The Privacy Report means, quite simply, that WebKit’s global tracking protections, such as truncating all cross-site referrers and blocking all cookie access in third-party context have been applied to all the cross-site HTTP requests sent from the site, including but not limited to those shown in the Privacy Report.

The purpose of this approach is without a doubt to just show how the biggest trackers on the web have been prevented from cross-site tracking, but the measures are not limited to just these domains. Nor are WebKit’s ITP measures applied to these domains automatically (I repeat: WebKit does not use blocklists - it classifies domains algorithmically).

Jeff Johnson:

The Safari 14 release notes didn’t mention an important new feature: support for web extensions. Probably because there aren’t any Safari web extensions yet! But support is indeed there for web extensions in Safari 14 for Catalina and Mojave. Previous versions of Safari already had support for Apple-specific app extensions, such as my own StopTheMadness, but Safari 14 also supports the cross-platform WebExtensions API used by Firefox and Google Chrome. Unfortunately, that support is not complete. Ever since the Big Sur beta was released at WWDC in June, I’ve been working on a brand new Safari web extension that I’m really excited about, and I think you will be too. I would love to release it now that Safari 14 is publicly available, but I can’t, because I found a bug in Safari’s web extension support that’s a showstopper for my extension. In short, the bug is that run_at document_start is not reliable in Safari.

Update (2020-09-28): Lloyd Chambers:

Some websites that used to work fine, e.g., Chase.com are drawn with a blank area, a refresh is required.

Save Image As... is not working at all. I get a rainbow beachball, then nothing.

Update (2020-12-08): Mr. Macintosh (MacRumors):

Apple has just released a Mojave Supplemental Update that address all the problems that the previous Safari 14.0 and 2020-005 Security Updates! This news comes one day after Apple pulled both software updates from the software update catalog.

The State of SwiftUI

Peter Steinberger (tweet, 2, Hacker News):

Since then, there have been many betas, and we’re nearing the end of the cycle, with the [Big Sur] GM expected in October. So it’s time to look at Fruta again. And indeed, the SwiftUI team did a great job fixing the various issues: The toolbar is pretty reliable, the sidebar no longer jumps out, multiple windows works… however, views are still sometimes misaligned, and it’s still fairly easy to make it crash on both macOS (FB8682269) and iOS 14b8 (FB8682290).

[…]

Most SwiftUI crashes are a result of either a diffing issue in AttributeGraph, or a bug with one of the bindings to the platform controls (AppKit or UIKit). Whenever you see AG::Graph in the stack trace, that’s SwiftUI’s AttributeGraph (written in C++), which takes over representing the view hierarchy and diffing. […] Googling for this error reveals that there are a lot of similar problems.

[…]

This isn’t unique to Fruta. I’ve been taking a look at @Dimillian’s RedditOS app, which is built with SwiftUI on macOS. He stopped development because it’s so slow that it’s not shippable.

This is sad because stability and speed are supposed to be the selling points of Swift.

Frank Reiff:

On the Mac, Swift UI is so far away from being practical that Apple might well have moved on to the next technology before it is.

Mac apps need to be backwards compatible for at least 5 years, so if Swift UI is ready in 2022, it can’t be used until 2027.

It will be really interesting to see what happens with companies like Omni Group who try to go all-in on SwiftUI. On the Mac side, it just doesn’t make sense to me at this point, both because of the limitations with first responder and more advanced controls and because of the potential bugs and performance issues. Making the easy stuff even easier doesn’t seem worth possibly painting yourself into a corner. Also, roughly 1/3 of my customers can’t run SwiftUI apps at all.

Nathan Lawrence:

I wouldn’t use Fruta as a model for SwiftUI, even though Apple does.

It’s not well structured, it has huge bugs, cruft from different approaches to certain problems that got abandoned months ago…it’s not an illustration of the framework or its inner mechanics at their best.

I think what you learn when you build with SwiftUI at any kind of magnitude is that you’re a little on your own. Many approaches that experts or instructors (including at friggin Stanford University!) offer are just plain nonfunctional or inefficient.

This is not because SwiftUI is broken — there are some decisions I disagree with, sure, and often those decisions can be a big enough problem the require some workarounds or extra coding of your own - but because it’s poorly documented and explained. It is evolving so fast.

Roshan Choxi:

For frontend designers and developers trying to deal with building UI that runs across dozens of devices, the goal of “write once, run anywhere” has been the panacea of UI development. If anyone had the motivation, talent, and platform control to achieve this goal it would be Apple. And I believe they have been largely successful with SwiftUI.

[…]

As great as SwiftUI does at universal UI code, it demonstrates that there is still a large amount of code that needs to be specific to the device because of the spectrum of different sizes, inputs, accessories, and hardware performance of different devices.

Steve Troughton-Smith:

As a situational tool, SwiftUI is awesome. There’s no way I’d trust it to build an app directly, it’s nowhere near reliable enough for that, but it’s great for providing the content views for your UIKit view controllers and reducing so much manual layout code or storyboard work

Damien Petrilli:

My favorite SwiftUI bugs: when it crashes internally without knowing which line of code is involved so you have to troubleshoot, line by line, without any clue.

Samuel Coe:

I can’t bring myself to release this horribly buggy experience to users (thanks SwiftUI).

My faith that Apple fixes this is low and I’m feeling really let down that these keyboard-avoidance issues weren’t fixed in Beta.

This is a big lesson learned for me.

Previously:

Update (2020-09-28): Michael Buckley:

I feel pretty bad about all the time I spent trying to make SwiftUI work at Panic. The idea behind it is great, the actual design has some issues, but the implementation has been a nightmare to work with compared to AppKit or UIKit.

Steve Troughton-Smith:

My determination last year was that SwiftUI was a fantastic tool if used as a replacement for Interface Builder; spending a lot more time with it this year I think that’s just as true today. Takes about the same amount of time to lay out a UI, but SwiftUI leaves you with code

Code is great because you can refactor it. Localize it. Switch container types by renaming them. Copy/paste properties between views. Extract previously-static metrics to properties and tweak them dynamically layout-wide. Use ifs and ifdefs for conditional views & layout

Even if you’re wrapping UIKit (/AppKit), and don’t trust SwiftUI for actual app logic (I definitely don’t), I feel like moving from nibs & storyboards to SwiftUI should be high on your priority list. I’m genuinely surprised there isn’t a SwiftUI replacement for launch storyboards

Previously:

Apple Says Epic Is “Saboteur, Not a Martyr”

Tina Davis (Slashdot, 9to5Mac):

In an overnight filing, Apple said “Epic started a fire, and poured gasoline on it, and now asks this court for emergency assistance in putting it out.” Epic can fix the problem “by simply adhering to the contractual terms that have profitably governed its relationship with Apple for years.”

How can they do that when Apple terminated their account said “we will deny your reapplication to the Apple Developer Program for at least a year”?

Apple told the court that removing the game from its store wasn’t anticompetitive because Epic’s players can use other mobile devices or PCs, laptops, or gaming consoles. “Only a fraction of Epic’s customers access Fortnite using an iPhone, and Epic’s revenues from other platforms greatly exceed its revenues from iPhone players,” Apple said.

Florian Mueller:

The numbers that Apple’s opposition brief provides speak a clear language:

“Apple has taken this approach thousands of times with other developers and their affiliates.”

[...]

“Apple has terminated over 75,000 unique accounts for introducing new features without going through App Review; over 2,000 accounts for introducing a non-IAP payment method; and over 60,000 accounts for introducing hidden features or obfuscating code (for example, by installing executable code).”

[...]

“Apple does not wait to be fooled a second time before terminating an affiliate for the bad deeds of its principals.”

So it’s not just that the language of Apple’s contracts allow such termination; it’s routinely done.

Florian Mueller:

Apple’s filing furthermore explains that Unreal Engine is not the market leader--Unity is. While Unreal Engine is, according to Apple, “used by a minuscule fraction of iPhone apps,” Unity (which my app development company uses as well) “characterizes itself as ‘the world’s leading platform for creating and operating interactive, real-time 3D content,’ and is available for ‘more than 20 platforms, including Windows, Mac, iOS, Android, PlayStation, Xbox, Nintendo Switch, and the leading augmented and virtual reality platforms, among others.’” Apple goes on to say that “Unity is used by the overwhelming majority of Apple developers that use a graphics engine.”

M.G. Siegler:

I don’t think that Apple, while they might be explicitly following the letter of what Jobs said back then, I don’t think they’re following the intents of what was implied by what he was saying. If you go back and read those quotes, I think he’s basically saying, look, we’re launching this new in-app purchase service because we’re trying to make the best user experience for people to be able to transact within our apps and on our devices. And we think that we can create a better experience for those users using what at the time was the iTunes Rails to be able to pay for these subscription services, and now it’s obviously all run through the App Store. And if you feel like, if you’re a service that brings in your own users a different way and you can do that, that’s great, you get to keep all of that money. And if they choose to use our Rails to do it, then we’ll take that 30% cut.

And we can talk about the 30% cut itself in a second, but I just think that Apple has deviated from that mentality and now it’s all just like, how do we make sure that we are getting that 30% cut and they are signing up are via our mechanism. So it feels like they’re not so much competing on having the best experience or product necessarily anymore. They’re competing on obfuscation and trying to make it confusing and/or just like impossible to sign up.

[…]

I think that they should get a lot more granular in terms of how they support those types of businesses and recognize that not every type of business necessarily should be taking a 30% cut of their revenue out of, and I know that they’ve changed it slightly over the years. They have the 30% finder’s fee that again morphs into a 15% thing in year two and whatnot. But some of that was just because of back-end deals that they cut with some of the other bigger players like Amazon, and then they felt like probably some level of hypocrisy if they didn’t offer it to everyone, but there’s still a lot of hypocrisy going on behind the scenes.

Bobby Allyn (via Hacker News):

“It’s not just Epic being exploited by Apple, but it’s every developer who goes along with that scheme colluding with Apple and Google to further their monopoly,” Sweeney said in the interview. “These stores are making a lot more money from creative works than the creators.”

[…]

A 30% fee on new technologies in the future, Sweeney says, can stifle innovation. And more than that, “it’s going to be one of the worst dystopias you can imagine from the science fiction literature with a few corporations controlling not just digital items and games but everything,” he said.

The Fortnite Team:

Apple is preventing Epic from signing games and patches for distribution on Mac, which ends our ability to develop and offer Fortnite: Save the World for the platform. Specifically, our upcoming v14.20 release will cause bugs for players on v13.40, resulting in a very poor experience. Since we are no longer able to sign updates and release fixes for these issues, beginning September 23, 2020, Fortnite: Save the World will no longer be playable on macOS.

We are issuing a refund for all players who purchased any Save the World Founder’s or Starter Packs (including Upgrades) and played Save the World on macOS between September 17, 2019 and September 17, 2020. Additionally, any purchased V-Bucks spent on Llamas on macOS in this period will also be refunded.

Current Mac versions of Fortnite are signed with the Epic Games International certificate, which hasn’t been revoked. That account is otherwise used for Unreal Engine and related sample apps. In theory, Epic could sign new Fortnite builds with this certificate, but Apple would see that as trying to get around the termination of the main Epic account and perhaps endanger Unreal Engine.

Previously:

Copyright © 2000–2024 Michael Tsai.