Archive for November 4, 2019

Monday, November 4, 2019 [Tweets] [Favorites]

“Real” Photoshop for iPad

Michael Steeber:

A full, desktop-class version of Photoshop on iOS has been one of the most hotly anticipated creative apps for designers and artists since the original iPad’s introduction in 2010. In the years since, competitors have released their own products hoping to fill the void, but can’t offer true integration with Creative Cloud that existing Photoshop customer have come to expect. Today at 2018’s Adobe MAX conference in Los Angeles, Adobe is answering the requests of the creative community by previewing what it calls real Photoshop CC for iPad.

Mark Gurman and Nico Grant:

Adobe has been testing Photoshop for iPad under the codename Rocket with a small group of beta testers since earlier this year. Participants have told Bloomberg News that some beta versions don’t include well-established features they expected to be part of the release. They complained about less advanced or missing features around core functionality like filters, the pen tool and custom paintbrush libraries, vector drawing, color spaces, RAW editing, smart objects, layer styles and certain options for mask creation.

[…]

“I understand it is based on desktop Photoshop code, but it doesn’t feel like it right now.” Other testers have called the app “rudimentary” and said, in its current state, it is inferior to other apps like Procreate and Affinity on the iPad.

John Gruber (tweet):

From what I gather, the mistake Adobe made was not precisely setting expectations for the initial release of Photoshop for iPad. When Adobe described it as “real” Photoshop, what a lot of people heard was “full” Photoshop, and that was never the plan. Some of this expectation-setting is attributable to Bloomberg, which described the project as “the full version of its Photoshop app” as far back as July last year.

Photoshop for iPad is real because it is using the same code base that’s been running on the desktop for decades. That’s an amazing technical accomplishment. Photoshop for iPad is not full — and the initial release was never planned to be — because it only exposes a subset of features from the desktop version.

Steve Troughton-Smith:

I’d phrase it more like: Adobe is years late to what Serif is doing with Affinity Photo on iOS, and it’s no surprise that it might take years to catch up. It’s up to Serif to really take advantage of that lead while they can

John Voorhees (tweet, MacRumors):

It’s against this backdrop of rumors and hype that Photoshop for iPad has emerged finally. Mindful of the outsized expectations that were created, Adobe takes great pains in its announcement today to explain that Photoshop for iPad 1.0 ‘is just the beginning,’ emphasizing that the new app is built on the same code base as the desktop version but optimized for touch. The company also stresses that its new cloud-based PSD file architecture will allow users to move seamlessly between platforms.

That’s good news, but not the same as the ability to substitute one app for the other. What users can accomplish on the new iPad app is more limited than the desktop. Adobe says the initial release focuses on compositing, masking, and basic retouching, which I can confirm from my limited use of the app. Those are core Photoshop features that many users will welcome, but desktop Photoshop can do much more. So, for the time being, Adobe is positioning its new iPad app as an accessible way to introduce Photoshop to new users, a complement to the desktop version, and a companion app for professional users.

Russell Ivanovic:

Alternate take: Photoshop for iPad is going to be and feel like Photoshop Lite forever. Adobe sucks at this. I can’t see them ever getting it right.

Lightroom, certainly, remains very different from the “classic” desktop version. Of course, Microsoft Office, iWork, and Omni’s apps are also “real” but not “full.”

Dave Mark:

Looks like Photoshop for iPad does NOT support RAW.

This seems like a huge deal to me.

Eli Schiff:

I’d like to write off the cuff about the evaluation of design tools based on my thorough usage of @photoshop @sketch and @figmadesign

Update (2019-11-07): Scott Belsky:

a real-time v1 lesson: you’ve gotta ship an MVP to start the journey, but it will be painful at first. by definition, it won’t please everyone (and if it’s a reimagination of a 30yr old popular/global product, will displease many)

Bob Burrough:

Changing the way the user interacts with software (replacing mouse+keyboard with multitouch) is a major, fundamental change. Adobe did not carefully manage expectations. Instead, they misled their customers by describing it as “real” Photoshop.

For Apple’s part, they had no qualms letting Adobe take center stage to make such a claim. Apple has been trying to convince us for years that iPad is a suitable replacement for mouse+keyboard PC’s. Unfortunately, that isn’t the case. It will never be the case.

[…]

Keyboard+mouse is better at open-ended computing that requires high bandwidth input. iPad is far superior at mobility. Apple Pencil and Wacom tablets are far more expressive than mouse or multitouch will ever be. But, different they remain.

Electron Apps Rejected From the Mac App Store

David.dev (via Ben Sandofsky, Hacker News, Slashdot):

Allright, as a follow up to the previous chapter in this odyssey I can now state that, apparently,  you cannot submit an electron 6 or 7 app to the apple store:

The first refusal from apple states:

Your app app links against the following non-public framework(s):
CAContext
CALayerHost
NSAccessibilityRemoteUIElement
NSNextStepFrame
NSThemeFrame
NSURLFileTypeMappings

I am not the only one having this issue and I did write back to Apple trying to explain that I am using Electron and I can’t really change any of these public-framework usage (I assume is something from Chromium)[…]

Craig Hockenberry:

There was a time when digging into the bowels of the macOS implementation was “necessary”. Back in the day, you’d use NSThemeFrame to get UI into an app’s titlebar.

iTunes did it, so everyone wanted to do it.

But those days are long gone - there are public APIs to get the job done now.

And with the advent of Spaces, split-screen windows, and translucent effects, using these private APIs are likely to break an app.

Unfortunately, that isn’t the whole story. Some of the private APIs are used in the Web rendering engine itself:

Mozilla recently published a good write up on why they started using the undocumented CALayer API in Firefox 69. The TLDR is that that these private API’s allowed them to get up to 3x better battery usage in Firefox. The article also mentioned that Chrome uses these Core Animation API’s.

So there are a multiple problems here:

  1. It’s (apparently) impossible for Chromium to get competitive performance and battery life without using private API, which Safari freely uses.
  2. Apple probably has good reasons for keeping these APIs private.
  3. Private API has always been banned, but Apple has been accepting these apps for years and then abruptly stopped without any notice.
  4. Apps using Electron probably didn’t know that they were even using private API. Neither Xcode nor Application Loader reports this, and App Review was accepting the apps.
  5. The rule is not being enforced equally.

Jeff Johnson:

I just checked Slack, which was updated 3 days ago, and its embedded Electron Framework contains all of the listed private symbols.

“And developers, from first-time engineers to larger companies, can rest assured that everyone is playing by the same set of rules.”

thomascgalvin:

This, however, is draconian:

Continuing to use or conceal non-public APIs in future submissions of this app may result in the termination of your Apple Developer account, as well as removal of all associated apps from the App Store.

“Keep trying to submit, and we might just ban you forever” is insane. Every program of any complexity depends on third party libraries, and many people wouldn’t be able to tell what arcane APIs their dependencies (or their dependencies’ dependencies) call. “If you continue to have an upstream dependency that violates our terms, we might permaban you” is bullshit.

Colin Cornaby:

This has got to be a big problem for Apple. The widespread distribution of Electron and Chromium means they have to maintain this as semi-public API. Or risk breaking a lot of apps in a future OS release. Google is forcing them into a bad spot.

Matt Birchler:

Good people of Twitter, what are your favorite Catalyst apps? Asking because I am yet to find one that is remotely as good as the Electron apps I use daily.

I’ll be more specific: Slack and Visual Studio Code works great for me, while Postman is a little annoying, but very functional. Meanwhile the Jira and Twitter Catalyst apps have sent me running back for the web.

Previously:

Update (2019-11-05): anatomisation points out that the Mozilla post does not actually say that they are using private API and that WebKit is not using CALayerHost very extensively. However, Chromium does seem to be using it for compositing during rendering.

Pierre Lebeaupin:

Reminds me of the time people found out Unity was relying on an undocumented API, around the iPhoneOS 3 or iOS 4 timeframe IIRC. I think we were affected too (by direct usage, not through Unity. Our bad.

Jeff Johnson:

These private symbols have been in Electron/Chromium for a long time. Strange coincidence that Apple is changing their enforcement now, so soon after Catalyst is available.

[…]

That neither Chrome nor Firefox is in the MAS could be considered an indictment of the MAS.

Previously:

Rosyna Keller:

FWIW, Chromium is using CALayerHost for something better served by public IOSurface APIs and public CALayer properties.

Update (2019-11-09): Owen Williams (via Hacker News):

Developers use technologies like Electron and PWA because they allow for faster updates across platforms without an array of different codebases. Some argue that this results in lower quality apps, but I’d argue the alternative is no app at all or apps that are rarely updated because maintaining unique Windows, Mac, and web-based products is complex and expensive.

[…]

Apple’s subtle, anti-competitive practices don’t look terrible in isolation, but together they form a clear strategy: Make it so painful to build with web-based technology on Apple platforms that developers won’t bother.

[…]

These types of changes may be made in the name of privacy or security, but the reality is that the argument looks weak when both users and developers simply don’t have a choice because Apple controls the platform, browser engine, and the distribution method. Regardless of your opinion of Electron app quality, choice is important.

Apple TV, Apple TV, Apple TV, and Apple TV+

Dustin Curtis (via Hacker News):

Apple TV is a hardware device.

Apple TV is an app on Apple TV that curates content you can buy from Apple and also content you can stream through other installed apps (but not all apps, and there is no way to tell which ones).

Apple TV is an app on iOS/iPadOS devices that operates similarly to Apple TV on Apple TV. Apple TV on iOS/iPadOS syncs playback and watch history with Apple TV on Apple TV, but only if the iOS/iPadOS device has the same apps installed as the Apple TV – and not all apps are available on all platforms. Apple TV is also an app on macOS, but it does not show content that can only be streamed from external apps on an Apple TV or iOS/iPadOS device.

Here’s the post color-coded.

Update (2019-11-07): Jason Snell:

An article like this would also be written if Apple went to market with a hardware device called Apple TV, an app called Videos, a smart-TV app called Apple, a reselling strategy called Apple Channels (or having no name at all!), and a subscription streaming service called Apple Cinema. Too many names, Apple! It’s confusing! Why not something simpler?

[…]

So, yes: Apple’s strategy is a mess. I’m also not sure that the alternatives are any better.

I saw someone the other day say that television is so much simpler than it used to be, and I had to laugh. Television has never been more complicated. Apple’s very Apple-like attempt to stick to a single simple phrase—“Apple TV”—can’t spackle over just what a messy situation the streaming entertainment world is right now.

Twitter’s Ban on Political Ads

Will Oremus:

Twitter CEO Jack Dorsey announced on Wednesday that the company will ban political advertising, a move that earned the company a rare wave of positive press.

[…]

There’s something to be said for a tech platform taking its responsibilities to the democratic process seriously. But banning political ads is not as straightforward, nor as obviously correct, as those cheering Dorsey’s announcement seem to think.

The problem is twofold. First, defining which ads count as “political” gets tricky in a hurry. Second, prioritizing commercial speech over political speech is itself a political stance, and not necessarily one that we should want our online communication platforms to take.

Facebook’s policy is to allow such ads but to “[exempt] political candidates from its rules on misinformation in advertising.” This perhaps makes sense because fact checking is not straightforward, and it would set them up to be blamed for any controversial decision. But it creates an obvious loophole, which is already being exploited.

Update (2019-11-05): Ben Thompson:

Start with the latter: it is hard to interpret Twitter’s decision as anything other than a Strategy Credit. The company, by its own admission, earned an immaterial amount of revenue from political ads in the last election cycle; now it gets to wash its hands of the entire problem and chalk up whatever amount of revenue it misses out on as an investment in great PR.

Such a policy, however, particularly were it applied to Facebook, where much more advertising is done (political or otherwise), would significantly disadvantage new candidates without large followings, particularly in smaller elections without significant media coverage. It is, at a minimum, a rejection of social media’s third estate role; best to leave the messy politics to the parties and the mass media.

Facebook, meanwhile, has struggled to defend its decision in the context of a “marketplace of ideas”. After all, what value is there in a lie? In fact, Mill would argue, there is a great deal of value in exactly that, but it’s a hard case to make! Never mind that most disputes would be less about easily disprovable lies and more about challengeable assumptions.