In 2019.

That summer, I began work to add sleep data analysis to RECaf, a feature I had wanted since I conceived of the app. The timing seemed right. If Apple were going to be adding sleep tracking to Apple Watch as a first-party feature, I wanted to be right there, ready to take advantage of that sleep data as soon as Apple started its marketing.

Scientifically, it’s pretty well established that caffeine has some sort of impact on sleep for many people. (Not everyone, of course. I seem to be immune.) But most people I know can’t have coffee at night and then get a great night’s sleep. Taking the sleep data people record on their watches or phones and comparing it to the caffeine data being recorded in RECaf seemed so obvious.

This is at the heart of why we track these stats. We want to know how we as individuals respond to different stimuli. Maybe caffeine has no impact on your sleep, even though it does for many other people. Why not figure that out for yourself?

Shockingly, no other caffeine tracking apps seem to be doing this analysis. And very few sleep trackers do, either. This made it a perfect differentiating feature for RECaf.

But it was a hefty challenge. So much to learn. Sleep data is stored in a somewhat unintuitive way in HealthKit. And every sleep tracker seems to record data a bit differently. And then there was the challenge of how to display the data. How to compare it to your caffeine data. What were the most interesting conclusions I could draw? What would present the most value to my customers?

In the end, I settled on scatter charts (Shout out to Mike Selsky, not only for pointing out the appropriateness of scatter charts, but for writing the Swift code for generating the trend lines for me.) And I focused on a few basic data points. How much caffeine did you have vs. how much sleep did you get? How late was your last caffeine intake vs. how much sleep did you get? And finally, how long did it take you to fall asleep vs. how much caffeine you had, and how much time had passed between your last caffeine intake and going to bed?

The feature was close to being wrapped up and ready to go a year ago. It still had bugs that needed to be worked out. But I was on track to ship at least sometime in the fall of 2019.

Then Apple announced a new Series 5 Apple Watch—without a single mention of sleep tracking.

Still, there were plenty of third-party sleep trackers out there. Plenty of people interested, I’m sure, in how much caffeine was impacting their sleep. But the golden marketing opportunity seemed to be lost. I got super busy with other things, and before you knew it, those last few bugs never got fixed, and nothing ever shipped.

Fast forward to this June. WWDC. Apple finally announces a native sleep tracking app in the upcoming watchOS 7. Okay. Time to dust off the old sleep tracking code and work up a new release for this fall.

And so here we are. Almost a year to the weekend after I “finished” the feature. Sleep analysis is finally here in RECaf.

I could have waited for Apple’s announcement of this year’s new Watch series. I assume it will have some sort of hardware enhancement to make sleep tracking even better. But for the sake of all those folks who won’t or can’t upgrade their watches this year, I wanted to get the feature into a watchOS 6-compatible version, so they could enjoy it, too. (I plan to move RECaf to iOS 14 and watchOS 7 very shorty after iOS 14 ships.)

There are some other good new features in the latest RECaf version as well. Reordering of favorites. Logging hydration into HealthKit along with the caffeine entries. (Coffee and Tea are mostly water, after all.)

There are also a lot of under-the-hood enhancements in this version. A complete refactoring of the caffeine source model. Finally properly utilizing Apple’s Measurement API for conversions. More reliable Siri Shortcuts. Improved performance and reliability of statistical data presentation. And on and on. Combine. SwiftUI. All the buzzwords.

It’s a big release.

So check out RECaf today. The update is now available on the App Store.

via David Smith

I mostly agree with David in this piece on Intentional Subscriptions. I have a few thoughts, however.

First and foremost, I love the idea of a system-owned screen for confirmation of subscriptions. Apple has made the guidelines for the subscription presentation page so muddy that almost no developer I know is ever confident that the requirements are being met by their apps. Let Apple design this page exactly how they want it, and let every app get the exact same screen. More consistency for customers, leading to fewer surprises. No more fearing I’m going to get rejected. Apple saves money on App Review. It’s a win all around.

Let us upload Terms and Conditions text and a description of each subscription item directly into AppStoreConnect. Then, Apple can pull everything it needs right off its own servers. All a dev would need to do is ask to pop up the SubscriptionConfirmationViewController, or whatever they call it. Similar to asking for a review prompt. When dismissed, we get a completion handler with confirmation that they subscribed and an ID for the item to which they subscribed, or a notice that the customer cancelled or that the transaction failed. Devs could even update their text descriptions this way without having to upload a new app binary. They’d have to get the new metadata approved, of course. Which would cut down on fraud as well.

Please, please, Apple. Do this.

Next, notifications. I agree that a notification makes more sense than an email on renewal of subscriptions. However, I get hundreds of notifications every week. And I’m pretty careful about turning off notifications for many apps. Ideally, these renewal notifications would be on by default, but they should only fire at the end of trial and at the first renewal after. And I should be able to opt out of them on an app-by-app basis. I don’t need to be reminded every month for every one of my apps separately. (There’s a fine line between not surprising a customer and treating them like a child who can’t be responsible for their own finances.)

Curtis Herbert said it better on Twitter (thread):

So @_DavidSmith got me thinking - while I agree with the idea of a more comprehensive pop-up for subscription confirmations, I think a few well-timed push notifications would help a _lot_ more. Because people don't read. Especially walls of text.

— Curtis Herbert (@parrots) May 28, 2019

As far as being able to cancel your subscription right from the notification itself is concerned, I think this sounds better on paper than it would be in practice. People don’t read their notifications carefully. I see a ton of people accidentally unsubscribing to apps, then getting super confused when their apps no longer work. This would lead to increased support load for everyone. Tapping on the notification should take you directly to the subscriptions page on the App Store, however. (See Curtis’ thread linked above.) Then you could unsubscribe, intentionally, with another tap or two.

As far as auto-renew happening a the end of the trial, I think a lot of developers don’t realize how common this is in most markets. Yes, it’s different from the shareware days of yesteryear, but auto-converting trials are a practice with which most people are very familiar. Magazines have been doing this for decades, for instance. And it makes sense. For every customer who we might be saving from an accidental payment by disabling auto-conversion, we’re annoying ten others who already indicated they want to keep using the app and don’t want to verify yet again.

As long as customers are getting notifications before the trial ends, and they get a 24-hour grace period to cancel (another good idea from Smith) I don’t see any need for Apple to remove the convenience of auto-renewal after the trial ends.

Especially for apps like my own RECaf that almost never get launched (you can interact with it primarily through Siri), having to manage subscription renewal in the background could get hairy quickly. I could see tons of customer support issues stemming from this.

Any developer who doesn’t want to have a trial auto-subscribe at the end has the freedom to do that right now. Just don’t use Apple’s trial system. Track how long the customer is using the app yourself, then just present the subscription without a trial at the appropriate time.

Lastly, and I’ve written about this before, I think Apple should require apps to provide a link to the subscription management page inside our apps. We have the ability to do that (I do it inside RECaf), but few developers actually do.

And that subscription management page also absolutely should be linked at the top level in Settings.app with the title “Manage Subscriptions.” I don’t know any non-developers who know where that page is buried inside the App Store and iTunes settings.

RECaf 1.6

For a while now, I’ve noticed RECaf users had a very different approach than I intended of logging an item from earlier in the day, or from the day before.

The frequents list on the front panel of RECaf is great for one-tap access to your most frequent sources. But logging that way always records the current time and date. If you want to customize the date to say, this morning, my intention was for people to go through the custom logging process. (Push down the frequent and favorites panels, choose your category, drink, amount, and then set the time before logging.)

Instead, what I observed many people doing was simply logging the item with the frequent button. Then, they would slide over to the history screen, tap into the newly created log entry, and edit the date from there. (I’m fairly certain this takes longer, but nevertheless, it seems many believe this is the only way to change the date—after they’ve logged.)

For a long time, I’ve had a quicker remedy than both of these methods planned, and with version 1.6 it is finally ready.^[1]

Enter our old friend, 3D Touch.

Now, if you force press on a frequent button (or tap and hold on it on devices without 3D Touch), you can bring up a quick actions menu to change the date (or the amount) very quickly.^[2]

I’m sure I’ll still see people in the wild logging, then editing the entry just to change the date. But hopefully this will help some folks log just a bit faster.

I’m hoping to add similar functionality to the favorites menu soon as well. Along with many other improvements in the works.

My driving principal while designing RECaf was to make the app “thumb-able.” That is, I wanted to be able to do as many tasks as possible with the phone in one hand, gesturing only with my thumb.

This is getting harder with every new iPhone generation.

Years ago, Jeff Hawkins, creator of the original Palm Pilot and then CEO of Handspring, commented on the one-hand-ability of the Treo line of smart phones. He was getting asked frequently why Handspring had adopted plastic RIM-style keyboards on its phones, rather than relying on the Graffiti handwriting recognition he had pioneered for Palm devices.

“I think the most important thing here is that on a phone, you have to have a keyboard. You really want to have one-handed operation, and that requires a keyboard....”^[1]

This was a few years before Apple released an on-screen touch keyboard that anyone would consider usable, of course. The point is, in Hawkins’ mind, any task you needed two hands to do on a mobile phone was a failure, at least to some degree. The task may be easier or better to do with two hands, but it needs to be possible with one hand. I believe this is still largely true.

We’re busy people, and our hands are often busy throughout the day. When I’m walking around the city, I’m often lucky to have one hand free to pull out my phone and get something done. The last thing I want is to have to free up the other hand just to do the simplest of tasks.

Unfortunately, phone manufacturers and software developers have all but thrown the one-hand principle out the window in recent years. The allure of larger and larger screens has decreased the thumb-reachable percentage of the screen significantly. And yet, much of our software, particularly on iOS, has failed to accommodate.^[2]

When the first iPhone was released, with its puny 3.5-inch screen, I could easily reach every corner with either thumb. On an iPhone XS Max, with its gargantuan 6.5-inch screen, I’m lucky to reach even 60% of the total screen area without a second hand. And yet, Navigation bars, with their all-important Cancel and Done buttons, and many other controls are still located at the top of the screen, way out of thumb’s reach.^[3]

And it’s not just the top of the screen. The larger your screen area, the more difficult it becomes to carefully balance the device and reach the bottom of the screen as well. Simply moving navigation to the bottom of iOS would not adequately address this issue.

With this in mind, I approached RECaf’s design as if my thumb were the only option for at least the most common actions^[4]. If it was something I needed to do more than occasionally, and I couldn’t do it with my thumb without some sort of awkward phone juggling, I declared the design a failure and started over.

Throughout the process, I studied other apps that had tackled this issue—some built-in from Apple, others from third parties—and I adapted what I considered to be the best ideas from each.

The Tab Bar

I’m not a big user of Snapchat (I’m not in the correct demographic) but when a few developers I trust showed me Snapchat’s swipe-able tabbed interface, I knew a variation of that would be perfect for RECaf.

The Tab Bar lives at the bottom of the screen, so technically, it is reachable by the thumb. But I find it so much easier to simply swipe between tabs vs reaching down to the bottom of the screen and tapping that frankly I would love it if Apple stole this idea for the standard Tab Bar.

Since this is not a standard implementation, of course, it took a bit of work to get the animations and the gestures working as well as I liked. But the end result is so fluid and simple. While a more complex tabbed interface with more tabs and deeper navigation structures might make this impractical, in RECaf’s case, with only three tabs, it’s perfect. With the easiest flick of your thumb, you can get from one major area of the app to another. You can still tap on the icons on the bottom toolbar as well, of course, if you are unaware of the swipe gesture.

Drag-able Panes

Over time, Apple has been adding drag-able panes to Maps and other built-in apps, such as Stocks; a variation of the same pattern also exists in the current Music app. And many third-party apps have copied and enhanced this pattern themselves, most notably ride-sharing apps like Lyft. The idea is to put information in a panel, or pane, that can be dragged up or down to reveal more information/controls on two different z-depths. This way, you get almost two screens worth of UI on a single screen, and you can move the information you don’t want out of the way with a simple thumb movement up or down as needed. Put a scroll view inside these panes, and you can get just about any active controls you need under your thumb with relative ease.

In RECaf-this became the perfect way to show both a listing of historical statistics about your caffeine habits and a listing of your entire caffeine logging history on the same screen. Just tap, swipe, or drag the All Log Entries pane up, and the history is concealed behind the long list of entires. Drag, swipe, or tap it back down, and the stats become visible again.

A more complex variation appears on the Log Entry screen, where you can move two different panes (frequents and favorites) to show three different methods of logging on a single screen (frequents, favorites, or custom). Rather than putting these three modes behind a segmented control, having to tap all the way on the top of the navigation bar to switch modes, you can simply move your thumb up or down to reveal the UI you need. Because the panes are drag-able from any visible part of the pane, it doesn’t matter how precise you are about the dragging, either. Wherever your thumb happens to land on the pane, you can move it up or down. You can even move both panes at once, so you’re never more than one drag away from he UI you need.

The podcast app Castro uses a similar approach with its now-playing screen. You can swipe down from just about anywhere on the now-playing screen to go back to the main interface.

Implementing this in RECaf took quite a bit of UIPanGestureRecognizer gymnastics (and ample use of container views) to get it working smoothly, but at the end of the day, I ended up with an extremely “thumb-able” UI. Given how often Apple is using a similar pattern to avoid putting UI tools in navigation bars in Maps and other built-in apps, I wouldn’t be surprised at all to see drag-able panes become a much more common part of iOS in the future. That would make me very happy. I’d love to have an official API for creating such interfaces, rather than the custom implementations many of us have had to create in the meantime.

Viewable Content vs Interactive Regions

Clearly, we can’t put our entire interfaces under our thumbs. We have these gorgeous giant screens; we want to use every pixel. But if you reserve the areas that are out of reach of your thumb for visual information that isn’t interactive, you can free up the thumb-reachable region for your interactive elements.^[5]

In RECaf, I wanted to take advantage of the larger screens of some iOS devices by putting the pertinent information, whenever possible, above my thumb. On the source detail page, for instance, the name, icon, and other information about the source is listed just below the navigation bar, while the interactive buttons for favoriting amounts and adding Siri Shortcuts are placed in the thumb zone.^[6]

By all means, we should make use of every pixel of our screens. We just have to be sure the parts with which we need to interact are not out of reach.

Conclusion

Large screens on phones are not going away anytime soon. At the same time, our thumbs aren’t going to magically start getting longer. That shrinking percentage of reachable screen real-estate needs to become the focus of interactivity, while the outer regions of the screen are devoted mainly to information display. The more designers and developers consider this, the better time we will all have with our apps, regardless of our screen-size preferences. I hope Apple, too, is planning on leading us in this direction with future versions of iOS.

One common argument I hear from the Apple community against subscriptions is that most customers don’t know how to manage their subscription settings. It’s difficult, they say, to explain in a customer support interaction how a customer can cancel or alter a subscription. And because customers are confused about how to cancel or manage subscriptions, many customers may be afraid to start an auto-renewing subscription in the first place.

These are fair points. I definitely agree Apple could do a better job of exposing subscription management settings in iTunes. Oddly, the subscription management page can be found (with some effort) in the App Store app, in the iTunes Store app, and also in the Settings app, which adds to the confusion.^[1] As you can reach the same subscription page from multiple places, there’s no single definitive set of instructions we all use.

No wonder customers and Apple pundits get confused.

If Apple were to place the link to subscription management somewhere more obvious in the Settings app, perhaps under the iTunes & App Store section—or better yet, right in the top-line Apple ID, iCloud, iTunes & App Store—that would be a big improvement. Adding an easier-to-find link in the iTunes Store and App Store apps would also be welcome.

Fortunately, developers can help make finding subscription settings easier, too.

