قالب وردپرس درنا توس
Home / Mac / WWDC, A Wish List (2019 Edition) – MacStories

WWDC, A Wish List (2019 Edition) – MacStories



Back in 2016, in the era of iOS 9, I released the tent pole functions I wanted to see, coming to iOS and Mac. Now three years later, so many things from this wishlist have become a reality that it is a good time to look at the topics that have not yet come, and plan a new wish list for the coming years. I originally planned this list to have a Developer / User split, but it became clear that the two go hand in hand; If you're doing complex things on iOS today, using the various automation apps, you're just steps away from needing the same things that developers do.

Xcode for iOS

Much has changed since 201

6 for development on the iPad, but much remains the same. Apple introduced Playgrounds that year, giving its own Swift IDE to the iPad. Playgrounds are fantastic but you still can't build and install an app using it, and you can't mix and match C and Objective-C code with Swift. It has no project structure, so your entire code must take place in a file that is good for teaching materials, but not for anyone who wants to create something more complex. In 2017, the Apple App Store rules changed to enable the programming apps to live on iOS without fear of being removed, albeit with unfortunate limitations such as not being able to display the end of an app on more than 80% of the screen. However, there is still no way for a third-party programming app to run code out of the process so any user errors can crash the app altogether, and of course there is no way to build and install an app locally using one of these IDEs.

There's still an incredible need for something to bridge this gap – an iOS programming environment that lets you design, write, build, sign, and install a program without resorting to a Mac. No third party can build this because Apple has App Store rules and platform restrictions that prevent anyone else from being able to. Therefore, Apple must be the one who builds this "Xcode for iOS" and makes it as powerful as a developer may need, while incorporating the mechanisms into the operating system to make it as safe and secure as possible. In 2016, many of the basic pillars that were needed to build an Xcode like this existed, not in iOS, as an easy-to-use file system, drag and drop, multiple windows and floating panels – but they do now (or will soon if rumors should belief).

iOS Terminal Environment

Like the file system, for a particular user group, the need for a command line environment of some kind has not gone as I am sure Apple would have hoped. Now, with Apple's own shortcut app, more users than ever automate automated tasks on iOS – it makes perfect sense to give something more to the power users who need it, especially if the Xcode for iOS becomes a reality. After 2016, I went and built the sandbox Terminal app I described in my post and populated it with the core BSD tool from Apple's Darwin as a demonstration. We have seen Mosh and OpenTerm, who do much of the same. Now it is iSH, which goes as far as simulating an X86 Linux environment just to try to provide a working shell on iOS.

All these apps are sand-discarded and use public APIs, but only Apple can build the real thing. I'm not going to install an X86 emulator on my iPad just to curl a URL and untar it, or to run ffmpeg to convert a local video file . A sandboxed terminal does not have to mess with the system or other applications, or provide ways to perform unsigned code or kill processes; It should be able to live in your own prison and let you do whatever you want inside it, just as a GUI user does what they want in shortcuts while keeping the security and security of the operating system.

System -Level Drawing / Markup Views

Four years after Apple pencil, and still, Apple does not provide developer APIs for drawing, sketching and marking. All apps need to reinvent the wheel if they want pencil-based drawing, and while some developers have invested a lot of time and effort into their own drawing engines, it excludes any other developer who does a good idea for a way to integrate sketching. in his own app.

Apple has given test code earlier to this, unfortunately OpenGLES-based, but if you want something more appropriate, you're left to scour GitHub. Building a drawing engine that looks good and feels responsive to ProMotions 120Hz is incredibly difficult, but Apple has its own great drawing framework in the operating system that they use in the Notes app that would be perfect to give to developers.

There are several Apps that sit on my shelf, which would greatly benefit from a built-in API for a drawing view; I hope Apple comes to this before rather than later.

Custom Display Controller and Non-Extended Expansion Suppliers

Extensions have run so many new APIs in iOS and macOS, completely avoiding the plug-in model with a robust out-of-process signed and sandboxed mechanism. However, developers cannot define their own expansion points and thus cannot use them to enhance their own apps. An iOS programming environment should be able to run the code in an extension – a proprietary process that can be scanned securely only to the task it does, and if it crashes, it will not take down the host program with it. Of course, this is exactly how Apple's Playgrounds app works, but no third party is allowed.

Likewise, you should be able to define your own extension interface so that other apps can implement an extension that will appear in your app. If you've ever used the Audio Unit expansion point, this is exactly what you can do – presenting the custom user interfaces from various instrument or audio applications you've installed, in a region in your own apps' user interface – but only if you & # 39; re an audio app using CoreAudio.

