If you rely on iCloud Backup for your iPhones and iPads, be aware that Apple automatically deletes inactive backups after 180 days. In other sour news, Apple is ending support for iBooks Author, a once-groundbreaking ebook creation tool whose functionality has largely been subsumed by Apple’s Pages word processor. Rumors are once again hot and heavy about Apple switching the Mac from Intel processors to its own ARM-based chipsets. Apple veteran David Shayer joins us again this week to explain why Apple might make the switch. Wrapping up the issue, Josh Centers shows how you can use shell scripts with BitBar to put just about anything in your Mac’s menu bar. Notable Mac app releases this week include Art Text 4.0, EagleFiler 1.8.14, Typinator 8.4.1, Default Folder X 5.4.6, and Logic Pro X 10.5.1.
TidBITS reader Walter Ian Kaye had a simple question: “Did you know Apple deletes iCloud backups over 180 days old? I didn’t. 😭”
I’m always bemused when I discover myself adopting one of my son’s expressions, and my immediate reaction was a teen-speak refrain from his high school years: “Wait, what?”
I had no idea that Apple deleted iCloud backups after 180 days, and a quick poll in the TidBITS Slack channel showed that it wasn’t common knowledge among other TidBITS staffers and contributing editors.
But a quick Google search revealed that the policy is far from new—I see perturbed iCloud users complaining as far back as 2014, and Take Control author Kirk McElhearn mentioned the fact in a 2013 Macworld article.
Apple does document this fact in various places, including in the iCloud User Guide, the Manage Your iCloud Storage support document, and the iCloud Terms and Conditions. But if you were expecting that you might be warned about such a limitation in the iOS interface, such as on the screen where you enable iCloud Backup or learn more about what’s backed up, you’d be disappointed.
Apple’s acknowledgment of the deletion policy is not quite as hidden as the plans for demolishing Arthur Dent’s house in The Hitchhiker’s Guide to the Galaxy. But the effect is roughly the same if you were planning on restoring from your iCloud backup, only to discover that Apple had deleted it, with the only warning being in support documents you’ve never read.
On the one hand, it makes some sense that Apple would want to delete device backups—which can be quite large—that no one is ever going to want to use again. With hundreds of millions of devices backing up to iCloud, the storage requirements boggle the mind.
But on the other, what was Apple thinking?!? Deleting a user’s one and only backup, particularly without clear documentation in the user interface and express warning of the pending deletion, is simply unacceptable.
Of course, most people will never run into this problem. It’s unusual that someone would make a backup and then let it sit for over 6 months before wanting to restore. Unusual, but far from impossible. Walter had backed up a dying iPad and was saving the money to replace it, assuming that he’d be able to restore because he was paying Apple every month for 200 GB of iCloud storage space.
Apple clearly already has a scheduled process that checks backup age and deletes backups over 180 days old. It can’t be that difficult for Apple’s engineers to adjust that process to send out an email message to the user saying:
Your iCloud backup for “Adam’s iPad 2” made on January 1st, 2020, expires on June 30th, 2020. It will be deleted after that unless you make another backup using that device before then.
Even better would be to include in that email message a link the user could click to reset the 180-day counter. That would let people like Walter prevent the backup from expiring until they could restore it.
In the meantime, if you want to ensure that an iOS device backup sticks around indefinitely, you’ll need to back it up to your Mac, using either the Finder in macOS 10.15 Catalina or iTunes in previous versions of macOS (there are other differences between the backup types as well, though the 180-day limit isn’t mentioned). Unfortunately, local backups can consume significant space (my iPhone 11 Pro’s backup is over 67 GB). Plus, they must be stored in
~/Library/Application Support/MobileSync/Backup/, which is problematic for those with small boot drives—that was why Walter was using iCloud Backup in the first place.
Apple has informed participants in its iTunes Connect media publishing service that the iBooks Author app for Mac “will no longer be updated and will soon be removed from the Mac App Store.” This is a moment long feared by fans of iBooks Author (see “iBooks Author Conference Highlights Worries about iBooks Ecosystem,” 24 October 2017).
Introduced at a special education event in early 2012 (see Apple Goes Back to School with iBooks 2, iBooks Author, and iTunes U, 19 January 2012), iBooks Author was Apple’s attempt to provide a tool for “educators and smaller publishers to create their own books.” Apple instead will focus its ebook creation software efforts on Pages and has provided a support document, “Transition from iBooks Author to Pages,” to help iBooks Author users make the switch to Apple’s word-processing and page-layout app.
At its introduction in 2012, iBooks Author seemed to herald a renewed interest in instructional software on Apple’s part. Designed to put the creation of interactive textbooks into the hands of educators, it provided powerful yet (relatively) simple to use word processing and ebook layout features along with a gallery of “widgets,” interactive items that book authors could drop into their manuscripts, such as image galleries, embedded spreadsheets, quizzes, and various kinds of media.
However, ebooks produced with the early versions of iBooks Author were not standard EPUB documents, readable in third-party ebook readers. Instead, they were limited to Apple’s iBooks reading software, which provided support for the non-standard interactive content that iBooks Author books could contain. Nonetheless, many publishers took advantage of the software to produce media-rich books not intended for the educational market, such as travel books and cookbooks.
iBooks Author soon fell on hard times: Apple’s book publishing business became mired in an antitrust case over price-fixing just a few months after iBooks Author was released (see “Explaining the Apple Ebook Price Fixing Suit,” 10 July 2013). While Apple battled the suit, which it eventually lost, the company seemed to lose interest in promoting the app and providing support for educators who wished to use it. Apple continued to update iBooks Author, even adding support for exporting in EPUB format (see “Updates Expand iBooks Author’s Reach,” 10 July 2015), but the company rarely mentioned it in public.
Instead, Apple turned its attention to Pages. Long a part of Apple’s iWork suite, Pages was being completely redesigned by Apple at the same time the company was fighting for its book business in court. When that app, now Pages 5, arrived in late 2013, most observers considered it to be feature-poor compared to the previous versions of Pages (and to iBooks Author), and it offered none of the distinctive capabilities that iBooks Author possessed (see “New Free iLife and iWork Apps Share across Devices and Platforms,” 22 October 2013). Nonetheless, Apple continued to enhance and expand Pages’ capabilities, and recent versions of Pages have included ebook templates, ebook publishing capabilities, and media features similar to some of those in iBooks Author (see “Pages 7.3, Numbers 5.3, and Keynote 8.3,” 12 November 2018).
With the imminent demise of iBooks Author, Pages is the only ebook publishing app from Apple available to publishers and educators. As far as publishers are concerned, the current version of Pages may well fill the void that iBooks Author’s absence will create. Its ebook formatting capabilities have become quite powerful, and, unlike iBooks Author, Pages can produce standard EPUB books that can be read on other devices than Apple’s own.
For educators, Pages is a mixed bag. On the one hand, Pages provides only a few counterparts to iBooks Author’s widgets—specifically, media and image galleries. On the other hand, Pages runs on iPads, iPhones, and Web browsers as well as on Macs and offers collaborative capabilities that iBooks Author never possessed.
This last point is important. Even though educators should have access to powerful ebook publishing tools, few working teachers have the time or expertise to write and publish books on their own while also preparing lesson plans, marking assignments, and, of course, teaching classes. Being able to share the workload, to collaborate with other teachers and with content experts on a book project, is a capability that iBooks Author never offered.
Unlike the proverbial doghouse in which iBooks Author has languished over the last half-decade, Apple has updated Pages regularly and with at least a modicum of fanfare so that people know it exists. In many ways, Pages has become the rich media authoring app that iBooks Author aspired to be. We can hope that Apple brings more of the iBooks Author widgets to future versions of Pages.
Fortunately, veteran iBooks Author users need not discard their hard work when the app they have been using finally disappears into the great bit-bucket in the sky. In its letter to iTunes Connect members, Apple said, “If you have iBooks Author books you’d like to import into Pages for further editing, we have a book import feature coming to Pages soon.”
If that import feature works well, the demise of iBooks Author, while sad, may not be as heartbreaking to aspiring educational authors as it might have been.
Persistent rumors suggest that Apple will switch from the Intel x86 processors in current Macs to ARM processors like Apple’s A series of chips that power iOS devices. Apple has said nothing about such a transition, but that’s par for the course for Apple. Recently, however, Mark Gurman at Bloomberg wrote about Apple moving to ARM-based Macs in 2021 (“Bloomberg Reports Apple Will Start Transitioning the Mac to ARM in 2021,” 27 April 2020) and he followed it up this week with another piece suggesting that an announcement might come on 22 June 2020 at Apple’s Worldwide Developers Conference. While Bloomberg has its problems (see “Apple Categorically Denies Businessweek’s China Hack Report,” 8 October 2018), Gurman is known for reliable sources and accurate reporting.
ARM is by far the most popular processor family in the world. While there are several billion Intel PCs in the world, there are over 100 billion ARM devices. When Apple designed Intel-based Macs, they were the first major products Apple had ever made with x86 chips. But Apple has lots of experience with ARM chips. The first Apple device to use an ARM processor was the Newton in 1993. Since then, Apple has put ARM processors into the iPod, iPhone, iPad, Apple Watch, and Apple TV.
Apple has successfully switched the Mac’s processor twice before. In 1994, Apple moved from the Mac’s original Motorola 68000 processors to IBM PowerPC processors. And in 2006, the company ditched the PowerPC in favor of Intel x86 processors. Both transitions were fairly smooth due to years of testing—Apple maintained a version of Mac OS X running on Intel chips years before the first Intel Macs shipped. Apple almost certainly has a version of macOS running on ARM right now, in some secret lab.
I don’t have any inside information on whether Apple is working on ARM-based Macs. But let’s look at the pros and cons of switching from Intel to ARM.
The Obvious Win: Reduced Power Consumption
The most commonly cited advantage for ARM processors is lower power consumption. It’s true that ARM processors use less power than Intel’s x86 processors. Part of this advantage comes from ARM’s relatively clean, modern design, as set against the years of baggage that Intel has accumulated since the original 8086 processor. Perhaps even more important is the way ARM would allow Apple to add the specific support it needs into its own ARM chip designs, instead of relying on off-the-shelf parts that Intel has designed for generic PC implementations.
Lower power consumption would lead to better Macs in several ways. Most obviously, the battery on your laptop would last longer. Instead of 8 hours, a new ARM-based Mac laptop in the same form factor might get 12 hours from a single charge. But Apple is always trying for thinner, lighter laptops. Apple might decide that 8 hours of battery life is fine for most users and instead use a smaller battery in an even skinnier, featherweight laptop design.
Reduced power usage would also result in less heat generated by the processor, which would mean smaller heat sinks and less fan noise. That would bring benefits to both laptops and desktops. Computers that run close to their thermal design limits, like the iMac Pro, could get more powerful processors in the same design or smaller cases with the same processing power.
But lower power wouldn’t be the only benefit of switching to ARM, or even the main benefit.
Apple’s True Motivations: Control and Profit
Apple wants to control its own destiny, and the best way to do that right now is to control the processor roadmap. Roadmap refers to future development plans: what features are added, in what order and on what schedule, which fabrication plants and processes are used, how many processors are produced, and how many units are allocated to each manufacturer. Apple doesn’t want to depend on Intel for these key decisions. As Tim Cook has famously said, “We believe that we need to own and control the primary technologies behind the products we make.”
The other reason for switching from Intel to ARM is profit. Intel processors are high margin products, and Apple wants to capture that lucrative margin for itself rather than paying it to Intel.
In short, Apple’s main reasons for switching from the Intel x86 architecture to the ARM architecture are business, not technical. Let’s look at these and related business decisions.
Controlling the processor roadmap lets Apple better control its products. Rather than being stuck with the components Intel puts in a particular chipset, Apple can custom design a System On a Chip (SOC) specifically for the Mac, just as it has for iOS devices for years now. Apple could control the number and type of cores, the digital-signal processor media cores, the size of the data and instruction caches, the memory controllers, USB controllers, Thunderbolt controllers, etc. Apple would control not just a single chip, but the entire direction of the processor line.
Unlike PC vendors, who license Windows from Microsoft or ChromeOS from Google, Apple also controls the operating system. This gives Apple a huge advantage over its competitors. Apple’s latest iPhone SOCs include both fast and slow cores, which the company prefers to call “performance” and “efficiency” cores. The advertised speed for a computer, like “3 GHz processor,” is the speed of the fast cores. When you do something processor-intensive, like rendering video in Final Cut Pro X or compiling an iPhone app in Xcode, those tasks would spin up all the fast cores. When you’re writing an email message or reading a Web page, the Mac doesn’t need to do hardly anything. Right now, all macOS can do is run the main Intel processor at a slower speed. With a custom ARM-based SOC with fast and slow cores, macOS could switch to slower, more energy-efficient cores. Dynamically switching cores depending on the task is key to saving energy.
In its A series chips for iOS devices, Apple also has custom-designed media cores for tasks like decoding video for a movie, audio for a podcast, and encryption. While Intel chips have similar features, with a custom chip, Apple could optimize for the media formats and encryption algorithms most common on Macs. And since Apple also controls macOS, it can ensure that macOS algorithms and processor cores are perfectly matched, again ensuring that they consume less power for any given task. When Apple engineers improve their algorithms, they can update their next-generation media cores to perfectly support the improvements, without those improvements also becoming available to competitors.
Much of the code in a modern Mac app just glues together macOS API calls to accomplish a task. For many apps, the bulk of the processor-intensive work happens in macOS. This means Apple can optimize much of the work that apps do for the new ARM processors, even before third-party developers become expert at exploiting the new ARM processors themselves. For instance, playing a movie mostly consists of calling on macOS, which does the heavy lifting of decoding the video using Apple’s optimized media cores.
Intel’s Production Problems
Over the last few years, Intel has suffered a series of production problems. Many of them were the result of moving to smaller processes, that is, etching smaller parts onto the silicon. Smaller processes create smaller chips that use less power and generate less heat. Although we’ll never know for sure, one likely reason Apple had a long dry spell releasing new Macs was Intel’s tardiness in providing the new chips Apple needed. This had to impact the number of Macs sold. Although Apple never complains about partners publicly, it obviously isn’t happy with Intel.
Buying Intel chips makes Apple dependent on Intel chip fabs. When Apple designs its own chips, it can use whatever fab it likes. Apple currently relies on TSMC and Samsung for its A series chips, but if those companies have problems meeting Apple’s needs, Apple can use another fab, assuming it has equivalent capabilities. Apple prefers having multiple sources for components.
Sometimes production problems are technical, like Intel’s were. But they can also be political, like tariffs applied to Chinese goods, or natural disasters like the floods that closed Thai hard disk factories in 2011 and caused worldwide shortages. Multiple sources mean that problems with one vendor won’t halt production.
Next to the screen, the processor is one of the most expensive parts in a computer. The processor isn’t just expensive; it’s also high margin. In high production volumes, processors are sold for much more than they cost to build. Relying on Intel processors means Intel earns those rich margins instead of Apple. Designing and building its own processors would let Apple capture those margins. Apple can keep selling computers at the same price and book the additional profit, or it can sell the same computers for less, without compromising the company’s famously fat margins.
Although it might seem as though Intel and ARM are competitors, they actually have utterly different business models. Intel designs the processor and all the associated support components like memory controllers. It integrates them into a System On a Chip. It manufactures the chips in its own fabs. And while it sells the chips directly to computer manufacturers, it also markets its brand to the public (“Intel Inside”). Intel makes most of its money selling high-end processors. The fastest processors have the fattest margins but are quickly obsoleted by even faster processors, so Intel is always pushing the envelope. Intel has a few rivals like AMD, but for the most part, Intel is the dominant vendor of high-end processors.
ARM (previously known as Advanced RISC Machines, now Arm Limited) works completely differently. ARM designs processors and licenses the designs. ARM doesn’t supply supporting components or build its own chips. The licensee integrates the ARM processor and supporting components into a SOC—this is what Apple does for its A series of chips. ARM processors are inexpensive and have low margins, so ARM makes money on volume. There are many, many more ARM processors than Intel processors—I heard someone say that, to a first approximation, all processors in the world are ARM processors.
Intel makes a lot more money than ARM because Intel CPUs are expensive high-performance chips, and Intel designs, builds, and sells the processors. ARM just licenses its designs, and most of those are inexpensive low-power designs.
But Apple is successfully scaling up the performance of its ARM-based processors to compete with Intel’s processors. The ARM business model lets Apple make competitive parts much more cheaply and capture that margin itself.
Using the same processor in all Apple products would be more efficient company-wide. Apple’s hardware teams would have to support only one processor architecture, one memory controller, and one I/O system. Most apps written in a high-level language like Swift or Objective-C wouldn’t need a lot of modification. Low-level software like boot code and device drivers could be shared. Development tools and the App Store would save work targeting a single instruction set architecture.
Of course, these savings will take several years to materialize. In the meantime, Apple will support Intel-based Macs for customers and developers for a few years.
What Would the Transition Look Like?
Apple’s transition from IBM’s PowerPC architecture to Intel x86 was fairly quick—the entire Mac line switched in less than a year. While Apple could switch to ARM that quickly, the company might proceed more slowly. The most obvious customer advantage comes in smaller laptops like the MacBook Air. An ARM-powered MacBook Air could be more powerful than its Intel predecessor, with longer battery life, while simultaneously being thinner and lighter: a winning package. The ARM SOCs in the current iPads are already more powerful than the Intel processors in most of Apple’s laptop line, so transitioning all Apple laptops to ARM makes sense.
The Mac mini isn’t any more powerful than a high-end MacBook Pro and could be powered by the same ARM processor. Users of the iMac, and especially the iMac Pro, probably want a more powerful processor than any ARM chip shipping now, since the goal isn’t just to match currently shipping products, but to surpass them. An ARM chip powerful enough for an iMac seems well within Apple’s immediate roadmap.
The issue is the Mac Pro, which relies on high-end Intel Xeon processors. It’s certainly possible for Apple to develop a competitive ARM processor—the only question is how long that would take. Also, the sales volume of the very expensive Mac Pro is probably fairly low, meaning that a custom ARM SOC developed for it is unlikely to ever sell in high enough quantities to amortize the cost of its development on its own. Apple will have to consider it part of the overall cost of moving to ARM.
As long as Apple sells and supports any Intel Macs, it must build, test, and maintain two versions of macOS, two copies of every app, and two sets of Xcode development tools and App Store infrastructure. This effort will come at a significant cost. Once the transition starts, Apple will want to move past the Intel era as quickly as is practical.
In past transitions (Motorola 68000 to IBM PowerPC, then PowerPC to Intel), Apple included an emulator in the operating system that ran apps written for the previous processor family. It’s logical to assume Apple would include an emulator for running Intel apps on the new ARM Macs. Previous emulators worked with near-perfect fidelity, and an Intel emulator on ARM ought to have excellent fidelity too.
But to take full advantage of the new ARM chips, third-party developers would have to recompile their Mac apps for ARM and submit updates to the App Store. Some minor changes may be required, but it shouldn’t be too much work. The App Store accepts apps encoded in the LLVM intermediate language, which allows developers to submit one compiled version of their app, which the App Store then translates for iPhone models with slightly different ARM processors. But the LLVM intermediate language isn’t robust enough to translate an Intel app into an ARM app.
What About Windows?
One casualty of an ARM transition may be Microsoft Windows compatibility. Current Macs use the same Intel processors as Windows PCs, letting you run Windows and its apps at full speed. Apple makes it easy to boot your Mac as a Windows PC with Boot Camp, and third-party virtualization products like VMware Fusion and Parallels Desktop run Windows inside macOS. If Macs no longer have Intel chips, they won’t be able to run Windows, at least the mainline version compiled for Intel processors, natively.
There are several other options. Apple’s Intel x86 emulator might support running Windows too. There were Windows emulators for PowerPC Macs, but they were never as fast as Windows running on a real PC. The performance may be good enough for occasional tasks that require Windows, but it will probably be unsatisfactory for gaming or other hardcore use.
Plus, Microsoft released Windows for ARM for its Surface Pro X. But most third-party Windows software isn’t available in an ARM-compatible version. While there may be a vocal minority of Mac Windows users, they are probably too few for Apple to care about.
ARM in Your Future
The case for ARM Macs is compelling. Long term, it doesn’t make sense for Apple to support two processor families, so the entire Mac product line will probably move to ARM eventually. If the transition to ARM goes as smoothly as the transitions to PowerPC and Intel did, customers have much to gain and little to fear.
There are all sorts of apps that add various capabilities to your Mac’s menu bar, but I’ve stumbled across one that can add literally anything to the menu bar through a plug-in system. It’s called BitBar, and it’s both free and open source. I’ve tested and confirmed that it works in both macOS 10.14 Mojave and 10.15 Catalina.
When you first launch BitBar, it asks you to choose a directory to store plug-ins. I made a BitBar folder on my iCloud Drive so I can easily sync plug-ins between machines. That works well, and I presume Dropbox or Google Drive would work similarly.
The BitBar Web site contains a rich library of community-created plug-ins. There are plug-ins for displaying weather, stock prices, cryptocurrency prices, email messages, Slack notifications, and pretty much anything you can think of, such as whether your cat is in or out. Installing a plug-in is as easy as clicking the Add to BitBar button on a plug-in’s library page, which installs the plug-in into your specified plug-in folder.
All BitBar plug-ins are simple text-based shell scripts. Removing one is as simple as moving it out of your plug-in folder, Control-clicking BitBar in the menu bar, and choosing Preferences > Refresh All (I disable plug-ins by putting them in an Archive folder in my plug-in folder). Likewise, you can drag any shell script you want into the plug-in folder and refresh to make it available. You can quickly get to your plug-in folder by Control-clicking BitBar and choosing Preferences > Open Plugin Folder.
The beauty of BitBar is that any script that works in Terminal can be a BitBar plug-in. It could be a simple shell script, a Python script, a Ruby script, or even an AppleScript if you put the right hooks in. It also means that you can easily modify all the available plug-ins in any text editor, and you may be able to figure out how to make small changes just by following the script’s example, even if you don’t know the scripting language well. In fact, that’s a common situation.
Modifying BitBar Plug-ins to Get What You Want
Imagine that you find a plug-in that does kind of what you want, but not quite. The good news is that it’s easy to modify a plug-in.
For instance, I took the Got Internet? plug-in, changed its
ping_address variable from
188.8.131.52 (Google DNS) to
tidbits.com, and changed the display text so that it shows “TidBITS 👍” when our Web site is reachable and “TidBITS 👎” when it’s not.
Here’s a little hack you might find useful. Install the Simple RSS Reader plug-in, open up its file, and change the
FEED_URL variable, which is by default
https://tidbits.com/feed/. You can now access all the latest TidBITS articles from your menu bar!
I also tweaked the Coinbase Prices plug-in. It shows a bunch of different cryptocurrencies by default, but not the one I mostly care about: Chainlink. So I simply copied the
dash_price line of code, pasted it at the end of the block, renamed it to
link_price and changed
DASH-USD in the Coinbase URL to
LINK-USD. Finally, I added an
echo $link_price line at the end. This was just monkey scripting—the script is in Python, which I don’t know well, and my changes worked just fine, aside from not showing a fancy icon on the side of the price.
The plug-in that I’ve modified the most heavily—and the one that actually led me to BitBar—is mpd-control. After getting fed up with iTunes/Music messing up my music library, I’ve been experimenting with the command-line-based mpd music daemon, which has a number of front ends. I like the Terminal-based ncmpcpp, but it’s awkward having to switch to a Terminal window to pause my music. The mpd-control plug-in, by default, shows the currently playing track and clicking it plays or pauses the music. It was simple enough to change it so that I have a menu of commands that let me play/pause, move to the next or previous track, and open ncmpcpp in a Terminal window.
If you’re not as nerdy as I am, there’s also a nice iTunes Now Playing plug-in to control your music from the menu bar.
For an extreme example, I brought in a menu bar script I use in Linux to see the weather forecast. Amazingly, it worked pretty much out of the box. I modified it to add an option to open Terminal and
curl wttr.in, which brings up a console-based weather forecast.
Creating Plug-ins in BitBar
Let me show you how easy it is to create a BitBar plug-in. If you don’t know any shell scripting, this is a great way to learn, since you can easily integrate your shell scripts with the native macOS interface without much risk. And if you don’t want to learn, you could sweet-talk or pay someone to create the plug-in you need.
You don’t have to start from scratch. The BitBar documentation includes several top-to-bottom examples, and the plug-in gallery even has tutorial plug-ins illustrating different concepts that you can modify to your heart’s content. But let me show you how I created a plug-in from scratch to demonstrate how simple it can be.
Open Terminal in
/Applications/Utilities. Don’t worry, we’re not doing anything scary. Type
date and press Return. You get the current date and time.
You can easily put that into BitBar. I opened BBEdit and made this simple script called date.sh.
The first line,
#!/bin/bash, tells the system that it’s a script. Once you make that text file executable, macOS will recognize it as a program (see below for instructions) and execute any Terminal commands that follow the first line. The next line simply invokes the
date command. In other words, typing
date in Terminal shows you the current date and time, and if you put that command in a BitBar script, it will do the same thing.
Making a script file executable can be a little intimidating if you’re not used to the Terminal, but it’s not hard. You have to do this so it can be run as a program.
- Open Terminal.
- Open the BitBar plug-in folder in Finder.
- In the Terminal, type
chmod +x(including the trailing space) to make the script executable.
- Drag the
date.shicon from the the Finder window into Terminal, which inserts its directory path.
- Press Return.
Refresh BitBar, and you now have a date and time display.
If you type
man date in Terminal to see the manual pages for the date command, you’ll see examples of how you can customize the output. Feel free to play around with it.
But what if we want to make it so clicking the date opens the Calendar app? That’s easy to do, but it takes some jiggering. There are special formatting hooks you can add to a script to add BitBar actions, listed on BitBar’s GitHub page. But they work only in the context of an
echo command, which is a simple Unix command to display text or the value of a variable in Terminal.
So first, I changed the script to assign the output of the
date command to a
MYDATE variable, like so:
MYDATE=$(date) (note there are no spaces around the equals sign!). Don’t let the symbols intimidate you—you’re just creating a variable called
MYDATE. The dollar sign and parentheses tell the system to assign the output of the date command to that variable.
Next, I created a line that tells BitBar to display the date and make it clickable. If I were to write just
echo $MYDATE, it would show only the contents of the
MYDATE variable—no different than before. But I then added the special BitBar hooks, so it looks like this:
echo "$MYDATE | href=file:///Applications/Calendar.app"
First, it echoes the
MYDATE variable. (Note that in shell scripting, you refer to a variable by putting a dollar sign ($) in front of the variable name.) Inside the quotes, I put not only that
MYDATE variable but also the BitBar-specific commands, delimited by the pipe symbol. If you are familiar with HTML, you’ll recognize the
href command, which specifies a link. I use that to create a link to the Calendar app.
After a refresh, I could click the date to open the Calendar app. The full script looks like this:
#!/bin/bash MYDATE=$(date) echo "$MYDATE | href=file:///Applications/Calendar.app"
But what if you want a menu of commands? You can accomplish that by adding
echo "---" anywhere in the BitBar plug-in script. However, with the way the plug-in is set up now, I won’t see the menu because it opens Calendar whenever I click it. So I need to change it back to make it not clickable:
#!/bin/bash date echo "---"
But what commands should we put in our menu? Let’s make a clickable link to the Calendar app, like this:
echo "Calendar | href=file:///Applications/Calendar.app"
All I’m doing here is echoing the word “Calendar” and using the code from the previous example to make it open the Calendar app when clicked.
So our final plug-in script looks like this and shows the date as a menu from which you can open the Calendar app:
#!/bin/bash date echo "---" echo "Calendar | href=file:///Applications/Calendar.app"
You might notice that the time it reports is slightly off. By default, each BitBar plug-in refreshes once every minute. You can change this by simply adding a timestamp to the filename, like this:
date.1s.sh. Change that to
date.1h.sh to refresh every hour or
date.1d.sh to refresh once per day. Check the BitBar documentation for more info.
You can take this basic example and expand it in a few ways:
- Change the date format
- Open other calendar apps like Fantastical or BusyCal
- Create a shortcut to the Date & Time preference pane
Making a Bookmarks Plug-in
I often switch between Web browsers, and I get tired of trying to keep my bookmarks in sync. I could use Alco Blom’s URL Manager Pro, but in the interests of rolling my own, I’ve been thinking that a good solution would be a simple text file with one URL per line. Text editors like BBEdit usually let you easily follow URLs in text files (in BBEdit, Command-click a URL to open it in your default browser). While playing with BitBar, I thought: “Wait, maybe I could turn a list of links into a plug-in.” It turned out to be pretty easy, though I’m still working on perfecting it.
My first plug-in along these lines was extremely basic. I created a list of URLs and saved it in
~/Documents/urls.txt. (If you want to follow along, you can name it whatever you want and store it wherever you want.)
I then structured the script like so:
#!/bin/bash # Tell the system this is a script LINKFILE=~/Documents/urls.txt # Create a variable called LINKFILE that points to my URL list, # which is cleaner than referring to the list directly in the code. echo "URLs" echo "---"
These two lines tell BitBar to make “URLs” the display name and echo
--- indicates a submenu.
Here’s where things get interesting. We’re going to bring in our URL list and echo each line along with the command that tells BitBar it’s a link.
while read line; do echo "$line|href=$line" done <$LINKFILE
The key part is at the end,
<$LINKFILE, which tells the shell to import every line of that file into the
while read line translates to “While this file has a line I have not processed, read the line in and store it in variable
do just means do. While there are lines to process, it will echo that line,
$line, along with the pipe character and
href=, which tells BitBar that the following text is a link. The second
$line simply tells BitBar to link the title
$line to the URL
$line. In this case, the link title and link URL are identical.
In practice, it looks like this:
That works, but I’d rather have descriptive names instead of raw URLs. Also, I have a lot of bookmarks and only so much screen real estate. So I tried my hand at creating a Markdown-based bookmark file that would contain descriptive names and a menu hierarchy. Such text processing necessitated using regular expressions, and the simplest way to do that in a shell script is the
sed command, with which I’m not very familiar. So I Googled enough
sed commands to make it sort of work:
#!/bin/bash LINKFILE=~/Documents/SyncThing/links.md echo "Bookmarks" echo "---" while read line; do [ -z "$line" ] && continue LINKNAME=`echo $line | sed 's/^.*\[//;s/\].*$//'` LINK=`echo $line | sed 's/^.*(//;s/).*$//'` echo "$LINKNAME|href=$LINK" done <$LINKFILE
The above code isn’t that different from the first bookmark script. It cycles through a list of links, only in Markdown this time, and in each line it uses
sed to extract either the title or the URL and add it to a variable. It then echoes the
LINKNAME variable and tells BitBar to link it to the URL stored in
[ -z "$line" ] && continue line at the top of the
while loop tells the shell to skip blank lines.
Note the backticks (`) around the commands assigned to
LINK. They tell macOS to assign the results of the commands to the variable instead of just the text.
I have one problem with this setup. The way BitBar does sub-menus is weird. In Markdown, headings work like this:
#Bookmarks [TidBITS](https://tidbits.com/) [TidBITS Talk](https://talk.tidbits.com/) [The Prepared](https://theprepared.com/) ##News [Slashdot](https://slashdot.org/)
# indicates a top-level header,
## is a subhead, and so on. However, to get it to work with BitBar, I have to format my Markdown URL list like this:
[TidBITS](https://tidbits.com/) [TidBITS Talk](https://talk.tidbits.com/) [The Prepared](https://theprepared.com/) News [--Slashdot](https://slashdot.org/)
So the subfolder name is “News,” and to indicate that an item goes into that subfolder, I have to put two dashes in front of the line. I’m sure it’s possible to create a script to count the number of lines under a Markdown header, strip away the
# characters, and insert
-- in front of each line under the header, but I don’t know
awk that well. (If you do, let me know, and you’ll earn my eternal regular expression appreciation.)
However, the result in BitBar is nice and tidy, and choosing one of these bookmarks from the menu opens it in my default Web browser. When I switch browsers, all I have to do is change which one is the default to make my bookmarks work with the new one instead.
BitBar Can Be Anything You Want
I hope I’ve given you a good idea of some of the things you can do with BitBar, even if you’re not super comfortable with the Terminal or scripting. If you’ve ever thought, “I wish I could put that in my menu bar,” there is probably a way to do it with BitBar. You’re limited only by your imagination and what you or someone you know can do in a shell script.
If you want to download the BitBar plug-ins I’m using, creating, and editing, you can find them on my GitHub page.