Hacker News new | ask | show | jobs
by Ryanmf 5232 days ago
Apple needs to do better than this.

For the duration of the company's existence, one of their biggest customer segments has been the creative industry. I can't think of a single pro audio/video/graphic/etc app that doesn't make extensive use of plug-ins, another Mac App Store disqualifier.

Do the developers of these apps necessarily have a "right" to iCloud APIs, delta updates, and other benefits of playing in Apple's sandbox? Of course not.

But is Apple harming themselves and their customers by excluding the creators of these apps from the party and potentially causing them to focus their development efforts elsewhere? I think they may be.

3 comments

> For the duration of the company's existence, one of their biggest customer segments has been the creative industry

I would have thought the Final Cut Pro X debacle (http://pogue.blogs.nytimes.com/2011/06/23/professional-video...) would have served adequate notice to those folks that Apple doesn't consider them an important market segment anymore...

Maybe. I hope not. All the filmmakers/editors I know still use a previous version of Final Cut, many of them really like some of the features of Final Cut X (syncing is apparently dead easy, nearly automagic), and remain hopeful that Apple will pull it together and address their needs in future updates.

I don't know if you have used/use Final Cut 6/7, but it is a phenomenally ugly, often poor performing, generally unintuitive piece of software. I can see where the motivation for a full reboot would stem from.

Now, a reboot that involves consolidating formerly modular panes into a single window when the target market typically works on two, three or more displays is just dumb. A reboot that was, as a practical matter, 0% backwards-compatible may have been necessary, but if it could have been avoided, it should have been. But buried under all the mistakes, I think there was some genuine good intent (yes, I know I'm grasping at straws).

I primarily work with music, and you don't need to be as involved as I am or attend as many shows as I do to know that for any artist/band that uses a laptop on stage, the MacBook Pro is the de facto standard. The same applies to Mac Pros in studios (although those boxes may be going the way of the Dodo as well).

None of this necessarily makes a difference to Apple; the new features in Mountain Lion which focus on Chinese web portals and social networks serve as a reminder that the emerging Chinese middle class is likely as important a segment to Apple as any, and the number of potential customers in that group already dwarfs the ranks of every DJ, producer, sound engineer, and electronic musician on earth.

Still, it would be a great disappointment to me and many others if Apple were to abandon such a loyal group of customers who helped them reach this point.

FYI, the latest update to Final Cut Pro X was a major update, adding impressive multicam support which uses "audio waveforms from the different cameras to sync them together. The audio doesn't have to be the final production track and can be used for syncing purposes only,"[1] chroma keying, media relinking, import of photoshop layered graphics, support for XML 1.1, and beta broadcast support. This new update has an average review score of 4.5 stars Mac App Store.[2] While Final Cut Pro X started out weak, it looks like it's becoming very solid.

[1] http://www.tuaw.com/2012/01/31/apple-updates-final-cut-pro-x... [2] http://itunes.apple.com/us/app/final-cut-pro/id424389933?mt=...

It's the opposite. Taking the time AND money to rewrite the old Final Cut Pro codebase from scratch is an indication that Apple is pretty much dedicated to their Pro apps.

Unlike, say, Adobe, that merely piles incremental bloat upon incremental bloat, and calls it a "new version of the suite".

The complains are from people that:

1) see a black interface as some kind of iMovie-fication (iMovie is black, so they have dumded down FCP).

2) Think professional software means convoluted GUI (they made things simpler, so they have dumbed it down)

3) Expect a rewrite of a 10+ year old codebase to have feature parity with the old version from day one.

4) Expect a rewrite of a 10+ year old codebase, with the intention to support modern movie making practices, to also cater for obsolete practices that the old version covered (like tape editing).

As I indicated above, I think the reboot of Final Cut was well intended.

Having said that, I've had far too many conversations with far too many professional filmmakers and editors (I'm talking "multiple all-nighters every week editing multicam RED; invitations to Cannes; contracts to produce music videos for multi-platinum selling artists and promos for Fortune 100 companies" professional) about the weaknesses of Final Cut X to have much regard for the opinion you've shared here.

Ultimately, if the intended users are dissatisfied, then Apple missed the mark, any rationalizations from armchair analysts notwithstanding.

By the way, you left a complaint off your list: Zero compatibility with project files from previous Final Cut versions. Hope you've got some free time to recapture everything you've ever shot.

Ultimately, if the intended users are dissatisfied, then Apple missed the mark

Not really. System 9 Users also complained about OS X 10. How it wasn't like OS 9, how it missed some features, how it was unstable etc. But putting a nice foundation down is better than giving instant gratification to your users in the long run.

By the way, you left a complaint off your list: Zero compatibility with project files from previous Final Cut versions. Hope you've got some free time to recapture everything you've ever shot.

Or just use the old version for your old projects, and only move to the new one for new stuff?

What kind of Pro jumps to a new version of a core tool anyway as soon as it it released? Most actuals Pros keep their setups steady for many years. Which is why I think most of the noise is from low production tinkerers, that already use both FC and Premiere etc.

Actually, the sandbox seems like a requirement for safely distributing apps that allow plug-ins.
Can you explain how this works? My understanding is that plugins — defined for clarity's sake as "loadable code that interacts with the original application but was not included in it" — are not allowed in the sandbox. Has this been fixed? Or did you mean something else?
I mean that plugins are very unsafe if there's no sandbox. I don't mean they got actually allowed.
Are you suggesting that every pro media application released before March 1, 2012 was not safely distributed?