Just in case some folks are unaware, and for those who have argued that developers should be able to provide a way to manage subscription settings from within their apps, I wanted to point out that developers, can, at least, provide a direct link to their customers’ subscription management settings. Your customers can manage their subscription to your app from your app, as long as you provide them with this link.^[2]

The more places this link is made available, the faster we can overcome any customer fears of not being able to find subscription settings.

I did a quick check, and just about all the apps to which I currently subscribe (including Castro, Weather Up, GifWrapped, Ulysses, Carrot Weather, Drafts—just to name a few) provide a quick link within their own settings pages that takes you to the iTunes subscription management page. So good devs, at least, seem to be doing the right thing. (Surprise, surprise.) Unless you are actively trying to discourage your customers from finding a way to unsubscribe from your app (Don’t be that dev.) there’s no excuse not to make this link an easy tap within your own application.^[3]

When I approached placing this link in RECaf, I decided I’d make it a top-line item in the More tab. Since I had a More tab for miscellaneous items, and subscription status is not technically an app setting, I figured it made sense to put subscription status right there at the top level. You could argue that more customers will expect it to be inside app settings, since that’s where a lot of developers put this link.

Feel free to find a place where it makes the most sense for your app.

Tap on the subscription status cell, and RECaf will take you to the appropriate place in the iTunes Store app to manage your subscriptions.

To make things easy for these sorts of links, I like to create a quick extension on UIApplication. That way, I avoid repeating a lot of UIApplication.shared.open() code if I need to link from more than one place in the app.

extension UIApplication {
    class func openAppSettings() {
        guard let url = URL(string: self.openSettingsURLString) else { return }
        self.shared.open(url, options: [:], completionHandler: nil)
    }
    
    class func openSubscriptionManagement() {
        guard let url = URL(string: "itms://apps.apple.com/account/subscriptions") else { return }
        self.shared.open(url, options: [:], completionHandler: nil)
    }
}

With this extension in place, wherever I want to link to the subscription page, I just call UIApplication.openSubscriptionManagement() and the app does the right thing.^[4]

Note, my URL uses itms://, which will pop customers directly to the iTunes Store app, bypassing the need to first bounce to Safari.^[5] It’s also not app-specific. That exact generic link will go to the correct place in iTunes Store from any app.

There may be a better way to code a quick link to the subscription management page. Feel free to let me know. But the point is, there’s no reason your customers should need to contact you to find this link, if you put it somewhere obvious enough. And even if they do contact you, you should be able to point them to a button within your own app, rather than having to walk them through several steps in Settings, App Store, or iTunes Store.

The more apps provide this link to the management page, the faster the argument that subscriptions are too hard to manage becomes moot.

And Apple, if you’re listening, take a look at my suggestions above for making it easier to find subscription management elsewhere in the system. Also, adding a static variable on UIApplication, or wherever you feel it would be appropriate, (something like UIApplication.openSubscriptionManagementSettingsURLString, perhaps?) would go a long way to making it even easier for devs to provide a link without having to worry about the URL changing in the future.

I was all set to go on a weeklong trip out of the country just one day after the new iPads became available. It was as if Apple knew I was leaving town and rushed it out on a Wednesday instead of the usual Friday.

Now that I’m back, some initial thoughts, in no particular order:

• I went with the 11-inch model. As I’ve said in the past, this is purely a personal decision. There is no right answer to which iPad size is best. I’ve owned literally every size iPad screen Apple has ever offered. For me, last year’s 10.5-inch (now stretched to 11) is the one. As a bonus, it still fits inside my Waterfield Designs AirCaddy travel case. The 12.9, despite being smaller this year thanks to shrunken bezels, is still a bit large to fit into my current carrying case lineup. But I totally get why others want the larger screen. I still think Apple will make an even bigger iPad eventually.
• This is the best-looking iPad to date. I probably should have gone with silver this time around, since it still has the black bezel. But I ordered the Space Gray out of habit. No regrets. But now I’m craving a matching Space Gray Magic Keyboard.
• I went with 256 GB. I will eventually want more storage, but for now, I can load up quite a bit of media while traveling without filling the device. I don’t sync music to it, since I always have my iPhone handy for music listening. Once I start Photoshopping next year I may wish I had more storage, but I’ll cross that bridge with my next iPad.
• Once again I went with cellular. I can’t recommend this enough. T-mobile offers me 5 GB of data that I can use over a span of 6 months for only $10. No commitment. No recurring fees. Use it until I run out. Buy more as needed. If someone offered me this on my Watch, I’d actually pay for data on my Watch. Most of the time, I’m on WiFi. For those few times I’m not, though, having cellular kicks the ever living crap out of trying to tether, draining my phone battery, and so on.
• I love the new Pencil. It’s smaller. The magnet is clever and way more convenient for charging. I never lost the cap on my old Pencil, but I certainly came close a few times. Glad to see it gone. I will still likely use the Pencil less often than I should.^[1]
• I wish Apple made a Smart Cover for this new iPad. Instead they went with a two-sided folio. Not for me.
• I never get the Smart Keyboard with my iPads. I hate the feel of those keys about as much as many developers seem to hate the new generation of MacBook Pro keyboards. To each their own.
• The squared-off sides: Oh man, do I love the way the sides of this new iPad feel. Some people call it “retro” to the iPhone 4 or 5. Fine. As far as I’m concerned, squared off sides are better. The tapering gives the illusion of a thinner device, but once you’ve reached peak thinness, there are many advantages to a squared off edge. (Pencil charging, for one.) I can’t wait until the iPhones go back to squared off edges.^[2] I think this is the future, not the past.
• Face ID: I was right to be scared of the camera being on the “short” portrait side of the device. Whenever I’m holding the iPad in Landscape (just about 100% of the time) my thumb is covering the camera. I tend to hold the device in my left hand and use my right to “swipe up” to unlock. But because I’ve always wanted the home button on that right side as well, I tend to hold the device with the camera on the left side. (Apple clearly figures this as the “normal” landscape orientation as well, since they set the pencil charging magnet along the top edge when you hold it this way. That means despite taking a hand off the device to unlock, it’s always the “wrong” hand for me. Thus, I get the dreaded “Camera covered” message about 70% of the time when I am unlocking.^[3] As I wrote earlier, this could be completely avoided if the camera were on one of the longer landscape sides of the device. But who knows? Maybe there’s some engineering reason that couldn’t be done. Suffice it to say, this is my only true complaint about this new iPad. It’s annoying as hell, in fact. But I will learn to swipe to unlock with my left hand, hold the device with the camera on the right (which will put my Pencil under the device), or just reposition my thumbs somehow. I’ll get over it.
• The home indicator. My friend Alec Pulianas pointed this out, and he’s absolutely right: There’s really no need for a permanent home indicator on this iPad. The behavior has not changed for swiping up since iOS 11 last year. People have had a year to “figure out” how to go home with the iPhone X. Sure, turn the indicator on for the first few days for new customers, but it should disappear after that. The graphic only gets in the way for most apps. I hope Apple is considering this UI affordance a temporary thing.
• It’s taking longer than it should for some apps to be updated to support the new screen aspect ratio. I’m not talking about indie apps made by developers who are working their butts off. I’m talking about Netflix (Took almost a week.) HBO. (Still not updated as of this writing.) Apps with large teams who, let’s be honest, had more than a year to prepare for the removal of the home button. Watching letter boxed video inside a pillar boxed app is far from ideal.
• I didn’t think much of the switch to USB-C at first, but the benefits are slowly sinking in. I’m charging my nearly dead iPhone as I write this with my iPad. Sounds silly, but in a pinch, it’s turning out to be a very handy feature. I doubt I’ll be connecting to an external screen anytime soon. But I’m glad that’s now available to video editors, etc. Eventually, I have to think the Files app will get external drive support, which will be awesome. More accessories will work with either Mac or iPad. I think this is one of those changes that will take some time to sort out but eventually will be a “how did we ever live without that?” type of thing. Not sure if it makes sense for iPhone, but I’d be happy to see that happen as well. I wouldn’t be surprised or disappointed either way.
• Being able to travel with just my laptop charger and give it double duty for charging iPad as well is quite nice. I will probably never need a second charger for this iPad.
• Speed: I’ve never thought any iPad I’ve owned is slow. Then again, why not push the state of the art forward? I’m happy these iPads are getting faster, support more storage and RAM, and are generally kicking the ass of laptops the world over. This is what Apple does. I know some have suggested the RAM is overkill, but when I think of apps like Final Cut Pro X, Logic, and other “pro” apps people complain about not existing for iPad, the one thing those apps need that current iPads don’t have yet is tons of RAM. (Have you ever loaded a set of virtual instruments into Main Stage?) I say bring on more and more speed and RAM until it becomes physically impossible to add more. Here’s the thing: an iPad is in no way a “lesser” device from a hardware standpoint. Which means it doesn’t need to be any lesser from a software standpoint, either.
• Speaking of software: Yes, iOS needs more iPad-only features. Apple is still paying for the mistake of encouraging “Universal” apps for iPad back in the day. I wrote about all that years ago, so I won’t go into it again. I do think starting simple with iPhone’s OS and getting more complex over time was the right move. It’s taking longer than any of us would like, but I’m optimistic about iOS 13 next June. Will they fork iOS into an iPadOS eventually? Maybe. Not sure it’s necessary, though. Just keep adding iPad specific features where appropriate, and share with iPhone when that makes sense. I don’t think maintaining yet another full operating system is going to be a net gain.
• More on software: Apps. Pro apps. Whatever that means. They exist. More will exist. All I can say is when they come, be willing to pay for them. And for my friends making those apps: be willing to charge for them. I’ll be using Photoshop on my iPad a year from now. I can’t imagine XD won’t follow soon after. At that point, I’ll be able to do almost all my design work on iPad. If you have design apps now that are Mac only and you don’t have an iOS road map, you’re as good as dead to me in a few years.^[4] How long before I can say the same for most of my development work?^[5] And once apps like Photoshop appear, look for the gaps in the surrounding ecosystem. I’d love to see Adobe bring something akin to its plugin architecture to iPad. That may take some cooperation from Apple, but it could spark an entirely new market for third parties on iOS. The future is looking bright.
• And that brings me to my final point. iPad has been my favorite Apple device for a long time now. This new edition only strengthens my feeling. I am newly inspired to write apps for this machine. I want to use it more than I already do. It doesn’t have to replace my laptop. It needs to expand my current concept of how and where I use computing devices. And that’s been steadily happening since the first iPad was released in 2010.

Congrats to the entire team who worked on these new iPads. They are truly remarkable.

Okay: Crazy designer ideas time. Bear with me. This is not a prediction of what may or may not happen at tomorrow’s Apple event. Just a thought that’s been rattling in my brain for the past few months.

Have an iPad handy? Great. If not, use your imagination.

Pick up the iPad and hold it as you normally would in landscape orientation. Where are your hands? If you’re anything like me, one of your thumbs is roughly on top of the home button, and the other one is just about covering the selfie camera. Hands are basically in the middle of the device, in other words.

Now, hold the iPad in portrait mode. Where are your hands? Chances are, your hands are towards the bottom of the device, not the middle. Your thumbs are not covering the center of either long side of the device.

Is it me, or is this an argument for Apple putting the Face ID sensor array on one of the longer, landscape sides of the device?

Now, there may be some perfectly logistical, engineering reason why the selfie cam/sensor array needs to stay on the short side of the device. This is why I’m not making any predictions here. But if it isn’t physically difficult or impossible to put the array on the longer side, I think Apple would and should put it there. Otherwise, forget whether or not Face ID can work in landscape or portrait. We may have to take one hand off the device every time we need to authenticate when we are holding in landscape, anyway. Which would not be ideal.

Ever since the 10.5-inch iPad Pro was released, with it’s slightly longer aspect ratio, I’ve used my iPad in portrait mode approximately 0% of the time. It’s just awkward to hold that iPad in portrait, because of its elongated geometry. Positioning the sensor array at the “top” of that orientation makes no sense from a design standpoint, as it optimizes for an edge case, rather than what I’m guessing is “normal” use for most people. (Again, assuming that engineering challenges don’t make this a moot argument.)

On the other hand, if the sensor array were on one of the long edges of the device, Face ID would work just fine in either orientation for most people, as your hands would never be covering the array regardless of how you hold it.

Just a thought. I’m sure I’ll be proven wrong tomorrow. But I couldn’t let this thought go without at least documenting it.

RECaf version 1.1 is making its way to the App Store today. In addition to some minor bug fixes, this version adds some cool new Siri Shortcuts that make it easy to quickly check on your day’s logging. You can customize the phrase to invoke these to anything you like, of course. They will also work on your HomePod if you have one, which is really cool.

I've found these extra Shortcuts very handy for checking in on my current intake, and when deciding if I really should have that one more Cold Brew in the late afternoon.

You can set up these Shortcuts by going to the History Tab and tapping on the microphone at the top of the screen.

Today Counts

Siri will give you a count of how many items and milligrams of caffeine you’ve logged thus far today.

Elapsed Time

Siri will let you know how long it’s been since your last log entry. If it’s been over ten hours, it’ll also let you know that you are likely no longer under the influence of any caffeine in your system.

Siri will let you know how today compares with the rolling 30-day average that you’ve been logging. If you’ve only started logging recently, of course, your 30-day average is going to be quite low for a while. Once you have a month’s worth of data under your belt, you’ll get a good picture of how today stacks up against your recent days.

RECaf is available now on the App Store. A 14-day free trial is available if you want to try it out.

In case you didn’t see it last week: RECaf is available for download on the App Store. If you are interested in tracking your caffeine intake for health purposes (or just out of curiosity) I encourage you to give it a try. A free 14-day trial is available, which gives you access to every feature of RECaf, so you can see for yourself if it suits your needs.

Why track your caffeine intake? Caffeine is a drug. While studies have debunked earlier conclusions regarding heart problems, high blood pressure, and other issues associated with caffeine, and some studies have even suggested moderate caffeine intake can be good for you, it’s still important to monitor any chemical substance you put into your body. Knowledge is power.

While you are giving RECaf a spin, I also highly encourage you to try logging with Siri Shortcuts in RECaf. Everyone I’ve spoken to who liked the app initially, ended up loving it once they started logging with Siri. Shortcuts really are transformative. I’m starting to set them up in a number of apps on my personal phone, and it’s changing the way I interact with my phone regularly.

Finally, I want to take a moment to thank some folks. First and foremost, my good friend Curtis Herbert (of Slopes fame) who spent more time than he would have liked helping me out with the server-side validation / in-app purchase portions of RECaf. I would not have been able to launch this app without his help, and I definitely would not have been able to triage all the crazy errors I was getting on my initial launch day, either. Speaking of which, some folks at Apple (some of whom I will never know) were also instrumental in helping me track down some internal issues as well. And the review team has been extremely supportive. It’s easy to take swipes at big companies when you are frustrated, but the people I have interacted with at Apple have always been top-notch.

To all my beta testers, the folks at MacStories who have helped me get the word out (read Federico Vittici’s Review of iOS 12—it’s awesome), and the early-adopter customers who helped me fix some critical issues in the initial days the app was available—thank you for your patience and support.

You can call yourself an indie dev all you like, but you can’t do everything alone. If you know anyone who would be interested in RECaf, I always appreciate you helping me spread the word. And if you have any feedback on the app itself, there’s a link in the More section to drop me a line.

When I came up with the original concept of RECaf, shortcuts hadn’t been announced yet. I knew the key to any data-logging app is making the act of adding new entries as simple as possible, so I focused all my efforts on reducing log friction. If it takes too much work, you won't get into the habit of logging daily.

I put a ton of effort into designing the simplest logging process possible. RECaf only needs three pieces of information to make a log entry: a source, an amount, and a date. Since most of the time you want to log an item you are consuming right now, RECaf can usually assume the date is now. If you tend to have the same sources in the same amounts regularly (we are creatures of habit, after all) RECaf can notice those combinations and make them more readily available.

Surfacing your top three most frequent sources automatically and making them one-tap buttons, then, became an easy addition. Adding a favorites pane for any extra items you sometimes log helps to capture most everything else. Even custom logging infrequent, non-favorite items I managed to get down to just a few taps on a single screen. Choose a category, source, amount, adjust the date if necessary, and you’re good to go. No scrolling through long lists just to find what you want.

3D Touch shortcuts on the home screen icon, the today widget, and a watch app give you those most frequent items in even more places.

But then Apple announced shortcuts this June, and things got way more exciting. People could just invoke Siri and say “Log Cappuccino.” And that was it. I knew I had to get this into my app immediately.

Using shortcuts with RECaf all summer has been a game changer for me. It’s supplanted most of the need to ever have to log the “old fashioned way.” Shortcuts have finally given me a reason to actually do something with Siri beyond setting a timer or adding reminders. I’m going to be looking to set up shortcuts in as many apps as possible this fall.

But there is one issue with shortcuts—they need to be set up by the customer in order to work. And in order for that to happen, the customer needs to know shortcuts exist in the first place.

And so we run into our old nemesis: discoverability. This is going to be the central challenge for designers working to add shortcuts to apps. Doing this poorly will cost you dearly. Your customers will overlook one of the best features to come to iOS in years. And that would be a real shame.

Counting on Apple alone to make people shortcut-aware would be a mistake. Remember iMessage apps? How many of those caught on with your non-tech friends?

Counting on Siri Suggestions would also be unwise. What are the chances your app will stand out in a suggestions list with 50 other apps competing for attention?

So how did I approach discoverability of shortcuts in RECaf?

Let me start by saying that I do not like to bombard my customers with tons of pop-ups and annoying messages trying to teach them about the app. Especially on first launch. We’ve all downloaded lots of apps at this point. The first launch sequence often becomes a battle of how many screens so I have to swipe or tap though to get to the darn app, already?

If you make the first launch more than a few screens, you’re lucky if the customer remembers anything you tried to teach them. If there are tons of permissions pop-ups involved, chances are they will tap through everything without reading.

I like to stick to what’s absolutely necessary on that first launch. For RECaf, that meant getting HealthKit access permission (because RECaf relies heavily on HealthKit) and (optionally) getting a free trial started. This way the customer can get the full experience of using the app right out of the gate with minimal interruption. You will need to decide what is most important for your particular app.

RECaf does not ask for notification permissions on first launch. (I save that for after your first log.) No prompting for ratings. (How can they rate an app they haven’t used yet? That comes after several days of use.) No tour of the entire interface. (They can do that on their own.) No signing up for any newsletters, etc.

I want my customers to get in and start logging.

So where do I add shortcut prompting?

Well, first I wanted to be sure that setting up shortcuts was easy, and that it could be discovered without any prompting. Not everyone will find shortcuts in RECaf on their own, but it should be possible at least, right?

After a couple of iterations, I ended up with buttons placed on every amount listed on the source detail page, with a microphone icon^[1], to indicate the customer would need to record a voice phrase. Maybe this person has never heard of shortcuts. Maybe they’re just curious and want to know what that button does. They tap the microphone, and Apple’s standard shortcut creation screen comes up and does the rest for me.

Once you’ve already recorded a shortcut for that amount, the phrase you recorded appears, and the icon is filled in. This makes it easy to see which amounts already have shortcuts, and it reminds you what you need to say to invoke that shortcut. Tap on the filled icon and you can edit or delete the shortcut. I show the phrases on the favorites screen as well.

So that takes care of making it possible to create a shortcut at any time for any source. But I’ll be lucky if more than a few people go hunting into the source detail screen on their own.

So how to balance making people aware of shortcuts without bombarding them?

I came up with a nice compromise. Here’s the scenario. You log a particular source/amount combination. (Say a 12 fl oz Café Cubano, as an example.) RECaf checks to see that all of the following are true:

• You have logged this exact combination of source and amount at least five times
• You have not already created a shortcut for this source/amount combo
• This combo is one of the first three where a shortcut was suggested, and then you created the shortcut.
• You haven’t yet indicated that you’d like to stop being reminded about shortcuts

If all are true, then after the confirmation screen indicating your log was successful, this screen will pop up:

From here, you can read about shortcuts and their usefulness, get a tip on how to create a shortcut for any source in the future, and of course tap a button to create the shortcut right there if you like. I also give you a way to either cancel just this particular shortcut’s creation (maybe you are in a place where you can’t talk right now), or inform RECaf that you’d prefer not to get these reminders in the future. That way, if you want to record the shortcut later, it will remind you again next time. But if you hate the whole idea of shortcuts, you can ignore them forever.

Note my thinking here:

• At least five times. I’m not going to push you into shortcuts on day one or for everything you log. It’ll likely be days before you see your first shortcut prompt. That’s okay. The app is still great without shortcuts. It’s just better with them.
• The app is making note of your behavior and predicting your future intentions. The simplest form of machine learning, to be sure. But machine learning all the same. (I’ll have more to say about the more complex machine learning surrounding reminder notifications in a later post.)
• The prompt happens in response to an action. It doesn’t just show up on launch, when you’re likely trying to quickly log something. It waits until you’ve done your logging and then prompts you with a helpful tip to make logging that exact item even faster next time.
• After you set up three of these shortcuts, RECaf stops. By then, you get the idea behind shortcuts, and you’ve been shown more than once how to set them up on your own. Maybe you didn’t read that screen carefully, but chances are, you’ll get curious enough to go looking elsewhere in the app at that point.

I know this isn’t perfect. If you always log from your watch, for instance, you’ll never get prompted. If you drink something different every day, it’ll be quite a while before any shortcuts get suggested. Some people will just cancel the screen every time without reading it or just tap the button and get confused. At the end of the day, it’s still a pop-up screen, which is an interruption and a potentially unpleasant surprise if you have no interest in Siri or voice-activated computing. But like I said, it’s a compromise. If RECaf bugs you once, you tell it to never bug you again, and it obeys, I’m okay with that.

The alternative is the majority of my customers missing out on what I think is the killer feature of the app.

I’m very curious to see how other designers and developers approach this problem. It’s challenging designing these solutions in a vacuum, before you get the benefit of seeing other approaches. Perhaps once I get a glimpse of some other apps with shortcuts, I’ll revisit and develop it further.

I’m also curious to see how shortcuts are adopted by my customers. With any luck, the majority will be logging with their voices a few times a day, then carrying on, only launching the app occasionally to see their stats.

RECaf will be available shortly on the App Store. To find out more, visit the web site or sign up on the mailing list.

A new version of Fin is now available from the App Store. It includes the usual set of bug fixes and enhancements, as well as a few new features centered around the end of timers.

When a timer runs out in Fin, an animation sequence begins, with the screen fading from black to red, as the main timer shows 00:00. In addition, a small indicator at the bottom of the screen begins counting up, to indicate how much time has passed since the timer ran out.

Some have requested that this “overtime” indicator be larger, so that presenters can easily see exactly how long they have gone over their allotted time. Instead of showing the 00:00 time in the center of the screen, they would like the overtime to show there. My fear is that while presenting on a stage, a quick glance at Fin where anything other than 00:00 is showing in the center might give the presenter the false impression that time has not yet run out. The overtime, in other words, could be confused with time remaining.

I’ve always used the overtime counter during rehearsal, just as a measure of how much time I’ll need to cut from my presentation before the next rehearsal. I’ve never recommended using it as a way to distract the performer during the performance.

Nevertheless, since this has been a persistent request for some time now, I finally gave in and decided to make it an option. While I was at it, I also included the option of choosing between twelve different colors to use as an alternate to the standard red for the end timer animation. Since red is used to indicate your last warning color, it may be helpful to use something different for the end sequence. You can even choose to have Fin select one of the twelve colors at random each time a timer runs out. In case you can’t decide.

Combined with the customizable ending message text that appears, and three different styles of end animation (no fading, the classic slow fade, and the fast blinking hyper fade), you now have far more ways to customize the degree to which Fin insists to your performer that they really should wrap it up. If you are using the remote feature, of course, you can always type full-screen messages to your performers as well.

Unfortunately, your iPad still can’t break out the cane or play a gong for you.

Fin version 4.7 is now available for download.

Way back when I shipped Fin 1.0, it wasn’t very easy to set the timer to anything except a small set of presets. The presets weren’t even editable.^[1]

The only way to set a timer for anything beyond the presets was to swipe up or down to add or subtract one minute at a time. You could change the increments in settings—to make it two minutes, or five minutes, or whatever, per swipe—but this gesture was always meant for quick adjustments, not as the primary way to set the time.

To make matters worse, because I wasn’t very skilled at code at that point, I did what many developers do: I punted by using UISwipeGestureRecognizer rather than implementing a UIPanGestureRecognizer.^[2]

Later, when I added an animation to bounce the time label up or down with the swipe, and I still left it as a swipe gesture, that really didn’t sit well with me.

A swipe is almost never a simple yes or no. You want your interface to react to the swipe as it’s happening, which usually means moving something on the screen in a similar direction to your finger movement. A swipe gesture recognizer is incapable of reacting in real time.

In this case, I wanted the time label to move in concert with the motion of your finger. But all I could do with a swipe gesture was wait until it recognized the swipe and then move the label. If you swiped fast enough and with conviction, it almost felt okay. But any combination of changing speed or direction immediately gave it away as an inauthentic experience. I wanted a slower swipe to result in a slower animation. I wanted the gesture to be cancellable in mid swipe if you changed your mind.

But I had other fish to fry, so I let it slide.

Along the way, I added left and right swipe recognizers to toggle between the slower 5-second increment for the circle gesture and the fast 1 minute increment. This was a great shortcut for me personally, but it wasn’t very discoverable and probably was getting triggered accidentally more often than I wanted to admit.

Between swiping in all four directions, a long press to bring up the circle, and one and two-finger tap gestures, it was getting to be a pretty complicated gesture landscape on that main screen. Something had to give. The more time passed, the more features I added to that screen, the more daunting the prospect of getting a pan gesture to behave exactly the way I wanted became.

Fast forward to a few years later, and I decided enough was enough. The next update was going to put an end to the madness.

So I replaced all four swipe gestures with a single pan gesture that recognizes the difference between horizontal and vertical swiping, tracks with your finger, and allows you to cancel the gesture mid-swipe if you don’t swipe past a certain threshold.

For vertical pans, once you hit the threshold, time gets added or subtracted. As a bonus, if you keep holding, it will keep adding or subtracting every half second until you let go. So you can add or subtract several minutes with one gesture.

The circle gesture is probably still the way to go for bigger changes to the timer, but for adding or subtracting one or two minutes at a time, panning works great. The gestures work whether the timer is running or not, of course.

While I was at it, I added some icons to the horizontal panning to show the customer what the gesture is about to do.^[3] Now it’s clearer that this gesture will change the circle speed. In prior versions, you’d just get a message that the speed had changed after the fact.

As a final bit of fine-tuning, I added haptic feedback on compatible devices. And that really tied the room together. So much so that I added haptics to the circle gesture as well.^[4] There’s just something so visceral about that little click under your finger when a gesture gets recognized.

Anyway, now that one of the longest-standing embarrassing reminders of my early-developer years is gone, I’ll have to find something else that irks me about Fin to fix next.

The point is, most of the time you’re thinking about using UISwipeGestureRecognizer, what you really want is a pan. 9 times out of 10, it’ll feel way better to the touch.

That’s not to say I should have done all this work the right way years ago, by the way. Sometimes punting on the tough stuff and getting the product out the door is absolutely the right thing to do. It’s just nice to be able to go back and smooth over some of those rough edges in an app—even if you haven’t gotten around to it for years.

Rumor has it Apple is cooking up a new framework that helps unify the development of macOS and iOS apps. At least, that’s the part of the rumor that makes the most sense, anyway.^[1]

Code-named, Marzipan, this new framework would help developers who make either iOS apps or Mac apps to make both using the same basic toolset. Obvious differences between the platforms would necessitate some variation, of course (clicks vs taps, and all that), but the underlying APIs for creating either would be largely the same. And thus, perhaps you could even create (and sell) a single app binary that is capable of running on either platform, if you choose.

Rather than a straight port of iOS’s UIKit to the Mac, as some have requested from Apple for years, Marzipan would more likely be a new framework that replaces both AppKit and UIKit in favor of something more modern and clean.

However they go about it, the million-dollar question is: Would this be a good thing?

Let me start with the short version: Yes. Of course this would be a good thing. There are downsides, to be sure. But to me, the good outweighs the bad here.

Let me start with the downsides.

This will lead to a lot of crappy iOS ports on the Mac

No doubt about it. Thousands of previously iOS-only apps will end up on the Mac barely altered with bad UI on day one. Count on it. Remember how many terrible watchOS apps debuted minutes after watchOS was made available? Apps that had no place on the Watch, that tried to do way too much on the Watch, that didn’t understand the utility of the Watch, and so on? That will absolutely happen on the Mac, too. It will still take time and effort to make a good Mac app, and many developers will not bother. They will try to make a quick buck.

But who cares? The last time I checked, there is already a ton of crap available on the Mac. A few thousand more bad apps will be a blip on the radar.

Here’s the thing: People who care about good software will find the good stuff. People who care to make good software will make the good stuff. There aren’t many people in either group. And there never will be.

Developers who care about making great software keep wanting the majority of people to give a shit. They don’t. Find your little niche and set your business model accordingly.

This will lead to a repeat of iPhone and iPad Universal apps

When Apple made universal storyboards available on iOS, the promise was it would now be easier to make apps that run great on both iPad and iPhone. Looking at the disparity between the number of iPhone apps and iPad apps available, Apple decided getting more apps on iPad was a priority.

The result was a ton of new apps that now run natively on iPad but are little more than “blown up” iPhone apps. They don’t use the extra power and screen real-estate available on iPad in any fundamental way.

There are some apps, however, built with universal storyboards that take full advantage of iPad. The problem here isn’t the tool, but rather the people using the tool. The same will be true for Marzipan apps.

In the hands of lesser developers, any tool will be used to create crap. That’s no reason for the rest of us to keep using clunky tools.

This will negatively impact some businesses

Some developers make iOS and Mac versions of the same app and sell them separately for a one-time upfront price. If Apple makes a “universal” buy once-run-on-any-Apple-device binary possible, the customer expectation is likely to shift, and people will simply expect to have to pay only once.^[2]

I don’t have a lot to say to these folks, except you are correct. If you currently sell a paid-up-front app on iOS and Mac, there will be some customer expectation and pressure to make your app universal. And more than likely that will be coupled with the expectation of lower prices, too. There’s not a whole lot you can do about this, except:

• Don’t go universal: Fantastical has pulled this off for years on iOS, refusing to make the app a single purchase on iPad and iPhone. They get complaints, I’m sure. But they aren’t exactly going out of business over it. And given there are a lot of iOS users who don’t use the Mac, there may be at least a slightly stronger argument for not having to pay extra for a Mac app they will never use. I suspect more developers will go the non-universal route this time around. And given this is not a simple matter of screen size, as it was on the iPad, a port of an iOS app to the Mac, even using Marzipan, is going to take quite a bit of time. It will be a while, in other words, before the pressure from other developers gets extreme to start selling your existing app as universal. So you have time.
• Get out of the paid-up-front business. Apps like Ulysses have shifted to a subscription model for a reason. They see the future coming. Yes, I know subscriptions aren’t for every app. But two years ago, a word processor would have been on most people’s list of can’t possibly go subscription apps.^[3]

Undoubtedly, businesses will fold after Marzipan. And that’s a shame. But many of those businesses are likely going to fail, anyway. Others will adapt. The world has largely moved on from paid-up-front software. We’re long past the point where Apple (or anyone else, for that matter) is going to hold back on anything because it might hurt paid-up-front app makers. Sugar-coating that would be cruel to those who have been and continue to be affected. Better to be honest than spread false hope.

Eventually, UIKit and AppKit will end up like Carbon

It stands to reason that after Marzipan gets released into the wild, both UIKit and AppKit will be on “borrowed time.” Just as Cocoa replaced Carbon, eventually Apple will very likely want all apps to be written using Marzipan.

This is not such a huge deal for small utility apps. But consider an app like Photoshop. Or BBEdit. Those are massive codebases. For any company that’s had a Mac app since the early days of OS X, Marzipan is going to mean a lot of work rewriting bits that are currently working just fine. And that sucks.

Even larger iOS apps, like Procreate or Ulysses, would not be a small conversion job.

Now, very likely, there would be a generous grace period, just as there was with Carbon, where AppKit and UIKit apps could continue to run and be updated. Marzipan will very likely be optional for at least a while. (I’m thinking right up until the entire Mac hardware line goes ARM.) And in the case of macOS, I’m sure AppKit apps would continue to run for a long time, even past the point where Apple stops accepting them in the Mac App Store.

But eventually, Apple will start dropping hints at WWDC: “We believe Marzipan (or whatever the official name will be) is the way to create the best user experiences moving forward.” At which time you’ll know you have a couple of years to get your legacy code converted.

There’s no way around this being a pain in the ass for some developers. In fact, if there’s one group of people who have the biggest reason to gripe about Marzipan, it’s the folks with the largest legacy codebases. But technology marches on. It would be hard to argue that Apple should have allowed Carbon to go on this long.

Another thing to consider: The retirement of Carbon led to new opportunities for a lot of developers. Legacy companies spent years rewriting their Carbon-based apps, which gave small indies the opportunity to start fresh in Cocoa, move faster, and create legitimate competition. ^[4]

With any luck, Apple will make the translation over to Marzipan as painless as possible. Who knows? Apple isn’t as powerless in this transaction as it was in the Carbon days. So they could tell us to go pound sand, if they wanted to. But I suspect they will want to make this transition smooth.

So that’s the bad news. What do we get in return?

At least a few good iOS devs who have never tried macOS development will likely give it a try, and vice versa

Gus Mueller wrote a piece last week about Marzipan, suggesting that no miracle framework can be a panacea for all the problems associated with porting iOS apps to the Mac. He’s absolutely right. The hardest part of making a Mac app, or any software, for that matter, is never the framework. Anyone can learn to write code that executes. The challenge, as Mueller puts it, is caring enough to do it well.

No framework can make developers care more about making great things.

But speaking as someone who does care, I sure wouldn’t mind if Apple made my life a little easier.

Imagine you’re pushing a rock twice your size up a hill. It’s snowing, and you have no shoes or coat on. Someone is on the other side of the rock pushing in the opposite direction.

If I offered you a pair of shoes, you’re telling me you wouldn’t take them?

There’s no doubt in my mind there are good iOS devs out there who have never ventured over to the Mac because it looks like it would be just a bit more effort than it’s worth. It’s not that they can’t do it because AppKit is some incredibly hard thing that only a rocket scientist can figure out. (I’ve made AppKit apps, so trust me, it’s not rocket science.) But it is yet another thing to learn. In addition to having to sweat the details about the platform, user experience, etc., you also have to learn the differences between an NSButton and a UIButton, NSColor and UIColor, and on and on. I remember when I was going through it, I never once said “This is too hard!” It was more like “Why the heck is this so different?”

Also, there are many cases where the simplest of things take more effort in AppKit than on iOS. And even when something isn’t more effort, just finding answers to basic questions was a chore, because it’s harder to get answers from a web search about AppKit.^[5]

A unified API would obliterate these small frustrations. When I want to add a button to a view, I’d add it the same way on macOS as I do on iOS. When I want to specify a color, I’d use the same syntax for both.

If we apply the infamous “aliens landing on Earth” hypothetical to the development of iOS and macOS apps, of course the aliens would think it’s ridiculous this isn’t already the way things work.

And the benefits really could go in both directions. Some macOS devs may just find that once they learn this new framework, suddenly their great Mac apps are just a little bit easier to port over to the iPad.^[6]

Regardless of how much junk gets made by others, in the hands of those who care, better tools are still a good thing.

If you care about making great apps, then Marzipan should at least make you excited about a slightly easier path to platforms you haven’t yet explored, or a simplification between the two versions of your apps you already maintain.

A lower barrier to entry for new devs

Marzipan will not only make it easier for an existing iOS dev to move to macOS, and vice versa. It will also be easier for new developers to get started in Apple’s ecosystem. If we’re not talking about UIKit ported to AppKit, but rather a completely new set of APIs, that would mean years of knowledge about how those current frameworks get used would be baked into the new framework. Apple’s engineers are pretty good at this stuff.^[7] I’m guessing they know all the pain points for new developers coming to the platform, and they’ll seek to decrease that pain.

More new blood in the ecosystem means more innovation, more creativity, more inclusiveness. It probably also means more terrible apps, but like I said before, the cream that rises to the top will be worth it. As much as the old-timers love their little niche community of app celebrities, the future of the platform depends on all of us getting replaced eventually. Personally, I welcome the possibility of an influx of bright new talent, particularly to the Mac.

Less code is a good thing

While we’re on the subject of making things easier, Marzipan also promises more shared code between iOS and Mac versions of apps. We’ve been able for a long time to share some elements of our apps, models, classes, etc. in the same project file with different targets. With Marzipan, we could end up sharing even more code between platforms. Not all of it, of course. But a lot more of it.

Fewer repeated classes equals less code, which equals easier testing, which equals less room for human error, which equals more-reliable apps.

It also means less duplication of effort. Which is easier to sell to middle managers on a budget.

A unified framework that’s still native

I was a middle manager once. Every year, my boss would bring me into his office and hand me a budget that was invariably 15% smaller than last year’s and tell me to make it work, no matter what I had to do. Same output. Lower cost. That meant giving part-timers fewer hours, not extending contracts, and in some cases, eliminating positions altogether.^[8]

That was always my last resort, though. More often than not, I’d look at ways to spend less money on the services we delivered. There are always inefficiencies in any business, and if you put enough pressure on people, they will find them, even if it ends up hurting the product.

Enter our old friend, Write-Once, Run-Anywhere. We had a brief period of bliss with Apple’s push for native iPhone apps back in 2008. But the Dark Lord’s lieutenant has returned, and although he is not yet regained his full strength, his minions are gathering in Mordor.

Slack. Skype. Banking apps—chances are, you are already seeing more cross-platform Electron apps on your Mac and non-native apps on your phone as well. This is a trend. It will continue.

Marzipan probably won’t save us from this nightmare. But if even one of these JavaScript-infused beasts turns out to be an iOS-to-Mac native port on my Mac instead, it will be worth it.

As a consultant, I like the idea of being able to pitch an even slightly less expensive Mac add-on to an existing iOS contract. “Oh, you were going to build a Mac version in Electron? Well, we can make a much richer native experience reusing a lot of our efforts on iOS…” It’s still a tough sell, but it is just a bit easier.

The Mac is less likely to get left out of new API goodies

If Apple only has to maintain one framework for adding new features to iOS and macOS, it’s less likely to leave the Mac out of new APIs. That means no longer waiting a year or more to get the same interesting cool new features we see on iOS.

And given Apple’s tendency to eat its own dog food, I can see this having a very positive effect on the App Store as well. Imagine the App Store app being built using Marzipan, sharing its code between macOS and iOS. Now features like gifting, app previews, review prompting, and other things that have been missing on the Mac App Store for years would actually take effort to exclude from the Mac.^[9]

Simplifying to one framework could also improve the speed at which Apple keeps up with its documentation and sample code. Wouldn’t that be a wonderful thing?

The Mac market is far too small compared to iOS to be a top priority for Apple. At least with Marzipan, macOS can maybe tag along with its more popular baby brother on new features.

More options is almost always better than fewer options

People who have been reading me for a long time know that generally I’m a fan of having more options. It’s always better when Apple gives us something than when it takes something away.

Right now, even if I wanted to, I couldn’t sell an iOS app that also runs on the Mac in one simple transaction. At least not easily. Marzipan looks to make that very easy. Even if I never end up selling an app that way, I like having the option. I also like the idea of one button my customers press to download my app on all their devices, Macs included.

Developers are fond of criticizing Apple for all the things we can’t do. They tend to forget that Apple often gives us new things we can do. Sure, there are other things we’d rather they let us do. But I’ll take what I can get.

Conclusion

All of this, of course, is merely speculation on a rumor. But it’s a rumor that makes a whole lot of sense to me. I would not be surprised to hear something official about this from Apple come June in San Jose. I would not be terribly surprised if it came a year or two later. I would be surprised, however, if it never comes to pass.

When you look at all four of Apple’s operating systems (iOS, tvOS, watchOS, and macOS) one of them is clearly not like the others. And that’s inefficient from Apple’s perspective. The benefits to Apple of a unified framework are just too numerous and obvious. So if I had a stake in the macOS or iOS ecosystems (and I do have one in both) I’d be doing some serious planning in the new year, so I can be prepared to reap the benefits, rather than wasting time fearing the negatives.

I was recently asked on Twitter for practical examples of how I use Tally, made by Greg Pierce of Agile Tortoise. My response is way too long, even for the new 280-character limit, though, so I thought I’d write it up here.

Note: This is not a paid endorsement. I know Greg, and I know he makes great apps. Which is why I downloaded Tally in the first place. But he has never asked me to promote anything of his. I just like talking about great products.

Tally, for those who don’t know, is a simple iOS app for keeping a tally of just about anything. Tap anywhere on the screen to add one to the counter. Couldn’t be easier.

You can run multiple tallies at once, too. And there are other settings inside the app for customizing further. But that’s the basic gist. It’s a very simple app. But it’s this simplicity and malleability that make Tally so valuable to me.

Tally is also one of the few apps with an iOS widget that I actually use. Thanks to the widget (and the very good Apple Watch companion app) I almost never have to actually launch Tally on my iPhone to keep my tallies going.

The obvious use case for an app like Tally is to keep score in games, or count the number of people who enter a room. That sort of thing. But that’s not how I use the app.

Basically, I use Tally to keep track of behaviors I’m curious about tracking, but that I don’t want to get too deep into a rabbit hole about tracking. Make sense?

Let me give you an example. A while back, my doctor asked me to estimate how often per week I eat red meat. I couldn’t really give her an honest answer. I figured it was more than she was going to recommend, regardless, but that didn’t bother me as much as simply not knowing. I had never thought to track my red meat intake before. So I made a tally called Red Meat, and I started tracking it, casually. Every time I ordered a cheeseburger, I’d flick over to Tally on my Apple Watch or on the widget screen and add one to the count. Carne Asada burrito? Add another to the count. And that was it. I wasn’t trying to guilt myself into changing any behavior. I didn’t want to create permanent stats on my red meat intake for the rest of my life. It wasn’t a chore. I was just curious.

The results, of course, surprised me. I was definitely eating red meat more often than I thought I was. Given the health drawbacks of cholesterol, cancer risk, heart problems, etc., it was definitely more than I wanted to be eating. But I didn’t panic. I just kept tracking it, this time setting my sights on reducing that weekly number. Could I do one fewer this week than last week? No pressure. No judgement. Some weeks I’d do better. Others I wouldn’t. Let me just see if I can make different choices on occasion.

Over time, I went from eating red meat more than seven times a week (or roughly once a day) to three or fewer times per week. That’s a big shift, but I did it over a prolonged period, so it barely felt like a change. Months later, I find myself craving red meat less often, so keeping the number down at three or so has become second nature. I can probably stop tracking it at this point, I’ve gotten so consistent at keeping that number down.

And that’s the whole point. There are some things in my life I absolutely want tracked over the long haul, in an app tailored specifically for that thing. My caffeine intake, for instance. My heart rate. My weight. And so on. But for other things, I’m just mildly curious. I suspect I have a habit that isn’t ideal, and so I gather some data to see if my suspicion turns out to be true. If the number makes me concerned, I make small adjustments to my habits, so I can be less concerned.

I didn’t need a red meat tracking app, in other words. I just needed to keep a casual tally for a few months. I needed data, and Tally was the easiest, low-pressure way to gather that data.

The beauty of Tally is that I can use one app to track just about anything. Another thing I started tracking not long after red meat was my alcoholic beverage intake. I never drink myself into a stupor, but I do like a nice glass of wine most nights for dinner. I also mix the occasional cocktail at home, mostly as a hobby. Throw in the occasional social gathering in the evenings, and just how many drinks was I actually having during the average week? Once again, it was more than I thought. So I’ve begun working on reducing that number, too.

This isn’t about scaring myself into making a massive change to my behavior overnight. Experience has shown me that’s a waste of time. If I want to make changes to long-ingrained habits, I know I need to make small adjustments over a long period, until the new habit becomes as natural as the old one once was. Until the old habit seems downright unattractive. It’ll take much longer to accomplish, but it’ll also last much longer.

You can also use Tally with an eye for increasing, rather than decreasing, behaviors, of course. How many times this week did I resist the urge to correct someone on the Internet? How many times did I work on gathering new leads for my consulting business? The possibilities are endless. And it’s so easy to track things, you’re far more likely to do it than with more complicated data entry apps. It only takes a few seconds to pop into the Apple Watch app or flip over to the widget screen on my iPhone, and add one to the count. It’s quicker than checking in on Swarm, or posting a pic to Instagram, for sure.

At the end of the week I reset the count, and I can start fresh. There’s no permanent record on which to judge myself. I don’t even really look at the numbers as the week goes by. I just view each tap as collecting a data point. Nothing more. On Sunday, when I actually look more closely at the numbers, I take a moment to reflect on how I’m doing. If I did better? Great. If I didn’t? No worries. I’ll try to do better next week.

We all want to improve ourselves in some way. I don’t know if this will work for you to help make adjustments in your habits. But it’s sure worked for me. I encourage you to give Tally a try, if you think it may help. It’s free to download and very inexpensive to get all the features unlocked.

I’ve seen a number of complaints about the iPhone X keyboard implementation. “So much wasted space.” “They should put the spacebar down at the bottom, where it always was.” “They should fill that space under the spacebar with emoji buttons.” And so on.

All of these suggestions strike me as poorly thought out. I immediately understood why Apple made the choice to leave that area mostly blank. The space bar is where it used to be. The home button used to be where that empty space is.

Given how difficult it is to change muscle memory, and given how much of a stretch it actually is to reach the bottom of the iPhone X in real-world use, putting frequently used buttons down at the bottom is a really bad idea.

I got to test this firsthand with my own app, x2y. I wasn’t expecting to get my iPhone X version finished in time for the release date, but at the last minute I had some time, and I was able to handle all the changes I felt were necessary—except one. My custom number pad still reached down to the bottom of the phone. I figured this would not be ideal, given what Apple had chosen to do with the built-in keyboard, but not having the hardware in my hands, I figured I’d ship it and see what happens.

Sure enough, as soon as I played around for a few minutes on my own iPhone X, I knew this could not stand. I was accidentally typing the wrong numbers constantly. And it was just too much of a stretch to get to that bottom row regularly.

So I fired up Xcode again and started figuring out a fix. In the end, the new design technically doesn’t look as good, but in practice it feels a thousand times better. My number pad isn’t quite as high up as Apple’s own built-in version, but it’s up above the Safe Area, at least.

So there you have it. Apple clearly did the right thing with keyboard placement on iPhone X. As I mentioned before, just because your screen goes edge-to-edge, that doesn’t mean your UI should. The extra space is most often best filled with background color.