Tag: apple

Code · Mighty Convolvuli · Work

On macOS, arm64, and universal binaries

Chris Cannam

A handful of notes I made while building and packaging the new Intel/ARM universal binary of Rubber Band Audio for Mac. I might add to this if other things come up. See also my earlier notes about notarization.

Context

I’m using an ARM Mac – M1 or Apple Silicon – with macOS 11 “Big Sur”, the application is in C++ using Qt, and everything is kicked off from the command line (I don’t use Xcode).

To refer to machine architectures here I will use “x86_64” for 64-bit Intel and “arm64” for 64-bit ARM, since these are the terms the Apple tools use. Elsewhere they may also be referred to as “amd64” for Intel, or “aarch64” for ARM.

Universal binaries

A universal binary is one that contains builds for more than one processor architecture in separate “slices”. They were used in the earlier architecture transitions as well. Some tools (such as the C compiler) can emit universal binaries directly when more than one architecture is requested, but this often isn’t good enough: perhaps it doesn’t fit in with the build system, or the architectures need different compiler flags or libraries. Then the answer is to run the build twice with separate output files and glue the resulting binaries together using the lipo tool which exists for the purpose.

How does the compiler decide which architecture(s) to emit?

The C compiler is a universal binary containing both arm64 and x86_64 “slices”, and it seems to be capable of emitting either arm64 or x86_64 code regardless of which slice of its own binary you invoke.

Perhaps the clearest way to tell it which architecture to emit is to use the -arch flag. With this, cc -arch x86_64 targets x86_64, cc -arch arm64 targets arm64, and cc -arch x86_64 -arch arm64 creates a fat binary containing both architectures.

If you don’t supply an -arch option, then it targets the same architecture as the process that invoked cc. The architecture of the invoking process is not necessarily the native machine architecture, so you can’t assume that a compiler on an ARM Mac will default to arm64 output.

I imagine the mechanism for this is simply that the x86_64 slice of the compiler emits x86_64 unless told otherwise, the arm64 slice emits arm64 likewise, and when you exec the compiler you get whichever slice matches the architecture of the process you exec it from.

There’s also a command called arch that selects a specific slice from a universal binary. So you can run arch -x86_64 make to run the x86_64 binary of make, so that any compiler it forks will default to x86_64. Or you can do things like arch -arm64 cc -arch x86_64 to run the arm64 binary of the compiler but produce an x86_64-only binary.

If you invoke a compiler directly from the shell without any of the above going on, then you get the machine native architecture. I assume this is just because a login shell is itself native.

For my builds I found it helpful to provide a cross-compile file to tell Meson explicitly which options to use for the architecture I wanted to target. That avoids the defaults being just an accident of whichever architecture Meson (or its Python interpreter, or Ninja) happened to be running in, without having to litter the build file with explicit architecture selections. I then scripted the build twice from a separate deployment script, using a different cross file for each, rather than try to have a single Meson file build both at once.

How do I target a particular version of macOS?

Use a flag like -mmacosx-version-min=10.13 at both compile and link time.

For ARM binaries, the oldest version you can target is 11. But you can still build a universal binary that combines this with an Intel binary built for an older version, and the result should run on those earlier versions of macOS as well.

How does a version of macOS decide whether my binary is compatible with it?

I had this question because I had built a universal binary (as above) in which the Intel slice was, I thought, built for macOS 10.13 or newer, but when I brought it to a machine with macOS 10.15 it showed as incompatible in the Finder and could not be opened there.

The answer is that it looks at the relevant architecture slice of the universal binary, and inspects it to find a Mach-O version number. In “older” versions of the macOS SDK this version is written using the LC_VERSION_MIN_MACOSX load command; in “newer” versions (I’m not quite sure when the cutoff is) it is tagged as the minos value of the LC_BUILD_VERSION load command instead. The linker quite logically decides which load command to write based on the value of the version number itself, so if you build -mmacosx-version-min=10.13 you get a binary with LC_VERSION_MIN_MACOSX specified.

You can display a binary’s version information with the vtool tool, and it also appears in the list of information printed by otool -l. In theory you can also change this tag using vtool, but (a) that’s a bad idea, fix it in the build instead and (b) vtool segfaulted when I tried it anyway.

And after all that, in my case the cause turned out to be that I’d failed to supply the -mmacosx-version-min flag at link time.

Why is my program being killed on startup?