There are many ways developers can innovate by providing their own expansion points; In fact, so much of the custom URL ecosystem on iOS jumped up because there is no standardized way for apps to talk to each other or use features apart. Apple's own shortcuts app, no Workflow, was born out of the custom URL ecosystem, and Apple realized that the potential was so great that it bought Workflow and built it into the operating system. Your own extension point can be exposed as a shortcut app action, letting it call it transparent as part of a workflow, with or without a user interface, rather than dosado between apps that custom URLs currently involve.

Enter / Key Down Events

It seems wrong in 2019 that you still can't track fast keyboard events on iOS – there is no way to block using a private API, for an app that lets you keep physical keys like input (like WASD keys for a game), or as modification keys (like holding Shift while resizing something in an app like Photoshop to maintain aspect ratio). A developer only knows when a key is pressed, not released, or a shortcut is called. This limitation seems so pointless today, and incredibly restrictive, affecting everything from professional creative apps to games. iPad needs robust hardware keyboard support and should not be linked to a constraint formulated ten years ago for a completely different world.

Mouse Support and API

Similarly, it is time for robust mouse and track slot support on iOS. With the UIKit coming to the Mac, the frame has to add a variety of interactions like right-click, hover and scroll bar; Why not bring this to iPad too so that users can benefit from it if they choose, or if the workflow requires it?

While controlling the user interface with absolute coordinates, it is an important function of the mouse, let's not forget that mouse capture and relative motion are important for games, remote desktops and emulators. UIKit must therefore allow you to capture the mouse pointer for your own needs and not just to click on screen items. Combine this with robust keyboard support and you'll be able to play games like first-person shooters on the iPad, just like you can on Mac or PC. Quake 3, anyone?

Android has supported mice for almost a decade, and it hasn't done anything to reduce the touch experience, so there's no need to worry about it on iOS. For users or workflows who really want or need a mouse, the iPad will always be a non-starter pack until it supports one. Time for the barrier to go away.

Larger iPads and External Touch Screen Support

There are times, but when the computer I want on my desktop is a 30 "iOS lookup table. IPad is essentially a blank canvas – better since it doesn't have any buttons at the front – And a larger canvas is a whole new experience, and I'm about to die for the desktop desktop workflow iOS scale, with multiple apps on the screen at the same time, if not a desktop iOS device itself, why not a big external touch screen for Apple quality?

I want to love a 15 inch iPad too: I haven't used a Mac laptop since 2013 – iPad has completely rejected the form factor it's getting stronger – and I can't imagine Go back, but for people like me, Apple must offer an even bigger model iPad than 12.9 ". 12.9-inch iPad Pro already has customized user interfaces with expansive layouts and three column views, and UIKit on the Mac will require developers to create programs and layouts that can scale to 27 "screens anyway. I'm deeply envious of Microsoft's Surface Book (that is, of course, until you turn it on), and as a result of running iOS, will suit my needs.

Extended iOS device support

MFi can be gone with USB-C iPad Pros, but developers need public APIs to write user mode drivers for everything you want to plug into the iPad. I will be able to plug in my different EyeTV tuners and make the EyeTV app happy to launch them as it does on Mac I want my Game Capture HD60 to work on iOS so I can record pictures from my game PC and actually be able to edit and do it on the fastest computer in my house (2018 iPad Pro). # 39; s FTDI cable l and see serial output on the iPad without buying crazy MFi-based serial cards. If, for any workflow I may have, I need to burn a CD or DVD, I should be able to connect to a floppy disk and do so with an app designed for the task. This should "just work" in a way that iPads simply can't do today.

Read / Write External Drivers Through the Files App

Now this is on everyone's wish list. Do I need to say more? It's been so long since I can't imagine Apple keeping much longer. But I would like to move on …

Format / Partition External volumes and read / write disc images

I don't just want to read my stations: I must also be able to handle them. Delete, partition volumes. Understand multiple file systems. Image them into a file or use a disk image for them.

Mac's transparent disk image support is genuinely one of their high performance. As a result, I have lots of disk images from two decades on macOS. I use disk images every day; I create CD and disk images to send files to / from VMWare and Qemu. If user file system access becomes a central part of using iPad, we need the rest as well. If I choose to never use a Mac again, Apple tells us that all my old data is lost.

Scripting

