Hi Apple Developer Forums and Final Cut Pro team, I am developing a Final Cut Pro Workflow Extension focused on speech-to-text / subtitle recognition and generation. The extension runs inside Final Cut Pro, analyzes clips, generates accurate subtitles (often hundreds of individual elements), and allows users to drag the generated subtitles directly back into the FCP timeline as a clean, editable Compound Clip or Storyline. We are implementing this drag-and-drop functionality using the official pasteboard mechanism (com.apple.finalcutpro.xml and versioned types such as com.apple.finalcutpro.xml.v1-10). While the high-level documentation is helpful: Supporting Drag and Drop for Data Sent to Final Cut Pro FCPXML Reference Designing Workflow Extensions There is still no detailed public specification for the exact internal XML structure that Final Cut Pro expects for a drag operation to reliably result in a usable Compound Clip (or direct Storyline insertion), especially when dealing with large numbers of subtitle titles. After extensive systematic testing (multiple rounds over several weeks, with full experiment logs), we have observed the following: Short subtitle sequences work with many different structures (various combinations of , , , inline titles, etc.). Long subtitle lists (800+ individual elements) only succeed reliably when the outer structure uses a specific shell: root= containing + (often combined with a mainflow sequence and inner / layers). In all working cases, the dropped result appears as a “fake” / nested Compound Clip that requires 2–3 Break Apart (unpack) operations before the real editable Storyline with individual titles is revealed. Almost all other structures — pure as root, as root, wrapper layers, direct inline titles without the clip + gap + storyline shell, etc. — are immediately rejected by Final Cut Pro when the subtitle count is high. This undocumented behavior forces third-party Workflow Extension developers to engage in time-consuming blind guesswork and reverse-engineering just to achieve basic, reliable drag-and-drop integration. Our request: We kindly ask Apple to publish a detailed, official specification for the Draggable FCPXML Text Protocol (or expand the existing FCPXML Reference) that clearly defines: The minimal and recommended XML structure for dragging content into the timeline as a Compound Clip or Storyline. Exact roles and requirements for , , , , , and any implicit “mainflow” patterns. Best practices for handling large numbers of nested titles/subtitles. Reasons why certain nesting patterns are rejected or produce multi-level fake compounds. Any version-specific differences across FCPXML DTD versions. This specification is critically necessary for the FCPX Workflow Extension ecosystem. Reliable drag-and-drop from extensions back to the timeline is one of the most valuable integration points for subtitle/caption tools, transcription services, title generators, and other workflow utilities. Without clear guidelines, developers waste significant time on trial-and-error, leading to inconsistent user experiences and slower innovation in the Final Cut Pro community. We are more than happy to share our complete experiment logs, working and failing XML samples, and GitHub repository with the documentation or engineering team if it helps accelerate this. Thank you in advance for any official clarification or guidance. Clear documentation in this area would greatly benefit both developers and Final Cut Pro users.

I have exhausted standard debugging approaches and need guidance on Final Cut Pro's AU plugin loading behavior. PLUGIN OVERVIEW My plugin is an AUv2 audio plugin built with JUCE 8. The plugin loads and functions correctly in: Pro Tools (AAX) Media Composer (AAX) Reaper (AU + VST3) Logic Pro (AU) GarageBand (AU) Audacity (AU) DaVinci Resolve / Fairlight (AU) Harrison Mixbus (AU) Ableton Live (AU) Cubase (VST3) Nuendo (VST3) It does NOT load in Final Cut Pro (tested on 10.8.x, macOS 14.6 and 15.2). DIAGNOSTICS COMPLETED auval passes cleanly: auval -v aufx Hwhy Manu → AU VALIDATION SUCCEEDED Plugin is notarized and stapled: xcrun stapler validate → The validate action worked spctl --assess --type exec → Note: returns 'not an app' which we understand is expected for .component bundles. Hardened Runtime is enabled on the bundle. We identified that our Info.plist contained a 'resourceUsage' dictionary in the AudioComponents entry. We found via system logs that this was setting au_componentFlags = 2 (kAudioComponentFlag_SandboxSafe), causing FCP to attempt loading the plugin in-process inside its sandbox, where our UDP networking is denied. We removed the resourceUsage dict, confirmed au_componentFlags = 0 in the CAReportingClient log, and FCP now loads the plugin out-of-process via AUHostingServiceXPC_arrow. Despite au_componentFlags = 0 and out-of-process loading confirmed, the plugin still does not appear in FCP's effects browser. We also identified and fixed a channel layout issue — our isBusesLayoutSupported was not returning true for 5-channel layouts (which FCP uses internally). This is now fixed. AU cache has been fully cleared: ~/Library/Caches/com.apple.audio.AudioComponentRegistrar /Library/Caches/com.apple.audio.AudioComponentRegistrar coreaudiod and AudioComponentRegistrar killed to force rescan auval -a run to force re-registration