It appears that if you build a program for one architecture and then rebuild it for the other arch to the same executable file without deleting the executable in between, sometimes it doesn’t run: it just gets “killed (9)” on startup. I failed to discover why and I failed to reproduce it just now in a test build. I guess if that happens, delete the executable between builds.

* * *

Bonus grumble about Mac trackpad and mouse options

This is not useful content. Please do not attempt to read it

I haven’t used a Mac in such earnest for a while now, so of course I’ve been rediscovering things about macOS that I don’t get on with. One that I find particularly maddening is the way it handles scroll direction for the trackpad and an external mouse.

I switch between the two a lot, and I like to use the “natural scrolling” direction (touchscreen-like, so your fingers are “pushing” the content) with the trackpad, but the opposite with the mouse, which has a scroll wheel or wheel-like scrolling zone whose behaviour I became accustomed to before touchscreen devices started sprouting everywhere.

Fortunately, macOS provides separate touchpad and mouse sections in the system preferences, which contain separate switches for the scroll direction of the trackpad and mouse respectively.

Unfortunately, when you change one of them, the other one changes as well. They aren’t separate options at all – they’re just two different switches in different windows that happen to control the same single internal option! So every time I go from trackpad to mouse or back again, I have to also go to system preferences and switch the scroll direction by hand. That is so stupid.

(Linux and Windows both have separate options that actually work as separate options. Of course they do. Why would they not?)

Code · Mighty Convolvuli · Security And That · Work

On macOS “notarization”

Chris Cannam

I’ve spent altogether too long, at various moments in the past year or so, trying to understand the code-signing, runtime entitlements, and “notarization” requirements that are now involved when packaging software for Apple macOS 10.15 Catalina. (I put notarization in quotes because it doesn’t carry the word’s general meaning; it appears to be an Apple coinage.)

In particular I’ve had difficulty understanding how one should package plugins — shared libraries that are distributed separately from their host application, possibly by different authors, and that are loaded from a general library path on disc rather than from within the host application’s bundle. In my case I’m dealing mostly with Vamp plugins, and the main host for them is Sonic Visualiser, or technically, its Piper helper program.

Catalina requires that applications (outside of the App Store, which I’m not considering here) be notarized before it will allow ordinary users to run them, but a notarized host application can’t always load a non-notarized plugin, the tools typically used to notarize applications don’t work for individual plugin binaries, and documentation relating to plugins has been slow in appearing. Complicating matters is the fact that notarization requirements are suspended for binaries built or downloaded before a certain date, so a host will often load old plugins but refuse new ones. As a non-native Apple developer, I find this situation… trying.

Anyway, this week I realised I had some misconceptions about how notarization actually worked, and once those were cleared up, the rest became obvious. Or obvious-ish.

(Everything here has been covered in other places before now, e.g. Apple docs, KVRaudio, Glyphs plugin documentation. But I want to write this as a conceptual note anyway.)

What notarization does

Here’s what happens when you notarize something:

  • Your computer sends a pack of executable binaries off to Apple’s servers. This may be an application bundle, or just a zip file with binaries in it.
  • Apple’s servers unpack it and pick out all of the binaries (executables, libraries etc) it contains. They scan them individually for malware and for each one (assuming it is clean) they file a cryptographic hash of the binary alongside a flag saying “yeah, nice” in a database somewhere, before returning a success code to you.

Later, when someone else wants to run your application bundle or load your plugin or whatever:

  • The user’s computer calculates locally the same cryptographic hashes of the binaries involved, then contacts Apple’s servers to ask “are these all right?”
  • If the server’s database has a record of the hashes and says they’re clean, the server returns “aye” and everything goes ahead. If not, the user gets an error dialog (blah cannot be opened) and the action is rejected.

Simple. But I found it hard to see what was going on, partly because the documentation mostly refers to processes and tools rather than principles, and partly because there are so many other complicating factors to do with code-signing, identity, authentication, developer IDs, runtimes, and packaging — I’ll survey those in a moment.

For me, though, the moment of truth came when I realised that none of the above has anything to do with the release flow of your software.

The documentation describes it as an ordered process: sign, then notarize, then publish. There are good reasons for that. The main one is that there is an optional step (the “stapler”) that re-signs your package between notarization and publication, so that users’ computers can skip ahead and know that it’s OK without having to contact Apple at all. But the only critical requirement is that Apple’s servers know about your binary before your users ask to run it. You could, in fact, package your software, release the package, then notarize it afterwards, and (assuming it passes the notarization checks) it should work just the same.

