Writing originated for recording numbers not words, computing likewise. Yet today, numbers are second-class citizens in macOS, and frustratingly difficult to use.

In the course of developing Stibium, I’ve realised that its statistical analysis is more generally useful, and want to give access to those techniques, like 20% trimmed means and Theil-Sen linear regression. Even if no one else ever uses them, I’d like to be able to access these in other apps, like Numbers. Unfortunately, because of the numerical processing involved, they’re not suitable for building into a formula. The regression in particular requires nested iterative loops, which are easy to code in a language like Swift, but a real pig in a spreadsheet.

So I first looked at how to write a plug-in for Numbers, something which isn’t apparently supported at all. AppleScript isn’t a good choice for numerically-intensive algorithms either, so my next thought was to implement a utility into which Numbers data could be pasted.

With text, there’s a wide range of different formats supported by apps which handle text: you can have it in plain Unicode UTF-8, complete with styling in Rich Text (Attributed Text in code), even as a PDF if you want. Following a little check using Pasteboard Viewer, I discovered that the only truly numeric pasteboard format is com.apple.iWork.TSPNativeData, which of course is private to Apple’s own apps and undocumented. Although this native data is likely to use Core Foundation’s CFData, trying to decipher it would be a time-consuming task. In any case, that format isn’t supported by other apps.

The most commonly available pasteboard format across different numeric apps seems to be plain UTF-8 text, with some apps (excluding Numbers) offering public.utf8-tab-separated-values-text, in which numbers are represented not as Integers, Doubles, etc., but simply in plain text. Either way, the numbers aren’t passed in numeric datatypes, but formatted as text. Before they can be used in any sort of calculation, they have to be unpacked from each row, their type identified, and each converted back into a number.

If we had to do the same with styled text, it would be like exchanging it character-by-character, each with its own style attributes.

This is the reason why almost every app which works with numbers has to provide its own spreadsheet-like display, tools to manipulate the contents, import and export facilities to handle formats such as CSV and tab-delimited text, and other overhead. It’s an enforced duplication of code and effort. And apps like Numbers which could so easily promote a numeric interchange format don’t, instead relying on proprietary formats. In case you’re thinking that Microsoft Excel might be any better, I’m afraid that it too is just as closed.

So if I do decide to provide these robust methods of data analysis for wider use, I’m condemned to build a superfluous spreadsheet-like interface to help you correct the many errors and misunderstandings which occur when exchanging numbers which have been converted into tables of text. Unless, that is, you have any better suggestion.