ARM

Katherine as always gets to the core of the matter – Apple’s tight partnership between hardware and software, plus willingness to sunset backwards compatibility, gives them much tighter control over how easy these kind of platform migrations can be.

There are some kinds of apps that developers might not choose to port to ARM, however. In general, if you aren’t relying on the standard system libraries but have a lot of time and effort sunk into optimized code for specific purposes, that may take a bit more work. If your customers are regularly using workloads with your application that are pushing the limits of performance on existing Intel-based Macs, well, those may not be a good fit for ARM systems and the developer may not wish to open themselves up to the support tickets that would result in users not following sizing guidelines and overloading new hardware.

Those are the two most obvious cases I can think of. In general, though, most apps from my understanding are coded using Apple’s frameworks and would work very hard to tax the system through normal use (absent bugs in the framework that cause memory leaks or other resource contention), so for most developers, I would suspect it won’t be a huge issue. When the new version of the programming toolkits come out, there’s always a process where devs need to review their code and clean up the use of deprecated APIs, see if they can take advantage of new features for existing code, etc. – and if Apple pulls Intel-to-ARM as smoothly as they did Power-to-Intel, I suspect there’s going to be as little ripple. Some will be the front-line devs who find the bugs in the new ARM libraries, others will lag behind a bit, but in the end, most everyone will get there.

Many thanks, both.

Over the years, Keith has mentioned coding around Apple bugs / limitations, but on the whole, the expectation is that Intel-Scrivener should compile to Arm-Scrivener more or less as it is now? Fabulous if that is the case.

I think things are a little different now to when Apple transitioned to Intel: they already have a lot of experience with Arm chips, and they have a huge instal base of Arm-based iOS devices. I assume all of that experience will speed any transition up this time around.

Really grateful for the insight you have both shared.

Apparently re-compiling may not even be necessary:

highcaffeinecontent.com/blo … ng-Bitcode

Trying to get my head around why any software company would develop two distinct versions of an app now that Apple has a platform for running one app on sibling OSes that dance and cavort on essentially the same silicon.

Not saying that is what is going to happen with Scrivener. Just mighty interested to see how things pan out now that the Arm path has been cut and Intel’s arm into the world of Apple has finally been severed.

And we can run iOS apps on Big Sur. Drooling at that thought, especially for iOS Scrivener (assuming it will be available).

Because the app for iPad and iPhone is substantially less capable than the MacOS app. That’s the only reason needed.

And THAT is directly a result of Apple’s not making sure the toolkits and system calls that are available in each OS are on par. But if they were doing that, they’d essentially have a unified OS…which potentially the move of MacOS to ARM make more viable for the future.

I mean, sure, if I were just now sitting down to start an application, I’d do my best to make sure it shared as much code between the platforms as possible. Absent any critical limitations in the frameworks and toolchains, that would make a bunch of sense. But for existing applications which are tied very deeply into nooks and crannies of MacOS that current and near-future versions of iOS/iPadOS just don’t support…that’s a lot of retooling that takes significant time away from fixing current bugs, adding requested features, and generally having your devs do things that make existing customers happy and willing to spend money. And that kind of rewriting will guaranteed open up new bugs in existing stable functionality, causing annoying and painful regressions.

Which they have had for less than 24 hours. Keith’s copy of the developer tools probably hasn’t even finished downloading yet, plus it’s the middle of the night in the UK. So it’s probably a little premature to speculate on What This Means for Scrivener.

Katherine

Never too early to think. And be excited, of course, especially when such a large part of my life is lived working with Scrivener.

:smiley:

And devinganger, was there ever a more propitious time than now, when Apple is clear about the notion of universal apps and has just announced changes that it sees as being historic?

Would appear to be a lot more work to hold on to the past with two distinct apps [emphasis on distinct] rather than to embrace the future with one core app. And that’s for any developer, I would have thought.

And isn’t that really what this is about: making it easy for Apple users to use their apps everywhere, without having to make major shifts to know how any app works on different OSes?

Apple has not been clear about universal apps. What they have said is that iOS apps will run on 11.0. On Apple Silicon. They haven’t suggested that is the way for everyone to go.

For some apps, messages for instance, where there is a narrow functionality, limited memory requirement, yes. For some developers that adds a whole extra market.

For complex apps such as Scrivener and FCP, and a whole raft of others, no.

Don’t read more into it than was said.

I really wish Apple did a better job at communicating the differences between iOS and macOS. Unfortunately, I think they’re often so keen to promote the iPad as a potential laptop replacement that they don’t always push just how much more advanced the macOS frameworks are in many areas - including those that are most relevant to Scrivener.

