Archive for May 27, 2019

Monday, May 27, 2019

Wish for a Return of Vibrant Tapdown States

John Gruber:

I don’t know why, but one of those things has been bugging me a lot in recent months: the drab gray color that indicates tapdown state for list items and buttons. Putting aside skeuomorphic textures like woodgrain and leather and the 3D-vs.-flat debate, the utter drabness of tapdown states is just a bad idea. I didn’t like it when iOS 7 debuted, and I like it even less 6 years later.

In classic iOS, when you tapped down on list items or buttons, they’d instantly light up in vibrant color. The standard color was a bright cheerful blue. In iOS 7 through 12, the tapdown state is the color of dirty dishwater.

Steven Aquino:

John talks about delight being sapped from iOS post-iOS 7, which is true in many ways. But the tap down state he calls out here is an accessibility issue too. iOS 6 blue was better—more visually concrete and contrasting.

Andy Lee:

Related: a key principle of graphical user interfaces is the notion of direct manipulation, which necessarily means clear and immediate visual feedback. More than once I’ve seen Apple fail in this respect.


Skeuomorphism was a visual device used to train users on how to use phones when we transitioned from the physical form to digital. It was a solution of the time and that’s all.

Kyle Howells:

I see this point of view a lot. That skeuomorphism was a crutch we as society needed but have now outgrown.

I think this sort of thinking is incredibly misguided and damaging.

Dan Masters:

Some joyful Apple software highlights

Benjamin Mayo:

The standard set by iOS 7-12 is much more drab, almost clinical. It’s a flat, nondescript, grey that seems like it was chosen specifically because it would not draw the eye. The grey is close enough to white that anything white would not have sufficient contrast, so the illumination effect is also no longer present. Cell content no longer reacts in tandem. The whole interaction is a lot more lifeless. Rather than the UI egging the user on to complete the tap action, today’s iOS drearily yawns and says “okay, if you must”.

This is just one of the laundry list of things that people railed against in 2013. Criticism died down as people acquiesced to what was given to them. Many critics, myself included, accepted the iOS 7 design as a rush job and thought that Apple would obviously catch their breath and ‘fix it’ over the next couple of OS versions. I don’t think anyone at the time expected us to still be stuck with these missteps six years later.


Gatekeeper Symlink/Automount Bypass

Filippo Cavallarin (Hacker News):

To better understand how this exploit works, let’s consider the following scenario: An attacker crafts a zip file containing a symbolic link to an automount endpoint she/he controls (ex Documents -> /net/ and sends it to the victim. The victim downloads the malicious archive, extracts it and follows the symlink.

Now the victim is in a location controlled by the attacker but trusted by Gatekeeper, so any attacker-controlled executable can be run without any warning. The way Finder is designed (ex hide .app extensions, hide full path from titlebar) makes this tecnique very effective and hard to spot.


The vendor has been contacted on February 22th 2019 and it’s aware of this issue. This issue was supposed to be addressed, according to the vendor, on May 15th 2019 but Apple started dropping my emails. Since Apple is aware of my 90 days disclosure deadline, I make this information public.

Howard Oakley:

These checks are in any case only performed when an app is run via LaunchServices, i.e. the Finder. So a user shouldn’t be able to run an app with a broken signature from a new location using the Finder, but they can run an app with no signature at all, and any malicious script or process can execute code from an app with a broken signature without any signature checks being performed, unless it’s kind enough to ask for them.


Movist Removed From the Mac App Store

Movist (via Leo):

This is because Apple has refused to update the app, and they have also removed from the App Store the already accepted version.

What Apple pointed out was that Movist has a feature of “downloading 3rd party media”. So we removed the Safari Extension to allow YouTube videos to be played in Movist and removed the feature from Movist too. But Apple still refused to update because Movist has that feature yet. After all, we had no choice but to remove all streaming functionality from Movist.


5.2.3 Audio/Video Downloading: Apps should not facilitate illegal file sharing or include the ability to save, convert, or download media from third party sources (e.g. Apple Music, YouTube, SoundCloud, Vimeo, etc.) without explicit authorization from those sources. Streaming of audio/video content may also violate Terms of Use, so be sure to check before your app accesses those services. Documentation must be provided upon request.

It doesn’t look like the app is intended for saving media. I don’t see what would be objectionable about streaming—any app with a Web view can already do that.

Previously: IINA 1.0.

Apple Developer Survey

Felix Krause:

If you get the email, this is your chance to give feedback about:

- Binary processing time
- Code signing
- Lack of API endpoints
- Inconsistent rejection reasons
- Managing app metadata and screenshots
- TestFlight review times

Tyler Hall:

Also, in general, the Mac App Store is a kafkaesque hellscape full of scam artists that erode customers’ trust in the overall system and shitty apps that are nowhere near the level of quality that long-time Mac users expect from 3rd party software.

Add to that the arbitrariness of App Review, which seems more interested in penalizing legitimate developers for the most insignificant of reasons, while big name companies get away with flaunting the rules, and fly-by-night developers actively ship malicious, misleading, predatory, and outright-broken software.

Previously: Apple Pulling High-Grossing Scammy Subscription Apps Off the App Store