Hi, We have created an app which allows recording 4K 60 fps videos in the app. We have noted that some time the recording switched to 20 fps (the value 20 is constant) even though the resolution settings is at 4K 60fps. We are using AVCaptureDevice to invoke the camera. has anyone experienced this problem before ? What is unique to 20 fps? Why does it resort to 20 fps from 60 fps and why not to other numbers ?

Our Final Cut Pro workflow extension built with ProExtensionHost framework uses an advanced NSPasteboardItemDataProvider system with multi-version FCPXML support (1.9, 1.10, 1.13) and proper relative path UIDs for Motion templates. We've implemented clip wrapper approach with placeholder assets and elements containing effects to enable direct timeline drag functionality. However, drag and drop from our Final Cut Pro workflow extension directly to timeline is still not working despite proper element structure in our FCPXML. Our implementation creates valid clip elements with effects applied, but Final Cut Pro timeline doesn't accept them during drag operations from our ProExtensionHost-based workflow extension. Steps to Reproduce: Create Final Cut Pro workflow extension using ProExtensionHost framework with NSPasteboardItemDataProvider implementation Generate FCPXML with proper element structure: Expected Result: Clip should be accepted by timeline and effect applied from workflow extension Actual Result: Timeline rejects drag operation from ProExtensionHost-based workflow extension Question: Are there additional requirements or ProExtensionHost API calls needed beyond standard NSPasteboardItemDataProvider for Final Cut Pro workflow extension timeline drag functionality?

I'm developing a Final Cut Pro X workflow extension that transcribes audio and creates a text output. I need to allow users to drag this text directly from my extension into FCPX's timeline as titles. Current Implementation: Using NSFilePromiseProvider as per Apple's guidelines for drag and drop Generating valid FCPXML (v1.10) with proper structure: Complete resources section with format and asset references Event and project hierarchy Asset clip with connected title elements Proper timing and duration calculations Supporting multiple pasteboard types: com.apple.finalcutpro.xml.v1-10 com.apple.finalcutpro.xml.v1-9 com.apple.finalcutpro.xml What's Working: Drag operation initiates correctly File promise provider is set up properly FCPXML generation is successful (verified content) All required pasteboard types are registered Proper logging confirms data is being requested and provided Current Pasteboard Types Offered: com.apple.NSFilePromiseItemMetaData com.apple.pasteboard.promised-file-name com.apple.pasteboard.promised-suggested-file-name com.apple.pasteboard.promised-file-content-type Apple files promise pasteboard type com.apple.pasteboard.NSFilePromiseID com.apple.pasteboard.promised-file-url com.apple.finalcutpro.xml.v1-10 com.apple.finalcutpro.xml.v1-9 com.apple.finalcutpro.xml What additional requirements or considerations are needed to make FCPX accept the dragged FCPXML content? Are there specific requirements for workflow extensions regarding drag and drop operations with titles that aren't documented? Any insights, especially from those who have implemented similar functionality in FCPX workflow extensions, would be greatly appreciated. Technical Details: macOS Version: 15.5 (24F74) FCPX Version: 11.1.1 Extension built with SwiftUI and AppKit integration Using NSFilePromiseProvider and NSPasteboardItemDataProvider Full pasteboard type support for FCPXML versions

In Final Cut Pro, keyframes for transform parameters (such as Position, Scale, and Rotation) are automatically set to “Smooth” interpolation. This often results in undesired easing between keyframes, especially when linear motion is required. Currently, we have to manually adjust each keyframe to "Linear" using the Video Animation Editor, which can be time-consuming when working with many keyframes. Would it be possible to add an option to set the default keyframe interpolation to "Linear"—either globally in Preferences or per parameter in the Inspector? This would greatly streamline the animation workflow for many editors. Thank you for considering this request!