I guess I should step back a bit and make my argument more clear. I'm not opposed to the concept of sandboxing, I recognize the benefits of these policies as Apple's user base grows and malware becomes a greater concern.

My contention is that the imposition this places on users and developers alike will most likely dissuade pro media software developers from participating in the Mac App Store to begin with, thereby depriving Apple of potential income, depriving developers access to useful features like iCloud file sharing/mirroring, and exposing users to the very risks this policy is intended to shield them from.

I'm suggesting that every single application prior sandboxing was not safely distributed. It's not like anyone had a choice, there was an age before airbags.

I also disagree that extensibility is in conflict with sandboxing. As for pro media software developers, I'm pretty sure it's just a matter of time and polishing of the platform. AutoCad LT is already in.

I'm not sure why the Mac App Store represents the high water mark for safety (as opposed to a secure server maintained by the people who actually developed the software or MacPorts/Fink/Homebrew) but whatever.

Many popular audio plugins are themselves plugin hosts (just off the top of my head, Native Instruments' Reaktor, Maschine, and Guitar Rig and Five12 Numerology match that description). In this context, wouldn't that require nested sandboxes? You're sure you don't see any potential conflicts there?

Not really. They still can't access files outside of what has already been granted to the main application.
Are you suggesting that every pro media application released before March 1, 2012 was not safely distributed?

Yes. Is that hard to grasp? Sanboxing is safer than the old distribution practice. You won't find any security expert to disagree with this.

Thus, every pro media application distributed without sandboxing was LESS safely distributed than a sandboxed one.

My intent isn't to bash Apple, I love their products and intend to use them for the rest of my life, provided they don't fuck it up.

I don't want to see them fuck it up.

Now:

>Thus, every pro media application distributed without sandboxing was LESS safely distributed than a sandboxed one.

First, they weren't less safely distributed, they were less safely executed. Nothing gets sandboxed until after it's been distributed. The only reason we're discussing both issues here is that Apple has elected to conflate the two with their MAS policies.

I'm only 25, and yet I've installed thousands of pieces of software during my brief time on this planet. Very few of them wreaked havok on my life, so you'll have to forgive me if I remain unconvinced that every single application I run must be sandboxed to maintain the stability and integrity of my system.

My contention is not that sandboxing, generally speaking, is bad for users. It isn't.

My contention is that sandboxing, as Apple has narrowly defined it, is impossible to implement in a large segment of professional applications as they are currently written.

Furthermore, if developers choose to eschew the MAS, users of their applications will be deprived access to useful new tools like iCloud file sharing for reasons that seem arbitrary at best.

Finally, in two weeks time when Apple begins to enforce regulations which will exclude these applications from MAS distribution, but does not remove VST/AU support from Logic Pro, Rewire support from Mainstage, or [insert your favorite hypocrisy here], they may be acting anticompetitively, which is bad news.

First, they weren't less safely distributed, they were less safely executed. Nothing gets sandboxed until after it's been distributed.

Well, it's a pedantic distinction if sanboxing occurs before or after. Since, sure, sanboxing rules are applied at runtime, but sanboxing is also built into the app before distribution (the developers adds the certs, the "ask for permission" bits, etc).

I'm only 25, and yet I've installed thousands of pieces of software during my brief time on this planet. Very few of them wreaked havok on my life, so you'll have to forgive me if I remain unconvinced that every single application I run must be sandboxed to maintain the stability and integrity of my system.

Well, in Windows lots of apps have wrecked havoc with my system. Malware, spyware, what have you. I've hand around 10 instances of my machine being infected in around 8 years of using a Windows machine. In OS X, on the other hand, nothing yet. And sandboxing is a way to ensure it won't be so in the future.

But there's is also another issue for which I think sandboxing is nice, besides malware. It keeps apps from spiting stuff all over the system. Like, how MS Office installs its shit everywhere it can, or how Abode Creative suite does. Same things for lots of small apps. If sandboxing can keep the confided in their own space, that will also be a win.

My contention is that sandboxing, as Apple has narrowly defined it, is impossible to implement in a large segment of professional applications as they are currently written.

Well, I think those rules can change. They already extended the period before sandboxing is applied. I'm sure as limitations are found we will see other changes too.

For some apps, on the other hand, like developer tools, rsync, git etc, they will always have to run without sandboxing.

Finally, in two weeks time when Apple begins to enforce regulations which will exclude these applications from MAS distribution, but does not remove VST/AU support from Logic Pro, Rewire support from Mainstage, or [insert your favorite hypocrisy here], they may be acting anticompetitively, which is bad news.

I'm not sure about the "anticompetitively" thing. It's their store, their rules. If sandboxing is about not trusting apps, then why would Apple require it for their own apps? One would think they trust them already.

MAS applications are not disallowed from supporting plugins.
You're technically correct.

They're just disallowed from supporting plugins in the manner that they have been on every platform for 20 or 30 years.

Providing deep platform-specific support in a cross-platform codebase is a pain; believe me I get that. But platforms evolve, and frankly the ways they've been evolving recently is likely much tougher to keep up with than "loading plugins from a new location, or with a new security context", especially for a time-based media application.

Wholesale changes in OS or environment runtime? Changes in underlying processor architecture? Forced update to full 64-bit support? Customers wanting to operate on files that are an order of magnitude larger?

If these apps have any claim to being worth hundreds or thousands of dollars per seat, and charging hundreds of dollars for basic compatibility updates, their developers should Pro-up and deal with this change like they've dealt with others.

And given the motivation for the change, I think they should skip the complaining step and lean into the work.