Apple seems very proud of the new ‘Marzipan’ App Store app in Mojave, and in technical terms it is a good proof of this system for porting iOS apps to run in macOS. It’s a shame that a little more attention wasn’t paid to the way that it works. I don’t know how you feel, but it is at best upsetting, and at times downright irritating.

Take, as an example, its Updates view. There’s so much wrong here that it is close to being functionless, and is often misleading. The previous App Store app provided a time-ordered list of (almost) all the updates that you had installed, although most recently Apple had even tampered with that record, removing old versions of macOS, for instance, without any good reason.

When it comes to displaying updates, this new version has a mind of its own. It sometimes only lists a specific update there for a few minutes. It weeds the list as and when it feels like, and doesn’t pay much attention to how long ago the update was installed. Few, though, are allowed to remain longer than a few days, then apparently pass out of the scope of its very limited memory. If I can remember as far back as a week ago, why can’t this wonderful new app?

Its list of updates is extremely wasteful of space. All I want to see here is the name and version of the update, and when it was installed. Yet in quite a sizeable window, the app is incapable of displaying more than about 14 updates, when it can recall them.

But its most bizarre behaviour is the way in which it calculates how long ago each update was installed. This may seem a small point, but almost every time that I look at the list of updates, it makes me stop and check. At first, I thought it might be locked into Pacific Standard Time, even though I access the UK App Store from UK local time. But when it reports that an update was installed X Days Ago, it isn’t applying a human concept, but that of a machine date calculation.

What it does is calculate the time difference between now and the time that the update was installed. If that is, for example, between 1 and 2 days, then it reports that the update was installed yesterday; if between 2 and 3 days ago, then it was installed 2 Days Ago. This has bizarre effects.

Let’s say that I updated Y app at 1800 local time the day before the day before yesterday. In human reasoning, this morning that occurred three days ago. But until 1800 today, the App Store list of updates will claim that Y was updated 2 Days Ago, then suddenly at 1801 report that it was installed 3 Days Ago. That may be the way that date calculations work in macOS (it is, I use them in my apps), but that isn’t the way that this human thinks.

It’s a small point, I know. But almost every time that I look at the Updates view it makes me stop and puzzle. Alternatively, I could just ignore the information which it provides, and I am now getting to the point of recognising that the Updates view is next to useless, and only annoys.

What’s most irritating is that this has nothing to do with iOS or Marzipan – it’s just poor design and lack of interface testing. There’s no point in putting marzipan on a cake that’s not fully baked.

Appendix: A Lesson in Date Calculation

This all becomes simple once you frame the problem correctly, and perform all calculations in local time.

What the App Store app does at present is to calculate the number of 24 hour periods which have elapsed since the update was installed, that is the truncated integer result of the time interval divided by 24.0. That isn’t the way that most humans consider elapsed time in days, e.g. yesterday, two days ago (although I believe that some cultures may view this differently).

What most humans do is consider the date, not the time interval that has elapsed. So if the date (day number) has changed, then we consider that this event occurred on a different day. The snag with comparing dates is that, in most calendars, months have irregular lengths, so calculating how many calendar days have elapsed gets messy.

Much better is to reframe the problem in terms of how many midnights have elapsed since the update was installed. That is easily computed from the time interval since the last midnight (i.e. the time difference between 00:00:01 today and the current time), and the time elapsed since the update. If the latter is less than the former, then you know that the update was installed today; otherwise all you have to do is calculate the truncated integer of the time interval between the update and last midnight divided by 24.0.

Whoever implemented this calculation in the App Store app forgot the role of the last midnight in the calculation required.

Surprisingly, although this is quite a commonplace date calculation and performed correctly in the Finder and in other parts of macOS, easy access isn’t provided in the NSDate class in macOS public frameworks.