January 30, 2019 at 11:46 PM by Dr. Drang
It’s a month after the end of a fiscal quarter and time for another round of graphs showing Apple’s performance. As always, you can get a full meal of graphs from Six Colors and MacStories. Here, you’ll be served an amuse-bouche.
The big difference this quarter is that Apple’s report no longer contains unit sales for its devices. As it’s unit sales that I’ve been graphing for the past few years, I had to either give up or figure out a new set of graphs to produce. I chose the latter, but I’m not sure if I’ll keep doing this every quarter. Generally speaking, I don’t find the money Apple makes as interesting as the devices it has out in circulation. It’s the devices that change the world, not Apple’s bottom line. On the other hand, revenue is certainly related to device sales, and moving from unit sales to revenue allows me to talk about services, which are becoming a larger part of the Apple story.
Whatever I decide to do in the future, here’s how I looked at the data for Apple’s holiday quarter. The first thing to know is that Apple breaks down its revenue into five product categories:
- Wearables, Home, and Accessories (which I will call Other, as Apple used to)
The first three are our old friends, the fourth is a lumping together of all the other hardware Apple sells—Watches, AirPods, HomePods, and so on—and the fourth is the category Tim Cook flogs every chance he gets.
It doesn’t take much analysis to realize that none of the latter four categories comes anywhere close to the iPhone as a revenue generator.1 The iPhone accounts for about 60% of Apple’s income, so I decided the best way to start the presentation of the quarterly results was to aggregate the latter four categories and display that alongside the iPhone.
There’s a lot in here, so let’s go through it piece by piece.
First, Apple’s fiscal year starts at the end of September of the previous calendar year, and I think it’s easier—especially if you want to compare Apple’s performance with the release of products or the introduction of new services—to deal with dates in the regular calendar we all use. So I plot things by calendar year.
Second, I got into this Apple graphing business because I found it difficult to interpret graphs of raw quarterly data. Most of Apple’s sales are so strongly seasonal that it’s hard to see trends unless the data are smoothed. I chose a simple moving average smoother; the smoothed data are calculated by adding the current quarter’s revenue and those of the previous three quarters and dividing that sum by four. The thick solid lines shown in the graph are these moving averages.
Next, the raw revenue figures are plotted as points. In the graph, these are smaller and somewhat muted in color so they don’t detract from the moving averages. I’ve plotted them as dots at the middle of the quarter to which they apply and have connected the dots of the most recent quarter in previous years with a light dashed line. This gives a sense of the year-over-year change.
Finally, Apple just made a change to the way it assigns revenue to the five categories, and it’s published an explanation that also recalculates the revenue in those categories for the four previous quarters.2 Here’s what Apple says:
Starting in 2019, in connection with the adoption of the new revenue accounting standard, Apple will classify the amortization of the deferred value of Maps, Siri and free iCloud services, which are bundled in the sales price of iPhone, iPad, Mac and certain other products, in Services net sales. Historically, Apple classified the amortization of these amounts in Product net sales consistent with its management reporting framework. As a result, the 2018 net sales information has been reclassified to conform to the 2019 presentation.
In a nutshell, by reclassifying some portion of the sale price of its devices as going toward Maps, Siri, and iCloud, Apple has boosted its services revenue by about $640 million per quarter. As a consequence, it has reduced the quarterly revenues for the iPhone ($450 million), the Mac ($70 million), the iPad ($110 million), and the other devices ($10 million).
Thus, comparing revenue figures before the 2017 holiday quarter to figures after that quarter is not an apt3 comparison. The Six Colors crew have done their best to account for this change by estimating how Apple would have presented its revenue figures using the new system for all of the previous quarters, not just the most recent year’s. I decided to avoid the perils of estimation by using shading to partition the graph into two sections, one for the old accounting method and one for the new. The reader is alerted to the change and can make their own judgments about comparisons across the section boundary.
On the scale of the graph above, the adjustment from the old method to the new would be barely noticeable. $450 million is less than one-quarter of the distance between the minor tick marks on the vertical axis, or about the diameter of one of the raw revenue dots. No big deal.
What is a big deal is the downward kink in iPhone revenue caused by the most recent quarter. It’s not just that Apple missed the estimate it made three months ago; it’s not just that iPhone revenue is down from the year-ago holiday quarter; it’s that iPhone revenue is down from the holiday quarter of two years ago. Unsurprisingly, Apple has been focusing on its overall revenue, which although down, is buoyed by the continuing upward trend of the non-iPhone revenue.
And speaking of non-iPhone revenue, let’s split that out into its four components. This makes for a nice graph, because they are all of comparable scale.
On this scale, the $640 million that Apple has robbed from Peter to pay Paul is not insignificant. The Services revenue in the unshaded area would be noticeably below what I’ve plotted if we were still using Apple’s old accounting method. Still, Services is rightly considered Apple’s biggest growth category, even though it is growing at a slower rate than it was a few quarters ago.
Down further on the graph, we see that the iPad is about to be overtaken by Other, an ignominious position for what used to be the top dog of the non-iPhones. In fact, if we were to look at the raw revenue figures instead of the moving averages, we’d see that the iPad has come in below Other for the past two quarters.
But we can’t look at the raw figures because I didn’t plot them. Why not? Because doing so makes a mess.
It’s not impossible to interpret this graph, but who’d want to? Plotting two aspects of four data sets that intersect one another is just too much at once. If we want to look at the raw data of these, it’s best to plot no more than two on the same graph.
You certainly can’t explain Apple in two graphs, but I think these do a good job of presenting an overview of the company’s progressions and regressions from the product side. One unaddressed problem with them is that they don’t account for inflation—something I didn’t have to worry about when I was plotting unit sales. Apple doesn’t account for inflation either, of course, but that doesn’t mean I shouldn’t. If I’m going to keep doing this, I’ll have to decide on an inflation index and a basis year.
The same was true with unit sales, which is why I typically broke out the Mac and iPad sales into their own graphs. ↩
Big thanks to Jason Snell for pointing me to this document. I could see in the consolidated financial statement that the previous year’s revenue figures had changed from the values reported last year, but I didn’t understand the changes until I saw the recalculations. ↩
I will not use the phrase “apples to apples.” Even I have some dignity. ↩
January 25, 2019 at 10:26 AM by Dr. Drang
At the end of my last post, I said that after giving up on trying to use a Luna Display to view local Mac files on my iPad, I hit upon a way to use FileBrowser instead. It wasn’t a particularly profound discovery, but it’s made my setup at work run much more smoothly.
To summarize the last post, I often find myself in the lab at work wanting to look at photos or drawings stored on the iMac in my office. I bought a Luna Display, thinking it would be a good way to do this, but I found running Mac programs on my iPad a frustrating experience. The Mac way of doing things doesn’t work well without a mouse/trackpad and keyboard, and the iPad way of doing things isn’t supported by Mac software.
Enter FileBrowser. Or I should say “Re-enter FileBrowser.” I tried to use FileBrowser a couple of years ago for a similar task—I wanted access to photos on my iMac while in our conference room so I could display them on a TV via my iPad—but didn’t like the long delays and occasional disconnections that kept occurring. So FileBrowser sat on my iPad unused for a long time.
Then about a year ago, I read Federico Viticci’s article about potential replacements for Transmit, the file transfer app. Panic had just announced that they were halting development of the iOS version of Transmit because of low sales, and Transmit users (like me) would have to prepare for a time when an update to iOS would cause Transmit to stop working.1 To my surprise, FileBrowser was Federico’s top choice.
So I found the folder where I had tucked FileBrowser and gave it another chance, this time connecting via SFTP to a couple of servers, including the one that runs this blog. And it worked… fine. It wasn’t nearly as easy to set up or as cleanly designed or as pleasant to use as Transmit, but it was serviceable. The disconnections and delays I’d seen earlier when connected to my iMac over a local network didn’t seem to happen when connected to a remote server. Good to know, I thought, and went back to using Transmit.
It was only after my disappointment with working through a Luna Display that I thought again about FileBrowser. Maybe I should give it another chance.
So I did, but this time I used a different network connection type. When you create a new connection in FileBrowser, you’re presented with a list of connection types to choose from:
When I first tried FileBrowser, I had selected the Computer/Network Drive, which led to another set of choices:
From here I chose Mac, and FileBrowser then searched the local network for Macs. I selected my office iMac, entered my user name and password, and then had a connection that I could turn on and off with a tap. A connection that turned out to be frustratingly unreliable.
This time, after my success with SFTP connections to outside servers, I decided to choose the FTP option from the second list. That led me to this setup screen:
As I had learned when making the server connections in FileBrowser last year, this configuration system is not much different from starting an SFTP connection at the command line. Fortunately, I have some experience at the command line, so I knew the address field had to include a colon and a port number2 after the IP number and then the path to my home directory after that.
The user name and password fields are straightforward unless you use SSH keys to connect. If that’s the case, the password field should be the passphrase for your SSH key. The file with your private key must then be saved to FileBrowser’s private file area with a special name of the form
So for this connection (which is fake), the filename is
If you’re a Transmit user, you’re probably looking at this with shock and dismay. Panic makes all of this so much easier. FileBrowser’s way of setting up an SFTP connection is very much like editing a Unix configuration file. Inevitably, you will make some small, hard-to-find mistake the first couple of times you try it. Luckily, once you have a connection configured properly, you never have to do it again.
With the connection to my local iMac made, scrolling through a folder of photos is not unlike scrolling through the Photos app.
You can use pinching to make the thumbnails bigger or smaller. Tapping on an individual photo brings it up in full-screen mode.
Pinching also works here to zoom in on a particular area.
Although these examples are JPEG files, all of this works with PDFs, PNGs, Numbers spreadsheets, Word documents, etc. Whatever can be displayed in iOS’s QuickLook will be viewable in FileBrowser.
The obvious question is why is FileBrowser working so well for me now when it didn’t before? That’s easy: I don’t know. But I can think of two possibilities.
- Two years of development made FileBrowser better since I first used it.
- The SFTP connection I’m using now is simply more reliable than the SMB connection I was using before. SMB is a Microsoft protocol that isn’t always reliable even when connecting a Mac to a Windows computer.
These are not mutually exclusive.
I suppose I should try again with the connection I used two years ago to see if it still gives me problems. Don’t hold your breath. When I’m working in the lab, I need to concentrate on the hardware on the table in front of me, not the software in the air around me.
So far, this hasn’t happened, and I’m still happily using Transmit. ↩
The standard port for an SSH connection (which is what SFTP runs over) is 22, but many people, including me, configure their SSH server to use a different port number in hopes of cutting down slightly on the number of outside attacks. This is no substitute for real security, but it doesn’t hurt. ↩
January 20, 2019 at 9:57 AM by Dr. Drang
A couple of weeks ago, I bought a Luna Display. It worked fine, but it didn’t feel comfortable doing what I’d bought it for, and I returned it after a few days. I learned in those few days that I don’t like running Mac software on an iPad, especially an iPad without a hardware keyboard.
If you know about Squarespace web hosting, Away luggage, and Casper mattresses, you’re familiar with the Luna Display. It’s been a ubiquitous sponsor of Apple-centric podcasts for months, so you know it’s a little plug that pops into the USB-C or Mini DisplayPort on your Mac and allows you to use your iPad as a sort of controllable monitor.
If you want to supplement what you’ve heard on podcasts and what you can read on the Luna site, T.J. Luoma has an excellent writeup on his Luna Display configuration, including some practical tips he’s picked up as he’s gained more experience with it.
When I bought my Luna, I had a very particular use in mind, and it’s that use that informed my ultimate decision that the Luna wasn’t for me. I have an iMac in my office at work on which all my project-related files reside. Each project gets a folder (in Dropbox so I can also get them easily on my home iMac) and a bunch of subfolders for drawings, plans, specifications, and photographs of the machinery or building that the project is about. While I do most of my work in my office, inspections and testing of equipment are done in my company’s laboratory space, some 75–100 feet from my office. What I wanted from the Luna display was a quick and convenient way to refer to drawings and (especially) photographs from my iPad while I was looking at parts back in the lab.
With the photos on Dropbox, I could access them from the lab through either the Dropbox or Files apps, but latency was often a problem, as the iPad had to download each photo from the cloud before it could be displayed. I figured a local network solution, like the Luna Display, would solve the latency problem.
And it did. Photos viewed through the Luna software popped up on the iPad screen quickly because they were coming through a fast internal network instead of through a sometimes sluggish outside connection. Overall, I’d say the Luna Display worked exactly as advertised. But…
Because my iPad was acting as a Mac display, I was viewing the photos through Mac software, and none of the software I tried—while perfectly fine when run directly on the Mac itself—felt right when run indirectly on the iPad.
When I’m working on my Mac and I need to flip through a bunch of photos, I typically open up the folder in which the photos are stored and do one of two things:
- Use Icon View in a full-screen Finder window with a large icon size so I can scroll through the photos in a Finder window. When I need to see more detail in a particular photo, I invoke QuickLook to get a bigger view of it.
- Use a combination of List View and QuickLook, so I can see each image at a reasonable size while navigating from one to another with the ↑ and ↓ keys.
This system doesn’t work well on the iPad because its efficiency depends on keyboard shortcuts—the space bar to go in and out of QuickLook and the arrow keys to flip from photo to photo—and I don’t want to bring a keyboard with me into the lab. The value of the iPad in this situation is its compactness, the ability to set it up in a small space that doesn’t intrude on the inspection or test. You might think a keyboard wouldn’t take up enough space to get in the way, but it does.
There are other software options for viewing photos. Xee was the photo viewer I used to use a lot in the pre-QuickLook days. It’s a nice piece of software, and using it again during my Luna Display tryout has made me think I should go back to it (its ability to quickly show EXIF data very useful). But like the Finder/QuickLook system described above, it isn’t efficient without a keyboard and wasn’t a good fit with the Luna.
I also tried out Phiewer, which can give you both an overview of the photos in a folder like Icon View and a detailed view of an individual image like QuickLook. It has onscreen buttons for navigation—which is a waste of screen space for a Mac app, but a godsend if you’re running that Mac app on a keyboardless iPad—but it doesn’t allow zooming via pinching, and that just seems wrong when working on an iPad.
In fact, everything felt wrong when I was running Mac apps through my iPad. Buttons were too small, even when I tried tapping on them with the Pencil. Resizing windows was a chore; dragging felt off. I confess I didn’t spend time examining why the behavior just didn’t feel right, but it didn’t.
I use both my Macs and my iPad a lot, and while I don’t have any trouble switching between the two, I found it very annoying to be forced into using Mac-like actions on an iPad. This was surprising to me, as I have nearly 35 years of Mac use under my belt and only 2½ years of iPad use.1 But my immediate sense—a sense that didn’t change over the 4–5 days I used the Luna—was one of unease.
Would I have felt this unease had I been using the Luna Display in a more keyboard-centric manner? Maybe not. And I can see where people who are iPad-first users would find the Luna very convenient if they only occasionally need to be hands-on with their Mac mini server. But for my use, the neither-fish-nor-fowl behavior that the Luna forced me into was very inconvenient. It made me have to think about what I was doing instead of just doing it, and that got in the way of my real work.
The good thing that came out of my Luna Display tryout was that it made me think harder about a software-only solution to my problem. I finally learned of a way to use FileBrowser on my local network that was pleasant instead of teeth-grittingly frustrating, which was my previous FileBrowser experience. I’ll describe that in a later post.
The 11 years of iPhone are probably a confounding factor in this comparison. ↩
January 9, 2019 at 8:17 AM by Dr. Drang
If you saw Jason Snell’s recent article on reviving an old podcast feed and skimmed past it because you don’t expect to ever need to revive an old podcast feed, you missed some excellent generally applicable advice within the specifics.
The real purpose of Jason’s article is to show you how to use simple software tools we all know—a text editor and a spreadsheet—to accomplish what would normally thought of as a “programming” task. Listeners of The Talk Show may remember an episode in which Jason and John Gruber discussed how both of them have done this many many times over the years.12
Although I do often write short programs for text munging, I typically resort to that only if the problem requires more than just large-scale text editing or if I expect to be repeating the process several times. And even then, I usually start out by playing around in BBEdit3 to see what searches, replacements, and rearrangements need to be done. It’s a convenient environment for getting immediate feedback on each transformation step.
(And if you expect to do a series of text transformations often and really don’t want to get into writing scripts in Perl or Python or Ruby or whatever, BBEdit’s Text Factories allow you to string together any number of individual munging steps.)
I will say, though, that one bit of “programming” you’ll find really helpful—and which Jason uses in his podcast feed example—is the building of regular expressions for searching and replacing. Simply put, regular expressions allow you to find patterns of text instead of specific text. For example, if you need to find all the US zip codes in a long chunk of text, you can’t go searching for a specific zip code, like “60606.” You have to look for a pattern: five digits, optionally followed by a hyphen and four more digits.
Regular expressions allow you to build these patterns by using placeholders for generic character types (like digits), repetitions, and options. Unfortunately, for historical reasons, these placeholders consist of normal ASCII character strings like
?. This has the unfortunate effect of terrifying newcomers when they see something like
described as a simple regex, something I have probably done dozens of times.
Even worse, people who are thinking they should start using regular expressions often hear about this great book on the topic and have a natural reaction when they see it: A 500+ page book to learn how to search for text? No thanks.
This is too bad, because while Friedl’s book is great, it’s called Mastering Regular Expressions for a reason, and that reason is not because it’s a tutorial. My recommendation for a tutorial is the one I learned from over 20 years ago: the “Searching with Grep” chapter4 in the BBEdit User Manual. I believe it was largely written by a young guy named John Gruber.
The nice thing about regular expression syntax is that it can be learned a little bit at a time. You can be productive right away knowing only a few regex constructs. Even people who have been using regexes for ages tend to use just a dozen or so patterns, bringing out the more obscure ones only when they have a particularly tricky problem to solve. A good way to pick up new regex knowledge in small portions is to follow John D. Cook’s @RegexTip Twitter feed.
You may have heard that there are regular expression “flavors,” different regex syntaxes used by different programs, and been put off by the potential for confusion. Don’t be. There are different flavors, but that won’t have any practical effect on your learning until you’re an expert. Every program you run into nowadays uses the “Perl-Compatible Regular Expression,” or PCRE, syntax. Only very old programs use different flavors, and by the time you find yourself using them—if ever—you will be well-equipped to handle the variation.
And before anyone on Twitter can do it, I’ll bring out the obligatory Jamie Zawinski bon mot:
Some people, when confronted with a problem, think “I know, I’ll use regular expressions.” Now they have two problems.
Don’t be led astray by this, either. Only a person who’s used regexes a lot, and successfully, would make this kind of joke.
I would link you to that episode, but the episode descriptions in the TTS archives aren’t detailed enough for me to find it. I know it isn’t the most recent episode, even though they talk about BBEdit in it, because I haven’t listened to that one yet. ↩
But in looking at the links for the most recent episode, I see that they do talk about the Studio Neat and Fintie carrying cases for the Magic Keyboard, so I need to move it up in my overflowing podcast queue. ↩
Whatever text editor you’re comfortable with will do. Ten years ago, I would have been using TextMate. ↩
“Grep” is the name of a Unix command that uses regular expressions for searching through files. I have always believed—but never confimed—that Rich Siegel used the term “grep” instead of “regular expression” because the shorter word fit better in BBEdit’s Find dialog box. ↩