[Ed. Note: This is a guest post by developer Steven Troughton-Smith. You can follow him on Twitter @stroughtonsmith.]
I don’t often do this, but this year I think it’s important; Apple is more open & receptive to feedback today than it ever has been. With iOS 9 and iPad Pro, iOS has made a tremendous leap in the past year on iPad. With that in mind, I wanted to note down all the things in my head that I really want to see the iOS computing platform grow to cover.
What follows is an unordered list of things I’d like to see from Apple over the next few years, starting with the easy & obvious things upfront. Most of these have Radars filed against them, but since they’re more often than not dupes of existing Radars I won’t post the numbers here. Most of this is about iOS, but not all – I’ll say upfront that I don’t think OS X has a future with the way it’s going currently, and has been running on fumes for most of iOS’ lifetime. Even if you disagree with where I’m coming from, perhaps there’s still something for you here.
Split-screen letting you spawn multiple windows for the same app
This is a really easy evolution to see – right now, split-screen in iOS only enables two different apps side by side. The next obvious step is to enable an app to say it’s capable of handling a second window, so that you could have two web pages or documents side-by-side.
Another tiny tweak, but this would allow an app to say how it prefers opened links/apps to open – either side by side, or replacing the current app. This would allow e.g. URLs in Mail or Messages to automatically open Safari side-by-side instead of kicking you out of the app you’re using. Twitter on iOS has some clever logic to simulate this – if Twitter is pinned at the side of the screen, it will open URLs directly in Safari (side-by-side).
With Extensions, Apple has created an ideal way to present a view controller from one app inside another app. This is used throughout the OS, but most obviously with Safari View Controllers. Apple has already identified key areas where this is useful – this is how photo editing Extensions work, right now. I would love to see this expanded upon such that apps can register view controller providers for all kinds of different functionality, which could then be presented inside other apps.
In a similar vein, QuickLook seems like a really obvious system Extension point to add. OS X apps can register ‘QuickLook generators’ so that they can create thumbnail previews of their document contents such that other apps can render them. As document handling becomes more pervasive on iOS, no doubt QuickLook will expand to include this.
Very simple one – Apple has, in Notes, created one of the best drawing/markup views in any apps on the platform, ideal for Apple Pencil. This would be great to offer to developers in some standardized, customizable fashion such that they can implement it in their apps without having to reinvent the wheel – a drawing engine like that is an incredibly complex OpenGL/Metal renderer, which is difficult to reimplement.
With UIKeyCommand and keyboard shortcut support on iOS, I would really like to see a command key added to the iPad on-screen keyboard. Understandably it would only work when the keyboard is visible (i.e. in a text editor), but it would enable editing shortcuts beyond what fits in the bar atop the software keyboard. It would also help train developers that iOS apps should have keyboard shortcuts by default – in an era where most iPads support hardware keyboards, I think this is an important step forward.
With the addition of split-screen multitasking, much has been said about drag & drop on iOS. It seems like an obvious thing to add, on the surface, but when you think it through there are a lot of ways it could be detrimental to the OS. Finding a way to enable drag & drop without screwing over all the existing gestures in the OS, whilst still making it faster than copy/paste – that’s not as easy as you think. Despite that, I do think it’s worth figuring out, and makes so much sense on a touchscreen with its direct manipulation model.
WatchKit was an amazing stopgap, enabling a competent app platform on watchOS and all of the apps you use today. Sadly, third-party apps on watchOS suck, and ‘native’ WatchKit in watchOS 2.0 hasn’t really helped here. If watchOS is to succeed as an app platform, I think it will need the ability to run real (read: UIKit) apps. As someone who’s dabbled in this already, I’m not convinced the first-generation hardware is good enough to enable this without serious compromises. My wish, therefore, is that future hardware makes it possible. Third-party apps need to be as capable as the fantastic first-party apps. WatchKit is a shit sandwich.
A very easy thing to fix: right now, a game on tvOS cannot require a gamepad (unless, of course, it’s Activision requiring a hardware accessory because that’s clearly so different. /s). All games must support the Siri Remote: the problem with that is the Siri Remote is awful for games, and means any developer attempting to make anything even remotely complex (read: good) on tvOS has to include some ridiculous, often-patronizing, and mostly unplayable Remote-only mode. This is a policy issue – I understand where Apple marketing is coming from, but the godawful experiences it’s resulted in are worse than the alternative, and reflect terribly on the platform.
iBooks Author is an offshoot of the iWork suite that seems like it would be perfectly suited to running on iOS. For book-writers, iBooks Author on iOS could mean a fully-integrated writing & publishing solution that doesn’t require a desktop computer. One could even build multi-touch ‘enhanced’ iBooks on-device. To me, firmly rooted in the iOS camp, it seems like a no-brainer to bring to iOS.
I’m surprised this is still the case, but a bunch of system apps on iPad outright refuse to implement split-screen multitasking. My guess is that there are some concerns about security – iBooks, for example, tells you to make the app fullscreen if you want to see the iBookstore. Obviously the App Store, iTunes Store and Apple Music should support split-screen. It’s very hard to justify any (non-game) app not doing so (though I do know there are reasons some third-party apps have opted-out). Windowing support shouldn’t be optional, especially for system apps.
Now that the easy stuff is out of the way…
Unified App Platform between iOS and OS X
Right now, I really believe that OS X is a dead platform. It’s been coasting on iOS’ wake for years, picking up features often long after they’ve been implemented on iOS. Apple needs to create a unified app platform between the two operating systems.
This doesn’t mean a desktop would just run iOS apps, much like tvOS doesn’t ‘just run’ iOS apps. The same ideas should apply: a shared codebase, with minor platform-specific elements, and an optimized UI for the OS’ primary interaction model.
I could see this being UIKit-based. After tvOS, it is no longer valid to say that UIKit just flat-out wouldn’t work on a non-touchscreen – we know that’s just not the case. It’s all built on CoreAnimation, so it would make sense that you would be able to interleave legacy AppKit views/layers inside a (hybrid) UIKit Mac app, at least for the time being. AppKit itself should have a protracted deprecation period, like Carbon before it, as new functionality gradually gets built into UIKit-based frameworks instead. AppKit would remain on the desktop and not come to iOS, and eventually fade out as it gets replaced inside hybrid apps piece by piece.
In this way, iOS (primarily iPad) and OS X could grow together. Functionality built for one would much more easily translate to the other. iPad apps would have a migration path to the desktop, and legacy desktop apps to iPad – both platforms would evolve & grow as one, and not one at the expense of the other.
Xcode for iPad
A longstanding request of mine, but software development remains a key artform woefully under-represented on iOS. When I say I want ‘Xcode for iPad’, I mean ‘a means to write, debug & deploy Cocoa Touch apps on iPad without having to use a Mac’. It’s very likely that a project like this from Apple would look nothing like Xcode does on the desktop. It most probably would be Swift-only (something that makes me very sad). I imagine it would also involve Swift Playgrounds. Nonetheless, a complete software development toolchain is a huge missing piece of the iOS software ecosystem.
There are some great apps on iOS that have managed to pull something similar off – Pythonista is a prime example: a fully on-device Python IDE with bridges to C and ObjC code, powerful enough to let you interface with and rewrite its own UI using Cocoa (in Python), but there’s a learned unease that Apple will decide something like that is not allowed and remove it from the Store. This is a terrible situation to be in – things that push the boundaries of what people think iOS is capable of should be embraced.
File & disk management for iOS
From the start, iOS has tried to do the ‘right thing’ when it comes to file management. However, nine years on, this imaginary era where physical filesystems don’t exist hasn’t come to pass. Finally, we have an iCloud Drive app and third-party document providers, but we can’t interface with files on external storage, beyond importing photos to the camera roll. I think it’s time to implement this at the system level: allow document pickers to open files in place from external storage, and allow apps to copy files to external storage. On OS X, document pickers provide sandbox exceptions to the folders you, as a user, choose to give an app access to. Build on this model – maintain security, but stop pretending filesystems don’t exist.
Terminal environment for iOS
Worth a shot, huh? 😛 I would be so happy to see a Terminal/BSD environment on iOS, even if it were limited to its own sandbox and not the OS filesystem. Let technical users build the kinds of things that technical users need, that can’t be addressed in any other way by a GUI iOS. The only way I see Apple committing to this is if it were completely jailed from the rest of the OS – but even that would be a major step forward (or, backward, depending on your point of view).
iOS to pick up the remaining OS X apps
As iPad grows to replace more of what the Mac used be for, it makes a lot of sense (to me) that Apple should close the gap between the system apps on both platforms. I would like to see (interpretations of) TextEdit, Automator, Font Book, Keychain Access, and, with external storage support, Disk Utility. TextEdit on the Mac seems like a trivial one, but there is no built-in text editor on iOS that can access TextEdit documents on iCloud Drive – personally, I think that’s crazy. Automator is one of those tools that few people use, but those that do realize how incredibly powerful and useful it is. In fact, Workflow, one of the best third-party iOS apps on the platform, is pretty much an expanded Automator. Font management & keychain support are other areas that do not really have third-party equivalents on iOS, despite being essential for certain kinds of users.
Right now, one of the last remaining reasons to connect an iOS app to a desktop computer is to install the OS. Fixing this would be difficult, no doubt, but NetBoot & Internet Recovery have long been things on the Mac. It’s been a while, so I may be misremembering, but I think the first-generation (x86) Apple TV could redownload its OS from the internet in recovery mode if something went wrong. Eventually, I think iOS needs an expanded Recovery environment that can do this for itself.
A hard sell, especially when the Made for iPhone program is such a big thing for Apple, but there are all kinds of devices I’d like to be able to use on iOS through the USB adapter beyond audio, keyboard & mass storage devices. I’d like developers to be able to write user-mode driver apps to talk to existing hardware – in my case: capture cards, TV tuners, serial adapters. External cameras, input devices, etc. Having every single USB device require an MFi authentication chip and certified accessory apps really hurts. You could buy a pre-existing iPhone MFi RS232 adapter and use their already-approved SDK to make an app that talked to (/synced with) e.g. a Newton, Raspberry Pi, or Arduino. You can’t use Apple’s USB adapter to do the same with a non-MFi USB serial adapter. I don’t expect this to change, but I wish it did.
Finally, this is an important one: it’s become very clear that the Mac App Store is not fit for purpose. To be reductive, sandboxing restrictions & monetization issues have driven-out so many longtime, respected Mac developers. Those that stay often have MAS and non-MAS versions of the same app – the non-MAS generally being the one with the full featureset. Third-parties have resorted to coercing MAS customers to crossgrade to non-MAS versions of the apps. This never should have been allowed happen – it’s bad for developers, and it’s bad for users. It shouldn’t be crazy to think that all Mac software should be available through the Mac App Store. Microsoft Office, Creative Cloud, etc – every effort should have been made such that the MAS is the only place you’d even consider selling your Mac apps. Even today, Apple provides software through the MAS that does not play by its own self-imposed sandboxing rules, the same restrictions that drove everybody else out. This was so fixable, and perhaps still is. Right now it’s a travesty; there is no leadership here.