There's been a lot of talk over the past week about wooden apps — and it hasn't been about skeuomorphic renderings of bookshelves. No, it's been in reference to Rene Ritchie's excellent article on the role of indie developers in today's App Stores — if you haven't read it, definitely take the few minutes to. The main hypothesis is that indie apps are the hand-carved wooden toys of our era: once the best quality available, but now a curiosity or artistic endeavor, not a moneymaker.

I, like Rene, hope that this isn't true, especially since many early iOS indies were major innovators. I don't see the iPhone in 2016 as being the pinnacle of mobile software interaction, with no room for improvement, and I can't imagine that Apple would disagree with me. The market has shifted, and will continue to do so, but as a consumer I just want a marketplace where I can put a certain portion of my budget towards art — the wooden apps — and another portion towards reliable practical goods. But is that the plastic?

If we are witnessing a sea change on par with an "Industrial Revolution of apps", who are the giants of the new industry? Yes, big players can put out free apps that are mere conduits to the "real products", their services. But unless they hold true monopoly sway (or even if they do), those apps need attention too. The Google Docs apps are the current punching bag for poor app maintenance, and the reaction is merited. Google apps are relied upon for serious work; while wood is no good for modern play, flimsy plastic is no good for modern work.

Where then, are the steel, aluminum, or even carbon fiber apps? Premium products featuring the latest technology, that those willing to go above and beyond the basics would readily seek out — you know, a bit like Apple's hardware. It's a question that Apple observers keep asking: can it possibly be the case that of hundreds of millions of Apple platform users, only a vanishingly small slice would pay for sleek software? It seems paradoxical, like the math should make for clear opportunities. Perhaps they're not opportunities for those only armed with a block of wood and a chisel. Hopefully Apple will give guidance and support for a new class of app artisans with new skills and new materials. It can only stand to strengthen their economy — the App Store economy is their creation after all — and improve the quality of the digital lives of their customers.

For the past three months I've been sleeping next to, on, and with Sense, a sleep-tracking product that is confusingly sometimes synonymous with its parent company, Hello. It has three components: a bedside bird's-nest ball, a "sleep pill" that attaches to your pillow, and an iOS app for setting alarms and tracking your sleep data.

I have a checkered history with iOS sleep tracking. I religiously used Sleep Cycle for years, until my iPhone 5s died a quiet and mysterious death. I think Sleep Cycle was the culprit, but that's a story for another day. I went with standard iOS alarms for several months before receiving Sense as a gift last Christmas.

To keep this review short but still provide some detail: Sense is a lousy sleep tracker and still a very good device. This lies in the fact that the bedside Sense hardware, which plugs into the wall and connects to Wi-Fi, does everything but the sleep tracking. It tracks temperature, humidity, air quality, light, and noise — and, best of all, you can view 24-hour or one-week graphs for all of these from anywhere in the world with the Sense iOS app.

Checking these numbers has become part of my daily routine. We typically run a humidifier in our bedroom in the cold, dry winter months; with warmer spring weather finally moving in, last night I checked the humidity and — with confidence, rather than guessing — could say "we don't need the humidifier tonight." Sense's data has also provided great peace of mind when traveling away from home. It acted as an independent check on whether our Hue lights were properly turning on and off while away, since its luminosity sensor sits directly beneath one on my bedside table.

On the other hand, Sense's sleep tracking has proven subpar. It takes one week to start providing any data on your sleep trends. I traveled away from home for a few days in my first week with Sense. After seven total nights I thought "OK, I must need seven consecutive days to start." But now, returning home from a week-long vacation, Sense has replaced months of my in-app data with its original message about establishing trends, rather than allowing a gap. And since I want Sense to monitor my home while I'm away, taking it on the road would be counterproductive. What's more, Sense sometimes misses an entire night's sleep, despite giving its friendly green glow at night and waking you in the morning. And when it does record, I often have to manually adjust the times it reports. Sleep time does connect to Health.app, but unfortunately all the more-valuable sensor data doesn't talk to HomeKit. I hope that the Sense team will make the firmware and software updates to fix and improve these issues in the future. Until then, I'll rest easy about my home, but still be in the dark about my sleep.

Unless you've been living under a rock, you know that Apple is committed to the security of its users' data, and lately has been vocal about it. The PR blitz has been all about the hardware and OS software that unlocks iPhones. With TouchID, unlocking my phone is something I do dozens of times per day without thought. Even when I have to fall back to a passcode — it gets cold outside in places other than California! — it's seamless. Most importantly, it's predictable; I only have to authenticate in response to my own action of turning on the phone's display.

I can't say the same for iCloud authentication. In theory, I should only have to enter my iCloud credentials at device setup, or when performing specific actions like confirming a purchase. Yet most of the time I'm presented with an iCloud password dialog, it's out of the blue, with no explanation: simply "Please enter the iCloud password for…" my Apple ID. It's frustrating, sure, but more than that it's troubling. Because I respond to that dialog differently than the vast majority of iCloud users.

I always click Cancel.

My iCloud credentials are the key to my digital life across several devices. I don't give them away without an explanation, just as I wouldn't give my Social Security number to someone who stopped me on the street randomly. But if the person behind the counter at the bank asked me for my SSN, even if I'd never seen them before in my life, I would give it over — it's all about context.

On iOS, iCloud authentication is done in a modal dialog, which you can be reasonably certain is generated by either the foreground app or the system itself. In this sense, they are slightly less mysterious than their counterparts in OS X. On the Mac, iCloud authentication dialogs pop up of their own accord, at seemingly random times, with no indication of the process they are tied to. And since all they consist of is a stock phrase, an iCloud icon, and a couple text fields, they are the equivalent of the stranger on the street. So I dismiss them, figuring that if it was important, I'll notice what broke. Then I can navigate to the appropriate app or preferences and meet the dialog on my own terms.

But that's not how most users think. "It needs it! It says so!" Even though OS X is a relatively safe platform, there are always bad actors, sometimes lurking in unexpected places. A healthy dose of skepticism is necessary, even if in a perfect world it wouldn't be. But Apple could make the world more perfect — because, let's be honest, 99.9% of those dialogs come from them. It would be a very Apple-like thing to do, giving their users confidence and keeping them safe.

Yesterday I talked about how decreased internet access influenced how I dealt with my iOS apps while on vacation. My trip also put me in a rare situation: being completely without internet for several hours. This is of course a first-world problem — I was only disconnected because I was in an airplane over the Pacific Ocean — but it made me realize that an airplane cabin is a place I ordinarily assume will have access to the wider world, for a price anyway.

Those few hours were the perfect (and only) opportunity I had to plan my following day in Seattle, where I was making a 36-hour stopover. But I didn't have any printed travel guides with me, and I couldn't do research en route. Fortunately, I remembered a little-used feature of PDFpen Pro, which would work in a pinch. PDFpen can scrape websites and generate PDFs from them. Literally as I packed up my suitcase, I navigated to a TripAdvisor page on "things to do in Seattle" and set the machine in motion.

The process is simple: select File > New > From HTML…, provide a single URL, and tweak some parameters such as how many levels of links to follow and a maximum size for the output. After initially setting it too low, I capped my file at 250 pages. In about 15 minutes, I had the world's ugliest Seattle tour book saved to my desktop, ready for access 30,000 feet above the Pacific. Formatting and images weren't perfect, and some irrelevant pages were accessed (PDFpen is smart enough to stay within the hierarchical structure of a site, but many large, modern sites have extremely flat structure, foiling it). Nonetheless, I could see a list of top attractions and even many of the reviews for them — just enough info to plan an afternoon of touristing.

Obscure features like this seem silly at times when you don't need them. Why should a PDF app do something so esoteric? Certainly, basic PDF applications shouldn't need to scrape the web, but PDFpen is a professional app whose design is based upon having everything you need in an omnibus package. If I needed to download a separate app in that moment of packing and planning, it would have been too much of a barrier, and all that data would have stayed on the ground.

I've just returned home from vacation to the land of snow and proper broadband. While I was away, I had a good think about the need for Wi-Fi connections on iOS devices, particularly the phone, and the fact that Wi-Fi is assumed to be the superior connection. (It rarely is in terms of speed, but it lacks the data caps of a 10✕-faster LTE connection.)

One major use case for an unmetered Wi-Fi connection is downloading app updates — a process which I do daily, and still manually, since I like reading apps' release notes to see whether any interesting or useful new features have been added. As the badge on the App Store icon counted up, I noticed that Facebook, one of the absolute worst release note citizens, turned 50! (What's new? "Every two weeks we push an update to the blah blah blah we're not telling you.") But even more noticeable than this round number milestone was how Facebook.ipa is tipping the scales, now at over 100 MB. Two more of my low-use apps that were updated that day, Airbnb and the United Airlines app, also are pushing up towards triple digits. They're getting dangerously obese, and it can't be good for their health or the iPhone's.

i hope Apple starts enforcing app thinning rules on iOS because these guys are getting app obese. pic.twitter.com/rTJXErkSS2

These apps need to go on a diet, stat, and fortunately Apple has provided developers the means to make it happen: App Thinning (how appropriately named!) and On-Demand Resources. Plenty of attention was given to these features at WWDC 2015, but it seems clear that many developers are simply not adopting them, and likely won't without an intervention. Apple has already drawn a clear line on tvOS, where apps — as downloaded from the store — can't exceed 200 MB and may have temporary resources purged. And the 200 MB restriction applies on a device with a base storage configuration twice that of the iPhone!

While I paid the geek tax and got a 64 GB phone, I still want to avoid bloat on my device. Facing excruciatingly long download times, I opted to delete a couple of apps that I almost never use — especially ones that can be replaced in a pinch with a mobile website. The average user may never face these choices if they have automatic updates turned on. And if they aren't constantly seeing reminders of the ballooning size of what appear to be simple apps, they will quickly and quietly run into the trap of running out of storage space. It's a cliché: an iPhone user completely out of space, unable to take photos of the vacation they're on right now. They'd certainly trade the app for the airline they last flew three vacations ago for that ability. Single-minded corporate developers may not care, but Apple, as overseer of the ecosystem, should help trim the fat, even if it's by forcing Facebook et al. to eat their vegetables.

Last time, I described how I move from app to app on my Mac, largely with Keyboard Maestro. Having universal hotkeys doesn't save me hours at a time — it's more like fractions of a second. Those shortcuts aren't designed to save raw time (and that doesn't have to be the goal, as John D. Cook has pointed out and Dr. Drang has corroborated). Yet there are still everyday tasks where I can make significant time savings, and the simple act of saving a new file is one of them.

My worldview of files and folders is seen through the lens of LaunchBar — the Finder plays second fiddle. When prompted with a save dialog box, I know where the new file should land, and I can probably get to that location in LaunchBar in ten keystrokes, tops. But LaunchBar can't talk directly to the save dialog.

Anything navigated to in LaunchBar can be dragged and dropped, and (since Apple mercifully rolled back their decision to change this behavior while still in beta) you can drag any representation of a folder to the save dialog to set it to that location. I used the drag-and-drop strategy for years, switching from keyboard to mouse to keyboard to accomplish the task. It was as efficient as I knew how, but it still felt imperfect.

When I began using Keyboard Maestro, its building blocks — simulating keystrokes, copying and pasting text, and hitting dialog buttons — made me realize that a file path could be brought into an open/save dialog with they keyboard alone. The necessary hidden feature is hitting ⇧⌘G within the dialog to pop up a "Go to…" sheet, just like in the Finder. With that knowledge in hand, it's simple to have Keyboard Maestro copy a path and paste it into that sheet. Then the workflow proceeds: 1) trigger save dialog 2) use LaunchBar to navigate to save location 3) invoke macro.

There are certainly other ways to perform this and similar tasks (the 20-year Default Folder users are probably screaming at me right now). For the couple years that I've used this macro, it has absolutely felt like the smoothest way for me to do the task and move on. It feels automatic — and if that's not what automation is for, what is?

