Just wondered if Keith and his team have plans for a native ARM version in view of leaks about Apple’s forthcoming laptops.
And/or if I may add to your question, how much of their developing focus has been going to Scrivener iOS.
It hasn’t seen big feature-or design updates since its release in 2017.
The last year seems to have been important for the iPad:
- a separate name and focus of Apple, called iPadOS.
- advances in multitasking, including opening up multiple windows of the same app. Which I would love if Scrivener could adopt it. What if you could just open up the Binder in split screen, or the Inspector, or another project? Now, when working on iOS, you have to tap very much back and forth between synopses, notes, binder, etc. … Now, we only have the clunky ‘Open in Quick Look/View’ function, which I understood was a way of faking split screen in 2017, but now feels very limited.
- trackpad support which I think Apple nailed both aesthetically and functionally.
- rumors that Apple is preparing XCode, FCPX and Logic for the iPad Pro. Maybe in preparation for an ARM Mac, which rumors again say they are planning to release in 2021. Which probably means they will announce something about it at WWDC. (If you follow Final Cut Pro, there are also a couple of signs hinting at a big reveal in June which would fall together with WWDC)
Considering iOS is built on ARM, and the focus the iPad has been seeing from Apple with iPadOS (who would have thought we would get great trackpad/mouse support in the iOS-13 cycle already?), I hope Scrivener steps it up and gives a renewed focus at their iOS App. It’s a great app, but it seems like it has been on hold for a while.
I also understand you made this post in the MacOS forum, and my post is more towards their iOS version, but I do think we will see at WWDC, and with the rumors and the past iPad-related announcements, that these things are more and more intertwined with each other.
We remain committed to both Mac OS and iOS/iPadOS, and expect to support whatever Apple comes up with.
Beyond that, we do not comment on future versions.
I will say, however, that it is impossible to write functioning code for a rumor. No progress on a potential ARM version can occur until Apple has released appropriate developer tools.
Katherine
I would also point out that in the past, Apple has generally abstracted many of these issues for developers as much as possible – their dev kits take care of compiling the right kind of code to the selected target. I see no reason for them to somehow stop doing this.
With Apple’s Catalyst project and universal-purchase apps (let alone Arm Macs – if they are released, which I believe they will be), isn’t all development primarily heading towards Arm-based apps anyway?
Wouldn’t most users prefer a single purchase of a single app that largely works identically across devices without having to learn the quirks of using sibling apps on different OS platforms, especially if that app synched seamlessly through iCloud?
Had access to an iPad Pro for a few days recently and felt as though I had shunted back a decade when I returned to my MBP. The IPP is astonishingly capable and modern.
I’d be very happy to have an updated version of iOS / iPadOS Scrivener work on an Intel or Arm MacBook: one purchase of one app that worked everywhere.
Sure. But actually producing such a thing – particularly for a complex application like Scrivener – is not a trivial task.
Katherine
Absolutely agree with you about that.
Hoping that the existing iOS platform can be built on, as it already has such great foundations.
Though I’m super-interested in the rumored ARM-based 12-inch MacBook (see today’s headlines), my ability to purchase one will be 100% dependent on the availability of Scrivener (ARM) for macOS!
(This is a bit of a detour, but since I’m here… The iPad version of Scrivener is nice and polished. However the UI affordances—being necessarily finger-ready—are inherently large, which means I can see about ⅓ as much on the screen on my 11-inch iPad vs. my 12-inch MacBook. I’m not confident the iPad version will ever offer the UI density that the macOS version enjoys. If there’s any further UI convergence between Scrivener vs. Scrivener, I hope it’s toward the existing macOS version, and not the other direction.)
If Scrivener for Intel-macOS can run on Arm-macOS, all is good. But if it can’t run on Arm-macOS (without a substantial rewrite), what then?
If the switch to Arm is made, I expect this will be a time of significant opportunities for nimble developers to grab marketshare, in whatever field they specialise.
Must be hard for L&L to know where to focus. At the moment, efforts are being made to bring the Windows version of Scrivener into line with the Mac version. But what if the Mac version has to change significantly to run on Arm-macOS? Possibly back to square two for the Scrivener for Windows developers?
And then there are people who want iOS / iPadOS Scrivener updated, and calls for Scrivener on Linux and Android. And not to forget about Scapple…
I wonder what Scrivener’s most profitable (not necessarily its biggest) market is: Mac? Windows? iOS? (Not expecting L&L to disclose that information.) Wonder if there is ever a temptation to focus on a core market (like Ulysses does with MacOS and iOS / iPadOS) and to drop whichever part of the portfolio is least profitable. Presumably there is only so far that a small specialist company can stretch without significant upscaling (or refinement) being necessary.
Really looking forward to hearing what Apple announces on 22 June and if Scrivener for Mac as we know it will run on Arm-based Macs (if they really do materialise), and what will happen if we are about to be forcibly launched into a whole new era for Scrivener for Mac.
Y’all.
Apple has a good history of supporting multiple architectures under MacOS. They usually put out an updated version of the developer tools/framework that supports both the old chip architecture and the new chip architecture, so for most apps it is as simple as using the new version of the tools to compile either a unified binary or binaries for both the old chip and the new chip.
There are relatively few apps that need to make extensive changes to support a new chip architecture, as long as Apple does its job porting the full developer framework.
Then Apple will have made a tragic mistake, because all of the smaller developers who make the Mac OS ecosystem what it is will be facing the same situation.
I guess it’s possible for Apple to be that stupid, but I don’t think it’s likely.
As I said upthread, we remain committed to the Mac OS/iOS ecosystem, and expect to support whatever Apple comes up with. But we can’t write code for a rumor. No progress on an ARM-friendly Mac OS version of Scrivener can occur until Apple has actually released ARM development tools.
Katherine
Thanks, both.
Not expecting L&L or anyone to code to a rumour. Completely understand that.
Devinganger, when other people online talk about a possible switch to Arm, they keep going on about whether developers will make the effort to produce Arm-ready apps. If Apple makes the tools available, is there any reason why developers might choose not to compile for Arm? Or are people misreading or misinterpreting what is (possibly) happening? And if a change is relatively easy to accomplish, do you think Apple will switch over to Arm in one swoop, or start with one device and transition slowly? Would seem to make sense to make any change as swift and comprehensive as possible.
Thanks.
A little bit of history. Here’s the timeline for Apple’s transition from the Power PC to the Intel architecture:
en.wikipedia.org/wiki/Apple%27s … processors
It took a little over four years from the first product announcement to the first Intel-only version of Mac OS, two more years to drop support for the Rosetta emulator that allowed Power PC software to run on an Intel Mac.
Yes, of course developers will produce ARM-compatible versions. Once Apple announces the switch, they’ll have to either follow or abandon the platform. Exactly what that means is likely to depend on the specific application, the tools Apple makes available, and the specific hardware involved.
In general, though, the Apple world has always been different from the PC world: very limited number of hardware configurations, and a very strong emphasis on using the operating system tools rather than bypassing the operating system to work directly with the hardware. That layer of abstraction makes changing architectures much easier for developers than it otherwise might be.
Katherine
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.
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