One of my tasks this week was to compile a set of instructions for emptying Safari’s caches, covering both macOS and iOS.

In macOS, the first step is to enable Safari’s Develop menu, which you do by opening its Preferences, selecting Advanced, and checking the box there. Once that menu appears, it includes the command Empty Caches, which you can select whenever you wish.

Only, as Phil Stokes of Sqwarq informs me, it doesn’t actually empty all Safari’s caches. To complete the job, you need to use a third-party app which can’t run in the sandbox so isn’t available through the App Store, or resort to Terminal’s command line.

In iOS, you don’t do this from within the Safari app, but in that jack-of-all-trades Settings. Tap your way through Safari > Advanced > Website Data > Remove All Website Data to reach your goal. Only once again it doesn’t actually remove all Safari’s data, but here you can’t see what it does leave behind, and can’t get at it using any third party tool.

It’s an interesting reflection of the many and deep differences between the practicalities of working in the two different operating systems. macOS remains firmly WIMP-based – windows, icons, menus, pointer – with menus still a dominant control in the human interface. iOS relies on tapping relatively large targets like tiles and rows in lists, so has to bury fine controls within deep list hierarchies.

This illustrates some of the fundamental issues that arise in Apple’s Marzipan, a development project in progress, which had been the subject of speculation before WWDC, and was exceptionally previewed there. For many developers, it seems to have been the highlight of the week, and continues to generate great excitement.

Some have speculated that we will see a new type of ‘fat’ binary app, with executable code for iOS and macOS wrapped up in the single app. Run it in macOS 10.15 and it is a native Mac app, or run it in iOS 13 and it is a native iOS app instead.

Apple demonstrated two Marzipanned apps which already form part of the Mojave beta: the new App Store app, and Apple News. From the demonstrations at WWDC, they look impressive, and perfectly usable on any regular Mac. They definitely aren’t ‘fake news’, but neither are they representative of a great number of Mac apps. And their human interfaces are considerably simpler than Apple’s longstanding cross-platform browser Safari.

The starting point for Marzipan seems very reasonable: macOS and iOS apps consist of rather different layers over a common core. Look at most of the features in macOS and iOS, apart from their interfaces, and you’ll notice that the great majority of system calls are common to both. Look at anything which is closer to the interface, though, and there is a gulf between AppKit and its relatives in macOS, and UIKit and its relatives in iOS.

As you go deeper below those, you reach common ground: for example, your app would use platform-specific UIKit/AppKit features to provide a front end to UserDefaults, which is cross-platform.

At present, there is nothing to stop a developer from recasting an app’s interface from UIKit to AppKit, or vice versa, apart from the work involved. If Marzipan is going to succeed in bringing apps from iOS to macOS, that will be determined by the amount of effort required to port the app’s interface, rather than the internal engine which that drives.

From the limited demonstrations of Mojave’s App Store and Apple News, the differences between the macOS and iOS versions are relatively small. More relevant to the assessment of Marzipan will be its performance with an app like Safari, where the current macOS version has much more sophisticated controls and features. It seems unlikely that Marzipan will ever be able to refactor a control such as emptying Safari’s caches from iOS to macOS without extensive intervention, or the creation of an unnatural hybrid interace on macOS.

Another issue which hasn’t been discussed, as far as I can see, is language support. Apple’s engineers now have a lot of experience in transforming Swift source code so that it complies with changes in newer versions of the language and its interfaces. Although Apple has been investing heavily in rewriting its own apps, and components of macOS and iOS, in Swift, a great deal of commercial development is still done in Objective-C. If Marzipan requires Swift source code, or simply more effort when working in Objective-C, then a lot of iOS apps will be locked out.

The dream that a developer will be able to write one set of code, and Xcode turns that into a fat binary which runs sweetly on iOS and macOS may have come a little closer. But for many iOS apps which could make good ports to macOS, I seriously doubt whether that is likely to happen next year.