While I’m often the person my friends and family call upon for technical support for Windows, Android, or things on the internet, I have little experience with the Apple ecosystem. But when my friend Josh told me about his sudden and confusing issue with Final Cut Pro X, I was so intrigued that I had to investigate. We eventually figured it out, and I got a crash-course in OSX as well.

The issue:

Final Cut Pro X (10.2) would crash and display a “Final Cut Pro quit unexpectedly” error message whenever an export option was selected.

Further details:

• OS – El Capitan
• FCPX – Version 10.2, without Compressor or Motion.
• iMovie – 10.1.6

No new applications had been installed recently, and FCPX had been working correctly after the last OSX upgrade.

We couldn’t try restoring from a backup as there weren’t any viable backups, but all of the following troubleshooting steps had already been tried without success:

• restarting the MacBook
• clearing FCPX preferences
• making a new FCPX library
• deleting generated render files
• making a new user account
• booting in safe mode

Testing

Firstly, we sent a video from iMovie 10.1.6 to FCPX before exporting it – as we expected, it still crashed. Then we realised that we hadn’t tested iMovie itself. When we tried to export a video from iMovie, it didn’t crash, but it did give us an error message.

Exporting “test” has failed. The operation couldn’t be completed. (com.apple.Compressor.CompressorKit.ErrorDomain Error -1.)

With keywords to lean on, figuring out the issue got a little easier. Searching for an iMovie issue, rather than an FCPX issue, displayed multiple apple support threads and reddit posts from people with the same problem Unfortunately, most responses covered the troubleshooting tips we had already tried, or decried Apple for its insolubility.

Then Josh remembered that a few days before, he had plugged his iPhone into his Mac, and received a pop-up about updating his Mac to let iTunes understand his phone. This timing meant the iTunes-related update was now a prime suspect, even if that didn’t make any sense on the surface. 

After diving into Apple Support threads, I found someone else who had not only experienced this exact problem after updating their iTunes, but had also figured out why.  According to this user, the iTunes update “… updated the Library MobileDevice.framework, into a newer version that is only 64bits compatible, and not anymore multi-architecture i386 and X86_64.”

Although Apple have been building MacBooks with a 64-bit architecture since 2007, and encouraging developers to create 64-bit apps since OSX Snow Leopard (2009), they have maintained support for 32-bit apps. However, from OSX Catalina (2019) onwards, they only support 64-bit apps. This process of switching over to “exclusively 64-bit” appears to have created problems. 

Connecting a device that’s running iOS 12 or newer prompts iTunes to update its “Mobile Device Framework” – the services that let iTunes connect to mobile devices. This new version of the Mobile Device Framework is 64-bit only, while previous versions were compatible with both 64-bit and 32-bit apps. The problem with iMovie and with Final Cut appears to be caused by having the new 64-bit only version of the Mobile Device Framework. Searching further also revealed that Cinema4D users and GarageBand users experienced similar issues after updating their iTunes to connect to a new phone, so errors with the Mobile Framework appear to create problems for other video and audio applications. 

I assume that some parts of iMovie, FCPX, and other media programs rely on having a Mobile Device framework with 32-bit compatibility, and so are stymied by the new version. While I have no idea about the details of why this is the case, having a defined problem does make a solution easier to find. 

Solutions

I found two solutions, one logical and one less so. If you have a Time Machine backup from before the iTunes-related update, and having your video working is more important than connecting your iPhone, then the logical option is to swap the new mobile device framework file with the previous one to restore its functionality. The process for this is:

• Open a Time Machine backup and find the mobile device framework file. By default, this file is stored in /System/Library/PrivateFrameworks/MobileDevice.Framework
• Restore the backed-up MobileDevice.Framework to your Desktop (or anywhere that isn’t the Library). 
• Boot into safe mode (by holding Shift as you power on the Mac)
• Delete the old MobileDevice.Framework file and replace it with the backed-up version 
• Reboot
• Success…. well, hopefully!

If this procedure doesn’t work, if you don’t have a Time Machine backup, or if connecting your iPhone is a priority, the only solution recognised by Apple Support is to upgrade to OSX Catalina and use the versions of iMovie, FCPX and iTunes required by Catalina. 

We had to go with option 2, which required upgrading directly from El Capitan to Catalina, updating iMovie and iTunes, then installing Final Cut Pro 10.4.8. After completing this process, FCPX and iMovie both exported clips correctly. (However, we are ironing out an issue with FCPX not installing correctly, which is likely to be caused by the .dmg file we used rather than with Catalina).

Conclusion

I assume that the 64-bit only nature of Catalina means that apps will depend on fewer frameworks and system files, which in future will reduce the chances of conflicts like this one. However, in the present, transitioning to full 64-bit will result in more issues like this appearing. For many people, upgrading to Catalina isn’t possible yet, as it will invalidate apps they urgently need. So for Apple Support to emphasise upgrading as a solution seems clumsy at best. The advice reinforces how the unexplorable walled-garden nature of OSX makes it hard for users to understand why issues appear. More importantly, it ignores that customers who trust the advice to make upgrade their entire OS as a first-line solution to their issues may then be left with the burden of any problems that result.