Notarizing plugins

A plugin (in this context) is just a single shared library, a single binary file that gets copied into some folder beneath $HOME/Library and loaded by the host application from there.

None of the notarization tools can handle individual binary files directly, so for a while I thought it wasn’t possible to notarize plugins at all. But that is just a limitation of the client tools: if you can get the binary to the server, the server will handle it the same as any other binary. And the client tools do support zip files, so first sign your plugin binary, and then:

$ zip blah.zip myplugin.dylib
adding: myplugin.dylib (deflated 65%)
$ xcrun altool --notarize-app -f blah.zip --primary-bundle-id org.example.myplugin -u 'my@appleid.example.org' -p @keychain:altool
No errors uploading 'blah.zip'.

(See the Apple docs for an explanation of the authentication arguments here.)

[Edit, 2020-02-17: John Daniel chides me for using the “zip” utility, pointing out that Apple recommend against it because of its poor handling of file metadata. Use Apple’s own “ditto” utility to create zip files instead.]

Wait for notarization to complete, using the request API to check progress as appropriate, and when it’s finished,

$ spctl -a -v -t install myplugin.dylib
myplugin.dylib: accepted
source=Notarized Developer ID

The above incantation seems to be how you test the notarization status of a single file: pretend it’s an installer (-t install), because once again the client tool doesn’t support this use case even though the service does. Note, though, that it is the dylib that is notarized, not the zip file, which was just a container for transport.

A Glossary of Everything Else

Signing — guaranteeing the integrity of a binary with your identity in a cryptographically secure way. Carried out by the codesign utility. Everything about the contemporary macOS release process, including notarization, expects that your binaries have been signed first, using your Apple Developer ID key.

Developer ID — a code-signing key that you can obtain from Apple once you are a paid-up member of the Apple Developer Program. That costs a hundred US dollars a year. Without it you can’t package programs for other people to run them, except if they disable security measures on their computers first.

Entitlements — annotations you can make when signing a thing, to indicate which permissions, exemptions, or restrictions you would like it to have. Examples include permissions such as audio recording, exemptions such as the JIT exemption for the hardened runtime, or restrictions such as sandboxing (q.v.).

Hardened runtime — an alternative runtime library that includes restrictions on various security-sensitive things. Enabled not by an entitlement, but by providing the --options runtime flag when signing the binary. Works fine for most programs. The documentation suggests that you can’t send a binary for notarization unless it uses the hardened runtime; that doesn’t appear to be true at the moment, but it seems reasonable to use it anyway. Note that a host that uses the hardened runtime needs to have the com.apple.security.cs.disable-library-validation entitlement set if it is to load third-party plugins. (That case appears to have an inelegant failure mode — the host crashes with an untrappable signal 9 following a kernel EXC_BAD_ACCESS exception.)

Stapler — a mechanism for annotating a bundle or package, after notarization, so that users’ computers can tell it has been notarized without having to contact Apple’s servers to ask. Carried out by xcrun stapler. It doesn’t appear (?) to be possible to staple a single plugin binary, only complex organisms like app bundles.

Quarantine — an extended filesystem attribute attached to files that have been downloaded from the internet. Shown by the ls command with the -l@ flags, can be removed with the xattr command. The restrictions on running packaged code (to do with signing, notarization etc) apply only when it is quarantined.

Sandboxing — a far more intrusive change to the way your application is run, that is disabled by default and that has nothing to do with any of the above except to fill up one’s brain with conceptually similar notions. A sandboxed application is one that is prevented from making any filesystem access except as authorised explicitly by the user through certain standard UI mechanisms. Sandboxing is an entitlement, so it does require that the application is signed, but it’s independent of the hardened runtime or notarization. Sandboxing is required for distribution in the App Store.

Things That Are A Bit Like Other Things

How to change your friend’s OS/X Yosemite system font to Arial

Chris Cannam

Apple made a lot of visual changes in release 10.10 (“Yosemite”) of Mac OS/X. One of the most obvious was to change the system font, as used throughout the desktop, from Lucida to Helvetica.

Helvetica.
Helvetica.

A lot of people love Helvetica, so presumably they were happy. Others were less satisfied, leading to a little rush of code and articles to help you switch the system font back to Lucida or to some other font that happens to appeal.

