Microsoft to Add Trackpad Support to Word, Excel, and PowerPoint Apps on iPad

This may finally make Excel and PowerPoint usable on the iPad.

Exactly. So Apple made this thing but instead of it working for apps through the OS, the developers have to add the functionality on a per app. Another reason to avoid the $300-$350 Keyboard.

And how is exactly is it going to work perfectly in all apps that were never designed for it? If they added touch to MacOS, would it suddenly work perfectly in all apps that only expected a mouse pointer?

It generally works, but apps are going to need updates, especially if they aren't using Apple's standard text fields and controls (and something tells me Microsoft Office is in that category).

Aren't these OS level changes that work on all apps? Why would they have to add support for them?

If the developer uses standard controls, everything works. The more the developer creates custom controls (like say, the Ribbon), the more you then have to do yourself.

My trackpad works with the Office apps. It doesn’t properly support things like the I-Beam in a Word document. There are bugs with the Ribbon where it doesn’t always recognize the tap (like the other poster reports), and there’s no animation on the buttons in the Ribbon. I think they might be doing a lot of custom UI and in the process made the automatic stuff Apple provides not work. And I’m not sure how much choice you have when talking about the document view.

Another annoying bug is that there’s some stuff around making selection touch-friendly that Word seems to do that other apps don’t (tapping will try to put the cursor at the front or end of a word), which still happens with mouse input, and is just plain annoying.

By the fall, really?

I wonder if it is “by the start” or “by the end”. Huge difference there.

I hope they finally add the full versions of the Office apps to the iPad, it’s the right moment to do that

It is reasonable to think that, but no. Since iOS (and iPad OS) is, from the very beginning and continues to be, a smartphone OS, Apple relies on app developers to include support for what is typically OS-level functionality found on traditional operating systems.

Things like clipboard support, background processing, multi-window, etc.have to be included by the app developers. This is why features like multi-window are of limited value for some because not all apps support it. The larger the iPad the more frustrating it is.

Your examples aren’t great examples of “OS-level functionality” to begin with. They are more examples (minus clipboard) where iOS takes on more functionality at the OS level, rather than just leaving it up to developers to do it like on the desktop.

Clipboard support has always been something developers have to integrate with, even on macOS, if they aren’t using standard text controls which integrated by default. Win32 and Carbon (remember that?) devs had it worse, although WPF/.NET folks might/should have it about the same.

Multi-window created a bunch of work because devs assumed they were working in a single window environment, and tied a bunch of UI state to singletons or their AppDelegate. So now they have to go fix all their bad decisions. New projects get the new delegation model for multi-window by default, meaning they will instead tie all their state to the SceneDelegate instead of the AppDelegate, unless the dev actively sabotages themselves. The irony here is that I remember some of the cruft floating around from the desktop when that started going multi-window on the PC side, back when Windows used to give an app a single window. A lot of the same bad decisions were made then too, and had to be fixed, as with iOS. I’ve worked on projects that have code that dates back that far, and seen the things they did to support multiple windows. History repeating, sadly. But one key difference here between desktop and iOS is that on desktop, the app effectively manages the windows. iOS takes on more responsibility for window management than AppKit.

Backgrounding on desktop wasn’t so much an OS level feature, but a side effect of not having any care around battery management when a lot of the stuff was written. And desktops not having the memory/power to spare on process management like the mainframes of the time would. Because you didn’t have battery-powered computers when it was all designed. iOS can behave like macOS here if Apple wanted, the behavior of forcing backgrounded processes to be idle was bolted onto the normal process management Darwin uses. Making apps white-list their background behavior is new, but I’m not sure accounts for “putting the onus on the developer” beyond the fact that they should probably be thinking about how they use battery in the background instead of just spinning up threads and hoping for the best. It would have been nicer if the API for it was a little more general-purpose, I’ll agree to that.

It would work perfectly in all apps if iOS were designed properly. Android has had full and global support for mice and trackpads for many years. Android apps don't need to be "aware" of the presence of a mouse. That is handled by the OS.

When a mouse is detected, Android displays a mouse pointer. But when it is not, no mouse pointer. It's seamless.

I find it odd that people look at what Apple is doing with mouse support in iOS as if no other mobile OS provided mouse support before.

I find it funny you suggest that iOS wasn’t designed properly here. It is very similar to the Android model, but it also builds in the AppleTV-like animations which are new and I-Beam support as an OS-level feature rather than something the app developers have to implement like on the desktop. The problem is more that the OS also lets you hang yourself if you choose to. If I create my own button class instead of subclassing UIButton, it means I lose out on anything Apple does with UIButton (Reeder). Using UITextInput instead of UITextField means I’m now responsible for interacting correctly to enable the I-Beam (Office maybe?). Using a custom view with custom gestures instead of a scroll view means I’m now responsible for making sure all gestures are handled in my new custom view (Reeder again).

I’m not really sure I’d blame Apple for people doing this stuff. The apps getting bitten are the ones pushing the boundaries of UI on the platform, and building up controls/views from scratch to do it (which is generally a bad practice, but done anyways for various reasons). By doing that, they are taking on more responsibility themselves, and as a result, are more likely to be caught off guard when Apple does add new functionality to the platform.

And really, mouse input to an app is mostly indistinguishable from touch or Pencil. It mostly boils down to the UITouchType on the touch event. Most apps shouldn’t be messing with UITouchType, or having special behavior based on it. If they are, that’s where bugs can come into play where the mouse can’t click on things.

Office 365 users: You're going to make us wait until the fall?! Get it together Microsoft!

GSuite users: Wow, multi-window in beta, and cursor support by this fall? That sounds amazing...