It has thus far proven impossible to port a full-featured complex professional app such as Photoshop, Excel, Premiere, etc. to a mobile device using the mobile UI. If anybody had the incentive to do this, it was Microsoft. The initial purpose of the "Metro/Modern" interface was to take over desktop development, not supplement it.
It will probably never be done on anything like the current iOS or Windows mobile platforms. A full-featured pro app like Photoshop or Excel has *hundreds* of menu options spread across various UI constructs -- multilayer fly out menus, pop-up menus, pick lists, large scrolling panes full of sliders, twirl-down arrows, preview thumbnails, etc.
You cannot access the full functionality of the product without these. It is not a matter of re-imagining the UI -- each current UI element must map to some simplified mobile UI element. But there is no place to put it all. The mobile UI is simply not designed to support that. Mobile devices also lack the richness and complexity of UI constructs to handle it. The UI "widgets" just aren't there for the developer to use.
Except, you can make those accessible, and while the OS may not provide the widget for it, you can always build your own. In fact, talking about Photoshop, Excel and Premiere, an awful lot of it is custom widgets. Neither Windows or Mac has a "Ribbon" control, for example, but Excel uses it. Hell, when all three of these were first being built (think 80s and 90s), the expectation in many cases was that if you wanted to do anything fancy, you were on your own. So you will actually see a lot of this stuff built up using a lot of custom UI code anyhow. And I'd be surprised if a lot of it has changed, since rewriting the code comes with a cost.
But I've worked with iOS enough to know that you can build out custom UI without breaking the model of how iOS handles drawing and input as the model is very similar to AppKit, and in some ways is cleaner to work with than AppKit since it lacks the legacy of OS X pre-Core Animation. But custom UI is not cheap. It can take months to build something out. And that's on top of the time it takes just to bootstrap this stuff.
And when I think about reimagining the UI, I'm thinking more about how to effectively use the space on a small screen, and how to leverage gestures as contextual cues. Or even just better ways to integrate a hierarchal toolbar into the screen so that it doesn't dominate the content you are working on. Office seems to think the right approach is to keep the ribbon. I'm not sure it is enough on its own though, but it is a starting point.
You can definitely do a watered-down version on a mobile UI. Adobe initially did Photoshop Touch for iOS, which although not *remotely* equal to desktop Photoshop, at least had layers. It has been discontinued and the replacement Photoshop Express for iOS is much simpler still. So this rate of backward "progress" does not support the idea that mobile platforms will ever be able to run an app equivalent in functionality and UI richness to a complex desktop version.
Some future more sophisticated mobile platform with a more complex UI paradigm and richer UI constructs might achieve this, but it will be nothing like the iOS and Windows mobile platforms we are familiar with today.
Yet, if we want to use Excel as an example, it has been gaining features from the desktop over time, not shedding them. Some of this is companies trying to figure out what people want to actually do on tablets and the idea that these are still companion devices, rather than something someone wants to use in a full-featured way.
Honestly, I'm scratching my head on where Adobe is going with their stuff. It suggests more that they don't know where to take their iOS apps more than anything else. But hey, I can edit RAW on iOS now with Lightroom, and that's meant it is finally part of my photography workflow the way I wanted it to be. So it's not all muddled wandering.
But I don't think we need a "more modern" mobile platform to achieve this any more than you needed Windows to be anything other than a box of legos to do the same. But again, you have to have developers heading in the direction of richer apps (which the market data currently seems to point away from at the moment, yay?) and actually incentivized to invest the time and money required to deliver such a beast. There really isn't anything complex about the desktop paradigm, just that there's been 3 decades of work building up on that foundation that has given us what we have today, a lot of it coming from 3rd parties.
Honestly, if I wasn't tied to the company I work for at the moment, and money was no object, I'd be interested in pursuing the answers to the UI hurdles. But then I look at the size and scope of the multi-platform project I
do work on (with both desktop and mobile apps sharing the same codebase), and accept that it's well beyond the scope of what one person can contribute on their own.
Re the underlying code, you're right that is probably less a problem but typical high-end desktop apps are highly multithreaded and make extensive use of many different low-level concurrency mechanisms: spinlocks, thread pools, mutexes, etc. Such apps can be ported between Windows and Mac since the underlying API infrastructure has similar capability at the lowest level. However it is unclear whether *current* mobile device operating systems can handle that -- either at all or without a total re-think of how the core algorithms map to the API surface.
I recommend reading up on this before making comments like this, since it exposes the gaps in your knowledge. If we want to talk about that, then I'll simply point out that those mechanisms, using Mac and iOS as the example, are identical between the two. GCD, which is your thread pool mechanism for Apple platforms has identical functionality in both places, you have your normal atomics in the OS API, and the usual pthread stuff works in both places if you really need to write some POSIX-level stuff to try to avoid rewriting it too heavily for other platforms. On Win Mobile, you have the usual .NET stuff, including modern techniques like async/await if that's your ball of wax.
I'd actually go so far to say there's more difficulty porting between Win and Mac than there is Mac and iOS. Why? Because the approach to how Microsoft and Apple build their APIs is drastically different and you have to build layers that account for both approaches. If you don't, you find yourself sacrificing one platform's abilities to support the other. If going between Mac and iOS, the biggest difference is UIKit vs AppKit, and you can even smooth some of those over if that's your goal.
And the irony here is that the more established these apps are, the less likely it is actually multithreaded well, due to legacy code from decades ago. Yet, you will actually do better on iOS if you can at least be running on two threads instead of just one.
The one area I can think of that is a hurdle is things like enforced entitlements on iOS. When your app was written in an era where you kinda expected to be able to read/write any file you want, and not expecting APIs to fail due to the user blocking your access, it can be somewhat expensive to work through the issues.