The main use for my Mac is to move words around. (Picomac represents a new way of doing that for me, since I'm moving sound in addition to text!) As I manipulate text, I need to translate seamlessly from word to word, line to line, window to window, and app to app.

A major difference between the Mac and iOS is the full modularity of apps — just about anything can talk to anything else, and if they can't do it directly, a third party can step in easily to make the connection. My duct tape of connecting apps and data is Keyboard Maestro. It fulfills very specific roles, from the esoteric to the mundane. Among the more common tasks I use it for is app switching.

My app switching style has been a gradual evolution since the classic Mac. In OS 8, I relied heavily on the tear-off app switcher palette — that was the first step beyond navigating to the application via the Finder and double clicking it. On my first OS X machine, I started using LaunchBar, and I continue to use it to this day (a Mac without LaunchBar feels lobotomized to me, even though Spotlight has made significant strides recently). It too does much more than launch apps, but that core task is in its name. Press command-space, type a few letters (even some anachronistic ones work, like "ADB" for Contacts), and you're there.

It's possible to get even faster than LaunchBar for one's most commonly used apps by having global hotkeys. Some apps, like TweetBot, can establish these within their own settings, but that leaves many apps (including first-party ones) out of the workflow. Prego, Maestro.

I've heard of app-launching schemes that use number or function keys for the user's "top ten" apps, but this requires memorization. Instead I use a mnemonic system with letters. The trick was to find a combination of modifiers that would never be interfered with by in-app shortcuts. I selected control+option and I've never run into difficulties. From there the mnemonic choices are what works for you: some of my shortcuts are transparent — ⌃⌥T for TweetBot, ⌃⌥F for Finder — while others are less obvious — ⌃⌥R for Preview, because ⌃⌥P was taken for Pages.

Keyboard Maestro can not only switch to an app, but perform actions within it. So when I switch to Airmail (with ⌃⌥E for "email"), if there are windows open, it leaves them be; but if no windows are open, it goes to my inbox. For Chrome or Safari (⌃⌥B for browser), I get a new tab so long as none exist. This augments the app-switching behavior beyond what command-tab or even LaunchBar can provide. And for less commonly used apps, I still have LaunchBar and, yes, even the Finder to fall back on.

At work, I'm the grammar and vocabulary specialist. This means that I think a lot about the selection and position of words in the more cromulent uses of English. It also means that I'm fascinated by computer systems that try to do similarly, often with amusing results. Perhaps you have a twitter friend with an alter ego bot that mashes up their previous tweets in weird and wonderful ways. Or if you type with the default keyboard on an iOS device, you've certainly seen the QuickType bar, which since iOS 8 has provided suggestions for the current word you're typing — or the next word you might type, if you've just hit space.

The technology varies slightly, but all of these language guessers are built on the basic premise of a Markov chain, an algorithm that takes where it is and guesses what comes next. The simplest version works with bigrams, or pairs of words. English speakers have a sense for common collocations, or words that go together, and QuickType tries to approximate that. For example, typing "physical" gives two close collocates, "therapy" and "activity", plus "and" (a default option). As little as I use QuickType, since my thumbs are pretty adroit on the iPhone keyboard, I keep it on to watch these word pairs fly by. Sometimes they're disconcerting — like when "murder" is suggested for a split second for an unrelated word that begins with "m".

And sometimes they reveal all too much. As far as I've found, "teen" is the most loaded word in the QuickType lexicon, with suggestions "wolf", "mom", and "pregnancy". Yikes. But let's roll with it — in fact, when the feature was brand new, a lot of nonsense poetry generated by repeatedly choosing the first QuickType option was passed around the internet. These tend to get weird fast; the algorithm can only "look back" two words (maybe three? I'm not sure), and hitting common function words like "and" or "the" tends to reset things. It's hard to get a chain of 5 words or more all clearly conditioned on the previous.

So back to our "teen". "Wolf" comes first, and generates "pack". Next a function word, "of", which could send us astray. But "pack of" has a strong collocate: "cigarettes". It all makes sense in microcosm. But step back, and there's your next band name: Teen Wolf Pack of Cigarettes.

Rumors abound that Siri is coming to the Mac. The adverb "finally" is appropriate, as Apple has four major platforms and all but OS X are Siri-enabled. Pessimist commentators have already asked, "Would you really use it on your Mac?" Of course people will use Siri on their Macs; they'll also avoid it in the contexts where they stop short of using it on their iOS devices, like in a noisy coffee shop (ineffective) or in a quiet office or library (antisocial).

"But what will it do?" seems on the face of it to be an equally dumb question, but I think it is actually relevant. With the addition of the Mac, several distinct technologies are going to be presented to users under the umbrella of Siri. Each platform — iOS, watchOS, tvOS, Mac OS (macOS?) — will have specific features that others lack. I'd only ask my Apple TV to "show me the latest episode of Jessica Jones" and it would be fruitless to ask an iOS device to manipulate files or go to sleep. But with Siri as the core brand — and it is a core Apple brand, from a marketing standpoint — core features should be present on all platforms, and the cracks of fragmentation are already forming.

A concrete example: in January, I watched a lot of Australian Open tennis on my Apple TV with the WatchESPN app. Most years, the weather during the tournament varies considerably across two weeks, from pleasant to oppressively hot. Knowing the conditions is important to understanding how the players are behaving. Siri gave me the new ability to simply ask, "What's the weather in Melbourne?" and get a response in a bottom-third overlay, as the action proceded behind it — an excellent supplement to my viewing experience. As I continued watching, I saw players' serve speeds reported in kilometers per hour. As an American, that meant I'd have to do some mental math to get an estimate in miles per hour, and really I wanted the exact figure. Siri to the rescue again, right? Nope, Siri can't help me with that simple unit conversion on the TV. On my phone, absolutely! And on the Mac…who knows? (Although my bet would be yes, since Spotlight — which, look out, could be renamed Siri — does such computations as of Yosemite.)

I don't think this is a case of "Apple is spreading itself too thin". They are spreading a liberal layer of an important technology across all their products. Siri everywhere is just one more reason for an individual or household to go all-Apple. (And yes, a dedicated piece of Siri hardware, like the Amazon Echo, perhaps should fit into that vision as well.) But if users have to constantly second guess which Siri they're using at any time, that will be a deterrent. If it's a question that Apple hasn't thought about the answer to, Siri itself won't be able to tell you either.

My household is just finishing up our second week of Blue Apron, the cook-it-yourself meal delivery service. This is not about their iOS app, or their website. It is about Apple. Bear with me.

A home-cooked meal is generally something private. Even now that we're used to the internet being flooded with Instagram photos of food, they usually depict the final product, not the process. Half of Blue Apron's product is the process (you get to keep the recipes, after all) and the other half is the food that arrives on your doorstep. The plated meal isn't what they're selling; it's the outcome of your experience with their product.

The target demographic of Blue Apron certainly must skew tech-savvy — I wonder how many customers they have who aren't Amazon Prime subscribers too — so it ought to be no surprise that many members of the tech community are purchasing, receiving, cooking, and eating the same meals. Not in lockstep, since the plans are weekly, but in close enough proximity that people like Serenity Caldwell and John Siracusa have noticed.

@settern I just had that last night. Blue Apron makes for weird, widespread dinner confluences.

A discussion has sprung up around a shared cultural experience — in this case, chicken and biscuits. Less than a year ago, at WWDC 2015, Apple predicted that not just its close adherents but even its casual users would also be chatting about the faux serendipity of simultaneous experience. They were betting that the water cooler chat (both digital and analog) would revolve around what went in our ears, not our mouths, with the release of Beats 1. Apple was going to shape the conversation and the culture.

We are looking for the most exciting music and people that love it in all corners of the globe, broadcasting to 100 countries.

That shared experience just got so much bigger.

Worldwide. Always on.

LA. New York City. London.

Beats 1 was indeed a hot topic of conversation in the days following its launch, just as promised. But for me, I found that the times I most wanted to listen (in the afternoons at work) had the least compelling content for my musical tastes. The novelty waned, and I haven't touched the service in months. And I don't feel like I'm abdicating my responsibility to pop culture; nobody has recommended me music from Beats 1, or even that I give Beats 1 another fair try.

Back on the WWDC stage, after the promise of the shared experience, Eddy Cue cut the Beats 1 feed and plowed along through the script of his lackluster presentation.

That's really awesome.

That's not how I feel about Beats 1 anymore; the adjective I'd use is "forgotten".

But the biscuits and gravy? Now those are awesome.