Coping with Apple's pace of innovation in an application that can delete files

In a related blog article, I noted that older versions of CCC refused to open on newer OSes, and I'd like to explain here why that was the case, and also describe some improvements that went into CCC 4.1.5 that make that no longer necessary.

Every OS adds and removes system functionality

When Apple issues a new OS, there are always a substantial number of changes in that OS beyond the features listed on the Apple web page. On the back end, the way that applications interact with the OS, and the various application UI "widgets" that are provided by the OS change in subtle and sometimes dramatic ways. Apple also discontinues facilities in every OS, and each OS also finally discards facilities that were discontinued long ago. So with each OS upgrade, there is likely some small percentage of CCC's functionality that suddenly becomes driven by a discontinued OS facility.

Consider the following scenario:

  • CCC has has a feature "A" that depends on system functionality "X" in OS X 10.11.
  • Apple releases 10.12, and notifies developers that functionality X is being replaced with functionality Y, and in the future functionality X will be removed. While developing CCC 5, we make sure to adopt the new functionality Y.
  • Apple releases 10.13 and we release CCC 5. CCC 4 still works, but the feature that uses functionality X is starting to have some odd behavior.
  • Apple releases 10.14 and CCC 4 and 5 continue to work, but CCC 4 has additional odd behavior.
  • Apple releases 10.15 and completely removes functionality X. Now CCC 4 feature A is completely broken, because it depended on functionality X.

This sequence of events is ongoing, consistent, and predictable — without updates, application functionality will degrade until the applications are no longer practically usable. At this point, someone might ask, "Why not change CCC 4 to adopt the newer technologies?". The answer is not simple, it's a combination of economics (it is not economically practical to add new features to an older version of a product), logistics (major architectural changes may be required to accommodate the new features), and user experience (adopting the new features may make the product incompatible with older OSes). 

(Not) Predicting the result of these changes

What is not predictable about this process is the identity of "feature A", the extent to which it is rendered unusable, and the affect on a user's data that that might have. Suppose, for example, that "feature A" is CCC's ability to positively identify the source and destination volumes. If that functionality was broken, the best case scenario would be CCC refusing to run a backup task because it couldn't identify the source and destination. The worst case scenario would be CCC proceeding with the task and overwriting data on the wrong volume. That scenario in particular is the very reason that previous versions of CCC prohibited their use on new, unqualified OSes. This was often decried, with people insisting, "Let me make that choice and take the responsibility of CCC not working." I resisted, though, because this worst-case scenario literally kept me awake at night, and I can guarantee that the same person asking for that responsibility would be tweeting up a storm if some old version of CCC destroyed all his data.

Proactive notifications

One morning in my restless sleep, it occurred to me what it would take to alleviate my concerns and allow CCC to run on an unqualified OS. If some sort of data-loss scenario arises with CCC 4 on some long-from-now released OS, I need to know that I can proactively notify users that this sort of problem exists. Mailing lists don't work for this — email addresses change, and most users don't subscribe. What I really need is for CCC 4 to attain this information from our server, and present the information to the user. So that's exactly what we have done with CCC 4.1.5, and here's what happens if you attempt to run CCC 4.1.5 on an OS for which it is not yet qualified:

  • If the user feels confident in pursuing an "Advanced" configuration (i.e. in which they use a product in an unsupported manner), we will present to them a notice about the unpredictable nature of new OS releases, and ask them to confirm that they wish to accept those risks and proceed to use CCC in an unsupported manner:

  • When used on an unqualified OS, CCC will present a yellow banner that serves as an enduring reminder that that version of CCC is not qualified on the user's OS. CCC will continue to function, unencumbered by any restrictions imposed by us:

  • In the event that we receive a report of a data loss scenario with CCC 4.1.x and OS X 10.y, we will make that information available on our website. Upon launch, CCC will retrieve this information from our server and add a warning icon to the yellow banner. Clicking on the warning button will take the user to our website where the situation is explained, and then the user can make an informed decision about continuing to use the outdated version of CCC on the newer OS.

I hope folks will find this to be a fair and amenable solution that allows them to continue using an older version of CCC.