But these people are missing the point. The substitution you want to make is not to your own desktop, but to that of your most type-conscious Mac-using Helveticaphile friend. And it is to switch the system font from Helvetica to Arial.

Delightfully, you can do this without needing admin privileges—no password required, all you need is to get control of their keyboard for a couple of minutes.

Here’s how:

1. On your own machine, provided you are also using a Mac, install Yosemite System Font Patcher and its dependencies following the instructions in its README:

$ git clone https://github.com/dtinth/YosemiteSystemFontPatcher
$ brew install fontforge --with-python

2. Retrieve and patch the Arial font files so they report themselves as system fonts:

$ cd YosemiteSystemFontPatcher
$ cp '/Library/Fonts/Arial.ttf' '/Library/Fonts/Arial Bold.ttf' .
$ bin/patch 'System Font Regular' 'Arial.ttf'
$ bin/patch 'System Font Bold' 'Arial Bold.ttf'

3. The above should have created two new font files, in the current directory, called System Arial.ttf and System Arial Bold.ttf. Make these available somewhere you can easily retrieve them on your friend’s machine (shared in the cloud or whatnot).

4. On your friend’s machine, when you see the opportunity, retrieve the System Arial.ttf and System Arial Bold.ttf files and copy them into the $HOME/Library/Fonts directory. You must be logged in as your friend to do this, as it must be their home directory whose font library you are copying into.

And you’re done. The change will only take effect for apps started after the fonts have been installed, or globally from the next login—if you want to make it happen immediately, I’m afraid you’ll have to log your friend out.

Arial.
Arial.

Now, see how long it takes them to notice. For best effect, engage them in conversation about how clean and elegant Helvetica is, with reference to their own desktop.

Code

Single-key menu shortcuts with Qt 5 on OS/X

Chris Cannam

Several of my Qt-based applications, including Sonic Visualiser and Tony, have some menu actions attached to single-key shortcuts without a modifier key. Examples include the Space bar to start and stop playback, or the “f” key (without Ctrl, Alt or any other modifier) for zoom-to-fit.

While testing the update from Qt 4 to Qt 5.1 we found that some of these shortcuts were no longer working on the Mac, though they still worked on other platforms. Hoping this would be fixed in a Qt update, I decided to stick with Qt 4 for the official Mac builds of Sonic Visualiser for the time being. As of Qt 5.3.0, though, the problem still wasn’t fixed and I decided I couldn’t avoid it any longer.

After some digging (documented in this issue tracker) I think I understand the cause and have a workaround, although I don’t know how to fix it properly in Qt. Here’s the summary as I understand it:

  • Qt on OS/X does not (in general) handle menu shortcuts itself. It creates a native Cocoa menu and lets Cocoa’s Key Equivalents mechanism handle them.
  • Key Equivalents apparently do not work reliably for shortcuts without modifiers.
  • Before Qt 5.1, any menu shortcuts that Cocoa did not handle would drop through to Qt’s cross-platform layer and be handled as window-level shortcuts bound to a QAction instead. So the single-key shortcuts continued to work even though Cocoa didn’t handle them itself.
  • This broke in Qt 5.1 because of this commit which was applied to fix this crashing bug. The problem was that some menus that should have been inactive (because a modal dialog was overriding them) could still be activated erroneously from the keyboard through this fallback shortcut mechanism.
  • There is an open Qt bug about the single-key shortcut problem and it contains a partial workaround.

So there’s a workaround in that last bug tracker, which binds each of the menu actions to a separate, global, application-level shortcut instead:

foreach (QAction *a, menu->actions()) {
    QObject::connect(new QShortcut(a->shortcut(), a->parentWidget()),
                     SIGNAL(activated()), a, SLOT(trigger()));
}

This works as far as it goes, but it doesn’t check the action’s enabled status (and nor does the action’s trigger slot) so it’s possible to use this to invoke an action that is supposed to be disabled.

I ended up using a more complicated workaround, which you can find here. The code is basically as follows:

void MainWindow::finaliseMenu(QMenu *menu)
{
    QSignalMapper *mapper = new QSignalMapper(this);

    connect(mapper, SIGNAL(mapped(QObject *)),
            this, SLOT(menuActionMapperInvoked(QObject *)));

    foreach (QAction *a, menu->actions()) {
        QKeySequence sc = a->shortcut();
        if (sc.count() == 1 && !(sc[0] & Qt::KeyboardModifierMask)) {
            QShortcut *newSc = new QShortcut(sc, a->parentWidget());
            QObject::connect(newSc, SIGNAL(activated()), mapper, SLOT(map()));
            mapper->setMapping(newSc, a);
            a->setShortcut(QKeySequence());
        }
    }
}

void MainWindow::menuActionMapperInvoked(QObject *o)
{
    QAction *a = qobject_cast<QAction *>(o);
    if (a && a->isEnabled()) {
        a->trigger();
    }
}

I then call finaliseMenu on each of the menus returned by findChildren<QMenu *> from the main window’s menuBar() object.

There may be a simpler way: let me know if you can see one.

 

Computers · Computers That Are Telephones · Opinions

What laptop, tablet, or smartphone to buy? It’s a complicated business

Chris Cannam1 Comment

My Dad asked me recently what sort of computer he should buy to replace his ten-year-old HP laptop. And what sort of phone should he get to replace his old Nokia? And while I was at it, should he get one of those tablet things?

There are a lot of possible options at the moment, because all kinds of devices from smartphones to traditional PCs have become broadly capable of doing the same work, and because a whole raft of new Windows 8 laptops and convertibles have just arrived to clutter up the shelves.

Therefore I’d suggest mostly ignoring the nominal capability and specs of any device, and considering instead how it feels to hold and operate and what ecosystem it is part of.

Let me explain, and then give some more concrete advice.

Ecosystems

This slightly absurd term describes a set of services and systems that work together, many of which are likely to have been provided by the company that made the device’s operating system.

Increasingly, when you buy a device, you are making a decision to participate in its maker’s ecosystem: it will make your life easiest if you are prepared to use backup, file and photo sharing, music download, email, mapping, browsing, app installation, and other services all from the same supplier.

For example, if you buy an Android device, you’ll be most content if you also use Google mail, maps, marketplace, etc. Buy a Mac or an iPhone, and you’ll have the happiest time if you use Apple services wherever they exist. Windows 8 and Windows Phone expect you to have a Microsoft account and to use it. If you have two devices, say a laptop and a phone, they’ll get on best if they’re both within the same ecosystem as well.

You can make a conscious decision to mix and match—I do that myself, somewhat, because it pains me to side with any one megacorporation more than I have to—but it can be heavy going. If the idea of understanding what you’re doing and why you’re doing it appeals to you more than having an easy life, then install Linux and subscribe to no single ecosystem; I’ll be happy to help out. But I’m guessing you don’t really want to do that.

So no, the usual thing seems to be to decide which company you dislike least, then let that one have your credit card details and as much goodwill as you can muster. And that means picking one of: Apple (with OS/X and iPhone/iPad), Google (with Android), or Microsoft (with Windows and Windows Phone).

“Feel”

Modern computing devices, from smartphones to PCs, are increasingly touch-driven (either through a multi-touch touchpad or a touchscreen), portable, and versatile. The way you hold and interact with them does matter.

I’d strongly suggest you start by trying out the best devices you can find from each ecosystem, hands-on, either by borrowing from a friend or in a very relaxed shop. Decide which one you enjoy the basic interactions with the most.

If the design, interaction and animation (and materials and heft, for specific devices) please you every time you pick it up, you’re probably going to be happy with it. If they annoy you, you’re not. If it’s ugly and inconvenient now, it’ll be ugly and inconvenient in five years’ time.

The options

These are the things you can buy at the moment.

Laptops you know. They run either Windows (if PCs) or OS/X (if Macs). Some of the Windows 8 ones now have touchscreens, but not all of them (and nor do any of the Macs).

Tablets such as Apple’s iPad, the Google/Samsung Nexus 10, or the Microsoft Surface are slatelike touchscreen devices in which a separate keyboard is strictly optional (there is a “virtual” one on the screen). They typically run one program at a time, full-screen, rather than having multiple separate windows side by side, and the programs are redesigned for touch rather than mouse operation (the buttons are bigger and they have fewer menus, for example). All software is installed from a central “app store” run by the operating system manufacturer.

Smartphones are small tablets that can make phone calls. Most mobile phones nowadays are smartphones.

Things to bear in mind