FxPlug is one of Apple’s official SDKs, recently updated to version 4.3.2. In theory the SDK should guarantee third-parties can build plug-ins that are backward compatible with older versions of Final Cut Pro, Motion and Compressor. FxPlug SDK includes two frameworks that third-party developers like me end up bundling inside our third-party plugins: FxPlug.framework and PlugInManager.framework. Behind the scenes, the SDK relies on PlugInKit, but the FxPlug.framework provides abstractions so that third-parties don't have to handle the intricacies of XPC directly. The most recent version of FxPlug.framework included with the SDK was possibly built with an error: the Info.plist shows a LSMinimumSystemVersion entry of 14.6, suggesting the binary may have been compiled and linked with MACOSX_DEPLOYMENT_TARGET set to 14.6 by accident. The problem: when older versions of Final Cut Pro or Motion load a third-party plugin (itself built with the appropriate deployment target, macOS 11 or 12, for example) on pre-macOS 14.6, the dynamic linker immediately loads Apple’s own FxPlug.framework, but this causes the process to crash immediately: Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libobjc.A.dylib 0x7ff81e065955 map_images_nolock + 5399 1 libobjc.A.dylib 0x7ff81e0643d6 map_images + 67 2 dyld 0x10bd551fb invocation function for block in dyld4::RuntimeState::setObjCNotifiers(void (*)(unsigned int, char const* const*, mach_header const* const*), void (*)(char const*, mach_header const*), void (*)(char const*, mach_header const*)) + 275 3 dyld 0x10bd506c9 dyld4::RuntimeState::withLoadersReadLock(void () block_pointer) + 41 4 dyld 0x10bd550e2 dyld4::RuntimeState::setObjCNotifiers(void (*)(unsigned int, char const* const*, mach_header const* const*), void (*)(char const*, mach_header const*), void (*)(char const*, mach_header const*)) + 82 5 dyld 0x10bd68d45 dyld4::APIs::_dyld_objc_notify_register(void (*)(unsigned int, char const* const*, mach_header const* const*), void (*)(char const*, mach_header const*), void (*)(char const*, mach_header const*)) + 79 6 libobjc.A.dylib 0x7ff81e064244 _objc_init + 1279 7 libdispatch.dylib 0x7ff81e01d993 _os_object_init + 13 8 libdispatch.dylib 0x7ff81e02b1b8 libdispatch_init + 311 9 libSystem.B.dylib 0x7ff828fd585f libSystem_initializer + 238 10 dyld 0x10bd5ae4f invocation function for block in dyld4::Loader::findAndRunAllInitializers(dyld4::RuntimeState&) const + 182 11 dyld 0x10bd81aad invocation function for block in dyld3::MachOAnalyzer::forEachInitializer(Diagnostics&, dyld3::MachOAnalyzer::VMAddrConverter const&, void (unsigned int) block_pointer, void const*) const + 242 12 dyld 0x10bd78e26 invocation function for block in dyld3::MachOFile::forEachSection(void (dyld3::MachOFile::SectionInfo const&, bool, bool&) block_pointer) const + 557 13 dyld 0x10bd47db3 dyld3::MachOFile::forEachLoadCommand(Diagnostics&, void (load_command const*, bool&) block_pointer) const + 129 14 dyld 0x10bd78bb7 dyld3::MachOFile::forEachSection(void (dyld3::MachOFile::SectionInfo const&, bool, bool&) block_pointer) const + 179 15 dyld 0x10bd81604 dyld3::MachOAnalyzer::forEachInitializer(Diagnostics&, dyld3::MachOAnalyzer::VMAddrConverter const&, void (unsigned int) block_pointer, void const*) const + 466 16 dyld 0x10bd5ad82 dyld4::Loader::findAndRunAllInitializers(dyld4::RuntimeState&) const + 144 17 dyld 0x10bd6165a dyld4::PrebuiltLoader::runInitializers(dyld4::RuntimeState&) const + 30 18 dyld 0x10bd6e76e dyld4::APIs::runAllInitializersForMain() + 38 19 dyld 0x10bd4c38d dyld4::prepare(dyld4::APIs&, dyld3::MachOAnalyzer const*) + 3443 20 dyld 0x10bd4b4e4 start + 388 Can someone at Apple with the right domain expertise confirm that this is the type of crash you would see because the framework was built assuming it would run on macOS 14.6 and later, and when facing an older environment (e.g. ObjC runtime) it lacks extra code that would ensure backward compatibility with the earlier ObjC runtime found on macOS 12.x?