Wednesday, December 2, 2020 [Tweets] [Favorites]
This update brings Forecast and Perspective widgets—quickly becoming a popular feature in OmniFocus for iOS—to the Mac for the first time.
In macOS Big Sur, widgets appear in the updated Notification Center on the right side of the screen. Click Edit Widgets beneath any existing ones to add the new OmniFocus widgets.
“We experimented with moving away from the diamond, but that seemed a little silly considering that it’s such a strong part of our brand,” he explains. “So we created a bunch of new diamond shapes — some with perspective, some without; some with more faces, some with less.” From there, it became of question of which ones worked best, and how to integrate these elements with different backdrops.
[…]
Getting the balance right between the foreground shapes and the background was particularly tough. “Something we found out very quickly was that there was often a visual struggle between the rounded rectangle backdrop and the diamond,” he says.
[…]
The rounded rectangle background is actually a simplified representation of Sketch’s Big Sur user interface, and the Sidebar on the left has transparency, which means it ever-so-slightly takes on the background color of your wallpaper.” The diamond itself got some love too — Prekesh redrew and re-colored it from scratch to improve the contrast and make it slightly more vibrant. Plus, a new, deeper shadow makes it feel like it’s really floating in front of the UI.
Previously:
By becoming a patron, you will be allowing me to focus on this project as my primary job, and spend much more time on it that I ever could as a side project.
The goal is to bring Linux support on Apple Silicon macs to the point where it is not merely a tech demo, but is actually an OS you would want to use on a daily driver device. To do this, there is a huge amount of work to be done. Running Linux on things is easy, but making it work well is hard. Drivers need to be written for all devices. The driver for the completely custom Apple GPU is the most complicated component, which is necessary to have a good desktop experience. Power management needs to work well too, for your battery life to be reasonable.
[…]
All development will be in the open, pushed to GitHub regularly. Contributions will be written with the intent to upstream them into the respective upstream projects (starting with the Linux kernel), and upstreamed as early as is practical. Code will be dual-licensed as the upstream license (e.g. GPL) and a permissive license (e.g. MIT), to ensure that the work can be reused in other OSes where possible.
So the System volume at disk3s1 (your numbers may differ) has a broken seal?
To understand why that’s perhaps the wrong question, we need to step through how Big Sur creates the SSV in the first place. During system installation, the whole system is created on the System volume. Once complete, and protected by SIP, the installer then creates the Merkle tree of hashes up to the Seal, the one hash to rule them all, and makes a snapshot. The tree of hashes and its Seal are then stored in the file system metadata which make up that snapshot. The sealed snapshot is then mounted and the System volume itself is unmounted.
So it’s not the System volume which is sealed now, but that snapshot.
[…]
That crucial piece of information appears to have been omitted from other locations in Big Sur when it’s running on an Intel Mac.
Previously:
Monday, November 30, 2020 [Tweets] [Favorites]
Chris Forsythe (tweet, Hacker News, Slashdot):
Growl is being retired after surviving for 17 years. With the announcement of Apple’s new hardware platform, a general shift of developers to Apple’s notification system, and a lack of obvious ways to improve Growl beyond what it is and has been, we’re announcing the retirement of Growl as of today.
It’s been a long time coming. Growl is the project I worked on for the longest period of my open source career. However at WWDC in 2012 everyone on the team saw the writing on the wall. This was my only WWDC. This is the WWDC where Notification Center was announced. Ironically Growl was called Global Notifications Center, before I renamed it to Growl because I thought the name was too geeky.
Thanks to Forsythe and the other contributors for all their work over the years.
There’s one issue, which is that of “Sherlocking” a third-party solution with a first-party implementation. Then there’s another, which is having an open enough system to support such innovations in the first place.
Something like Growl, or f.lux (mentioned down-thread) could never have come about if macOS had been as restrictive as iOS. I have little doubt that we’ve missed at least a few such innovations over past decade, especially on the iPad, due to this.
Previously:
Katie Abel (via Hacker News):
Tony Hsieh, the brilliant and big-hearted Zappos.com luminary who revolutionized the shoe business and built one of the most innovative companies in modern history, has died. He was 46.
[…]
After Zappos co-founder Nick Swinmurn latched onto the idea of selling shoes online, he left a voicemail with Hsieh’s San Francisco venture capital fund, Venture Frogs, hooking him with one factoid: “It was the fact that 5 percent of a $40 billion shoe business was already being done through mail order,” Swinmurn told FN during a 2009 interview. “That was my big statistic. People were already buying shoes without trying them on.”
Tony’s passing has taken me down a memory lane to the earliest days of the Internet when we were all very young and innocent. Tony, then, only 23, had started work on LinkExchange, an early banner ad-exchange network that launched in early 1996.
[…]
With Tony’s passing, I feel something special has ended. I can’t put my finger on it. Maybe a certain innocent aspect of the early possibilities of the Internet. Maybe I feel the contrast of those days to a now that is more mercenary, less friendly, and more polarized. Whatever, without knowing Tony as well as I should, I mourn him deeply.
[…]
Tony and Zappos’ biggest achievement was that it showed long before everyone else: you can build an Internet company anywhere. Unlike so many pundits and Twitterati, it didn’t take a pandemic for Tony to have that insight. Zappos was also an example of how tech companies could care about their customers and not treat them as data.
The outpouring of love and admiration for Hsieh from those who knew him is just remarkable.
What seems to still be missing from SwiftUI is the notion of the intrinsic content size: the natural size that a view really wants to be unless it is forced to be something else. This is the size that views should adopt by default. Working in-hand with this would be the ability to define compression resistance priorities and content hugging priorities, something that SwiftUI also lacks. These are important features to describe how views should behave relative to each others when they are forced to deviate from their natural size.
[…]
You heard that right: merely looking at the size proposed by the parent will change the layout in unwanted ways.
[…]
It is bothering that third-party developers are not able to write the same kind of views that Apple provides in SwiftUI.
[…]
But the SwiftUI code only builds a description of the wrapper view, there is no function that can directly be called to talk to the underlying AppKit view. The natural SwiftUI way of doing this would be to add a new state variable such as
@State var isAuthorized: Booland pass it along to the view representable but alas this really doesn’t work well as theSFAuthorizationViewowns the state already (the authorization reference). There is no obvious way that I know to address this sort of discrepancies.
I still don’t know what to think about SwiftUI. Much of it seems amazing, but two major releases in there’s this basic stuff that remains broken, and stuff that was easy with Auto Layout is needlessly difficult or impossible. How much is just bugs vs. limitations of the overall system’s design? For the latter, is the long-term plan that some UIs are just not possible? Or that AppKit/UIKit will live forever?
With Auto Layout, you could always opt out certain subtrees if what you were trying to do was too slow or couldn’t be expressed. But, as Clement describes, SwiftUI’s NSViewRepresentable isn’t the same kind of escape hatch.
SwiftUI on Mac is a constant struggle of wondering “am I doing this wrong or is this just broken on Mac”
Previously:
Since the iPhone 12 has a bit more noise, there’s less detail. Still, the detail isn’t easy to spot in bright daylight. Everything changes between the iPhone 12 and 12 Pro Max the moment sunset begins. As shadows get darker and light gets dimmer, you can start seeing shifts in detail.
[…]
It seems Apple’s Camera app applies just as much noise reduction to the 12 Pro Max image as it does for regular iPhone 12. This unfortunately ‘blurs’ superior details out of the iPhone 12 Pro Max.
[…]
The iPhone 12 Pro Max’ new sensor-shift technology really shines when you take away that computational magic and focus on traditional, single-shot photography.
[…]
With a traditional DSLR, nobody would dare take a one-second photos handheld.
Yet the iPhone 12 Pro Max can take sharp images at ridiculous exposure times.
I’m excited to see what becomes possible with ProRAW. Too bad there’s still no way to change the default iOS camera app.
Previously:
Friday, November 27, 2020 [Tweets] [Favorites]
Becky Hansmeyer (Hacker News):
Power and performance aren’t the bottleneck for iPad, and haven’t been for some time. So if raw power isn’t enough, and new display tech isn’t enough, where does the iPad go from here? Will it be abandoned once more, lagging behind the Mac in terms of innovation, or will Apple continue to debut its latest tech in this form factor? Is it headed toward functional parity with the Mac or will it always be hamstrung by Apple’s strict App Store policies and seemingly inconsistent investment in iPadOS?
[…]
It’s clear that Apple wants the iPad Pro to be a device that a wide variety of professionals can use to get work done. And since so many people use web apps for their work, the introduction of “desktop” Safari for iPad was an important step toward that goal. The Magic Keyboard and trackpad was another step.
Here are ten more steps I believe Apple could and should take to help nudge the iPad into this exciting next era of computing.
[…]
The new M1 Macs should give iPad fans reason to be excited; now that we’ve seen hints of what future Macs can be, it’s time for the iPad to reassert itself—to remind us once again who it’s for, and what makes it special.
As an iPad user, the new M1 Macs don’t make me want to trade in my iPad Pro since basically all the new features are variants of things I already had with the iPad Pro.
[…]
The question is how the iPad distinguishes itself as the Mac adopts some of its key features. One option is to loosen restrictions for apps and enable more powerful workflows so that more work can get done on the iPad. The other option is to bow out of the “Pro” line of iPads and lean into it being a more casual device. As an iPad fan, I very much want to see Apple make the iPad much more powerful, but that’s not absolutely the way they are going to go.
So, while I generally agree with Hansmeyer’s suggestions for changes, I have to wonder if these limitations are somehow deliberate, rather than something Apple has yet to change. The touchscreen-oriented interaction model of the iPad necessarily limits its software in some ways, but that does not excuse users’ more egregious workarounds. I find myself reading about the way Federico Viticci makes his iPad work for him, or the way that Jack Wellborn assembled a shortcut for rating songs in Music, and I wonder why these methods must be so convoluted. They are undoubtedly clever, but they also often feel like they are working around outdated limitations to multitasking. So, I have to wonder: is this a way of clearly separating the iPad and the Mac, so users do not attempt to treat one as the other? If so, what is Apple’s long-term strategy?
Previously:
We posted CCC 5.1.23 yesterday which includes support for making bootable backups on Intel Macs running Big Sur.🎉CCC runs natively on & is fully compatible with Apple Silicon Macs, but we’re still tracking some macOS issues here.
Some Big Sur startup volumes don’t appear in the Startup Disk Preference Pane
[…]
To avoid deleting your snapshots and the rest of your backup, CCC will not update the System volume on the destination when System updates are applied to the source.
[…]
In the current shipping version of macOS Big Sur (11.0.1), Apple’s ASR utility cannot replicate the startup disk in an M1-based Mac.
[…]
Finder will show and allow you to customize the volume icon for your current startup disk, but not for other Catalina- or Big Sur-bearing startup disks that your Mac is not currently booted from.
[…]
Finder will let you rename the current startup disk, but you won’t be able to rename any other startup disks that have an installation of Catalina or Big Sur because the System volume is mounted read-only.
Previously:
This is not Catalyst. It’s also not the future™ (aka SwiftUI). This is a practical, albeit compromised, solution for today. A solution to give the Mac App Store a kick in the butt, an adrenaline shot, a splash of cold water.
[…]
Most importantly, for users that are OK with running the FoodNoms iPad app on their Mac and would get value out of it, now they can, as long as they have an M1 Mac. It’s clearly branded and marketed as an iPhone/iPad app, so I don’t have anything to apologize about – it’s not a Mac app!
[…]
I was pleasantly surprised how well it seemed to work out of the box. That said, there were a few bugs and issues that needed to be fixed. As part of this blog post, I figured I’d share what those bugs were. I think it could give a good idea for developers and non-developers of a) how trivial it is to get an iPad app running without known issues and b) how good of a job Apple did with getting all of the iOS frameworks working smoothly on macOS.
Previously:
A number of M1 Mac owners are reporting problems with Bluetooth connectivity on the new machines, ranging from intermittent disconnects of wireless peripherals to completely non-functional Bluetooth connections.
[…]
M1 owners have taken to the MacRumors forums and Reddit to discuss the glitches, and Mac mini owners appear to be worst affected, with the problems compounded by the fact that many rely on wireless peripherals to interact with their Mac in order to free up available ports.
Previously:
Previously:
The original design of Widgetsmith put configuration of the aesthetic aspects of each widget on equal footing as purely functional aspects. You’d choose the text color in the same way as you’d assign the desired timezone location. This made sense in a world where the principal use case was utility. In a world, however, where Widgetsmith is primarily being used to add aesthetic flair to your home screen this approach leaves something to be desired.
So instead, in version 2.0 of Widgetsmith I’m introducing the concept of themes to the app.
[…]
I’ve begun working with top designers to provide a wide range of seasonal and fun borders and overlays for your widgets to give them that little extra pop.
Previously:
The only problem with this method is that it kicks you to and from the Shortcuts app whenever you open an app with a custom icon, which isn’t a great way to optimize usage and can be annoying. However, thanks to the latest update to Launch Center Pro, there’s now a way to add custom app icons without going anywhere near the Shortcuts app.
[…]
When you’ve finished creating your icons, a downloadable configuration profile is generated by Launch Center Pro that you then need to install on your device.
[…]
Launch Center Pro is a free download on the App Store, but the Icon Composer is a $20 in-app purchase. In addition, the app offers a $14.49 subscription bundle that includes the icon composer as well as several other features. A free 7-day trial is also available.
See also: Chaim Gartenberg, Federico Viticci on Launch Center Pro 3.
Previously:
Wednesday, November 25, 2020 [Tweets] [Favorites]
If there’s a single disappointment in the release of Apple’s first wave of M1 Macs, it’s the lackluster launch of iOS apps running inside of macOS. What should be an amazing unification of Apple’s platforms and a massive expansion of the Mac software base is, instead… kind of a non-event.
Running iOS apps on the Mac can be a little weird, it’s true. But it can sometimes be good. Unfortunately, a lot of interesting iOS apps just aren’t available at all, because their developers have removed them from the Mac side of the iOS App Store.
[…]
But Apple’s biggest impact can come with the decisions it makes about hardware. The reason some iOS apps feel weird on the Mac is that they were designed for touch, not for a cursor and keyboard. Introducing Macs with touchscreens won’t change the Mac’s status as a mouse-first operating system, but it will offer alternate modes of input—and open up better compatibility with some iOS apps.
App developers can choose not to make their iPhone and iPad apps available on M1 Macs through the Mac App Store, and many popular apps like Netflix, Hulu, and others have made this choice. There is a workaround for installing these apps anyway, but it involves third-party software.
As it turns out, the M1 Macs are able to run any .ipa file, which is the format used for iOS apps. You need the .ipa file for an app to run it on an M1 Mac, and getting those files can be done through software like iMazing.
[…]
There is an alternative method that uses Apple’s free Apple Configurator 2 app, but does require you to use the Terminal to fix permissions. The instructions are detailed in this forum post.
Man Apple screwed this up - “opt out of distributing your iOS app on Mac” except not really because anybody can run it without even modifying the binary (and without FairPlay).
Apple has pretty much ignored the issue of how to validate purchases. This could have been an advantage of the Mac App Store, with the system handling it automatically like on iOS. Instead, we got nine years of buggy sample code for receipt validation. And now no protections for apps that opt out of Mac support.
Previously:
Apple demonstrated the libdispatch and the promise seemed great, they introduced the notion of serial queues and told us that we should stop thinking in term of threads and start thinking in term of queues. We would submit various program tasks to be executed serially or concurrently and the libdispatch would do the rest, automatically scaling based on the available hardware. Queues were cheap, we could have a lot of them. I actually remember very vividly a Q&A at the end of one of the WWDC sessions, a developer got to the mic and asked how many queues we could have in a program, how cheap were they really? The Apple engineer on stage answered that most of the queue size was basically the debug label that the developer would pass to it at creation time. We could have thousands of them without a problem.
[…]
Then the problems started. We ran into thread explosion which was really surprising because we were told that the libdispatch would automatically scale based on the available hardware so we expected the number of threads to more or less match the number of cores in the machine. A younger me in 2010 asked for help on the libdispatch mailing-list and the response from Apple at the time was to remove synchronization points and go async all the way.
As we went down that rabbit hole, things got progressively worse. Async functions have the bad habit of contaminating other functions: because a function can’t call another async function and return a result without being async itself, entire chain calls had to be turned async.
[…]
Turns out Apple engineers are developers just like us and met the exact same problems that we did. […] An Apple engineer also revealed that a lot of the perf wins in iOS 12 were from daemons going single-threaded.
[…]
Now I’m a bit worried because I see all those shiny new things that Apple is planning to add into the Swift language and I wonder what might happen this time.
Via Peter Steinberger:
Please see past the clickbaity title. It failed to deliver on the promise. It’s still incredibly useful. It’s just dangerous that the documentation wasn’t updated to reflect this.
To call any technology a failure because it was initially over-promised would leave pretty much no successes ever.
Coding under Dispatch is a lot nicer than pthreads or
NSThread/NSLock, which were the options on the platform before its debut. By my definition that’d be success.
P1. Task queues will be easier than threads & locks.
P2. libdispatch can handle many queues and it is sensible to organize a program that way.
Could be we agree that P1 was true but P2 proved false for a mix of performance and programming model complexity reasons.
I say: dispatch long-running (like, seconds or more) tasks off the UI thread, including as much I/O as possible. Everything else can run on one thread. Other processes can use other cores. Enforce in API by making most stuff sync but long tasks async with a completion handler.
Personally I currently prefer a small number of queues (or workloops!) for execution contexts and unfair locks for protecting state. For example cfprefsd uses* a two queue model (“request processing” and “async IO” queues), but fine grained locking.
Marcel Weiher (quoting his excellent iOS and macOS Performance Tuning):
Due to the pretty amazing single-core performance of today’s CPUs, it turns out that the vast majority of CPU performance problems are not, in fact, due to limits of the CPU, but rather due to sub-optimal program organization
In the end, I’ve rarely had to use multi-threading for speeding up a CPU-bound task in anger, and chances are good that I would have made my code slower rather than faster. The advice to never optimize without measuring as you go along goes double for multi-threading.
Previously:
Update (2020-11-30): David Zarzycki:
As the designer of libdispatch, I just want to say: I get why people feel this way and I’m sorry that we/I oversold libdispatch to some degree at the time.
(And just to be clear, I left Apple many years ago and I still deeply respect them.)
I also feel bad because I knew that blocking was a pain point and I had plans/ideas for how to minimize that pain but I burned out after GCD 1.0 and took a leave of absence. I don’t think those ideas ever got recorded or implemented. So ya, I’m sorry about that too.
That being said, what we had before libdispatch was awful. POSIX and derived threading APIs are both more difficult to use and more inefficient. I do feel proud that we made life easier for people in this regard and helped people clean up their existing threading code.
Maybe you can clear something up for me: these days, we’re advised to not use concurrent queues, because the system will start a thread for every block in the queue because it has no idea which blocks depend on which others to make progress. Fair enough, but as I recall the initial presentations, concurrent queues only promised some amount of concurrency, where “some” might be “none”, meaning that if you deadlocked a concurrent queue, it would be your fault, not the system’s. Did something change, or am I misremembering?
that’s how one was told they worked, but never did. if a work item blocks on a concurrent queue, you get more threads eventually.
We now recognize some blocking situations as being due to contention and excluded such blocking points from the policy, but it only goes so far.
the other problem is that the concurrent queue pool (non overcommit threads in the implementation parlance) are a shared singleton which makes using them correctly fraught with peril if you allow blocking on future work.
This is why Swift Actors executors have to disallow it.
The overcommit queues were never supposed to exist. They were added as attempt to fix a bug on the single core Mac mini but later we found the root cause: workqueue threads defaulted to
SCHED_FIFOinstead ofSCHED_OTHERand it was too late to remove overcommit queues before GM
Until now, TensorFlow has only utilized the CPU for training on Mac. The new tensorflow_macos fork of TensorFlow 2.4 leverages ML Compute to enable machine learning libraries to take full advantage of not only the CPU, but also the GPU in both M1- and Intel-powered Macs for dramatically faster training performance.
[…]
Performance benchmarks for Mac-optimized TensorFlow training show significant speedups for common models across M1- and Intel-powered Macs when leveraging the GPU for training. For example, TensorFlow users can now get up to 7x faster training on the new 13-inch MacBook Pro with M1[…]
Previously:
Hazel is a classic Mac automation tool which we last covered several years ago for version 4. This week Hazel is back with version 5, a major update which brings the tool out of System Preferences for the first time.
[…]
Hazel 5’s interface combines the folders and rules views into a single multi-column layout. This change makes the app much more fluid to navigate, and the new ability to group folders makes organization far nicer as well. While editing rules you can now detach the editor view from the main window, making side-by-side editing of multiple rules possible for the first time.
Tuesday, November 24, 2020 [Tweets] [Favorites]
My apps are on sale for Black Friday and Cyber Monday, and here are some other good deals that I found:
Lists of deals:
Previously:
Rogue Amoeba (via Peter Steinberger, Jeff Johnson, Paul Kafasis):
In MacOS 11 (Big Sur), the initial installation of ACE requires a bit more set-up. The in-app installer provides an overview of the process, and is likely all you need. This page lists the full sequence of steps to install ACE and get Airfoil working.
[…]
Click the lock in the lower left corner, then enter your Administrator password. The Security & Privacy system preference will then be unlocked, and you’ll be able to make changes. From here, click the Enable system extensions… button to permit ACE to run on your Mac.
[…]
Boot to the Mac’s “Recovery” environment by pressing and holding down the Touch ID or power button on your Mac.
[…]
The default configuration is pictured above. Switch to Reduced Security and enable the first checkbox, “Allow user management of kernel extensions from identified developers”.
[…]
Despite the name of this setting, ACE is not a kernel extension. Instead, it’s a standard audio plug-in, which receives enhanced privileges to access your system’s audio. MacOS simply uses the kernel extension verification system to allow ACE to load as well.
[…]
Now, you need to allow ACE to run on your Mac, by authorizing it in the Security & Privacy system preference.
Keep in mind that you have to go through all of this even though the app has already been notarized. The last few versions of macOS have been a disaster for apps that do anything off the beaten path. Apple keeps adding hoops for users to jump through, scaring potential customers away. Developers have to spend time engineering mitigations for the bad user experience, working around bugs in the new security features, and providing support for customers who have trouble with the hoops. Apple talks about how it loves the Mac and innovation, but each step of the way it does more to discourage the development and success of interesting apps.
Previously:
Update (2020-11-25): Jason Snell:
The good news for Rogue Amoeba’s customers is that their stuff works, and once you do the reboot two-step, you shouldn’t need to do it again. It’s a multi-step process, but it’s over fast and then you can get on with your work.
But it really shouldn’t work this way, and that’s on Apple. One reboot is bad, but two is ridiculous. Surely there’s a way, at the very least, to pre-approve an extension before rebooting to adjust the security setting? I know that Apple is trying to protect users from bad actors, but when a list of instructions like these are required to install Mac software, something’s really gone wrong.
See also: Reddit.
Update (2020-11-27): Dave Mark:
I’ve jumped through these hoops, and they are both intimidating and cryptic. Neither are Rogue Amoeba’s fault. If I want to use Audio Hijack, I have to jump through the cryptic hoops, and trust that it’s OK to accept “reduced security”.
I get it. I just hate that this is where we’ve landed.
Thomas Reed (tweet):
One of the common sub-groups of PUPs we detect are antivirus programs that show unwanted behaviors meeting certain criteria. As an example, a program that requires payment, but the antivirus engine it uses is available for free from another company, would be a likely candidate for detection.
Unfortunately, antivirus programs are also candidates for the system extension and EndpointSecurity entitlements. Anyone can apply for these entitlements, but you stand a much better chance of getting them if you are—or appear to be—a security company.
We’ve now seen a case where two different companies with a long history of making PUPs—including junk antivirus programs—have gotten these entitlements. Those programs now have a system extension, which cannot be removed by Malwarebytes or any other software.
[…]
However, it is starting to look like antivirus developers will have to play by increasingly limiting rules, and that now means not being able to protect users against certain things. Worse, Mac users will be unable to manually remove those things without contortions that the average person will find quite cumbersome.
Previously:
I hate to be a downer when it comes to improved technology that actually does what it says on the tin. 5G networks will provide substantial improvements in throughput and availability that we will notice—in a year or maybe two. Until then, not so much.
Previously:
Monday, November 23, 2020 [Tweets] [Favorites]
When iPhone OS 1.0 was released in 2007, it redefined the smartphone with a limited set of core features. Nowadays iOS 14 contains an incredible amount of components. By looking at them based on their size, we can determine the most important features. We thus distinctly see Apple’s AI push into on-device machine learning with technologies like object detection in images and video, language analysis, sound classification and text recognition.
Previously:
SF Symbols 2.1 is out. Over 40 new symbols, improved symbol localization, design refinements, and various software fixes.
Apple’s SF Symbols app has no release notes and the What’s New category doesn’t contain the symbols that were added or renamed in v2.1. In fact there are fewer symbols in this category in v2.1 than in v2.0: two symbols that were renamed have been removed without their replacements being added. The app shows OS availability (and other information) for the selected symbol in the side bar. Availability information is missing for the new symbols in v2.1. This makes it difficult to discover what has changed between versions.
[…]
The 41 symbols in the screenshot above annotated with
14.2+are completely new in iOS 14.2[…]
There are a bunch of new symbols - you can view the changes here, but I’ll include a list of new symbol names at the bottom of this post in case someone Googles for them. Some additions are relevant to recent events (like
aqi.high), new products (likeappclip), or just more general objects (likebuilding). My personal favorite iscandybarphone.
Previously:
What the hell, Apple? You won’t give me and other security researchers the EndpointSecurity entitlement, but you give f***ing MacKeeper the entitlement?!?! What in the hell is wrong with you? 🤬🤬🤬
The macOS entitlements granting process is a disaster. No feedback, frequent mistakes in what’s granted, nonsense requests (can’t link to app if can’t release app w/o entitlement), extremely slow (4-6 weeks turnaround in idea case), & some developers clearly favoured over others.
[…]
So then you have to apply again and ask for the distribution entitlement in the free-form text field, and wait another 4-6 weeks. Chances are you’ll also want user space apps & tools to access your driver. You have to apply for that specially via free-form request too, etc.
Obviously by now I’m basically an expert at asking for DriverKit entitlements, but it’s ridiculous that “filling out a form on Apple’s developer website” is a consulting service I should even need to offer.
[…]
Apply for the entitlements you will need and wait to receive them before you start coding. Seriously, if you aren’t granted them, your only recourse is to expect your users to turn off SIP. In other words, you will have wasted your efforts if the oracle denies your request.
[…]
If you get any kind of notification of success (or entitlements just silently turn up in your account), make sure everything is there for all deployment scenarios you care about. Individual entitlements are granted independently for development, app store, and developer ID.
In theory, entitlement-based security/privacy restrictions are a win because the apps that should have them will easily get them and the bad apps won’t. Users won’t have to evaluate what each app should be allowed to do. But the reality, for many years, is that legitimate apps are not granted the entitlements, and often don’t even get a formal rejection—just silence. We’re losing and limiting good apps either because Apple’s process is broken or because it’s playing politics.
Previously:
Update (2020-11-25): Stephen Flower:
Yep, took me a month to get entitlements granted and another month to get them fixed!
I have been waiting since mid-July for an entitlement request.
The M1 is apparently a multi-die package that contains both the actual processor die and the DRAM. As such, it has a very high-speed interface between the DRAM and the processors. This high-speed interface, in addition to the absolutely humongous caches, is key to keeping the various functional units fed. Memory bandwidth and latency are probably the determining factors for many of today’s workloads, with a single access to main memory taking easily hundreds of clock cycles and the CPU capable of doing a good number of operations in each of these clock cycles. As Andrew Black wrote: “[..] computation is essentially free, because it happens ‘in the cracks’ between data fetch and data store; ..”.
[…]
The benefit of sticking to RC is much-reduced memory consumption. It turns out that for a tracing GC to achieve performance comparable with manual allocation, it needs several times the memory (different studies find different overheads, but at least 4x is a conservative lower bound). While I haven’t seen a study comparing RC, my personal experience is that the overhead is much lower, much more predictable, and can usually be driven down with little additional effort if needed.
So Apple can afford to live with more “limited” total memory because they need much less memory for the system to be fast. And so they can do a system design that imposes this limitation, but allows them to make that memory wicked fast. Nice.
Mike:
The memory bandwidth on the new Macs is impressive. Benchmarks peg it at around 60GB/sec–about 3x faster than a 16” MBP. Since the M1 CPU only has 16GB of RAM, it can replace the entire contents of RAM 4 times every second.
[…]
Some say we’re moving into a phase where we don’t need as much RAM, simply because as SSDs get faster there is less of a bottleneck for swap. […] However, with the huge jump in performance on the M1, the SSD is back to being an order of magnitude slower than main memory.
So we’re left with the question: will SSD performance increase faster than memory bandwidth? And at what point does the SSD to RAM speed ratio become irrelevant?
And that makes me think that a Mac would either not go full NUMA, or would not have public API for it. Maybe Apple would let the kernel and some OS processes have exclusive access to the on-package RAM, but even that seems overly complex (particularly where you have more than one M1 in a computer, so you need to specify core affinity for your memory allocations in addition to memory type). My guess is that an early workstation Mac with 16GB of M1 RAM and 64GB of DDR4 RAM would look like it has 64GB of RAM, with the on-package memory used for the GPU and as cache. NUMA APIs, if they come at all, would come later.
Previously:
Update (2020-11-25): David Smith:
this further improvement is because uncontended acquire-release atomics are about the same speed as regular load/store on A14
The video includes a series of benchmark tests, ranging from Geekbench and Cinebench to RAW exporting tests. Geekbench and Cinebench benchmarks didn’t demonstrate a difference in performance between the 8GB and 16GB models, but other tests designed to maximize RAM usage did show some differences.
A Max Tech Xcode benchmark that mimics compiling code saw the 16GB model score 122 compared to the 136 scored by the 8GB model, with the lower score being better.
Beware of the swap disk space!
In most of the benchmarks performed on 8GB M1 machines, if Activity Monitor is shown, the swap space usage is always between 2,5GB and 4GB or even more. In my 10 years of being a mac user, I’ve never seen such big swap space being used unless I’m stressing my machine heavily, and that usage may be aging your SSD.
Thursday, November 19, 2020 [Tweets] [Favorites]
Joshua Harris and Sam Haveson:
To help people feel more comfortable, we’ve been working on a lower pressure way for people to talk about what’s happening. Today, we’re launching Fleets so everyone can easily join the conversation in a new way – with their fleeting thoughts.
Fleets are for sharing momentary thoughts – they help start conversations and only stick around for 24 hours.
How does this work with third-party clients? I can already see deleted regular tweets in Tweetbot.
Fleets have no retweets, likes, or public comments, do not show up in search or moments, and cannot be embedded on external websites.
Oct 2013: Snapchat launches Stories
Aug 2016: Instagram copies it
Feb 2017: WhatsApp copies it
Mar 2017: Messenger copies it
Nov 2018: YouTube copies it
Sep 2020: LinkedIn copies it
Nov 2020: Twitter copies it
Update (2020-11-20): Jeff Johnson says that Twitter did an Epic-style server update to enable fleets for users without updating the Twitter app on their phones. That would seem to go against guideline 2.3.1 about not including “hidden, dormant, or undocumented features in your app.”
Update (2020-11-23): Tim Hardwick:
Twitter’s new ephemeral tweets, or “fleets,” have been hit by a bug that allows them to be accessed long after their supposed 24-hour expiration time, less than a week after the feature launched.
[…]
According to Techcrunch, the bug allowed fleets to be viewed and downloaded by other users without notifying their creator. Details of the bug were posted in a series of tweets over the weekend. Twitter soon acknowledged the issue and says a fix is on the way.
Update (2020-11-30): Kris Holt (via John Gruber):
It emerged last year that Spotify was working on a stories feature for artists. The company started a public test of stories earlier this year, when it allowed some influencers to add them to playlists. Many other major platforms have stories features, including Instagram, Snapchat, Facebook, YouTube, Twitter and even LinkedIn. It probably shouldn’t be too surprising that Spotify looks set to get in on the action too. Whether it should do so is perhaps up for debate.
With Apple now officially selling Apple Silicon Macs, there’s a design decision which Apple made with macOS Big Sur that may affect various Mac environments:
At this time, macOS Big Sur does not install Rosetta 2 by default on Apple Silicon Macs.
I don’t understand what the benefit of this is. Big Sur already includes the Intel versions of all the system frameworks. Why not include the much smaller Rosetta translator, too? Just to shame them?
I think with the Intel transition, Rosetta was preinstalled until Snow Leopard.
Previously:
Here are more details on how iPhone and iPad apps will be installed on M1 Macs:
- Managed by the Mac App Store
- Toggle in search
- ‘Designed for iPhone/iPad’ badge
- Included in "curated selections"
With everything in macOS 11, it’s getting harder to define what Catalyst is. There are 3 forms:
- Unmodified iOS apps (Apple Silicon-only)
- Traditional Catalyst apps (more Mac like, but blurry scaling)
- Optimized for Mac/Mac Idiom Catalyst apps (pixel perfect, Mac controls)
Another component in Apple’s unified app platform is SwiftUI, which is a bit messier to explain. There are several forms:
- A SwiftUI multiplatform app
- SwiftUI inside AppKit app
- SwiftUI inside Catalyst (more iOS-y)
- SwiftUI inside Mac-idiom Catalyst (more Mac-like)
I think a lot of people overemphasize the fact that you need to do a lot of work and recreate system behaviors in a Catalyst app if you want a great Mac app — you need to do the exact same things if you want a great AppKit Mac app, too, as you can see
I’m still not a big fan of Catalyst, but I’m even more bummed that a lot of developers seem to be deciding to skip Catalyst and just ship bare iOS apps on Apple Silicon. Even if you’re just targeting new Apple Silicon Macs, this is not the way.
Never have I earned so much good press for doing absolutely nothing.
Coming to previous Macs via Catalyst is a longer-term goal that, unfortunately, I don’t have time to complete yet.
MacOS 11 “Big Sur” introduces one major new feature exclusive to Apple Silicon Macs: the ability to run iPhone and iPad apps from the App Store.
This sounds fine on paper, but in practice I don’t understand who thought this was a good idea to ship. My experience has ranged from terrible to OK, at best.
[…]
It’s possible HBO will fix some of this. Just making the window resizable and enabling full-screen video playback would make the app at least useful. But even at best, like Overcast, iOS apps running in a window on a Mac feel foreign. They feel like what they are: apps from another platform. I can see how some people might think this is a good idea, but I don’t see how anyone thinks it’s a very Apple-y idea. Sure, it works, which is why most companies would just ship it. More apps are better, right?
But they’re such a crummy experience, these iOS apps. This feature exemplifies a spirit of “better than nothing, ship it”. The Apple way, typically, is “insanely great”. It’s like someone said, “Oh, you thought lazy Catalyst ports were a bad experience on MacOS? Hold my beer…”
In some sense, the Mac App Store has been a failed experiment; 9 years on, few of the top Mac developers are prepared to accept its terms and requirements, including sandboxing. Apple has a large chunk of its Mac developerbase thus ill-prepared to follow them into the future
Arguably, this is one of the driving elements between merging the iOS and macOS software ecosystems; Apple wants/needs a core base of developers on board with the App Store and its unified, Universal model, and iOS provides it
I’ve always argued that the Mac App Store should have done everything in its power to accommodate and entice the Mac’s existing developer base (they’re the ones that make all the high-quality apps we love, after all). This entire strategy, UIKit on up, drives them away instead
There appears to be no DRM on iOS app binaries running on macOS.
Previously:
Update (2020-11-25): Marco Arment:
iOS devs, FYI: unmodified iOS apps running on M1 Macs appear to report themselves via hw.machine as model identifier “iPad8,6” (iPad Pro 12.9-inch, 3rd-gen, 1TB model).
So if you see a very recent spike in your analytics in iPad 12.9 users, that’s probably why.
I gotta tell you when we released Big Sur, and these articles started coming out saying, “Oh my God, look, Apple is preparing for touch”. I was thinking like, “Whoa, why?”
We had designed and evolved the look for macOS in a way that felt most comfortable and natural to us, not remotely considering something about touch.
We’re living with iPads, we’re living with phones, our own sense of the aesthetic – the sort of openness and airiness of the interface – the fact that these devices have large retina displays now. All of these things led us to the design for the Mac, that felt to us most comfortable, actually in no way related to touch.
I’ve never felt more comfortable moving across our family of devices as a user, which I do hundreds of times a day than I do now, moving between iOS 14, iPadOS 14, and macOS Big Sur. They all just feel of a family – there’s just less cognitive load to the switching process.
To me, it seemed obvious that the reduced information density was to enable touch. Because why else would you pay that cost for no benefit? Plus, the Mac App Store had started to feature artwork of a finger touching interface elements.
The cognitive load that Federighi mentions just isn’t something I’ve (consciously) experienced. And one could make the argument that it’s confusing to make systems that work differently look the same. But I take him at his word because it certainly explains decisions like the awful iOS-style alerts. That design provides no benefits for touch; it just makes macOS look more like iOS, which he considers to be a plus. All of these changes also help to make unmodified iOS apps running on Apple Silicon Macs blend in a bit better.
Big Sur offers a little more space around some elements, but not by much, so I think this speculation is quickly snuffed out if you use Big Sur for more than a couple of minutes. Most of the menus, buttons, and window controls are still tiny and clearly designed for a cursor and decidedly not a finger. It is still very much on the desktop side of the continuum.
Someone PLEASE create an app to decrease the spacing of the menu icons in Big Sur!
My apps now take up 50% of the width of it, instead of 25-33% previously. 😞
“We are willing to go through a multi-year transition on the Mac to use the same chip as the iPad, and do a design overhaul to make macOS icons look touchable, and even let iPad apps run on macOS, but we refuse to make these steps make sense by shipping a Mac with a touchscreen.”
macOS would still need dramatic changes if it were ever to go touch-first. Catalyst is not in any way designed to dynamically switch between ‘Mac’ & ‘iOS’ modes — if an app has adopted Catalyst to explicitly make a Mac UI, it would be a ton of work to support dynamic switching
But, to be clear, the Mac doesn’t have to go touch-first to justify touch support. Apple Pencil support on macOS, on a drafting table iMac, would fit into all kinds of pro-level workflows currently dominated by Wacom, from illustration to 3D modeling.
I think the charming and articulate executive is putting us on.
I absolutely think Apple will add at least limited touch support to future Macs, even if that wasn’t the plan when Big Sur was being designed. Federighi didn’t even deny that.
Previously:
Wednesday, November 18, 2020 [Tweets] [Favorites]
Apple (MacRumors, Hacker News):
Launching January 1, 2021, the industry-leading new App Store Small Business Program is designed to accelerate innovation and help propel your small business forward. The program has a reduced commission rate of 15% on paid apps and in-app purchases, so you can invest more resources into your business and continue building the kind of quality apps your customers love.
[…]
- If a participating developer surpasses the $1 million threshold, the standard commission rate will apply for the remainder of the year.
- If a developer’s business falls below the $1 million threshold in a future calendar year, they can re-qualify for the 15% commission the year after.
This doesn’t address any of the structural issues with the App Store, which I think are far more significant than the fee percentage, but it’s certainly a welcome change. It’s smart for Apple because most of the public complaints about the fee come from smaller developers, but almost all of the App Store revenue comes from mega-successful apps. So Apple can help a large number of developers at a small cost to itself. And now most developers are no longer on the same side as the likes of Epic, at least with respect to the fee.
Note that even 15% is still quite a bit higher than other full-service payment processors.
These odd incentives could be eliminated if Apple applied the commission more like marginal tax rates, where you never lose money by earning more income. I would suggest tweaking these rules so that each year, developers who qualify for the program would get the 15 percent commission until they reach $1M in revenue, then get charged 30 percent for sales over that threshold. Let developers stay in the Small Business Program even as their sales grow.
I wish it worked more like tax brackets, so that everyone paid 15% on the first $1M. That would help mid-sized developers.
We won’t know the details until December, but I think this system where developers need to apply and get approved to enter the program is just about a vetting process to prevent fraud (e.g. a developer with 10 apps setting up 10 different shell companies to try to get them all commissioned at the 85/15 split).
Previously:
Update (2020-11-19): Michael Love:
The thing about this is that there’s really no way for them to tell, or even really to lay out a clear definition of ‘shell company’ if they had perfect information; you’d have to start arguing about beneficial owners and at what point these companies are actually the same.
Subsidiaries are one thing, but how can they stop me from starting another software company to sell another app I’ve made? It’s a different company with a different name; ownership details would be easy to conceal if I wanted to.
And even if Apple knew that I was the owner of both companies, why would that necessarily disqualify me from the program? Plenty of people own more than one company; two different businesses making two different products.
Apple itself uses shell companies.
15% is still high, but one can run a business at that margin.
[…]
As great as this is for small developers, and as much as this is a first-class PR move… Apple’s concession doesn’t change the big picture. Small to medium-sized companies (at 1M revenue you are still small) are still held back to grow to bigger companies.
As to why the 15% doesn’t work like taxes, David Barnard:
Sensor Tower estimated that 2% of developers would be impacted. Some have multiple apps, so it’s not a perfect calculation, but 2% of 1.8M apps is 36k. $150k/yr gift to 36k apps is $5.4B/yr in pure profit. No way Apple would give that up.
An extra 15% for indies is great news!
Dealing with the customer sentiment that 99¢ software is an expensive one-time purchase would be even better.
This is very good news and I’m happy to see a reduction in fees finally happen.
Can we get upgrade pricing next?
Quote from Cook is beyond cynical. Written in that faux-care style so beloved by lobbyists. Apple is making smaller app developers growl before Apple (this program isn’t even automatic!), such that the abusive tax on payment processing is lowered from 10x to 5x the market rate.
[…]
It also further undermines the fantasy that “App Store rules are the same for everyone!”.
[…]
The root of the issue is the monopoly claim that Apple must process all payments, own all customer relationships.
Tim Sweeney, Epic’s chief executive and another of Apple’s toughest critics, also accused Apple of trying to divide developers. By charging smaller companies less, “Apple is hoping to remove enough critics that they can get away with their blockade on competition and 30 percent tax on most in-app purchases,” he said in a statement. “But consumers will still pay inflated prices marked up by the Apple tax.”
BUT WHAT DO YOU WANT FROM APPLE!? Simple:
1) The choice to use a different payment processor, so we can have competition. Monopoly platform can’t mean monopoly payments.
2) The right to tell customers that our software is for sale, without linguistic contortions.
To be fair, the real problem for us devs is not that we pay Apple too much, it is that Apple leaves us no choice and has the last word over what we can deliver to an iDevice and possibly soon also to a Mac.
If you ever wonder how old dinosaur companies got fat and started to rest on laurels, you’re watching it in real time with
It’s super frustrating because the hardware is so freaking good, and the strategy should be so freaking obvious.
The thing everyone is overlooking is that big players still get a better deal than we do. Why do small businesses get only 15% up to $1M while Amazon gets 15% up to infinity?
Scoop: Apple to charge 0% fee for first $1T in revenue from developers who choose to monetize through advertising or via the sale of real world goods and services.
I don’t know why people focus so much on the dev perspective. As a customer, that 15-30% doesn’t materialize into anything worthwhile for me. That 15-30% would make a bigger difference going to new features on that app than towards “AppStore improvements” that never happen.
15-30% on can be the difference between being able to afford a 2 person team or a 3 person team. That could translate to dedicated support for the app vs. the engineers having to split time answering emails. Just from a cold business perspective this is bad for customers.
I’ve been saying it should be 5% for a long time already. 👍
If other platforms do start adjusting their rates to 15% to match Apple’s terms, it just showcases Apple’s outsized influence and power (direct or indirect) over the entire industry
Once you think of it, the mechanism of “lower fee on $XM” is so obvious.
✓ EXACTLY the right incentives - new apps and creativity
✓ Apple gives up ~nothing (i.e. all the revenue comes from high end)
✓ Users get more better apps
I’m just glad Apple realized it too. Phew.
It makes a lot of sense, but I don’t know why it took Apple so long. This is the same pattern that eSellerate was using when I first started selling Mac apps in 2002.
John Luxford (via Hacker News):
Phones are general computing devices, and as such, should not be maintained as closed ecosystems. This doesn’t benefit users, many of whom are also developers themselves, because it limits our freedom on both sides of the equation. General computing platforms should be protected from such predatory practices by manufacturers through strong government regulations.
[…]
I’ve seen many comments on sites like Hacker News and MacRumours that this isn’t a problem users should care about and that developers should essentially stop whining or take their software elsewhere. But this also limits the choices users have, and it limits the types of apps they get to benefit from. This limitation won’t be felt directly, because you don’t feel the absence of something you never knew you could have. You don’t know what you don’t know.
Update (2020-11-20): Steve Troughton-Smith:
Apple’s rate drop, giving us 21% extra profit on App Store income, just barely compensates for inflation from 2008 to today money (which is just under 21% on USD). If you sold the same app at 99c from then to now, you’re only now earning as much as you were receiving in 2008 😅
Update (2020-11-23): Ken Harris:
Yet another reason not to price an App Store app at $0.99.
For an app priced at $10, and you have control over increments of 10%. At $20, increments are 5%, etc.
Beyond tier 50, you lose precision again. It’s like IEEE754. You want to stay in the middle of the range!
Update (2020-11-24): Apple:
Since Apple announced its new App Store Small Business Program, developers are sharing their positive reactions to the news. Under the new program, which launches January 1, 2021, the vast majority of developers who sell digital goods and services on the App Store can qualify for a reduced 15 percent commission. From focusing on their apps full time, to growing their teams, experimenting with features, and even launching new apps, developers are ready to write the next chapter of innovation and creativity on the App Store.
Update (2020-11-30): Jesper:
Seen from one perspective, Apple heard the feedback from developers and launched the program with clear and pure intent to build a better relationship with them. Seen from almost every other perspective, it is one in a series of ploys intended to protect, tooth and nail, a monopoly from being taken from them – a monopoly which ostensibly provides a marketplace for the enjoyment of developers and users, but which consistently serves themselves above any other party.
Tuesday, November 17, 2020 [Tweets] [Favorites]
Pop Quiz, what does this Swift program print?
5 years on, it still takes me a few tries to properly reason through this. Especially in the real world when the code is a bit more spread out or complex to fit in a tweet.
What is going on here is that the
MyProtocolconformance is onMySuperclass. Thus the witnesses are determined right there, and sinceMySuperclassdoesn’t implementmyFunction, the conformance uses the fallback implementation in the extension.Subclasses don’t/can’t “re-conform”
Previously:
Callum Booth (via Hacker News):
For all of Apple’s talk of being privacy-first, often its marketing speak doesn’t match up with what it’s actually doing. And the latest example? Well, it’s Apple apps on Big Sur bypassing firewalls and VPNs.
It is your right to know where your computer connects to. To whom it talks. It’s your right to see these connections. It’s your right to allow them. And it’s your right to deny them.
[…]
Three months later we realized, that a number of other Apple services like App Store, Maps or FaceTime also showed this strange behavior of acting invisibly, bypassing the new filter API. So we reported our new findings again on October 1 (FB8762834).
[…]
But hiding these connections completely from the user makes no sense. It contradicts the idea of a transparent and trustworthy system and undermines the user’s trust in that system.
[…]
In the light of the recent public discussions that this topic has triggered we are extremely confident that Apple stands by their word to give users control over their information and will therefore eliminate this kind of whitelisting in a future macOS update.
I used Little Snitch to diagnose the “OCSP apocalypse” last week.
It’s essential for network extensions to be able to block all network connections, including connections by Apple.
In Big Sur Apple decided to exempt many of its apps from being routed thru the frameworks they now require 3rd-party firewalls to use (LuLu, Little Snitch, etc.) 🧐
Q: Could this be (ab)used by malware to also bypass such firewalls? 🤔
A: Apparently yes, and trivially so 😬😱😭
Previously:
Update (2020-11-23): Maxwell Swadling:
Here is what a boot up of a clean Big Sur install looks like (+ ntp and push sockets). The Yahoo API ping is from spotlight asking what currency conversions are, not related to widgets.
And no you can not opt out of your Mac asking Yahoo what the currency conversion rates are.
All APIs are https, some send locale, Siri locale, software version and hardware string to Apple. Which enables Apple to build a pretty good understanding of international market distribution, current usage of each software version, etc.
If you’re a developer with a Mac app, you’ve likely heard both of the following support requests in the past few days:
1) “Can you put the old icon style icon back?”
2) “When are you going to update to the new icon style?”
It’s clear that customers want both icon styles.
The older icon style is easier to spot in the Dock (bigger and has a unique shape). More accessible.
The new icon style is more consistent, at the cost of readability. A cleaner look.
I get these questions every time the prevailing icon style changes. My apps have long offered the option to switch the Dock icon at runtime, as some people always prefer a previous style. Unfortunately, the -[NSApplication setApplicationIconImage:] API only works while the app is running.
Nova 3 even adds a super cool feature: a customizable dock icon that can automatically switch from “light” to “dark” when your Mac switches appearance.
This is using the (now somewhat dated)
NSDockTilePluginAPI, which is mainly used for calendar apps to show the current date in their icon.
This way works when the app isn’t running, but it requires an extra target/bundle and isn’t allowed in the Mac App Store.
I’m on Mojave, you maniacs!
Previously:
Update (2020-11-20): Guilherme Rambo:
I’m using
NSWorkspaceat runtime to change the icon on Big Sur while keeping the same icon on Catalina, precisely for that reason
He’s actually modifying the application package on disk.
Update (2020-11-24): John Gruber:
I would pay $$$ for an update to Transmit whose only new feature was bringing back the good app icon.
I like the new notification system a lot better than the prior one. Notifications are grouped better. Both notifications and widgets are on the same screen. Widgets also feel more intentional with the new iOS influenced widget system. This has been a win, and I’m using Notification Center now more than ever.
The grouping is nice, but I don’t like the invisible close boxes, and…
So many options and yet they are all the same.
I think Mojave’s notification design was better. When a new iMessage came in, there were buttons so that I could quickly reply or mark it as read. Catalina and Big Sur take extra clicks.
The important actions are now invisible, hidden behind a hover state that requires an extra click (“Options”).
Why?
I know the cost — it’s slower to use and less discoverable.
What are the benefits that make that cost worthwhile?
Wish we could move notifications down 80 pixels... below title bars and tabs.
Would be much less pressing to immediately dismiss them.
Previously:
Update (2020-11-20): Wojtek Pietrusiewicz:
I implore you to fix Messages and replying from a notification. What used to take 1 click on Mojave or Catalina, now requires 3 clicks. It’s actually faster to just open Messages and reply there.
Over the past several years, major music labels have taken legal action against several key players. YouTube-MP3 was shut down after a legal battle while 2Conv and FLVto are currently being sued. At the same time, rightsholders launched an active campaign to remove these sites from Google’s search results.
[…]
“There are 2 types of ‘purges’. The first one is ongoing; if YouTube notices too many requests coming from a single IP address – it blocks that IP. The second type is the ‘grand purge’ which sometimes happens daily, and sometimes two or three times a week,” he says.
In a world where Google did not own YouTube — and would, therefore, not have legal accountability for the misuse of licensed materials — would it be so keen to comply with copyright-based requests to remove stream rippers from search listings? I wonder.
theGunrun (via Hacker News):
No way, youtube-dl has just received a DMCA takedown
Looks like it’s was the RIAA that DMCA’d youtube-dl
Holy cow, the RIAA has gotten youtube-dl taken off Github.
I should say: Github has categorized the RIAA letter as a DMCA notice, but it’s not really — that term generally describes communications sent pursuant to §512. This letter is about the §1201, the controversial anticircumvention rules.
The closest example to this RIAA/youtube-dl letter is the one MPAA sent Github to try to shut down Popcorn Time back in 2014. That one cited §512, but relied under the hood on a fairly extraordinary tertiary liability theory
As anyone who has used youtube-dl knows, it is an extremely powerful and useful tool for format-shifting. It’s super popular among archivists and has incredibly broad fair use applications.
[…]
Keep in mind that Youtube has long allowed creators to expressly offer their videos under Creative Commons licenses.
This is a disgusting attack on software by @RIAA.
While Youtube-DL is a tool that can be used for piracy, it also has numerous legal applications. I use it almost every week, legally, to do my job.
Peter Higgins (via Hacker News):
Numerous reporters told Freedom of the Press Foundation that they rely on youtube-dl when reporting on extremist or controversial content. Øyvind Bye Skille, a journalist who has used youtube-dl at the Norwegian Broadcasting Corporation and as a fact checker with Faktisk.no, said, “I have also used it to secure a good quality copy of video content from Youtube, Twitter, etc., in case the content gets taken down when we start reporting on it.” Skille pointed to a specific instance of videos connected to the terrorist murder of a Norwegian woman in Morocco. “Downloading the content does not necessarily mean we will re-publish it, but it is often important to secure it for documentation and further internal investigations.”
According to the RIAA, the “clear purpose” of YouTube-DL was to “circumvent the technological protection measures used by authorized streaming services such as YouTube” and “reproduce and distribute music videos and sound recordings owned by our member companies without authorization for such use.”
As the debate and controversy over the complaint rages on, a company based in the US that operates a YouTube-ripping platform has filed a lawsuit alleging that similar complaints, filed by the RIAA with Google, have caused its business great damage.
Ernesto Van der Sar (via Hacker News):
An RIAA takedown request, which removed the YouTube-DL repository from GitHub, has ticked off developers and GitHub’s CEO. Numerous people responded by copying and republishing the contested code, including in some quite clever ways. Meanwhile, GitHub’s CEO is “annoyed” as well, offering help to get the repo reinstated.
Doc Edward Morbius (via Hacker News):
Under U.S. copyright law, “safe-harbour” provisions immunise service providers from copyright infringement claims, if the provider “takes down” the named content when a claim is received, under 17 USC 512 (c)(1)(C). The safe-harbour protections apply only to hosting of infringing works, and neither youtube-dl nor its test suites infringe on any RIAA or member copyrights as averred in RIAA’s notice. Further, a claim must identify the specific works infringed in the work, (§512 (c)(3)(A)(iii)) which the RIAA’s claim does not.
[…]
At best, youtube-dl’s test suite may be infringing works when run, in which case infringement would accrue to the operator, presumably a tester or Github’s CI/CD process. Even that argument is specious: Given output is discarded, no permanent copy is retained, and the action is for research and development, and numerous Fair Use affirmative defence claims exist under §107, notably (1) and (4), test suite execution falls outside exclusive rights. Any one fair-use test is sufficient, or none at all. Test suite execution could be argued non-infringing under numerous theories, including reverse engineering, research, interoperability, all under §1201, or under general limitations on exclusive rights in §112 (ephemeral recordings), §117 (computer programmes), or elsewhere.
Michael Collins (via Hacker News):
The notice claimed the youtube-dl software was a ‘Anticircumvention Violation’ as well as a violation of YouTube’s terms of service.
[…]
I reached out to previous maintainer Phillip Hagemeister, who had this to say about the incident[…]
so the CEO of GitHub popped in #youtube-dl a few hours ago, looks like they are trying to get youtube-dl back, i hope this works out
Andy Maxwell (via Slashdot):
While Github says it wants to help the project come back online, the platform is now warning that users reposting its code could find their accounts suspended and potentially banned.
Elliot Harmon, EFF (via Hacker News):
This is an egregious abuse of the notice-and-takedown system, which is intended to resolve disputes over allegedly infringing material online. Again, youtube-dl doesn’t use RIAA-member labels’ music in any way. The makers of youtube-dl simply shared information with the public about how to perform a certain task—one with many completely lawful applications.
Abby Vollmer, GitHub (via Hacker News, Slashdot):
Today we reinstated youtube-dl, a popular project on GitHub, after we received additional information about the project that enabled us to reverse a Digital Millennium Copyright Act (DMCA) takedown.
[…]
Section 1201 dates back to the late 1990s and did not anticipate the various implications it has for software use today. As a result, Section 1201 makes it illegal to use or distribute technology (including source code) that bypasses technical measures that control access or copying of copyrighted works, even if that technology can be used in a way that would not be copyright infringement. Circumvention was the core claim in the youtube-dl takedown.
[…]
First, we were able to reinstate a fork of youtube-dl after one of the fork owners applied a patch with changes in response to the notice.
Then, after we received new information that showed the youtube-dl project does not in fact violate the DMCA‘s anticircumvention prohibitions, we concluded that the allegations did not establish a violation of the law.
[…]
Going forward, we are overhauling our 1201 claim review process to ensure that the following steps are completed before any takedown claim is processed[…]
[…]
Nonetheless, developers who want to push back against unwarranted takedowns may face the risk of taking on personal liability and legal defense costs. To help them, GitHub will establish and donate $1M to a developer defense fund to help protect open source developers on GitHub from unwarranted DMCA Section 1201 takedown claims.
The “additional information” link is a response to the RIAA’s takedown request by the EFF, acting on behalf of the youtube-dl project.
Previously:
Monday, November 16, 2020 [Tweets] [Favorites]
Still on Catalina 10.15.7 SuppUp and just installed Safari 14.0.1 (15610.2.11.51.10) over 14.0 today, and all my .webloc icon previews are blank. That includes desktop icons, folder icons, and Get Info Preview icons.
Both my .webloc and .webarchive files now show only generic document icons. I’ve heard from others that the files no longer even open, but I’m not seeing that problem. On my Mac, it seems likely purely an icon display issue.
Safari 14.0.1 does fix the services bug that I was seeing, but only for some services.
Previously:
Hartley Charlton (tweet, Hacker News):
A large number of late 2013 and mid 2014 13-inch MacBook Pro owners are reporting that the macOS Big Sur update is bricking their machines. A MacRumors forum thread contains a significant number of users reporting the issue, and similar problems are being reported across Reddit and the Apple Support Communities, suggesting the problem is widespread.
I tried a number of the things that were advised below, but so far, none worked. I’ll try an install from USB next, I guess. It won’t be the end of the world if my data on this machine is lost, but still… makes me sad for my non-developers friends who have to deal with this.
[…]
this is machine is only 2 years old I think.
Previously:
Update (2020-11-17): Becky Hansmeyer:
I still get emails from my college (because I used to work there and they didn’t take me off the mailing list). Got this one from the Help Desk today about Big Sur. 😳
Pol23 (via Hacker News):
Then I closed the screen but the black light was still illuminating the apple on the back of my 2014 13' MBP. I opened it back up andpowered it down. Then tried restareing but got nothing but the black screen, no apple logo..
[…]
All of that lead to nothing. Genius Bar Reservations are hard to obtain during covid times.
Update (2020-11-20): Mr. Macintosh (also: MacRumors):
macOS Big Sur 11.0.1 (20B50) is Live
The only change?
The 2013-14 13" MacBook Pro’s have been removed from the Big Sur Installer compatibility list
Owners complained that the upgrade caused their Mac to boot to an unrecoverable black screen
Apple has now addressed this issue in a new support document that provides instructions on what to do if macOS Big Sur can’t be installed on a 2013 or 2014 MacBook Pro machine. Apple suggests Mac owners experiencing these issues unplug external devices, attempt restarting, reset the SMC, and reset NVRAM or PRAM.
[…]
To be safe, those with older MacBook Pro models from 2013 or 2014 should avoid installing the macOS Big Sur update at this time until a more definitive fix becomes available.
Apple has updated its TestFlight beta testing application for iPhone, iPad, and Apple TV to version 3.0. The update brings support for automatic updates, as well as stability improvements and bug fixes.
New version of TestFlight that’s NOT on the Mac.
After five years of promises, I can only conclude that there’s some underlying issue that’s preventing the release. I’m guessing there’s a vulnerability in one of the services that would be exposed with a debugger/analyzer.
It sucks for every developer who wants to get their products onto the Mac, and hurts Apple’s initiatives like Catalyst.
Previously:
