Essays/iOS Fitness For J

Nobody would commend the iPhone, or even the iPad, as an ideal platform for a pro IDE. Both devices have been designed for the user to consume content, not produce it. Given the unavoidable limits to both its size and energy usage it's no surprise that the iPhone is a cramped and crippled medium for doing anything clever with text, let alone supporting a fully-featured J IDE.

As for the iPad, although it is bigger and has a pretty screen, with high definition, its text presentation capacity is back in the 1970s. Think: IBM 3279 Color Display Terminal with GDDM if you can remember it. A marvel in its time.

A frequent user of macOS on a recent Mac will find the iOS ux (user experience) to be significantly inferior, in just about any task except playing games. The architects of iOS must be painfully aware of this, and have abandoned all but lip-service to making it less user-hostile and instead have concentrated on making it beautiful.

But beauty is only skin-deep. iOS isn't merely user-hostile: it is developer-hostile.

With J it is hard to tell the difference between a user and a developer. Most J coders write programs for themselves. This takes a variety of forms, but rarely can the result be mistaken for a commercial app. There are few apps on the market written in J which don't proclaim the fact. (But perhaps that is true of Python users too.) The users of a J "app" (typically distributed as a J addon) naturally expect the full facilities of a J IDE to come free with the app. The J IDE itself is open-source, and a lot of experienced J-ers are familiar with the code of JE (the J Engine). Many have even tinkered with it to modify the behavior of JE itself.

All this has to be borne in mind when we contemplate the idea of being able to type with one forefinger(!):

   1+1
2

Thus to maintain that iOS is developer-hostile is to invite disbelief from a J-er. But it warns you that attempting anything more elaborate in J will sooner or later run into trouble.

Apple promises (even if doesn't guarantee) to protect you, the iOS user, against malware. To give substance to this assurance, iOS is a locked-down, buttoned-up environment. The protection this affords against the unwitting injection of trojans is Apple's USP (Unique Selling Point) – the Crown Jewels of iOS.

But the resultant stifling system of security measures defeats all but the most creative approaches to providing user-assistance. J-ers are used to having complete control over the individual files forming and supporting the J IDE, a freedom which the iOS architects struggle to deny you.

iOS is built on top of Darwin, a properly accredited Unix system – and in Unix everything is notionally a file. But in the iOS environment, files – if they are supported at all – are a concession to heritage software ported to the platform. The app's files are "jailed" in a special container owned by the app (think: drive) called the Sandbox. Files are, after all, the chief vehicles for trojans. Especially dylibs (dynamic libraries, think: DLL).

Each dylib associated with an app requires its own certificate, issued by App Store after strict review, and automatically invalidated if the dylib is updated or modified in any way. That being so, monolithic binaries are the rule. Gone is the feasibility of downloading a dylib to update the JE in the J IDE. Instead the entire app must be re-submitted to App Store for review.

Thus iOS doesn't like files in any form, and would much prefer the developer to use something else: a monolithic app binary employing internal arrays, plus private and public proprietary data bases implemented in iCloud, to store data and share it with other users. General-purpose file transport mechanisms are festooned with intricate systems of permissions, authorizations, capabilities etc which proliferate with every release. The liberty of an email attachment (something still possible for the ingenious user) has largely given way to a kluge of import- and export- buttons which open a proprietary channel to another user identified by the all-purpose Apple ID.

Photos is a flagship example: your photo album doesn't exist as a (Unix) folder of PNGs or JPEGs, but in an iCloud data base (not to be confused with iCloud Drive, Apple's dropbox lookalike) and at no stage in showing a friend your holiday snaps does a JPEG change hands.

There's an analogy here with hot meals on an airliner: they are anything but the traditional relaxing convivial experience they stand in for. The diner must unpack and eat from sealed plastic microwaveable tableware, and use plastic knives and forks incapable of inflicting damage in malicious hands. Considerable ingenuity has clearly been expended on mocking-up the flavours and appearance of a Western mealtime, as indeed it has on meals for astronauts, but the ux has been devastated. Some might even be grateful for a transfusion of vitamins and nutrients rather than the pale shadow (or arguably the coarse parody) of an earthly dinner. There is of course no scope to bring your own fresh food and have the airline staff cook it up for you.

Such is the iOS experience for anyone trained in IT in the 20th century, whether as a user or a developer.

Coming from macOS, how will iOS and its chicken-farm of apps strike you in detail?

• There is no "hover" - therefore no hints as we know them.
• There is no mouse. Use your fingers. Older users will find their fingers too dry to interact with the screen reliably. Lick them and wipe them on your lapel. For the fastidious, the Apple Pencil helps enormously (at a price).
• There are no overlapping windows you can drag around with the mouse, expand or minimize. So you're back to navigating between screens like an old VDU, either by you locating the right menu and successfully picking from it, or at the app's discretion, which confuses and unsettles the new user.
• The (jqt) Term window has been renamed the Home Scene, to get you back fast to something familiar.
• The Mac has an onscreen keyboard, but nobody uses it because there are better ways of entering text. With iOS you are forced to use it (if you lack a bluetooth keyboard) but its ux is no improvement on the Mac's. Those smart young iOS jocks have come up with all sorts of clever tricks to distract you from the pain, including speech-to-text (courtesy of SIRI) – but the plethora of tricks warns you it's beyond redemption. A bluetooth keyboard will set you back $10 or so, but it improves your ux wonderfully. You'll then have most of the familiar hotkeys, not to mention finding all the ascii you need for typing J. And you'll never need to tap the screen again (…yes, the arrow keys work).

Without a doubt the iOS jocks will encourage you not to give up on the platform, but to persevere. People, they'll tell you, get used to anything. In six months' time you'll wonder why you ever had any problems with iOS.

The wonder is not that an iOS version of a J IDE opens up a new world of J experience (except in the wry sense). The wonder is that it's done at all.