A modern smartphone is a computer. It can do practically anything, but it’s sometimes fiddly because of the small size, and it has amazingly awful battery life compared with a classic mobile phone—be prepared to charge it every day. If you buy a nice new phone and make use of it as a handheld computer, you’ll probably find you use your laptop less.

Tablets overlap with both smartphones and laptops. If you have a smartphone, the laptop or tablet is likely to take jobs like “reading long documents, and doing anything that needs a lot of typing”. Don’t buy both a tablet and a laptop, just make sure whatever you get has a good clear screen and you can stand it up on a desk and type with it.

Asus Transformer

Proper keyboards are available for every kind of tablet: you can always get something you can either plug in or attach wirelessly. But convertible tablets (with a keyboard stand included, like the Asus Transformer, right) are nice too. They’re very like laptops to use and can be folded up and packed away the same way, but you can also pull off the screen and sit on the sofa with it. Most run Android.

There are also small tablets, but… While the iPad, Nexus 10, Transformer series, and Surface are in the 10-11″ diagonal range, there are also several in the 7-8″ range like the iPad Mini or Nexus 7. The small ones are natty and better for carrying around, but less good for sofa-surfing and can’t really replace a laptop.

If you’re buying an Android device, look for Android 4 or newer and get a Google Nexus if you can. They sell a phone (the Nexus 4), a small tablet (Nexus 7) and a big tablet (Nexus 10) and they’re all pretty good. Being Google’s “own” devices, they have good compatibility and more updates. You can’t generally get them through mobile network contracts though.

Don’t buy an Amazon tablet. The Kindle Fire series are really designed for only one thing: consuming content from Amazon.

If you’re buying a Windows 8 laptop, get one with a touchscreen. Windows 8 makes very little sense without a touchscreen. You can still use a mouse as well.

Windows 8 is extra-confusing because of the existence of both Windows 8 and “Windows RT”. These are essentially the same, except that Windows RT can’t run any “legacy” Windows software apart from Microsoft Office: it only runs touch-optimised full-screen apps from the Windows app store, of which there are not all that many available yet. Windows RT is found on tablets and some laptops. It’s a perfectly capable operating system, but there’s a big risk of disappointment if you want to run arbitrary Windows applications from around the internet and discover too late that you can’t.

So the range of applications available matters, but it’s not the be-all and end-all. Off the top of my head: Apple’s iPhone has the most apps, then Android phones, then the iPad, then desktop operating systems (Windows, OS/X), then Android tablets, and in last place Windows Phone and Windows RT. Numerically the difference from first to last pretty big, but it can be oversold: in practice you won’t find many things you can’t do, nor run out of new stuff to try out, on any of them.

You can safely ignore any review in which the star rating appears to be correlated to how fast the computer’s processor is. That’s practically irrelevant nowadays. Do test how smoothly the screen scrolls and zooms though.

Don’t forget to check whether you use any software that absolutely must continue to run on whatever you replace your laptop with. In most cases, all you need is software that does the same sort of thing (it doesn’t have to be exactly the same software) but you don’t want to get caught out if there’s anything specific you rely on.

The whole mobile-network contract business is an extra layer or three of bafflement that I can’t really help with. I generally buy hardware unsubsidised and stick a pay-as-you-go SIM in it.

Some suggestions

Give each of the ecosystem contenders a test run, and then, from the options below, pick the phrase you most agree with and read that bit!

(Although by the time you’ve given each them a test run, you may well already know what you want. That would be a good outcome.)

I’m totally ignoring price here, although sadly the most interesting options almost always turn out rather expensive.

“I really like the way the Apple things work” Well, that was easy. If you’re dead set on having a laptop or you want as much flexibility and control as possible, then you want a MacBook Air (probably the 13″ size, although the keyboard is just as titchy as the one in the 11″). Otherwise, get an iPad and forget about the laptop. Either way, buy the laptop or tablet first, then think about phones (the phone to get is obviously an iPhone, it’s just a question of which one and that basically comes down to price).

“Windows 8 and Windows Phone appeal to me, and I don’t think of Microsoft as an objectionable enemy” You’d probably find a Windows Phone 8 phone (any one, though the Nokia Lumia 920 has the most lovely screen) and a touchscreen Windows 8 laptop a good combination. Look at the Lenovo Yoga 13, which is a fine laptop that I predict will sell half-a-dozen at best because of the weird way it’s being displayed on a stand in the shops (the screen flips back to make it resemble a large and heavy tablet, but it’s really a laptop). Or consider the Samsung Series 5 Touch laptop or possibly the ATIV SmartPC convertible. Although Microsoft’s Surface RT is a beautiful object that I’d like to recommend, it isn’t yet quite the laptop replacement it thinks it is. There’s a Pro version due out in a few weeks that might be worth a look, though.

“I use a few Google services already, and I’ve tried at least one Android device I thought was nice to use” An Android tablet convertible like the Asus Transformer series can in principle replace a laptop quite well. Try one out, but if you’re thinking “hm, maybe Android might work” it’s probably cheaper to give it a go with a phone first. Google’s Nexus 4 is the obvious choice if you can find one.

“Those touchscreen laptops and tablets are all a bit small, I like my bigger PC” There are some reasonable touchscreen laptops with somewhat larger screens, including several from HP like the Envy TouchSmart 14. I hesitate to recommend one because I’ve actually never seriously used Windows 8 with a touchscreen on a larger screen. It might be a bit tiring. Do try it though.

“This is still all too complicated” Then stick with what you’ve got. The new Windows 8 machines have only just come out, and everything will look a bit simpler in six months’ time when the disasters have subsided and the new-fangled things have got cheaper.

What would I do?

If: money was no object; I had no corporate loyalty and lacked my affection for open Unix-type systems; I wanted to be able to do anything except programming; I didn’t have a laptop, tablet or smartphone already; and I didn’t mind if my phone was too big to fit in a small pocket… I’d buy a Nokia Lumia 920 and a Lenovo Yoga 13.

That’s because I like the Windows 8 look and feel, the different Windows 8 devices work well together, and both of these are attractive well-made objects that are a pleasure to use. I’d pick the Nokia over the otherwise excellent HTC 8X because of its better screen and camera and the inclusion of Nokia maps with navigation.

But in real life, I couldn’t afford that. If I wanted to keep the price down a bit and avoid being too locked in to any one ecosystem, I’d look at a Samsung Series 5 touchscreen laptop and a second-hand unlocked Google Nexus S phone from eBay. But I would go and have a play with a Surface RT tablet in John Lewis first, just in case. It’s a nicer physical object, for all its limitations.

And if money was the object—if it was the main thing that mattered, but the other conditions were the same—I might buy the entry-level full-size iPad and nothing else. It’s much cheaper than a touchscreen laptop and has a lot of software. I don’t really go for the visual design, but it’s cheaper than the alternatives I do really like, the basic interaction and feel are fine, and having all those apps available counts for a lot.

Of course, being a typical human creature I’d really do none of the above. I’d just buy whatever I happened to like the look of on the day and rationalise it afterwards. I trust you’ll do the same!

Academics · Code · Flat Things

Can you develop research software on an iPad?

Chris Cannam

I’ve just written up a blog article for the Software Sustainability Institute about research software development in a “post-PC” world. (Also available on my project’s own site.)

Apart from using the terms “post-PC”, “touch tablet”, “app store”, and “cloud” a disgracefully large number of times, this article sets out a problem that’s been puzzling me for a while.

We’re increasingly trying to use, for everyday computing, devices that are locked down to very limited software distribution channels. They’re locked down to a degree that would have seemed incomprehensible to many developers ten or twenty years ago. Over time, these devices are more and more going to replace PCs as the public idea of what represents a normal computer. As this happens, where will we find scientific software development and the ideals of open publication and software reuse?

I recognise that not all “post-PC” devices (there we go again) have the same terms for software distribution, and that Android in particular is more open than others. (A commenter on Twitter has already pointed out another advantage of Google’s store that I had overlooked in the article.) The “openness” of Android has been widely criticised, but I do believe that its openness in this respect is important; it matters.

Perhaps the answer, then—at least the principled answer—to the question of how to use these devices in research software development is: bin the iPad; use something more open.

But I didn’t set out to make that point, except by implication, because I’m afraid it simply won’t persuade many people. In the audio and music field I work in, Apple already provide the predominant platform across all sizes of device. If there’s one thing I do believe about this technology cycle, it’s that people choose their platform first based on appeal and evident convenience, and then afterwards wonder what else they can do with it. And that’s not wrong. The trick is how to ensure that it is possible to do something with it, and preferably something that can be shared, published, and reused. How to subvert the system, in the name of science.

Any interesting schemes out there?