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.

Update: It looks like Apple may finally have fixed this bug in the next version of macOS, called Catalina. Read more details in my new post here.

Over the years, the majority of my complaints about Apple have centered around music. That’s because I love music, and Apple clearly doesn’t always think enough about people outside of its contrived all-in-on-Apple-Music listener when it comes to the iTunes experience.

Today’s complaint actually begins with a recent positive discovery. I finally gave in to the temptation and signed up for a free trial of Apple Music, and it’s really great. The recommendations it makes are often good, or at least not terrible, and I love being able to try out lots of artists that I otherwise would probably not have discovered. I love downloading tracks on my phone as I discover them, and I like listening to them even when I’m offline. So far, so good. I definitely plan to remain a subscriber.

But then I ran into a bit of a snag when it came to the iCloud Music Library. This is the feature that syncs whatever you put on one device with all your iPhones, iPads, Macs, etc. In theory, it’s a great idea. If I discover a track on my iPhone and download it, it’ll be sitting on my Mac next time I might want to listen. And vice versa. On my iPad, I don’t auto-download these tracks, but they show up in my library for streaming if I want them. Perfect.^[1]

But after a couple of days of enjoying this new iCloud Library experience, I noticed a problem on my Mac. In iTunes, every track that is available on Apple Music but that I had acquired elsewhere (CD Rip, purchased from another store, etc) was doubled in my iTunes library. Each song would be listed twice, in other words.

In some cases, one version would have a little cloud icon with the down arrow, indicating that it can be downloaded from iTunes, and the other would have a cloud and an X, indicating a track that is from my library, already downloaded, but not from iTunes. On my phone and iPad, these tracks only show up once. But on the Mac, there were two. Right after one another.

In other cases, it would actually download the second copy, so I’d get one track with no icon (downloaded from iTunes) and the other with the X (my original file). All of these files were taking up twice as much space on my hard drive.^[2]

File size issues aside, you can see how this would be a problem for someone like me who likes listening to albums. Unless I want to hear each song twice in a row before advancing to the next one, I have to remove all the duplicate tracks from Up Next every time I click on an album. (Even the ones that aren’t yet downloaded just stream when I play the album.)

Well, that’s a strange bug, I thought. Maybe I should throw away the extra downloaded ones and just leave my original tracks. We’re talking about thousands of tracks, so that would be a lot of work. But if it’s just a one-time glitch, so be it.

When I attempted to remove a cloud track however, I got a warning that it would remove the track on my phone as well. That’s not good. I want the track to stay on my iPhone. I just don’t want two copies on my Mac.

The other option, of course, was to erase my copies of the tracks and just leave the cloud versions. Which means if I ever cancel Apple Music, those tracks will likely be gone forever, since I didn’t buy them on iTunes. They would not be part of my purchase history, so they would disappear, along with everything else I try in Apple Music.

This is not an option.

So I found a third alternative: I just turned off iCloud Music Library on my Mac. The duplicates immediately went away, and I was left with my old library intact. I miss out on syncing new tracks that I find on my phone, but those can be found and streamed on my Mac from the recents section of For You. Terrible user experience, but at least there’s a workaround.

Believe it or not, I wasn’t driven to write a long tirade yet. I tweeted something snarky, but then I let it go. Lots of others informed me this has been a known issue for quite a while. Yikes.

And then something happened this week, when one of my favorite bands, Big Big Train, released a pair of new Christmas songs. Only one is available on iTunes, while the other is a special b-side you can only get from their web store. A portion of the proceeds from those songs also gets donated to charity when you buy on their store. So I bought both tracks on their store, of course.

I often buy tracks from indie artists on their own sites, anyway. As an extra sign of support. This is not weird or extremely unusual behavior. It’s pretty common for music fans.

It’s when I tried to listen to these tracks that I found my inspiration for this rant. I could add these two new tracks to my Mac, no problem. But because I didn’t have iCloud Music Library turned on, those tracks were not synced up with my phone. Okay. I can just plug my iPhone into the Mac with a USB cable and drag the new tracks over to my phone, right?

Nope.

Because iCloud Music Library was turned on for the iPhone, I was now no longer able to simply drag and drop files between the Mac and iPhone. iCloud Music Library is an all-or-nothing proposition. The only way to get these two tracks onto my phone would be to either turn off iCloud Music Library on the phone (and thus lose all the Apple Music tracks I’ve downloaded) or turn iCloud Music Library back on for my Mac, and let the tracks sync.

