Archive for November 19, 2020

Thursday, November 19, 2020

Twitter Launches Fleets

Joshua Harris and Sam Haveson:

To help people feel more comfortable, we’ve been working on a lower pressure way for people to talk about what’s happening. Today, we’re launching Fleets so everyone can easily join the conversation in a new way – with their fleeting thoughts.

Fleets are for sharing momentary thoughts – they help start conversations and only stick around for 24 hours.

How does this work with third-party clients? I can already see deleted regular tweets in Tweetbot.

Juli Clover:

Fleets have no retweets, likes, or public comments, do not show up in search or moments, and cannot be embedded on external websites.

Alec Stapp:

Oct 2013: Snapchat launches Stories
Aug 2016: Instagram copies it
Feb 2017: WhatsApp copies it
Mar 2017: Messenger copies it
Nov 2018: YouTube copies it
Sep 2020: LinkedIn copies it
Nov 2020: Twitter copies it

Update (2020-11-20): Jeff Johnson says that Twitter did an Epic-style server update to enable fleets for users without updating the Twitter app on their phones. That would seem to go against guideline 2.3.1 about not including “hidden, dormant, or undocumented features in your app.”

Update (2020-11-23): Tim Hardwick:

Twitter’s new ephemeral tweets, or “fleets,” have been hit by a bug that allows them to be accessed long after their supposed 24-hour expiration time, less than a week after the feature launched.

[…]

According to Techcrunch, the bug allowed fleets to be viewed and downloaded by other users without notifying their creator. Details of the bug were posted in a series of tweets over the weekend. Twitter soon acknowledged the issue and says a fix is on the way.

Update (2020-11-30): Kris Holt (via John Gruber):

It emerged last year that Spotify was working on a stories feature for artists. The company started a public test of stories earlier this year, when it allowed some influencers to add them to playlists. Many other major platforms have stories features, including Instagram, Snapchat, Facebook, YouTube, Twitter and even LinkedIn. It probably shouldn’t be too surprising that Spotify looks set to get in on the action too. Whether it should do so is perhaps up for debate.

Rosetta 2 Not Preinstalled

Rich Trouton:

With Apple now officially selling Apple Silicon Macs, there’s a design decision which Apple made with macOS Big Sur that may affect various Mac environments:

At this time, macOS Big Sur does not install Rosetta 2 by default on Apple Silicon Macs.

I don’t understand what the benefit of this is. Big Sur already includes the Intel versions of all the system frameworks. Why not include the much smaller Rosetta translator, too? Just to shame them?

I think with the Intel transition, Rosetta was preinstalled until Snow Leopard.

Previously:

Update (2020-12-08): Xcode 12.3 RC Release Notes (via Jeff Johnson):

The first time you launch Xcode on a Mac with Apple silicon without Rosetta installed, Xcode prompts you to install Rosetta. The prompt prevents any interaction, and blocks Xcode from launching. (70853975) (FB8848625)

Workaround: Launch an x86_64 process to trigger the system’s Rosetta prompt.

Armin Briegel:

When a user opens an application that requires Rosetta for the first time, before Rosetta is installed, the system prompts to install. The same thing can happen with an installer package. The system might prompt to install Rosetta before a certain package is installed. However, not all packages trigger the dialog. I was curious what is required in the package to trigger or to avoid the prompt.

[…]

The confusing part here is that both component pkgs and distribution pkgs have the same file extension. They are hard to distinguish even from the command line. To tell them apart, you can expand a pkg with the pkgutil command and look at the files in the expanded folder. Component pkgs have (among other files) a PackageInfo file and distribution pkgs have a Distribution file[…]

[…]

When a distribution pkg has this attribute and it contains a value of arm64 then the installation process on an Apple silicon Mac will not check if Rosetta is installed. When arm64 is missing from the hostArchitectures, or the attribute or tag are missing entirely, the installation process on an Apple silicon Mac will assume the pkg requires Rosetta and prompt to install when necessary.

Be careful using productbuild on Catalina.

Update (2021-03-14): Joe Rossignol:

Installing the upcoming macOS 11.3 software update on an M1 Mac may result in Rosetta 2 being removed in one or more regions around the world.

[…]

It’s unclear why macOS 11.3 might remove Rosetta 2 on M1 Macs in some regions, but perhaps there are legal or copyright reasons involved.

Tricertops:

M1 Pro Tip: Duplicate Terminal​.app, change its App ID in Info.plist, change icon, enable Run using Rosetta.

iPhone and iPad Apps in the Mac App Store

Federico Viticci:

Here are more details on how iPhone and iPad apps will be installed on M1 Macs:

  • Managed by the Mac App Store
  • Toggle in search
  • ‘Designed for iPhone/iPad’ badge
  • Included in "curated selections"

Steve Troughton-Smith:

With everything in macOS 11, it’s getting harder to define what Catalyst is. There are 3 forms:

  • Unmodified iOS apps (Apple Silicon-only)
  • Traditional Catalyst apps (more Mac like, but blurry scaling)
  • Optimized for Mac/Mac Idiom Catalyst apps (pixel perfect, Mac controls)

Steve Troughton-Smith:

Another component in Apple’s unified app platform is SwiftUI, which is a bit messier to explain. There are several forms:

  • A SwiftUI multiplatform app
  • SwiftUI inside AppKit app
  • SwiftUI inside Catalyst (more iOS-y)
  • SwiftUI inside Mac-idiom Catalyst (more Mac-like)

Steve Troughton-Smith:

I think a lot of people overemphasize the fact that you need to do a lot of work and recreate system behaviors in a Catalyst app if you want a great Mac app — you need to do the exact same things if you want a great AppKit Mac app, too, as you can see

Colin Cornaby:

I’m still not a big fan of Catalyst, but I’m even more bummed that a lot of developers seem to be deciding to skip Catalyst and just ship bare iOS apps on Apple Silicon. Even if you’re just targeting new Apple Silicon Macs, this is not the way.

Marco Arment:

Never have I earned so much good press for doing absolutely nothing.

Coming to previous Macs via Catalyst is a longer-term goal that, unfortunately, I don’t have time to complete yet.

John Gruber:

MacOS 11 “Big Sur” introduces one major new feature exclusive to Apple Silicon Macs: the ability to run iPhone and iPad apps from the App Store.

This sounds fine on paper, but in practice I don’t understand who thought this was a good idea to ship. My experience has ranged from terrible to OK, at best.

[…]

It’s possible HBO will fix some of this. Just making the window resizable and enabling full-screen video playback would make the app at least useful. But even at best, like Overcast, iOS apps running in a window on a Mac feel foreign. They feel like what they are: apps from another platform. I can see how some people might think this is a good idea, but I don’t see how anyone thinks it’s a very Apple-y idea. Sure, it works, which is why most companies would just ship it. More apps are better, right?

But they’re such a crummy experience, these iOS apps. This feature exemplifies a spirit of “better than nothing, ship it”. The Apple way, typically, is “insanely great”. It’s like someone said, “Oh, you thought lazy Catalyst ports were a bad experience on MacOS? Hold my beer…”

Steve Troughton-Smith:

In some sense, the Mac App Store has been a failed experiment; 9 years on, few of the top Mac developers are prepared to accept its terms and requirements, including sandboxing. Apple has a large chunk of its Mac developerbase thus ill-prepared to follow them into the future

Arguably, this is one of the driving elements between merging the iOS and macOS software ecosystems; Apple wants/needs a core base of developers on board with the App Store and its unified, Universal model, and iOS provides it

I’ve always argued that the Mac App Store should have done everything in its power to accommodate and entice the Mac’s existing developer base (they’re the ones that make all the high-quality apps we love, after all). This entire strategy, UIKit on up, drives them away instead

Ian Carroll:

There appears to be no DRM on iOS app binaries running on macOS.

Previously:

Update (2020-11-25): Marco Arment:

iOS devs, FYI: unmodified iOS apps running on M1 Macs appear to report themselves via hw.machine as model identifier “iPad8,6” (iPad Pro 12.9-inch, 3rd-gen, 1TB model).

So if you see a very recent spike in your analytics in iPad 12.9 users, that’s probably why.

Big Sur Not “Preparing” for Touch Macs

Craig Federighi:

I gotta tell you when we released Big Sur, and these articles started coming out saying, “Oh my God, look, Apple is preparing for touch”. I was thinking like, “Whoa, why?”

We had designed and evolved the look for macOS in a way that felt most comfortable and natural to us, not remotely considering something about touch.

We’re living with iPads, we’re living with phones, our own sense of the aesthetic – the sort of openness and airiness of the interface – the fact that these devices have large retina displays now. All of these things led us to the design for the Mac, that felt to us most comfortable, actually in no way related to touch.

I’ve never felt more comfortable moving across our family of devices as a user, which I do hundreds of times a day than I do now, moving between iOS 14, iPadOS 14, and macOS Big Sur. They all just feel of a family – there’s just less cognitive load to the switching process.

To me, it seemed obvious that the reduced information density was to enable touch. Because why else would you pay that cost for no benefit? Plus, the Mac App Store had started to feature artwork of a finger touching interface elements.

The cognitive load that Federighi mentions just isn’t something I’ve (consciously) experienced. And one could make the argument that it’s confusing to make systems that work differently look the same. But I take him at his word because it certainly explains decisions like the awful iOS-style alerts. That design provides no benefits for touch; it just makes macOS look more like iOS, which he considers to be a plus. All of these changes also help to make unmodified iOS apps running on Apple Silicon Macs blend in a bit better.

Nick Heer:

Big Sur offers a little more space around some elements, but not by much, so I think this speculation is quickly snuffed out if you use Big Sur for more than a couple of minutes. Most of the menus, buttons, and window controls are still tiny and clearly designed for a cursor and decidedly not a finger. It is still very much on the desktop side of the continuum.

Wojtek Pietrusiewicz:

Someone PLEASE create an app to decrease the spacing of the menu icons in Big Sur!

My apps now take up 50% of the width of it, instead of 25-33% previously. 😞

Francisco Tolmasky:

“We are willing to go through a multi-year transition on the Mac to use the same chip as the iPad, and do a design overhaul to make macOS icons look touchable, and even let iPad apps run on macOS, but we refuse to make these steps make sense by shipping a Mac with a touchscreen.”

Steve Troughton-Smith:

macOS would still need dramatic changes if it were ever to go touch-first. Catalyst is not in any way designed to dynamically switch between ‘Mac’ & ‘iOS’ modes — if an app has adopted Catalyst to explicitly make a Mac UI, it would be a ton of work to support dynamic switching

But, to be clear, the Mac doesn’t have to go touch-first to justify touch support. Apple Pencil support on macOS, on a drafting table iMac, would fit into all kinds of pro-level workflows currently dominated by Wacom, from illustration to 3D modeling.

Jean-Louis Gassée:

I think the charming and articulate executive is putting us on.

I absolutely think Apple will add at least limited touch support to future Macs, even if that wasn’t the plan when Big Sur was being designed. Federighi didn’t even deny that.

Previously: