Search Results for: "mac app store"

Sponsor: Power Up Your Screenshots With ScreenFloat 2 ⇥ eternalstorms.at

ScreenFloat 2 icon

You’re still not sure if and how ScreenFloat 2 for Mac powers up your screenshots and recordings? There’s a very easy way to find out: download the no-strings-attached, free, 28-day trial (with a one-time purchase on the Mac App Store after that)!

It floats your captures, like Picture-in-Picture, which makes it a breeze to keep stuff always visible – and readily accessible for edits, markup, redaction and sharing!

Copy, view or quicksmart-redact texts, barcodes, and faces with a simple right-click. Pick colours. Synchronize your library across your Macs, and keep your shots organized in its Shots Browser.

Set up powerful double-click workflows to make repetitive tasks less of a hassle.

And much more!

Here’s what customers say about the app:

  • “I’d be lost without ScreenFloat, it’s one of the best apps ever”

  • “I’m miserable without it”

  • “It saves me headaches every single day, and makes my workflow much smoother”

  • “Nothing comes close to ScreenFloat”

For perspective, here’s a complaint:

  • “You have moved the icon containing the dragged file from left to right. Why? It’s not convenient.”

But what matters now is: what will you say?

A screenshot is just a screenshot. Until you use ScreenFloat. Download the free, 28-day trial today!

Apps and Vinegar

Big news out of Brussels:

The European Commission has fined Apple over €1.8 billion for abusing its dominant position on the market for the distribution of music streaming apps to iPhone and iPad users (‘iOS users’) through its App Store. In particular, the Commission found that Apple applied restrictions on app developers preventing them from informing iOS users about alternative and cheaper music subscription services available outside of the app (‘anti-steering provisions’). This is illegal under EU antitrust rules.

Margrethe Vestager, executive vice president of the European Commission, in the transcript of a speech announcing the Commission’s findings and penalty:

Let me give you three examples of Apple’s anti-steering obligations:

  • First, music streaming developers were not allowed to inform their users, inside their own apps, of cheaper prices for the same subscription on the internet.

  • Second, they were also not allowed to include links in their apps to lead consumers to their websites and pay lower prices there.

  • And third, they were also not allowed to contact their own newly acquired users, for instance by email, to inform them about pricing options after they set up an account.

These anti-steering rules have been among the most aggressively policed of all the App Store policies. They have snared apps for violations like having a link buried in some documentation, requiring even large developers to create special pages — perhaps because Apple saw even small transgressions as opening the door to loopholes. Better be as tedious and cautious as possible.

Nevertheless, a few years ago, the Commission started looking into complaints that streaming music services — specifically — were disadvantaged by these policies. One could argue its interest in this specific category is because it is one area where European developers have some clout: in addition to Spotify, Deezer and SoundCloud are also European products. That is not a criticism: it should be unsurprising for European regulators to investigate an area where they have the grounds to do so. Alas, this is a relatively narrow investigation ahead of the more comprehensive enforcement of the Digital Markets Act, so treat this as a preview of what is to come for non-compliant companies.

The Commission has illustrated this in its press release with an image that features the icons of — among other apps — Beats Music, which Apple acquired in 2014 and turned into Apple Music, and Rdio, which was shut down in 2015.

Aside from the curious infographic, the Commission released this decision without much supporting documentation, as usual. It promises more information is to come after it removes confidential details. It is kind of an awkward statement if you are used to reading legal opinions made by regulatory bodies elsewhere, many of which post the opinion is alongside the decision so it is possible to work through the reasoning. Here, you get a press release and a speech — that is all.

Apple’s response to this decision is barely restrained and looks, frankly, terrible for one of the world’s largest and most visible corporations. There is no friendly soft-touch language here, nor is it a zesty spare statement. This is a press release seasoned with piss and vinegar:

The primary advocate for this decision — and the biggest beneficiary — is Spotify, a company based in Stockholm, Sweden. Spotify has the largest music streaming app in the world, and has met with the European Commission more than 65 times during this investigation.

[…]

Despite that success, and the App Store’s role in making it possible, Spotify pays Apple nothing. That’s because Spotify — like many developers on the App Store — made a choice. Instead of selling subscriptions in their app, they sell them on their website. And Apple doesn’t collect a commission on those purchases.

[…]

When it comes to doing business, not everyone’s going to agree on the best deal. But it sure is hard to beat free.

Strictly speaking — and we all know how much Apple likes that — Spotify pays more than “nothing” to distribute its app on iOS because a developer membership is not free.

But — point taken. Apple is making its familiar claim that iOS software avoids its in-app purchase model is basically freeloading, but it is very happy for any developer’s success. Happy, happy, happy. Real fuckin’ happy. Left unsaid is how much of this infrastructure — hosting, updates, developer tooling, and so on — is required by Apple’s policies to be used by third-party developers. It has the same condescending vibe as the letter sent to Basecamp in 2020 amidst the Hey app fiasco. At the time, the App Review Board wrote “[t]hese apps do not offer in-app purchase — and, consequently, have not contributed any revenue to the App Store over the last eight years”, as though it is some kind of graceful obligation for Apple to support applications that do not inflate its own services income.

Nevertheless, Apple is standing firm. One might think it would reconsider its pugilism after facing this €1.8 billion penalty, investigations on five continents specifically regarding its payment policies, new laws written to address them, and flagging developer relations — but no. It wants to fight and it does not seem to care how that looks.

Today, Spotify has a 56 percent share of Europe’s music streaming market — more than double their closest competitor’s — […]

Apple does not state Spotify’s closest European competitor but, according to an earlier media statement, it is Amazon Music, followed Apple Music. This is a complicated comparison: Spotify has a free tier, and Amazon bundles a version of its service with a Prime membership. Apple Music’s free tier is a radio-only service.

On that basis, it does seem odd from this side of the Atlantic if the Commission concluded Apple’s in-app payment policies were responsible for increased prices if the leading service is available free. But that is not what the Commission actually found. It specifically says the longtime policies “preventing [apps] from informing iOS users about alternative and cheaper music subscription services available outside of the app” are illegal, especially when combined with Apple’s first-party advantages. One effect among many could be higher prices paid by consumers. In the cases of Deezer and SoundCloud, for example, that is true: both apps charge more for in-app purchased subscriptions, compared to those purchased from the web, to cover Apple’s commission. But that is only one factor.

Carrying on:

[…] and pays Apple nothing for the services that have helped make them one of the most recognizable brands in the world. A large part of their success is due to the App Store, along with all the tools and technology that Spotify uses to build, update, and share their app with Apple users around the world.

This model has certainly played a role in Apple’s own success, according to an Apple-funded study (PDF): “Apple benefits as well, when the ecosystem it established expands and grows, either directly through App Store commissions or indirectly as the value users get from their iPhones increases”. Apple seems fixated on the idea that many apps of this type have their own infrastructure and, therefore, have little reason to get on board with Apple’s policies other than to the extent required. Having a universal software marketplace is probably very nice, but having each Spotify bug fix vetted by App Review probably provides less value than Apple wants to believe.

Like many companies, Spotify uses emails, social media, text messages, web ads, and many other ways to reach potential customers. Under the App Store’s reader rule, Spotify can also include a link in their app to a webpage where users can create or manage an account.

We introduced the reader rule years ago in response to feedback from developers like Spotify. And a lot of reader apps use that option to link users to a webpage — from e-readers to video streaming services. Spotify could too — but they’ve chosen not to.

About that second paragraph:

  • This change was not made because of developer requests. It was agreed to as part of a settlement with authorities in Japan in September 2021.

    Meanwhile, the European Commission says it began investigating Apple in June 2020, and informed the company of its concerns in April 2021, then narrowing them last year. I mention this in case there was any doubt this policy change was due to regulatory pressure.

  • This rule change may have been “introduced” in September 2021, but it was not implemented until the end of March 2022. It has been in effect for less than two years — hardly the “years ago” timeframe Apple says.

  • For clarification, external account management links are subject to strict rules and Apple approval. Remember how Deezer and SoundCloud offer in-app purchases? Apple’s policies say that means they cannot offer an account management link in their apps.

    This worldwide policy is specific to “reader” apps and is different from region-specific external purchase capabilities for non-“reader” apps. It only permits a single external link — one specific URL — which is only capable of creating and managing accounts, not individually purchased items. Still it is weird how Spotify does not take advantage of this permission.

  • Spotify, a “reader” app, nevertheless attempted to ship app updates which included a way to get an email with information about buying audiobooks. These updates were rejected because Spotify is only able to email customers in ways that do not circumvent in-app purchases for specific items.

You can quibble with Spotify’s attempts to work around in-app purchase rules — it is obviously trying to challenge them in a very public way — but it is Apple which has such restrictive policies around external links, down to how they may be described. It is a by-the-letter reading to be as strict as possible, lest any loopholes be exploited. This inflexibility would surely be explained by Apple as its “level playing field”, but we all know that is not entirely true

Instead, Spotify wants to bend the rules in their favor by embedding subscription prices in their app without using the App Store’s In-App Purchase system. They want to use Apple’s tools and technologies, distribute on the App Store, and benefit from the trust we’ve built with users — and to pay Apple nothing for it.

It is not entirely clear Spotify actually wants to do any of these things; it is more honest to say it has to do them if it wants to have an iPhone app. Spotify has routinely disputed various iOS policies only to turn around and reject Apple’s solutions. Spotify complained that users could not play music natively through the HomePod, but has not taken advantage of third-party music app support on the device added in 2020. Instead, it was Apple’s Siri improvements last year that brought Spotify to the HomePod, albeit in an opaque way.

If we accept Apple’s premise, however, it remains a mystery why Apple applies its platform monetization policy to iOS and the related operating systems it has spawned, but not to MacOS. By what criteria, other than Apple’s policy choices, are Mac developers able to sell digital goods however they want — unless they use the Mac App Store — but iOS developers must ask Apple’s permission to include a link to an external payment flow? And that is the conceded, enhanced freedom version of this policy.

There is little logic to the iOS in-app purchase rules, which do not apply equally to physical goods, reader apps, or even some à la carte digital goods. Nobody has reason to believe this façade any longer.

Apple obviously believes the Mac is a different product altogether with different policies, and that is great. The relatively minor restrictions it has imposed still permit a level of user control unimaginable on iOS, and Apple does not seem to have an appetite to further lock it down to iOS levels. But the differences are a matter of policy, not technology.

Apple justifies its commission saying it “reflects the value Apple provides developers through ongoing investments in the tools, technologies, and services”. That is a new standard which apparently applies only to its iOS-derived platforms, compared to the way it invested in tools for Mac development. Indeed, Apple used to charge more for developer memberships when third-party software was only for the Mac, but even the top-of-the-line $3,500 Premier membership was probably not 30% of most developers’ revenue. Apple also charged for new versions of Mac OS X at this time. Now, it distributes all that for free; developers pay a small annual fee, and a more substantial rate to use the only purchasing mechanism they can use for most app types in most parts of the world.

For whatever reason — philosophical or financial — Apple’s non-Mac platforms are restricted and it will defend that stance until it is unable to do so. And, no matter how bad that looks, I kind of get it. I believe there could be a place for a selective and monitored software distribution system, where some authority figure has attested to the safety and authenticity of an app. That is not so different conceptually from how Apple’s notarization policies will be working in Europe.

I oscillate between appreciating and detesting an app store model, even if the App Store is a mess. But even when I am in a better mood, however, it seems crystal clear that such a system would be far better if it were not controlled by the platform owner. The conflict of interest is simply too great. It would be better if some arm’s-length party, perhaps spiritually similar to Meta’s Oversight Board, would control software and developer policies. I doubt that would fix every complaint with the App Store and App Review process but I bet it would have been a good start.

The consequences of being so pugnacious for over fifteen years of the App Store model has, I think, robbed Apple of the chance to set things right. Regulators around the world are setting new inconsistent standards based on fights between large corporations and gigantic ones, with developers of different sizes lobbying for their own wish lists. Individual people have no such influence, but all of these corporations likely believe they are doing what is right and best for their users.

As the saying goes, pressure makes diamonds, and Apple’s policies are being tested. I hope it can get this right, yet press releases like this one gives me little reason to believe in positive results from Apple’s forcibly loosened grip on its most popular platform. And with the Digital Markets Act now in effect, those stakes are high. I never imagined Apple would be thrilled for the rules of its platform to be upended by courts and lawmakers nor excited by a penalty in the billions, but it sure seems like it would be better for everybody if Apple embraced reality.

Scam ‘A.I.’ Apps and Shady Developers in the App Store ⇥ privacyis1st.medium.com

Alex Kleber:

In the last 30 days, I have been closely monitoring the Mac App Store and have made a disturbing discovery. In the midst of the OpenAI frenzy, several apps have surfaced that are copying the iconic OpenAI logo and color scheme in order to mislead unsuspecting MacOS App Store users. But that’s not all — I also found that some developers are abusing Apple’s Developer Agreements by spamming multiple accounts and flooding the store with nearly identical applications. […]

Kleber notes these apps are paywalled with “no close button”. That is not quite true: in very small text, the developer offers the option to “Continue with free plan”, but it is highly misleading. This should be the sort of thing Apple polices against in the App Store. These apps ride a rising tide of interest in a specific product, they offer in-app purchases, and they appear to be duplicative.

These apps are all still available in the Mac App Store, by the way, and this is not the first time fake ChatGPT apps have climbed the charts. In fact, upon opening the App Store on my iPhone, the first thing I saw was an ad on the search page for an app which looks, at first glance, like an official OpenAI app — same colours, similar logo, and a description with a conspicuous use of the word “Open”. As of writing, it is the ninth most popular app in the Productivity category — and, yes, of course it offers paid subscriptions.

Mac App Store Apps Using In-App Purchases to Hide Free Apps That Need Subscriptions ⇥ imore.com

Jeff Johnson:

Top Mac App Store dev abuses Free with In-App Purchase for bait-and-switch apps demanding upfront payment, not free in any respect.

This developer has 9 apps in the Mac App Store, all of which seem to have the same “business model”: free to download, with In-App Purchase, but the first time you open the app, it demands an upfront one-time purchase, otherwise it doesn’t work at all.

No trial, no subscription.

Stephen Warwick, iMore:

In response to this report, Fokusek Enterprise’s CEO contacted iMore with comment on the story. Tiberiu Prioteasa claims that the IAP monetization the developer uses “is used by most of the big companies such as NordVPN, Microsoft and many apps that provide Health, Lifestyle and Fitness apps from the Apple App Store,” noting that Apple has approved the use of this monetization process everytime it has been submitted to Apple. However, while lots of companies offer in-app purchases on the Mac App Store, and use auto-renewal after a free trial, Fokusek’s Docs Pro for Google Drive apps greets users with the following screen as soon as you open it: […]

This is the kind of thing Apple sought to prevent when it launched In-App Purchases as a feature for paid apps only. Opening them up to free apps has created different purchasing mechanisms in the App Store and has pushed the industry toward subscription pricing, but it has also enabled scummy behaviour like this.

Not that it matters much, but Prioteasa is not entirely wrong by pointing out how similar this model is to that of big-name companies. All of them offer a trial — unlike these crappy apps — but they are a bit of a bait-and-switch. You might see Microsoft PowerPoint as one of the top free apps on the Mac App Store, but to save or edit a presentation, you need to activate a trial that will roll over into a minimum monthly payment.1 Not really a free app, is it?

  1. Microsoft also pitches the subscription as being “as low as” the single-user price, but preselects the more expensive family subscription. Gross. ↥︎

With Its App Marketplace Principles, Microsoft Positions Itself as a Friend to Developers ⇥ blogs.microsoft.com

Microsoft president Brad Smith:

Today we’re announcing a new set of Open App Store Principles that will apply to the Microsoft Store on Windows and to the next-generation marketplaces we will build for games. We have developed these principles in part to address Microsoft’s growing role and responsibility as we start the process of seeking regulatory approval in capitals around the world for our acquisition of Activision Blizzard. This regulatory process begins while many governments are also moving forward with new laws to promote competition in app markets and beyond. We want regulators and the public to know that as a company, Microsoft is committed to adapting to these new laws, and with these principles, we’re moving to do so.

Microsoft is making eleven promises to developers for its Windows software marketplace. Some are straightforward enough, like how it says it will hold developers to standards of security — but not privacy — while others are clear shots at Apple and Google, like its flexible rules around in-app payments. But it says not all of the same rules will apply for Xbox developers, particularly those around in-app purchases and developer communications, because these promises are designed to get ahead of proposed legislation. That is not an oversimplification; Smith:

Second, some may ask why today’s principles do not apply immediately and wholesale to the current Xbox console store. It’s important to recognize that emerging legislation is being written to address app stores on those platforms that matter most to creators and consumers: PCs, mobile phones and other general purpose computing devices. For millions of creators across a multitude of businesses, these platforms operate as gateways every day to hundreds of millions of people. These platforms have become essential to our daily work and personal lives; creators cannot succeed without access to them. Emerging legislation is not being written for specialized computing devices, like gaming consoles, for good reasons. Gaming consoles, specifically, are sold to gamers at a loss to establish a robust and viable ecosystem for game developers. The costs are recovered later through revenue earned in the dedicated console store.

Microsoft says it will eventually make these rules standard on Xbox, too, but one wonders how that is possible when it says those existing payment structures are necessary for a “robust and viable ecosystem”. It may be happy to apply what it calls a “principled approach” in its Windows marketplace, but that is an open platform for developers. It would be like if Apple applied these same policies to its Mac App Store, but not iOS — I would have questions.

Emmanuel Maiberg and Edward Ongweso Jr, Vice:

We should recognize Microsoft’s messaging for what it is: an attempt to convince us that self-regulation will turn out good for all of us. Self-regulation is how we got here, though. We need laws, not agreements — antitrust actions backed up by law, not corporate rhetoric that will disappear at Microsoft’s earliest convenience.

Becky Hansmeyer:

As I think about Microsoft cleverly positioning themselves as a developer’s best friend, I can’t help but assume that Apple execs are whining “they’re making us look like the bad guys!” instead of asking themselves, “ARE we the bad guys?”

Well said.

Music and TV Apps Use JET in MacOS 12.2 Beta ⇥ 9to5mac.com

Luming Yin:

macOS 12.2 beta is now available, featuring smoother scrolling in Safari on the latest MacBook Pro with ProMotion, and a native Apple Music and TV experience backed by AppKit views instead of web views.

Filipe Espósito, 9to5Mac:

Some parts of the Music app were already native, such as the music library. But now Mac users will notice that searching for new songs in Apple Music is much faster as the results pages are displayed with a native interface instead of as a webpage. Scrolling between elements has also become smoother with the beta app, and trackpad gestures are now more responsive.

[…]

Yin mentioned that the Apple TV app has also been rebuilt with a native backend. While this is indeed true, 9to5Mac found out that Apple had already updated the TV app with JET technology in macOS Monterey 12.1, which is available for everyone. Of course, more refinements are expected for both apps in the upcoming macOS 12.2 betas.

Michael Tsai:

Note that Music was always an AppKit app (not Catalyst). The difference in 12.2 seems to be that more content within the window now uses native controls. Personally, I didn’t notice a change, perhaps because I don’t use the Apple Music areas of the app.

These changes seem exclusive to the Apple Music parts, which — like the iTunes Store — have long been webpages rendered in the frame of a native Mac app. They have always felt slow and disconnected from the main app. In MacOS 12.2, these web-based sections are now interpreted as native Mac views, and Music feels noticeably faster because of it.1 Scrolling is smoother, and the spacebar now pauses and resumes playback correctly. These improvements and the significantly reduced CPU consumption in MacOS 12.1 make me believe that someone at Apple really does care about the Music app on MacOS. There is hope.

Then again, the preferences window in Music is still modal. Some things will never change.

  1. I believe recent versions of the Mac App Store also use the Jet framework. ↥︎

The Mac App Store Turns Ten ⇥ macrumors.com

From the Apple Newsroom on January 6, 2011 [sic]:

Apple® today announced that the Mac® App Store℠ is now open for business with more than 1,000 free and paid apps. The Mac App Store brings the revolutionary App Store experience to the Mac, so you can find great new apps, buy them using your iTunes® account, download and install them in just one step. The Mac App Store is available for Snow Leopard® users through Software Update as part of Mac OS® X v10.6.6.

You know the first interesting thing about this? Apple issued a press release when the iOS App Store turned ten; Apple also posted one the day the Mac App Store turned ten, but it wasn’t about the Mac App Store:

As the world navigated an ever-changing new normal of virtual learning, grocery deliveries, and drive-by birthday celebrations, customers relied on Apple services in new ways, turning to expertly curated apps, news, music, podcasts, TV shows, movies, and more to stay entertained, informed, connected, and fit.

There’s a bit in the release touting the “commerce the App Store facilitates”, and Apple used it to announce $1.8 billion spent on the App Store between Christmas Eve and New Year’s Eve, but that’s it. Also, I want to thank the person who decided that Apple’s press releases do not need to contain intellectual property marks.

Perhaps it is not surprising that the Mac App Store did not get its own anniversary announcement. It could be the case that Apple considers the launch of the iPhone App Store the original, and everything else is simply part of that family. Apple also doesn’t indulge in anniversaries very often — the App Store press release was an exception rather than the rule.

But it also speaks to the Mac App Store’s lack of comparable influence. Joe Rossignol, MacRumors:

Since its inception, the Mac App Store has attracted its fair share of criticism from developers. Apple has addressed some of these complaints over the years by allowing developers to offer free trials via in-app purchase, create app bundles, distribute apps on multiple Apple platforms as a universal purchase, view analytics for Mac apps, respond to customer reviews, and more, but some developers remain unsatisfied with the Mac App Store due to Apple’s review process, the lack of upgrade pricing, the lack of sandboxing exceptions for trusted developers, the absence of TestFlight beta testing for Mac apps, and other reasons.

Michael Tsai:

Thinking back to the early days of the Mac App Store, I remember how its introduction killed a nascent third-party effort to build a similar store. And I recall how, just months after the store opened, Apple changed the rules to require that apps be sandboxed. […]

The Mac App Store has led a bizarre life in its first ten years — remember when system software updates, including operating system updates, came through the Mac App Store? A 2018 redesign made it look more modern, but it continues to feel like it was ported from another platform. Like the iOS App Store, it faces moderation problems, and its vast quantity of apps are mostly terrible.

There are some bright spots. I have found that good little utility apps — ABX testers, light audio processing, and the sort — are easy to find in the Mac App Store. Much easier, I think, than finding them on the web. It is also a place where you can find familiar software from big developers alongside plenty of indies, software remains up-to-date with almost no user interaction, and there are no serial numbers to lose.

Unfortunately, there remain fundamental disagreements between Apple’s policies and developers’ wishes that often manifest in comical ways. Recently, for my day job, I needed to use one of Microsoft’s Office apps that I did not have installed. I was able to download it from the Mac App Store but, upon signing in to my workplace Office 365 account, I was told that the type of license on my account was incompatible with that version of the app. I replaced it with a copy from Microsoft’s website with the same version number and was able to log in. I assume this is because there is a conflict between how enterprise licenses are sold and Apple’s in-app purchase rules. It was caused in part by Microsoft’s desire to sell its products under as many subtly-different similarly-named SKUs as possible, and resulted in an error message that was prohibited by App Store rules from being helpful. Regardless of the reasons, all I experienced as a user was confusion and frustration. Oftentimes, it is simply less nice to use the Mac App Store than getting software from the web.

Happy tenth birthday to the Mac App Store; it cannot be the best that Apple can do.

Apple Claims ‘Amphetamine’ Violates Illegal Drug App Store Policy, Threatens Removal ⇥ github.com

Amphetamine is a simple free app that sits in the menu bar and keeps a Mac awake — the spiritual successor to Caffeine, which has not been updated in years. It is well-liked; Apple liked it so much they featured it in a Mac App Store story.

So it surely came as a surprise to William C. Gustafson, the app’s developer, when Apple decided that it was in violation of policies that prohibit glorification of controlled substances:

Apple then proceeded to threaten to remove Amphetamine from the Mac App Store on January 12th, 2021 if changes to the app were not made. It is my belief that Amphetamine is not in violation of any of Apple’s Guidelines. It is also my belief that there are a lot of people out there who feel the same way as me, and want to see Amphetamine.app continue to flourish without a complete re-branding.

[…]

Apple further specified: “Your app appears to promote inappropriate use of controlled substances. Specifically, your app name and icon include references to controlled substances, pills.”

I can see how this app could be interpreted as violating those policies. It has a pill for an icon, and amphetamines are controlled substances in most countries. But:

  1. It does not promote drug use any more than the MacOS feature named “Mission Control” gives users the impression they can now work at NASA.

  2. Apple gave this app a dedicated editorial feature in the App Store, thereby increasing awareness of an app called “Amphetamine” — and it is only now that it says the app’s name is incompatible with its policies? That seems like a bait and switch.

I get that App Review might not catch policy violators on a first pass or even after several updates. But surely there comes a time when Apple has to decide that it looks less petty to treat a violation of a policy as minor as this as a special grandfathered case. If an app is featured by the App Store team, Apple ought to suspend their right to complain about superficial rule-breaking — if that is what this is, and I am still not convinced that Amphetamine violates the spirit of those policies.

The slightly good news here is that, unlike an iOS app, the removal of this Mac app would not entirely destroy its existence. It could be distributed outside of the Mac App Store if the developer chooses. But it should be allowed to remain.

Update: Gustafson says that Apple confirmed Amphetamine will stay in the store without a name change. In a parallel universe where this story did not receive press coverage, would the outcome be the same?

A Step Back

Let’s try something together. What do these things all have in common?

  • Photos

  • Music

  • News

  • Podcasts

  • TV

  • Stocks

  • Mac App Store

You thought they were all going to be iOS apps until I surprised you with that last one, right? These are all MacOS apps, yes, but they are not all of the same kind. Many of them are media apps, but it’s hard to think of Stocks, News, or the App Store in the same category.

Three of them — News, Podcasts, and Stocks — are Catalyst apps that were ported from their iOS equivalents. Two — Music and TV — are standard MacOS apps, but Music is built on a rickety base of code that dates back to the Clinton administration. Photos, meanwhile, is a Frankenstein’s monster of an app. It was originally built on a framework called UXKit, which appears to be some kind of cross-platform precursor to Catalyst. At some point in the last five years, obvious traces of UXKit were stripped from MacOS; alas, Photos still feels like it has one foot in iOS and the other in the Mac. The redesigned App Store introduced with Mojave is similarly confused about which platform it is supposed to belong to, but I have no clue what framework it’s built on.

The thing common to all of these apps is this — and you have to imagine that I am writing the next word with a similar tone to that which you might use in reference to a dog turd stuck to someone else’s gum stuck to the bottom of your shoe — button:

toolbar back button

This back button manifests in different ways in the apps I named above. Sometimes, it appears in the main toolbar alongside the traffic light window buttons, invisible until something happens in the app to cause it to show up. At other times — as in Music, TV, and Podcasts — the app will draw a toolbar containing only that button, usually very small and floating somewhere off to the lefthand side.

In no circumstance will it indicate where it will take you back to. Not on the button, not if you click and hold, not in a hover-activated tooltip — you get no sense of what that button will do, other than taking you back somewhere, whatever “back” and “somewhere” mean. If you click it immediately after performing an action, you probably have a good sense of what will happen. But if you search something in Music, click on a playlist in the search results, click on an artist in the playlist, play an album, and then go do another task for half an hour before returning, will you remember where that back button ought to take you? More to the point, will it take you where you might expect?

This back button does not behave like the one in any web browser which, I expect, is the back button any user is most familiar with. Trackpad gestures don’t work with it, so you cannot peek at the previous item. There are ways in which these apps try to meet in the middle ground between a standard Mac app and a web app — Apple Music is basically just a web view within Music, and you feel every aching moment of that, so the back button kind of works. Yet, the moment you get into the more Mac-like local music library section the app, the back button’s intent disintegrates. Here’s an example:

  1. Click on the Albums view of the local library.1

  2. Click on any artist name in that view. It’s grey text that doesn’t look clickable but, trust me, it will take you to a list of albums in your library from that artist.

  3. A new secondary sidebar will appear containing a list of all artists in your library. Click on another artist’s name.

  4. Click the back button.

This should, theoretically, load the most recent view — it should return you to the list of albums by the artist in step two. That’s what the back button in Finder’s column view does. But it doesn’t; it goes all the way back to your entire list of albums.

Is this a problem with Music, maybe? It’s janky as hell: it is inexplicably worse to use than iTunes despite losing the added-on cruft of TV shows, movies, iOS device management, and so on. It’s also built on decades-old code. What about something more modern — a direct iOS port, for example? What about News?

  1. From the Today view, click on any story.

  2. Swipe from right to left on your trackpad to advance to the next story.

  3. Click the back button.

Step two feels pretty much the same as something you might do in a web browser, yet the back button returns you to the Today view’s “home page”. Surprise!

Maybe you are getting the impression that, in these apps, the back button is a way of returning to the top level of a section. So let’s test that in the Mac App Store.

  1. From any of the store sections, click on an app from a well-known developer. I went with OmniGraffle from the Omni Group.

  2. Click on the developer’s name to pull up all of the apps they make, then pick another app. In this case, I picked OmniFocus.

  3. Click the back button.

Think maybe it will take you back to the top level of the store, or maybe to that first app’s page? Nope: it behaves like a standard back button and takes you to the list of developer’s apps that was previously open.

It does not even appear in all of the instances you might expect. For example, if you open an app’s page from the Discover screen of the Mac App Store, the back button appears. However, if you open one of the “editorial” stories, no back button appears at all. There is only a “Done” button that, bizarrely, sits in the upper-right corner of the App Store app instead of the back button’s upper-left positioning, requiring that you hunt for it as you vaguely recall that editorial items are somehow special or different.

The more common apps that have long featured back and forward buttons do not function in these peculiar ways. Web browsers do not; Finder doesn’t; neither does System Preferences. And, as I was writing this article, I was worried that it would be made obsolete by the forthcoming release of MacOS Big Sur, but everything is pretty much identical as of the latest beta.2 If the back buttons in the apps listed at the top of this post do not conform to the system standard in any way, the obvious question is something like: “why do these apps have a back button at all?”

In every instance, it seems to be a catch-all attempt to solve complex UI design problems. In Catalyst apps, it kind of works like the iOS system back button. In the App Store and in Music, it is a way to display web-based pages without having to implement a hierarchical navigation structure. In Photos, I suppose it is a way to reduce the amount of toolbars and buttons onscreen compared to iPhoto, and to make it conform closer to its iOS counterpart.

For completeness, I should note that iPhoto used back buttons in a handful of views. You can see one in the upper-left of the screenshot in this tutorial, but you will notice that it is labelled. When a user clicks it, they know they will be returning to the “All Events” view. The floating carets of Apple’s post-iOS 7 design language replaced contained back buttons — one of the more upsetting casualties of that redesign, I think — but MacOS still has buttons. If these back buttons were labelled, it would make them better.

I return, however, to my view from two paragraphs ago. I see these back buttons as a sort of cop-out — an easy way of covering for a lack of deeper consideration. You can see this most clearly in iTunes running on Mojave, in which there are two very different implementations of every view: the Apple Music way, and the local library way. If you open an album from the Recently Added view, it expands to reveal the track list below. If you open an album from Apple Music, you get sent to a new page, presumably because it is not possible to implement the local library style in a way that is performative or works across different platforms. It reveals the web-based underpinnings of Apple Music, it is slow, and it necessitates a back button.

In Catalina’s Music app, the two different implementations of an album view were dropped in favour of the Apple Music style. Now, it always opens an album in a separate view. As in every one of the apps I listed above, this decision makes Music feel like a semi-native wrapper around a collection of webpages, even when many parts of the app are still entirely native.

I do not think it is always wrong for an app to have a back button; it is a mechanism that works just fine in a web browser and in file managers. But I think that this new breed of apps that try to bridge the gap between MacOS and iOS use this specific implementation of the back button as a crutch. It is an inelegant way of dealing with inelegant and unique design problems. Its pervasion is a big flashing CAUTION sign that Apple’s Mac apps are not being lavished with the design attention they once were and still deserve. What bothers me more than what the button is is what it represents: it is, uncharacteristically for Apple, lazy.

  1. By the way, another casualty of the mixed MacOS and iOS metaphors is how the sidebar does not reflect the user’s behaviour in the app. For example, you can choose an artist in your local library and show their page in Apple Music. You can drill deeper, click on related artists, and do all of the Apple Music-ey things you might expect — but the sidebar will still indicate that you are in your local music library. ↥︎

  2. The sole difference in the examples I referenced here is that the App Store in Big Sur no longer has a “Done” button for editorial materials. Its toolbar has unified around the back button. ↥︎

Reuters Interviews Phil Schiller Ahead of U.S. Antitrust Hearing ⇥ reuters.com

Stephen Nellis, Reuters:

“One of the things we came up with is, we’re going to treat all apps in the App Store the same – one set of rules for everybody, no special deals, no special terms, no special code, everything applies to all developers the same. That was not the case in PC software. Nobody thought like that. It was a complete flip around of how the whole system was going to work,” Schiller said.

I know I wrote this once before today, but this simply isn’t true and I don’t understand why Apple’s representatives keep repeating it when it is so easily proved false.

Peter Steinberger enumerated several entitlements given to high-profile developers in a Twitter thread:

Panic’s com.apple.developer.security.privileged-file-operations

BBEdit’s com.apple.security.automation.apple-events

Microsoft’s com.apple.security.files.user-selected.executable

com.apple.developer.passkit.pass-presentation-suppression that we didn’t get

Amazon’s com.apple.storekit.request-data to run purchases without that 30% tax.

Uber’s com.apple.private.allow-explicit-graphics-priority

These entitlements are given to apps from trusted and revered developers; I do not necessarily think that it is wrong for Apple to be selective about the use of these exemptions. But the very existence of anointed apps shows that Schiller’s claim is not accurate.

It also means that it’s harder for an ordinary developer to compete with these apps. Uber’s use of that entitlement allowed it to improve the performance of its Apple Watch app; the entitlement afforded to Panic allows a user of Transmit, purchased through the Mac App Store, to edit unowned files. Microsoft’s products have a host of entitlements that allow for a similar user experience no matter if they were purchased through the Mac App Store or separately. Normal developers, lacking access to these entitlements, may not be able to implement some features with the same experience.

Nellis, Reuters:

In the mid-2000s, software sold through physical stores involved paying for shelf space and prominence, costs that could eat 50% of the retail price, said Ben Bajarin, head of consumer technologies at Creative Strategies. Small developers could not break in.

Bajarin said the App Store’s predecessor was Handango, a service that around 2005 let developers deliver apps over cellular connections to users’ Palm and other devices for a 40% commission.

With the App Store, “Apple took that to a whole other level. And at 30%, they were a better value,” Bajarin said.

This piece of analysis is pretty generous to Apple, and Nellis does not adequately contextualize it or push back. Software differs from physical goods in that it is both pragmatic and typical for creators to sell their product directly to users. I get why the App Store is being compared to other stores and marketplaces, but it isn’t as though buying software from the developer is uncommon.

But the App Store had rules: Apple reviewed each app and mandated the use of Apple’s own billing system. Schiller said Apple executives believed users would feel more confident buying apps if they felt their payment information was in trusted hands.

“We think our customers’ privacy is protected that way. Imagine if you had to enter credit cards and payments to every app you’ve ever used,” he said.

That’s how it has been done for ages, but I think Schiller’s right — I prefer using Apple’s in-app payment mechanism. I wish it was a better solution for developers, even without considering Apple’s commission. I wish it was something developers and users got to choose rather than having it forced upon them.

Climbing Up the Walls

Apple’s introduction at WWDC of Macs running on own-brand processors was as complete as many people were expecting. There was a rationale for the transition, an explanation of how developers can make their software run on these new systems, a way for older software to run without developer intervention, and a timeline for its rollout.

But what was not changed with this transition has proved to be just as interesting as all of the new things that were shown off. Apple is going to great lengths to make this transition as seamless as possible. It is contributing patches to popular open source projects, even Electron, and it is even bringing deprecated technologies like OpenGL to ARM. Most importantly, the company has repeatedly promised that it will not be taking the Mac to a more locked-down model like iOS.

For some reason, these assurances have not stopped Alex Cranz of Gizmodo from speculating that this is Apple’s walled garden “grow[ing] higher”:

Apple has finally announced its long-rumored transition away from Intel chips and will now make its own homegrown CPUs based on the ARM architecture for future Macs. The company’s goal is to shed its dependence on Intel so that it can control even more of its production and development pipeline. It’s an interesting move at an even more interesting time, given that Apple CEO Tim Cook has also finally agreed to testify on Capitol Hill in a Big Tech antitrust hearing. Just last month, the European Union opened its own antitrust probe into Apple and its App Store. The company is being investigated and criticized for its near-perfect execution of vertical integration more than ever before, just as it’s taking its biggest step toward its grand vision of vertical integration in nearly 15 years.

So that’s the argument: Apple’s vertical integration of own-brand processors for the Mac is of similar concern to the App Stores and in-app purchase rules that it enforces on iOS. I don’t think that makes any sense at all but, first, let’s hear from an analyst about why Apple would want to switch from Intel:

“Apple hasn’t been very successful over the past five years with the Mac and most of the innovation has come from Windows vendors,” analyst Patrick Moorhead told Gizmodo. “I think Apple sees vertical integration as a way to lower costs and differentiate. We’ll see. It’s a risky and expensive move for Apple, and right now I’m scratching my head on why Apple would do this. There’s no clear benefit for developers or for users, and it appears Apple is trying to boost profits.”

The Mac’s reputation has suffered in the last five years due, in part, to the crappy keyboards it shipped on its laptops and less-frequent product updates — and one reason it did not release new Macs as often is because Intel struggled with new processor development. But it should not be surprising that Moorhead ignores the benefits that Apple stated for users and developers and the problems Intel has had because Intel is one of his clients, something this article does not mention.

Also, despite its keyboard problems and more stagnant product line, Apple’s Mac sales over the last five years have been its best ever. It’s hard to see how it “hasn’t been very successful” on those grounds.

Cranz spends the next several paragraphs explaining why a purely financial argument does not adequately justify the processor switch. True. There are also many paragraphs about the benefits of and problems with Apple’s control over the App Store on iOS. That takes us to the core of Cranz’s argument:

Unlike iOS, macOS developers have always been able to skirt around using the Mac App Store. I can go to directly to a developer’s site for most apps and just buy what I want outside of the App Store. But how long will that continue in the future macOS landscape, particularly if the main people developing for the operating system are doing so alongside their iOS and iPadOS builds? Apple has repeatedly said it has no plans to turn macOS into a walled garden, as has always been the case with iOS and iPadOS, but it might effectively have done just that with the ARM switch.

That’s it. There is no greater explanation offered for why switching to a different processor architecture is an equivalent to the App Store model on iOS. Cranz points out all the ways the ARM transition is supposed to be easy for developers and invisible to users and some of its unique benefits, but writes absolutely nothing to justify this particular statement, other than the FUD-grade question about how long developers will keep shipping their apps independently. Given the state of the Mac App Store and how many developers would prefer to keep as much of their revenue as they can — this very article began with a nod at antitrust investigations over Apple’s in-app purchase requirements — I see no reason why great Mac apps won’t continue to be offered directly by developers.

Brent Simmons:

[…] I had been very worried that Apple would, as part of the ARM transition, lock down macOS so that only Mac App Store apps would be permitted.

That didn’t happen. And Apple employees explained that it’s not going to happen — and, given that it didn’t happen this time, given that they had this chance, I believe them.

I understand adding security features to the Mac. But to take away our freedom to create whatever Mac apps we want, and distribute them without Apple’s, or anyone’s, seal of approval, would be to take the heart out of my career.

But that’s not what happened! I feel great about this. I’m going to stop worrying about the Mac.

I was also fretting about what a Mac running on Apple’s own processors might entail. I was nervous about how difficult it might be to upgrade to one when it comes time to do so. I still have my concerns, but I truly believe Apple when it says that it does not want to merge the Mac and iPad, or implement an iOS-like App Store-only model on MacOS.

Cranz’s pieces feels like one of those articles where a writer started with a premise and found the parts that fit while ignoring those that did not. Just about everything that is possible on a Catalina system running on Intel will be possible on a Big Sur system running on Apple’s own processors, with the exception of using Windows through Boot Camp. It’s not nothing, but it does not indicate an expansion of a walled garden, either. We can speculate all we want about whether this might change down the road, but Apple laid out good reasons why it is not planning an iOS-alike model for the Mac. In short, it would not be good for Apple, it would not be good for developers, and none of that is good for users. Makes sense to me.

Catalina’s Dialog Bureaucracy

A few weeks ago, shortly after completing a clean installation of Catalina on my MacBook Air, I had a funny idea: wouldn’t it be great to reinstall Lion, the operating system it shipped with, and see what it is like to use nearly ten years after it was released?

I haven’t touched a truly old version of MacOS in years, and certainly not one called “Mac OS X” in a very long time. For a start, installing an old version of MacOS in 2020 is more difficult than it sounds, especially if you don’t have a copy of the specific or newer version of the operating system that shipped with your Mac because you resolved to become slightly better about your data hoarding habits.

It becomes significantly easier after you recognize that you failed that resolution.

Installing Lion was refreshing — in part because there are far fewer steps in Setup Assistant. There are just eleven screens, the last of which informs users that Lion changes the direction the trackpad scrolls relative to the material onscreen. There’s an animation of this and, cleverly, Apple requires users to scroll to the bottom of a small text area to click the button that finishes the setup process. You may not start using Mac OS X Lion until you have learned how to scroll.

However, perhaps the most notable part of installing Lion was that it was ready to go immediately after completing the steps in Setup Assistant. The last screen appears and confirms that Lion is set up, then the desktop zooms in, and then you can use your computer right away. Sure, Spotlight will be indexing, so it will be slow for a while, but you can get started.

Catalina is different. Many steps have been added to Setup Assistant since Lion, including options to turn on location services, enable Siri, enable various iCloud features, and — for Macs with supported hardware — steps to enrol fingerprints for Touch ID and add credit cards for Apple Pay. Some screens have been removed (remember registering your Mac?) or consolidated (picking the user picture is now done when setting up the admin user account), but the process is still far more expansive than it used to be. I counted at least seventeen screens; some screens have been consolidated as an “express setup” option, and the Apple Pay and Touch ID features are not supported on my Mac.

And that’s just Setup Assistant. After you complete those steps and you see the Catalina desktop for the first time, you have more work ahead of you. Apps need permission to send you push notifications, permission to use your contacts, and permission to use your location. Even though you said you wanted to switch on Location Services and that it was okay for Maps to use your location, Maps will ask for your location the first time you run it. Calendar will ask to use your location immediately after setup finishes. The weather widget in Notification Centre will need to be granted location permission now and probably several times in the future. Notifications will appear that you will need to dismiss.

There’s more, too. If you download apps from a source outside of the Mac App Store, you’ll be asked if you really want to open the app upon its first launch. This has long been a feature of MacOS’ Gatekeeper security software, but Catalina requires apps to be notarized. If the app is not notarized, Catalina will tell you that the app “cannot be opened” and give you the options to cancel opening it or move it to the trash. This is a lie: you can open the app — any app — by visiting the Security & Privacy preference pane, clicking the “Open Anyway” button, and then bypassing another scary-looking warning dialog.

The way that Catalina determines whether an app is safe seems to depend on several factors, and they can collide in comical ways. While writing this piece, I wanted to install a fresh copy of Catalina on a new volume of my MacBook Air’s hard drive to verify the installation procedure above. However, I only had a copy of the installer on my iMac, so I AirDropped it to myself. When I went to run the made-and-signed-by-Apple package, originally downloaded from the Mac App Store, I was told that it could not be opened because it was potentially dangerous.

The path to this present reality more or less began with Lion. It was the first version of the system to be available through the Mac App Store, introduced in a late update to Snow Leopard, and, with it, came the “Allow Apps Downloaded From” section of the Security & Privacy preference pane. It originally contained three options:

  • Mac App Store

  • Mac App Store and Identified Developers

  • Anywhere

That last option has been hidden since MacOS Sierra. It’s still possible to open apps from anywhere, but MacOS now requires you to jump through hoops that weren’t there previously. And these hoops are ratcheted tighter with every recent version of MacOS. Catalina, in particular, is notable for the vast quantity and types of cautions that users are expected to handle.

Want to download a file from a website? Safari will get you to confirm that you actually want to download that file.

Explicitly typed a command in Terminal that accesses your desktop — even something as innocuous as ls ~/Desktop? You’ll have to confirm that you are, indeed, okay with Terminal’s desktop access.

Want to run ls ~/Downloads? You’ll have to okay access to that folder, too. There’s no way to say, in any of these dialogs, that you’re entirely okay with anything Terminal wants to do. You can, however, give Terminal full disk access in a different tab of the Security & Privacy preference pane.

Security & Privacy was one of those things in Preferences that you used to set and forget. It now seems as though it’s something you’re expected to open regularly if you are a technically inclined user.

These security prompts and confirmation dialogs also have the effect of offloading some of the responsibility for a secure environment to the user in a way that, I believe, is unfair. It’s irritating to more technically literate users because it adds work to everyday tasks. For them, it is a regression.

Less technical users, on the other hand, do not have the skillset to determine what is a security concern and what isn’t. It doesn’t help that some of Apple’s own apps, daemons, and background service have inscrutable process names and many of them need some form of permission or password to run. Nor is it helpful that the Gatekeeper warnings change in mysterious and undocumented ways. But, even if everything were perfectly labelled, a user with less technical background wouldn’t have an informed clue about what they should allow and what is genuinely dangerous.

Furthermore, we know that overloading users with permission prompts encourages them to click whatever button will allow them to move on with their task, which means that they are more likely to agree to something unintentionally. We also know that people exposed to alerts and alarms on a frequent basis learn to tune them out, even in cases where those alarms are extremely important, like in hospitals (PDF). The fire alarm in my apartment building has been mistakenly activated so frequently that it is more or less just background noise. I’ll probably burn to death one day. I’ll also probably mistakenly click an “okay” button and unleash some form of minor havoc on my computer because I am inundated with permission prompts.

It’s not just security-related permissions, either. When a MacOS app wants to show push notifications, it must ask the user for consent. It’s the same thing for location, use of the microphone, a Mac’s camera, and accessing contacts, calendars, reminders, and photos. And then there are APIs that allow apps to watch over keystrokes, control other apps, and control the computer. Individually, these permission requests aren’t dreadful, but they quickly accumulate.

I’ve seen various proposed solutions to this onslaught, often centred around the idea that MacOS now needs some sort of “pro mode” — a command line switch or something of the sort that allows an advanced user to disable much of the system’s nanny state policies. That’s not a bad idea, but I don’t think it fully acknowledges how bad this situation is.

Permission consent dialog boxes are a particularly ham-fisted approach towards privacy and security. They are a last-ditch effort; an over-reliance upon them in Windows Vista was famously parodied by Apple in a “Get a Mac” ad. At best, they are irritating. But, at their worst, they are an acknowledgement by the company that builds the platform that they have been defeated in a larger argument.

The reason there are so many privacy-centric requests is because there are basically no limits to the exploitation of personal data. If we had the confidence that allowing an app access to our contacts, for example, would not expose that list to data mining and privacy-invading marketing nonsense, we would not need to spend time granting permissions.

Unfortunately, there isn’t a comparable fight for security vulnerabilities. Users’ trust is an infinitely exploitable resource and it is the primary job of malware creators to do just that.

Yet I return to my argument that requiring users to determine which processes are safe is a demand that is overwhelming to most and disruptive to the comparatively few users who are equipped to handle such a decision.

Of course, there are other protections built into the system that help prevent malware and other problematic software from running. Apple explains several of these on its marketing page for Catalina, and there are other technologies like sandboxing and the antivirus protection offered by XProtect and MRT. But if security is, as with so many things in life, like an onion, the dialog boxes are like individually wrapping a bag of the things in clingfilm: it ends up being something that gets in the way for pseudo protection. These seemingly endless permission requests disrupt the Mac’s balance of capability and user friendliness.

The future of the Mac — a friendly face atop a powerful Unix core with an amazing software ecosystem — should not be a bureaucracy that cripples its finest qualities, nor one which users are responsible for fidgeting with.

Update: The Mac App Store was introduced in an update to Snow Leopard, not Lion, as previously and incorrectly stated.

MacOS Will Soon Support Universal Apps, Enabling a Single Purchase for Mac, iPhone, and iPad Apps ⇥ macstories.net

Ryan Christoffel, MacStories:

As first spotted by Steve Troughton-Smith, release notes for the latest beta build of Xcode include a major development: Mac apps can soon be included as universal purchases with their iPhone and iPad companions.

Apple:

Starting in March 2020, you’ll be able to distribute iOS, iPadOS, macOS, and tvOS versions of your app as a universal purchase, allowing customers to enjoy your app and in‑app purchases across platforms by purchasing only once. You can choose to create a new app for these platforms using a single app record in App Store Connect or add platforms to your existing app record. Get started by building and testing your apps using a single bundle ID with Xcode 11.4 beta.

This has the potential to be great news for MacOS developers who want to create iOS apps and don’t want to devalue the products on either platform. I could imagine a situation where a Mac developer sells an app for $50 and wants to create an iOS app, but might struggle to find buyers for it at $10. Instead, they could charge $70 or $80 for the bundle. The Mac apps don’t have to be Catalyst apps, either.

This is interesting, too, in Apple’s notes:

In addition, App Store categories will be unified across the App Store and Mac App Store to align with this change, and to help make your apps more discoverable. The following changes will be made.

  • You’ll be able to select the following categories for iOS apps: “Developer Tools” and “Graphics & Design”.

I’m not sure it means anything beyond unification that the iOS App Store will now have a Developer Tools section, but it’s promising.

Catalyst and Cohesion ⇥ wormsandviruses.com

Jack Wellborn:

[…] Developers using first party tools from Apple shouldn’t have to swim upstream to build cohesive Mac versions of their apps. I am not saying that the existence of any incongruous Catalyst ports is worrisome — incongruous ports are inevitable and Catalyst is an opportunity to make them better — what’s worrisome is that incongruity seems to be the default with Catalyst.

Look no further than Apple’s own Catalyst ports. Developers have enjoyed a variety of good first party examples on both Mac OS and iOS. Mail, TextEdit, Preview, Notes serve as examples of what good cohesive apps on those platforms should look like. Outside of maybe the Podcasts app, Apple made Catalyst apps feel like ports.

Wellborn’s use of the word “cohesive” is inspired and speaks to the root of my worries about Catalyst. Great MacOS apps are often not entirely consistent, but they are cohesive — apps with unique user interfaces, like Coda and Tweetbot, feel very Mac-like, even though both are from third-party developers and neither one looks especially like Mail or Preview.

It worries me that some of Apple’s own MacOS apps lack cohesion; and, though Catalyst is the purest expression of this concern, it is not solely at fault. The redesigned Mac App Store that debuted in Mojave certainly looks like a Mac app, but it feels and functions like a crappy port from some distant platform. It launches by zooming in from the desktop; editorial collections open with an absurd sliding animation and cover the entire app like a sheet; it contains a truly bizarre combination of large click targets and tiny buttons. And none of this can be blamed on a bad Catalyst port, because the Mac App Store is not a Catalyst app, as far as I can tell.

It is frustrating to see Apple release a mediocre porting utility like Catalyst, but it is truly concerning that some of their newer Mac apps feel this incongruous. It would be one thing if it were a third-party developer, but these are first-party apps. As much as I am excited by the prospects of SwiftUI, I have to wonder whether this current stage of cross-platform-influenced Mac development is a distraction, or portends the lazy Mac experience of the future.

Update: Now that my MacBook Air is running MacOS Catalina, I see that the Mac App Store is improved compared to Mojave. It no longer features the comical zoom animation at launch, and the escape key can now be used to dismiss editorial collections. But it still doesn’t feel like a Mac app. Also, the JetEngineMac framework has been moved from within the Mac App Store app package to /System/Library/Private Frameworks, along with a new JetUI framework.

Owen Williams Rounds Up ⇥ onezero.medium.com

Hey, remember how a change was made to more accurately scan private API use for Mac App Store apps, and it caused Electron apps to be rejected because they rely upon Chromium? And even though these apps are still available for the Mac, they’re just not in the Mac App Store until the Electron project excludes said private APIs?

In Owen Williams’ eyes, this is nothing less than Apple “trying to kill web technology”. That’s right: Apple is trying to kill the web on all of its platforms, starting with the Mac:

But Apple has a reason not to like this recycling of web technology. It wants its Mac App Store to be filled with apps that you can’t find anywhere else, not apps that are available on every platform.

That’s why they’ve been so hesitant to promote cross-platform apps like those in the Microsoft Office and the Adobe suites, going so far as to only give them a few minutes of keynote time and publishing their press releases.

Electron has used these private APIs for years without issue. These private APIs allow developers to, for instance, drastically improve power usage whereas Apple’s sanctioned tools make the user experience worse. In the majority of these cases, Apple doesn’t provide real alternatives for developers who want to access these private API features.

Are private APIs unfair? Almost inherently so. Should the use of any API be withheld from distributed software until a public API is available for third-party developer use? That’s debatable.

But, again, Apple is not prohibiting the use of private APIs generally; they just don’t want apps in the Mac App Store that use private APIs. That’s a big difference.

Also, for what it’s worth, the Mozilla post that Williams links to doesn’t actually say that they’re using any restricted or private APIs, just that they updated Firefox to use Core Animation to improve its battery life and performance on MacOS.

Developers could distribute their apps from their own websites, asking users to download them directly. But that means abandoning features like Apple’s auto-update mechanism from the Mac App Store and iCloud sync. And this direct-to-consumer method could soon be locked down, too, with Apple’s controversial notarization requirements potentially requiring their review.

Setting aside the ability to use iCloud syncing in apps not distributed through the Mac App Store, notarization does not equate to locking down MacOS to outside distribution, despite Williams’ scaremongering. I have problems with notarization and Apple’s strategy for MacOS security, but Williams’ interpretation is overly simplistic and dependent on fear.

Williams follows with a couple of examples of how Apple does not implement new web standards as quickly as other browser makers do, and that leads him to this thesis:

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.

First, the premise of this argument isn’t a secret, nor is it new. Apple has long said that apps which are basically wrappers around websites should just be websites — most recently in September.

Second, Apple continues to develop and improve upon in-app web functionality, including fixing things like lacklustre WebRTC support in third-party apps, something Williams complains about in his post.

Third, encouraging a distinction between apps and websites does not therefore lead to the headline “Apple Is Trying to Kill Web Technology”. That’s rounding up to the nearest crisis position, and is wildly misleading. Plenty of ostensibly native apps continue to use web technologies — even many of Apple’s.

Apple has done a lot of stupid and controlling things in the moderation of their App Stores, but this isn’t one of those instances, and it certainly does not produce the panic-inducing headline of Williams’ post.

Apps Built With Electron 6 and 7 Are Currently Being Rejected From the Mac App Store ⇥ david.dev

“David Dev” (sic):

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) […]

I’m seeing a lot of anger directed at Apple over this, including accusations of monopoly practices and allegations that this is some sort of plot to neuter computing except for the ways in which Apple says you can use your Mac. This is ridiculous. These apps are being rejected from the Mac App Store, but can be distributed elsewhere; the Mac is not a closed platform. I get why this is frustrating: the lack of communication by Apple when changes are made to the App Review process may come as a surprise, and Electron is a popular framework upon which entire apps rest, so changing it would require a lot of work.

If anything, though, the main culprit here is whichever part of Electron — either Electron itself, or Chromium, upon which it is based — decided to use private APIs in the app. Apple has been wildly inconsistent with many aspects of its App Stores, but on private APIs the company has stood firm: they may not be used. It would have been useful for Apple to announce this change if it knew the revised App Review process would prevent Electron apps from being accepted into the Mac App Store, but it is by no means a death sentence for these apps, nor is it their responsibility to ensure that every intermediate app layer made by a third-party is compliant.

Update: Michael Tsai:

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.

The first point is relevant, but does not make a difference in whether the apps should be approved, hence Tsai’s second point. The third and fifth points are yet another entry in Apple’s biggest problem with the App Review process, which is its inconsistency and opacity.

But the fourth argument here is critical: private APIs are risky to use in any case, but it’s absurd to use them in a software platform. In this case, it’s layers of dependencies failing developers: apps are built on top of Electron, which is built on Chromium, which uses private APIs to help its atrocious battery and CPU consumption. It isn’t as though Slack — to use a notorious example — actually needs a 200 MB app to run its glorified IRC client.

MacOS Catalina’s Teething Problems ⇥ tyler.io

Mark Gurman, Bloomberg:

Apple rolled out Catalyst, the technology to transition iPad apps into Mac versions, on Monday. It’s the initial step toward a bigger goal: By 2021, developers should be able to build an app once and have it work on iPhones, iPads and Mac computers through a single, unified App Store. But the first iteration, which appears to still be quite raw and in a number of ways frustrating to developers, risks upsetting users who may have to pay again when they download the Mac version of an iPad app they’ve already bought.

From a user’s perspective, buying different apps on different platforms is the status quo; and, as the subscription model continues to grow in popularity, it makes little difference.

Gurman, continued:

Developers have found several problems with Apple’s tools for bringing iPad apps over to Mac computers. Some features that only make sense on iPad touchscreens, such as scrollable lists that help users select dates and times on calendars, are showing up on the Mac, where the input paradigm is still built around a keyboard and mouse or trackpad.

Troughton-Smith said Mac versions of some apps can’t hide the mouse cursor while video is playing. He’s also found problems with video recording and two-finger scrolling in some cases, along with issues with using the keyboard and full-screen mode in video games. Thomson, the PCalc developer, said some older Mac computers struggle to handle Catalyst apps that use another Apple system called SceneKit for 3-D gaming and animations.

Catalyst is a frustrating bridge between the entirely-discrete AppKit and UIKit worlds, and the ostensibly cross-platform SwiftUI model. It’s “frustrating” because apps built with it don’t feel like Mac apps, and it’s probably too early to start building with SwiftUI since it will likely change dramatically for developers over the next few years. It’s an awkward middle ground that isn’t as good as either. Apple’s promotion of it as “just a checkbox” in Xcode — and, weirdly, using that as part of its pitch to users — is overly optimistic.

That’s not to say that there are no good Catalyst apps. John Voorhees reviewed Lire for MacOS and was fairly impressed with its platform-specific customizations. But it’s a harder process than Apple promotes to developers, and I’m still not confident we’ll see truly great apps built with Catalyst.

Tyler Hall has compiled a list of bugs that he has run into so far:

I love the Mac and everything its software and hardware stand for. The iMac Pro and new Mac mini are phenomenal. The revamped Mac Pro (six years? really?) is a damn beast. And, honestly, I don’t even mind USB-C.

But the keyboards, the literally hundreds if not thousands of predatory scams on the Mac App Store, whatever the fuck is going on with Messages.app on macOS, iCloud Drive, the boneheaded, arrogant, literally-put-on-the-consumer-facing-marketing-website claim that iPad-to-Mac with Catalyst was merely a checkbox, all the dumb, stupid little bugs I mentioned above, and the truckload of other paper-cuts I’m sure to run into once I’m on Catalina for more than 48 hours…

My god.

It is absolutely clear that the Mac is far outside of what the upper-ranks of Apple is focusing on.

It is unsurprising to find bugs in an x.0 release of anything, but this post is maddening. The number and variety of bugs in iCloud-connected things is concerning when it displays error messages; it’s even worse when something silently fails.1