I chose the latter, which, of course, brought back all the duplicate tracks on my Mac as well. So then I had to turn off iCloud Music Library on my Mac after the upload of my new songs made it to my other devices. Fortunately, the two new tracks remained on my phone.

You read that right. Moving forward, whenever I get a new audio track that isn’t from Apple Music, I’ll have to add the track to iTunes, turn on iCloud Music Library on the Mac, let it upload that new track to the cloud and download all these thousands of duplicates, then turn off iCloud Music Library on the Mac to remove all the duplicates.

Lovely.

I purchase the vast majority of my music from the iTunes Music Store. I shouldn’t be punished for occasionally getting tracks from other sources. Especially when those tracks aren’t even available on iTunes.

All of this suggested to me that perhaps no one at Apple has any music that wasn’t downloaded from iTunes? Although that can’t be true. You’d think someone in charge of music over at Apple had listened to music prior to the iTunes Store’s existence, which means they at least have some tracks that were ripped from CDs in the early 2000s. Given this issue is so thoroughly annoying, I would think it would have gotten fixed somewhere in the last year or two once someone noticed, right? It’s simply not possible that no one over there has noticed this problem.

The only other two conclusions I can make is that no one at Apple cares (not likely) or that this duplication of tracks is somehow intended. Which brings me to my favorite question: Why? Why would anyone want to search through their entire library and delete all these duplicate tracks? Or erase their entire music library before signing up for Apple Music, so their library would be fresh and only sourced from Apple?

If the Mac can detect that I have a track in my library that’s from another source but also available on iTunes, why can’t it just mark that track as already downloaded, and then just download a copy to my other devices? Like I said, this works just fine on my iOS devices.^[3]

Despite my frequent complaining, iTunes has improved over the years. So many things that used to drive me nuts are better at this point. I’m back to using the built-in iOS Music app again. I recently wrote about drag and drop from iTunes to your iOS devices finally working reliably. I can finally sort albums on my phone by date instead of title. I signed up for Apple Music and I actually like it. Apple is working on making these experiences better. Maybe this duplicates issue is just another item on a long list of things to be fixed, and we’ll eventually see it go away. I have to hope so. It’s one of the few remaining big ticket items that leaves me scratching my head at an otherwise decent music experience.

Progress has been very slow going, though. I’ve already volunteered, if Apple ever wants to take me up on it, to help them find any remaining issues by examining my music library. If they want to find music-lover use cases they probably haven’t considered, my hard drive is full of them. Heck, I’m usually in the Bay Area at least twice a year, anyway. I’d be happy to stop by whenever they want to talk.

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.

I’ll be honest: when I added remote connectivity to Fin in version 4, I wasn’t sure how many people would actually use the feature. I just thought it would be a cool thing to have, and I wanted to learn how to work with Apple’s MultipeerConnectivity APIs.

All of my side projects have been about learning something, after all.

But to my surprise, a number of my customers do seem to like connecting two or more iOS devices together while running timers.

Recently, I received a support request for an additional feature: While connected, wouldn’t it be cool to send a quick text-based message to the other devices? That way, you could signal to someone performing on stage, for instance, that there was an important announcement, or something to that effect.

Not a bad idea.

So I went to work on getting that to happen. Since all the networking infrastructure was already done, it actually turned out to be more of a user experience problem than anything else. Where should the messaging UI live in the app, and how should it appear on screen? Those were the two hardest issues to tackle. The rest was just packaging up a string and sending it over to the other device(s).

After some experimentation and refinement, I managed to get something really simple and cool up and running. And so starting today with the latest update on the App Store, Fin can now be used to send notes to connected devices.

Type in a quick message, send it, and the connected devices on your network will display the message full screen for five seconds. Fin remembers the five most recent messages you’ve sent, so you can access them with a single tap, in case you often find yourself telling your performers the same thing. You can even send emoji in messages, if you want.

While I was at it, I improved the workflow for changing the end message that appears when the timer runs out using the same controller. Here, too, you will see the five most recent messages you’ve set. It’s a part of the user experience I’ve been less than thrilled about for a long time, so I was glad to improve it in this version.

Fin 4.3 is now available on the App Store.