6 ms·
Core ML and ARKit would be great examples if those weren't so core to Apple's mobile strategy that they really didn't have any other choice. I can almost hear t
by robenkleene 7y ago
Core ML and ARKit would be great examples if those weren't so core to Apple's mobile strategy that they really didn't have any other choice. I can almost hear the bitterness in the concession: "Well, we could try build these technologies on iOS but that would mean improving iOS as a platform for creative work, but that's our worst nightmare. So instead we'll actually make something good for macOS, which is our second worst nightmare." I know I'm exaggerating, but I think you can see where I'm coming from, the only examples of good technologies they've shipped for macOS are things that they absolutely had to do for their mobile strategy.
To answer the question of what they should be doing: The dream of the Mac in 2010 was a bunch of Cocoa native apps built custom for the platform. Sketch had just come out, Acorn and Pixelmator were great Photoshop alternatives, one of the best text editors was TextMate. All of these were native Cocoa apps that presented a consistent desktop experience, and more and more use cases had apps like that on an upward trajectory.
Then Mac App Store sandboxing came down like a hammer on those dreams, and it followed with AppKit languishing, AEpocalypse, then notarization. It's been nothing short of an all out attack on native Cocoa apps. And with these trends the dream of a consistent, native, Cocoa desktop experience is now completely and utterly dead. Most new apps use Electron, or non-Cocoa in-house GUI kits. And the actual powerful Cocoa apps are forced to either handicap themselves to be in the Mac App Store like Pixelmator, or tread-water trying to figure out some way to modernize their stack like Sketch to try and stay on the top of the heap by competing with Figma, with zero help from Apple.
I could go on and on, but here's a few bullet points:
1. The size of the company is incredibly important for powerful apps because they all support vast ecosystems, this is one of the ways sandboxing handicap's apps because sandboxing prevents ecosystems from forming. Every major creative app has a vast ecosystem of peripheral technology that springs up around it, and those ecosystems need employees to support.
2. The best case study on what Apple should be doing differently is to look at 3D, a market that Apple has almost entirely lost, I don't have time to write out the decade of neglect here, but this podcast is great summary https://greyscalegorilla.com/podcasts/is-this-the-end-of-the-macintosh-for-c4d-artists/ https://greyscalegorilla.com/podcasts/is-this-the-end-of-the...
3. They never got Mission Control/Spaces right, that's a true desktop-first technology that just isn't finished.
4. They have no automation strategy for the Mac, just letting AppleScript languish with no replacement.
5. Nearly every new app on the Mac has a command palette where you can type menu commands. This is an obvious true desktop-first feature they should add to AppKit.
6. WKWebView/WebView is another example of Apple's absolute contempt for macOS developers. Do you know there's no built-in search for WKWebView? You have to invent your own search for a web view in 2020 in Cocoa app! I don't even know what to say anymore...
7. Node-based editors are all the rage in high-end creative apps, they're every where from Foundry Nuke, to SideFX Houdini, to Blender, to Cinema 4D. I'd say Apple should provide some built-in support for doing this type of UI/implementation, but now I just feel like I'm dreaming...
- zepto 7y agoIt seems like you are determined to be contemptuous of Apple here. It’s fairly clear that things like sandboxing are good faith efforts to improve platform security against risks that are very real. It’s also clear that they are seeing their platforms as unified, and attempting to bring as much technology to the Mac as they can, rather than reserving some for iOS. Without these kind of improvement the Mac platform would have no future. I can agree that it would have been better for the dream of Mac application space if they hadn’t had to address these issues, but I can’t see where the idea that it is bad faith comes from.
- robenkleene 7y agoThat argument doesn't work because the Mac App Store is not a popular way to buy software. Most of the apps people still buy Macs for are not in the Mac App Store (source: none of the most popular creative apps are in the Mac App Store https://blog.robenkleene.com/2019/08/07/apples-app-stores-have-failed-creative-apps/ https://blog.robenkleene.com/2019/08/07/apples-app-stores-ha...), so it didn't help security (https://www.theverge.com/2019/7/8/20687014/zoom-security-flaw-video-conference-websites-hijack-mac-cameras. https://www.theverge.com/2019/7/8/20687014/zoom-security-fla...). What it did do is harm the Cocoa apps that relied on Apple's stack. Look I understand the prism that you're looking at this through, and I do believe that was the security team at Apple's intention, but I don't think that's the reality of how it has played out. UPDATE: I think the fatal flaw of Apple's security teams approach is that it only would have worked if there were some way to pull mobile use cases back to the Mac, because those use cases are compatible with sandboxing. But that just hasn't happened, the use cases that moved to mobile, e.g., social media, chat, video consumption, aren't coming back to the Mac ever. And the use cases that did stay on the Mac: audio/video editing, 3D, programming are just simply demonstrably not compatible with sandboxing.
- zepto 7y agoThe Mac App Store not being popular doesn’t invalidate the argument at all, since Apple had reason to believe that it would be when they made the investment. It’s not clear what you mean with your update - what would it even mean to pull social media apps back to the Mac, and how would that help the situation with tools for thought? It’s not at all clear to me that the use cases that did stay on the Mac are demonstrably not compatible with sandboxing. Can you explain that? Certainly in-process plug-ins aren’t compatible, but those are utterly insecure and Apple continues to improve out of process extension mechanisms.