It’s not the fault of the engineers; it’s the fault of whichever parties have decided that software updates must ship annually. While I’m happy to see that they’re willing to delay features that aren’t ready, Apple’s operating system updates are promoted every June with features that may not ship for months after the initial release and the first versions are still full of absurd bugs. It feels chaotic and uncontrolled — like all middle managers for every organization are not on speaking terms.

  1. A quick aside that has little to do with Catalina but has everything to do with silent failure and bug reporting: I’ve written a couple of times about how the Home app simply doesn’t work for me on any device. It just displays a screen that says “Loading Accessories and Scenes” and has an infinitely-running spinner on it. There is no error message; there is no way to move past this.

    What’s supposed to happen, according to Apple, is that a button for resetting HomeKit should appear somewhere on that screen if you leave it open for half an hour. This is their official troubleshooting recommendation. I cannot possibly stress enough how absurd it is that someone decided that the best way to present a reset button is for a screen to be left on and running in the foreground for an entire episode of Last Week Tonight, and users should somehow expect to know that a button will emerge from an otherwise-empty space. It’s also silly that there’s no remedy for HomeKit errors anywhere between live with it and delete everything; why isn’t there a way to roll back to a known good configuration?

    Anyway, I’ve tried this several times on different devices across four versions of iOS — 10.0 through 13.2 — and in MacOS Mojave, and I’ve never seen this unicorn of a button.

    This wasn’t a big deal — I don’t have any HomeKit devices — until I updated to tvOS 13, which prompted me to add the device to my Home network. I tried; it failed, predictably. And I have an allergy to red notification dots in Settings. So I got in touch with Apple support. In the past two weeks, I’ve spoken on the phone for several hours, sent in a couple of sysdiagnose examples, and have repeatedly pointed out that this occurs on all of my devices, so it’s likely to be something iCloud related and all I want to do is start from scratch. I don’t blame the support representatives for their inability to fix this, but it is tedious and irritating that there is seemingly no way for me to fix this silently-presenting problem myself. ↥︎

Defining ‘Free’ For All

Brent Simmons wrote a piece recently that I’ve been thinking about a lot:

In a way, it feels like iOS devices are rented, not owned. This is not a criticism: I’m totally fine with that. It’s appropriate for something so very mass-market and so very much built for a networked world.

But what about Macs?

Macs carry the flame for the revolution. They’re the computers we own, right? They’re the astounding, powerful machines that we get to master.

Except that lately, it feels more and more like we’re just renting Macs too, and they’re really Apple’s machines, not ours.

With every tightened screw we have less power than we had. And doing the things — unsanctioned, unplanned-for, often unwieldy and even unwise — that computers are so wonderful for becomes ever-harder.

I don’t mean to pick on Simmons here — I’m not picking on anyone, in fact. I’ve seen a similar sentiment expressed by lots of people lately; but, in particular, due to two recent triggers: Marzipan apps, and app notarization. So that’s been rattling around my head lately.

But I’ve also been thinking about a piece by John Gruber, written between the time the iPad was unveiled and when it was made available to buy:

If you could go back and show my 10-year-old self an iPad — millions of colors, video, photographs, gorgeous typography, a touchscreen interface, networking (wirelessly!) — and offered to let me write web apps for it in exchange for my agreeing never to touch an Apple II again, I’m pretty sure I know what the answer would be.

Something important and valuable is indeed being lost as Apple shifts to this model of computing. But it’s a trade-off, because something new that is important and valuable has been gained.

Change is uncomfortable, particularly when it involves a shift in the balance of power. The things that developers can do in MacOS today are, in some ways, more limited than what was possible thirty years ago. Restricting a developer’s access to memory, for example, has likely made computers more secure and more stable, but it would not be possible without shifting control away from developers. Over the same time period, developers have been able to do far more due to greater system capabilities and easier-to-use tools.

I have not kept secret my personal feelings about the four iOS apps Apple shipped with MacOS Mojave. They are poor Mac apps. I am, therefore, more than a little apprehensive about what lurks a month away at WWDC. But I, frankly, don’t give one thought to what technologies any app is built with so long as it behaves like a Mac app. Electron-based apps, clearly, do not; neither do the apps Adobe has shipped for the Mac since, like, always. But if Panic’s next version of the-app-formerly-known-as-Coda is built with the same underlying code base for Mac and iOS devices and it feels entirely native on both, who am I to complain?

What does this say about platform freedoms and capabilities in general? Will Apple one day require all third-party Mac apps to come from the Mac App Store; or, would they consider locking down the platform entirely? I think the doom and gloom thoughts are wildly off base.1

Do I know, for certain, that Apple isn’t going to massively fuck up MacOS through its own actions and what it encourages from third-party developers? Of course not. But I think there’s a whole world of developers out there who are eager to find out what they can do once MacOS 10.15 ships because, perhaps, those things were unnecessarily complex or out of their reach. Something about that is, in its own way, freeing.

  1. A separate but related consideration is Apple’s motivation for control. There are some people who, as I see it, consider Apple fetishistic about controlling their platforms for no other reason than for its own sake. I don’t buy that. I think there are specific motivations for when Apple tightens control over something, often with security and privacy in mind. Their effectiveness at doing so is debatable, but I don’t see it as control for control’s sake. ↥︎

Netflix and Spotify No Longer Allow iTunes Billing for New Users ⇥ venturebeat.com

Manish Singh, VentureBeat:

Netflix is further distancing itself from Apple’s iTunes tax bracket. Earlier this year, the streaming giant enabled iOS users in more than two dozen markets to bypass the iTunes payment method as part of an experiment. The company now tells VentureBeat that it has concluded the experiment and has incorporated the change globally.

“We no longer support iTunes as a method of payment for new members,” a Netflix spokesperson told VentureBeat. Existing members, however, can continue to use iTunes as a method of payment, the spokesperson added.

Damien Basile:

Companies are doing this more & more. Spotify doesn’t allow you to pay via Apple. And why should they? 30% is a huge fee to give to Apple when you have the name and market presence. Makes me wonder what Apple will do if this trend proliferates even more.

This is despite changes made last spring to Apple’s cut of subscription pricing, which is now set at 30% for the first year and 15% for every year thereafter.

Apple’s cut is booked under the broad “services” category in their financial reports. Services revenue, as a whole, has been growing rapidly for the company, but I’d be curious to know how much these moves are impacting Apple’s take. My initial assumption was that it must represent a lot of lost revenue for Netflix and Spotify, but perhaps it’s such a small amount that it’s worth the risk of some potential customers giving up on figuring out how to subscribe.1

Regardless of how much lost revenue Apple’s cut represents for Netflix and Spotify, it strikes me that this is an option for only a handful of established companies. In addition to the aforementioned, Adobe can also forego Apple’s option in favour of their own Creative Cloud subscription. The only indie company I can think of that is trying a similar approach is Panic with Transmit 5: it’s $45 directly from them, or a $25 per year subscription if purchased through the Mac App Store. This doesn’t seem viable for most small developers because of the more circuitous route customers have to take without instruction — see footnote — nor does it seem very efficient or safe, given that it requires many small studios to build a paid account infrastructure.

Update: Lawrence Velázquez points out that 1Password has a similar purchasing and subscription arrangement to Transmit 5.

  1. Which, by the way, is something Apple makes more complicated because they forbid developers from mentioning subscription options outside of officially-sanctioned in-app purchases. ↥︎

Safari Extensions in the Mac App Store ⇥ lapcatsoftware.com

Jeff Johnson:

Earlier this year, Apple announced that .safariextz files are deprecated, and starting January 1, 2019, new extensions will no longer be accepted to the Safari Extensions Gallery. Apple now prefers that Safari extensions be distributed via the Mac App Store. In Safari 12, the “Safari Extensions…” menu item in the Safari main menu no longer takes you to the Safari Extensions Gallery but rather to the Safari Extensions section of the Mac App Store. Let’s examine that customer experience. We’ll take a glance at the old Mac App Store on High Sierra and then move on to the new Mac App Store on Mojave.

Placing Safari Extensions in the Mac App Store makes sense to me, but its implementation has been pretty lacklustre so far. First of all, the menu item links to an App Store story that cannot be viewed in a web browser, which is irritating.

When you get to that story, you’ll see that it is titled “Getting Started: Safari Extensions”, which implies that this is just a small selection of a much broader library of extensions. Here are the first ten in the collection:

  • Ghostery Lite

  • 1Blocker

  • MarsEdit

  • Magic Lasso AdBlock

  • Blogo

  • Ka-Block!

  • Bookmarx

  • Valt

  • Utility Cube

  • StopTheMadness

Not a terrible selection, but not great — as Johnson points out, Utility Cube is made by some developer who releases crap like a $2.79 version of Safari’s private browsing mode, several PDF scanning apps, and loads of other repackaged Apple APIs as apps. I would not trust the developer’s electronic wallet app. Why would Apple allow these apps into the store in the first place, much less highlight something they’ve made?

Anyway, if you try to find every Safari Extension in the App Store, you’ll have a very difficult time. As far as I can work out, it’s completely impossible. If you search for “Safari extensions”, you’ll get a list of results that is completely different from the ones in the collection above. Just two extensions from the list of ten above are returned in the entirety of the store’s search results. Eight of them just don’t show up anywhere.