"AppleScript for iOS" was one of the articles on the 2016 list, but the Apple automation landscape has changed dramatically since then. Apple bought Workflow, now Shortcuts, and the notion is that AppleScript may not be farther after this world, slowly pushing out in favor of a sandbox, safe and modern expansion mechanism used by shortcuts. Scripting is still incredibly important, as evidenced by hundreds of shortcuts, used by someone who takes iOS seriously for work these days. So if not AppleScript, huh?

What I really want to see is a text interface for shortcuts that allows you to do all the same things without having to navigate and flaunt a user interface filled with actions so that the class of advanced user who prefers to write scripts can do the things they do need. Scripts need a way to run "silently" without presenting a user interface on the screen or jumping between apps. And scripting should be extended to the user interface, allowing developers to build proper scriptable applications as they can today on Mac with AppleScript. It is easy to imagine shortcut scripting using JavaScript or Swift, and shortcuts already have a script action that lets you run JavaScript on a website.

Virtual Machines

It's hard to see Apple that supports virtualization on iOS, as virtual machines require things like Just-In-Time compilation to execute arbitrary code in memory that breaks one of the basics of the iOS security model and burn through battery life as few other tasks. However, Apple provides WebKit on iOS, which also requires the special security exceptions to execute code in memory, and on macOS, Hypervisor.framework provides a lightweight virtualization system that allows developers to easily build virtual machines.

I am the type of user who would like to see hypervisor for iOS; Let companies like VMWare and Parallels bring their expertise to the iPad and offer approved ways to run ARM-based Linux or Windows (or for some years, MacOS maybe). X86 emulation may be out of the question for now, but maybe it won't always be the case; I'm sure I'm not the only developer with a library of VM for everything, from DOS to NEXTSTEP to older versions of MacOS and iPhone SDK. Of course I can use these VMs on iOS today, with open source apps like Bochs or mini vMac sideloaded on my device, but because they don't have the ability to JIT, they have to run completely using CPU emulation that is significantly slower and burns more battery.

Rights

Finally, it gives me rights. The iOS licensing system is what makes Apple have fine-grained control over which developers can access which features; If you want to use iCloud in your app, your app must be signed with an iCloud right, with similar requirements to Health, Home, Apple Pay and many other parts of the IOS. For example, CarPlay needs a special right that is not freely given to developers. In fact, you need to search for Apple and get your appeal approved before they even let you test the feature of your app. If an app or developer has ever been found to abuse their privilege, their rights may be revoked by Apple and the app is remotely disabled. Thus, rights are a good way for Apple to leave developer partners with special access to features that other developers can never use or abuse.

With that in mind, Apple could leave for example. Google, Microsoft or Mozilla with the rights they need to use their real browser engines on iOS instead of WebKit – real Chrome, real Firefox. VMWare and Parallels could be trusted to build virtual machines or emulators, without letting this be open as an attack vector for malicious third-party apps. Disk Utility may be allowed to partition disks, IDEs may be allowed to run background processes, install apps, or add a debugging software to run programs. So many of these things, freely given to developers, would undoubtedly make iOS a much less secure place (read: as powerful as a desktop computer), but with the rights mechanism in place, Apple could still keep the control they want and not leave it coming out of hand. When I look past the inter-company policy, iOS will need methods to do all these things eventually, especially if the iOS app ecosystem is to replace the Mac app ecosystem with time. A Mac without the ability to build and install apps or add a debugger would be incredibly paralyzed.


We have come a long way from the fear that activating third-party apps on the iPhone will bring down the cell networks; Trying to build the future on iOS today is like having your hands tied behind your back. The IOS has long been the fact that the Mac exists as a repayment to perform all the tasks Apple is not ready to rethink for its modern platforms, but that does not mean that these issues are not relevant or worth solving. This has left us in a situation where iOS moves forward with new ideas, but the Mac stands still and needs to keep compatibility with the iOS ecosystem as you seal the line between keeping things as they are or losing the freedom and power of old systems the active development and enthusiasm of the new. The right way forward is not only to go back to the mechanisms available on the desktop, with all the luggage that comes with, but to think of all these things to fit into a modern, safe world.

IOS is exponentially better with a working File app, with drag and drop, with automation, background tasks and multitasking on the screen. iPad with a stylus and hardware keyboard.

What iPad does so well is completely hidden from the complexity of the user who does not need to know about the mechanics of the system, without pressing an app to open it and swipe home indicator to close it. All these things, added to iOS, have not made the operating system more difficult to use. They are so transparent that I'm sure most users don't even know they exist, but for the users who need them, they have become important tent pins of the iOS experience.

With UIKit on the desktop, it's time to see exactly what an iOS app can and can't do; After all, they are no longer "iOS apps": they are just "apps" now.


Source link