Rest assured that Apple isn’t moving over to a whole new architecture for the Mac just so you can run iOS apps on your MacBook, though! Just take a look at Apple’s own apps. They fall into three categories:

  1. Apps such as Maps and Messages, which are essentially the same on iOS and macOS, allowing for differences in touch vs regular UI. Such apps can be built with Catalyst - that is, built to work on iOS and then converted to work on macOS. This approach is best for apps with a fairly simple UI that doesn’t need to change much between platforms (which doesn’t mean the underlying code base is simple, of course).

  2. Apps such as Mail and Pages, which are very similar across iOS and macOS but don’t quite have all of the same features, and which are clearly custom-built for each platform since they require different UIs. (For instance, Mail uses an outline view sidebar on macOS, a control that is not available on iOS; on iOS you use drill-down tables instead.) Such apps probably share around two-thirds of the same code but then have specific code for the UI. This approach is best for more complex cross-platform apps that would feel very clumsy on macOS if they just used a translated iOS UI.

  3. Apps such as Xcode and, currently, Final Cut Pro - pro power apps that still aren’t suited to iOS at all. There’s a good reason apps such as Xcode are not found on iOS - they require either complex UIs or power that is simply isn’t achievable in iOS, even today. Imagine having a side bar, an inspector, four editor panes and a bottom pane showing debugging information (as can be found in Xcode) even on an iPad Pro - it’s just not possible, let alone desirable.

So, to answer your implied question, iOS would have to evolve enormously for (1) to be possible for all apps. For one thing, presently TextKit on iOS is a mere shadow of TextKit on macOS, so any Catalyist app is going to have a limited text system. But even if that were not the case, (1) is not a model suited to an app like Scrivener, unless you were happy to forsake all of the macOS version’s power and have only the features available in the iOS version on the Mac. (Perhaps you are; most of our users wouldn’t be, though.)

Right now, Scrivener for macOS falls under category (3). One of the ideas behind Scrivener when I first created it many moons ago was that it would be a sort of “Xcode for writers”. There’s a whole swathe of stuff in Scrivener that just could not be translated to iOS - if Scrivener were to remain as it is, and keep the features it has.

It won’t. It would make zero sense to allow our iOS version to run on the Mac when we have a full-featured macOS version available.

Indeed. Supposing I were starting from scratch today, (2) above would be the route forward. A shared framework of code that handles all of the core functions, data and outline manipulation across platforms, with a UI custom-built for each platform rather than using shared UI code. Such an app would also need to eschew a lot of features that would not work well across platforms, too, radically simplifying in the same way Pages or Ulysses did a few years ago.

There’s a lot to think about, but we’re not twiddling our thumbs behind the scenes even if we don’t have anything to announce any time soon. Unfortunately, though, no matter which way we go, we’re bound to make some users unhappy.

Indeed there is a lot to cogitate over — given the very wide base of users you have I suspect it will be almost impossible to please all of them which ever route you take down the road. If you rewrote Scrivener to become something like (2), you would probably open up a set of potential new features at the expense of breaking lots of existing workflows. For that it sounds like you would have to drop TextKit as a minimum, and I wonder if there is another flexible edit engine[1] that could replace it without a huge heap of work?


[1] well there is, because Apple Pages works across platforms and even online, allowing syncing and collaboration in a way TextKit cannot. But instead of opening it up it closes the walls and consigns pages to forever be a bit player in an important domain.

It wouldn’t necessarily be a matter of dropping TextKit, which for all of its shortcomings is still incredibly versatile, but using it differently. Right now we really just build on TextKit’s RTF features. There are other ways of using it, different approaches you could take to harnessing its formatting features.

As for Pages - yes, it is a shame that Apple hasn’t carried some of their text system advances made in their apps across to the frameworks. Even Notes has much better tables than TextEdit and TextKit.

All the best,
Keith

So, one day after Apple announces its migration to ARM-based Mac’s, we expect Keith to communicate his Scrivener development strategy. We are a tough user group.

Well yes we are a curious, discursive and passionate bunch, but so I hope KB doesn’t mind us speculating on what is a momentous set of changes that are coming to macOS users and the impact this will have on Scrivener into the future…

Well, we are a little disappointed that Keith didn’t have the new ARM code fully developed and available for purchase before Apple announced it or made the tools available. Nothing if not a demanding bunch… 8)

I’m actually a little surprised that we don’t have a “Big Sur compatibility bug” post yet.

Katherine

Methinks you might have spoken too soon

:laughing:

Mark

No-I was very tongue in cheek lamenting Keith had not released scrivener for arm already. :laughing:

This written with pencil on iOS 14 Scribble has a way to go but is very useable already

Of course not - I enjoy the speculation, even though I can’t give any definite news yet because it’s early days.

You may have been tongue in cheek, but no doubt others will shortly pick it up and run with it!

:slight_smile:

Mark