#
2026
#
February
#
2nd February 2026
Happy Monday!
I've added a new section to FCP Cafe, under the Learn category called Immersive.
I'm currently really interested in adding more deep Immersive support for Blackmagic URSA Cine Immersive cameras via BRAW Toolbox, because... I can?
Currently the only way to edit Immersive is in DaVinci Resolve, and that just seems plain wrong, given you have to export a FCPXML from DaVinci Resolve to output Immersive in Compressor!
I'm currently busy attempting to rewrite, refactor and improve the rendering engine in BRAW Toolbox for better performance on Apple Silicon, to make working with 16320x7200 @ 90fps Immersive files a bit easier.
Hopefully I'll be able to start releasing these improvements to BRAW Toolbox over the coming days or weeks.
I'm also busily trying to get CommandPost working smoothly on Final Cut Pro Creator Studio. It's working on the lifetime/perpetual license of Final Cut Pro, for the most part - although there are some broken features.
Hopefully we'll push out a new version of CommandPost very soon, and have more regular updates over the coming weeks.
Also, in BIG CommandPost news, I posted in the CommandPost Discord this morning:
As a followup to my message in June last year... In July last year a tree fell on our house, and caused chaos - we're still waiting on one last tradie to fix the last item up. Needless to say, the last 7 months or so have been a bit of a rollercoaster personally, which meant I didn't get to spend as much time on unpaid CommandPost as I would have liked.
I also had several attempts to try and get CommandPost into the Mac App Store using all kinds of crazy tricks and workarounds, but alas, I kept on hitting roadblocks. Whilst I think it is TECHNICALLY possible to get CommandPost onto the Mac App Store - it would require a major rewrite, and as CommandPost currently generates no money, I don't have the cashflow to spend a year rewriting CommandPost with no income coming in.
So the Mac App Store currently falls into the too hard basket. After seeing how much work was required building a website and online store for Jumper, I also don't want to roll my own online shop and licensing system.
Given this, I think the EASIEST, cleanest and probably most fair solution is that CommandPost basically comes bundles with LateNite's paid apps - essentially, as long as you own ONE of LateNite's paid Mac App Store apps, then you get CommandPost for free. So the most you'd be paying is USD$9.99 - which I think is kinda bargain for the decade of development on CommandPost.
It'll remain free and open source, so if you want to save USD$9.99, you can always build it yourself (although if you consider your time, it's probably more expensive to build yourself, haha).
I'll try roll this out in the next CommandPost update and see what happens. Old versions will continue to work as always.
This means the next version of CommandPost will be v2.0.0 and you'll need at least ONE paid LateNite application installed for it to launch.
Recently in a private Discord I posted the below, in reference to Final Cut Pro's future updates:
They still need to rewrite a LOT of their code in modern Swift. Until we see third party Motion Templates come to iPad, I think there's still a lot of under-the-hood work that needs to be done.
As usual, the amazing Joe Marler came back with some more information and deep thought:
This is absolutely correct. They cannot "just do it" on the current code base. As you and I have mentioned, a deep study of FCP and private framework internals shows that the current language mix as of FCP 12.0 is still about 39% Objective-C, 47% C++ and 14% Swift. The key framework "Flexo" is 88% Objective-C, 12% C++ and 0.1% Swift. The current design intermixes pthread and GCD concurrency models. XCode Instruments shows there are long, compute-intensive code paths on the main thread, a key contributor to "beach balls." The data persistence model needs major work. 15 years ago the FCP codebase was an efficient, elegant implementation on that era's hardware. Today it needs major changes, and this is reflected in the recent Apple job ads for Sr video engineers. The terminology in those ads targets closely the weak points revealed by internal code studies.
They couldn't do this before because Objective-C was aging, new work in C++ should be reserved for performance-critical sections, and Swift was immature. The macOS frameworks are also evolving. If FCP development wanted to add distributed collaboration, it would not make sense to implement that solely in FCP if the macOS and cloud frameworks are developing that infrastructure.
Overall, the path forward is doing as much in Swift as possible, especially Swift Concurrency. Study of many crash/hang situations reveals many are caused by thread concurrency issues such as "use after free" or other race conditions. Swift Concurrency could eliminate much of that. Swift is now getting mature enough to undertake major FCP rework, but that is fairly recent. Recent Swift versions have improved bridging to properly build mixed Objective-C/C++/Swift methods, but that has only existed for about a year.
Resolve is written 100% in C++ using the Qt cross-platform framework. They can add whatever they want, whenever they want. But there is a reliability cost. Since they strip all symbols from the executables, the macOS crash dumps don't have any understandable data. Only their single internally-built ResolveDebug.txt file has a symbolicated trace. This is a hidden burden on problem tracking and resolution in the Mac environment. FCP is much better in that regard.
Joe also commented on a receipt FCP Cafe news entry with:
These are the differences in method names per language between FCP 11.2 and FCP 12.0 for all the private frameworks. This is only an approximation based on analysis of symbol syntax. Method = function (loosely speaking).
For comparing 12.0 vs 11.2, the first number is total number of methods in the newer 12.0 version. The (+) number in parentheses is the number of added methods between 11.2 and 12.0, and the (-) number is the number of removed methods. I didn't examine the Creator Studio version, but Chris posted those above.
The biggest difference was in added Swift methods. That is expected since the goal is apparently to write new functionality in Swift where possible. That is consistent with the previously-mentioned job postings.
While Swift has good performance and reliability advantages, for performance reasons, it's unlikely the product could be fully rewritten in Swift, thus the continuing C++ work.
(+n) = methods added (-n) = methods removed Framework | Obj-C | C++ | Swift --------------------------- | ------------- | ------------- | ------------- AECore | 173 (-1) | 3247 (+38) | 0 AppAnalytics | 361 (+55) | 0 | 2931 (+662) AppleMediaServicesKit | 58 (+16) | 161 (-15) | 1598 (+316) CloudContent | 682 (-7) | 0 | 6814 (+405) Compressor | 6178 (+14) | 16325 (+4343) | 289 (+289) CompressorKit | 7682 (+21) | 33140 (+4547) | 289 (+289) AECore | 173 (-1) | 3247 (+38) | 0 BatchActions | 81 (-1) | 622 (+29) | 0 ClusterManager | 0 | 246 (+3) | 0 Compressor | 6178 (+14) | 16325 (+4343) | 289 (+289) CompressorKit | 1289 (+3) | 401 (+23) | 0 ContentControl | 0 | 1414 (+25) | 0 DistributedObjects | 777 (+7) | 2159 (+26) | 0 ImageProcessing | 38 | 663 (+4) | 0 JobControl | 20 | 2970 (+41) | 0 MediaServerAPI | 0 | 304 (+3) | 0 Qmaster | 1331 (+8) | 13264 (+163) | 0 RequestProcessing | 0 | 399 (+9) | 0 ServiceControl | 0 | 569 (+12) | 0 Status | 0 | 420 (+3) | 0 StompTypes | 57 | 5402 (+67) | 0 StompUI | 4471 (+12) | 1571 (+86) | 0 StompUtil | 28 | 142 (+7) | 0 SwampCore | 42 | 1335 (+2) | 0 SwampService | 0 | 348 (+2) | 0 SwampTypes | 282 | 2901 (+24) | 0 SwampUI | 209 | 194 (+12) | 0 SwampUtil | 1 (+1) | 309 (+4) | 0 Transcoding | 214 | 7524 (+4127) | 289 (+289) EDEL | 20732 (+5) | 46127 | 13248 (+217) ChordsKit | 0 | 0 | 7670 (+217) MAFiles | 835 (+5) | 472 | 186 EmbeddedRemoteConfiguration | 1004 (+1004) | 0 | 44 (+44) Filters | 3155 (-13) | 7454 (-121) | 0 Final Cut Pro | 3493 (+105) | 13 | 4836 (+3158) Flexo | 66234 (+1549) | 12945 (+94) | 1229 (+894) AnalysisKit | 36 (+36) | 0 | 697 (+697) AudioAnalysis | 90 (+32) | 0 | 348 (+95) ProResRAWConversion | 0 | 767 (+4) | 0 FxPlug | 1299 (-10) | 264 (-1) | 0 FxPlugProvider | 156 (+19) | 58 | 0 Helium | 3 | 14925 (-159) | 0 HeliumSenso | 216 | 7739 (+27) | 0 Interchange | 2401 (+12) | 0 | 10769 (+91) Lithium | 20 (+1) | 10082 (-839) | 0 LunaKit | 7162 (+37) | 705 | 0 MDPKit | 774 (+53) | 429 (-4) | 0 MIO | 2145 (+1) | 823 | 0 MediaServerAPI | 0 | 304 (+3) | 0 MotionEffect | 1318 (+113) | 807 (+20) | 0 MusicUnderstandingEmbedded | 12 (+12) | 0 | 1917 (+1917) Ozone | 10967 (+248) | 38575 (+329) | 6550 (+6550) PAECIAdaptor | 0 (-51) | 0 (-10) | 0 PMLCloudContent | 9 | 0 | 566 (+1) ProAppSupport | 111 (+111) | 0 | 428 (+428) ProAppsFxSupport | 1621 (+40) | 3700 (-271) | 0 ProChannel | 704 (+1) | 7075 (+2) | 0 ProCore | 820 (+242) | 5259 | 0 ProCurveEditor | 1010 (+1) | 291 | 0 ProExtensionHost | 176 (+6) | 0 | 0 ProGL | 0 | 1427 (-1) | 0 ProGraphics | 3 | 1112 (-41) | 0 ProInspector | 1528 (+6) | 554 | 0 ProMedia | 3 | 2957 (+3) | 0 ProOSC | 1048 (+108) | 1642 (-337) | 0 ProOnboardingFlowModelOne | 95 (+95) | 0 | 1173 (+1173) ProShapes | 79 | 1870 (-3) | 0 ProTracker | 633 | 3049 (+3) | 0 Qmaster | 1331 (+8) | 13264 (+163) | 0 RegisterProExtension | 22 (+4) | 0 | 0 SwiftASN1 | 0 | 0 | 913 (+913) TextFramework | 1409 (+45) | 7682 (-32) | 0 TimelineKit | 6989 (+43) | 121 | 0 USearch | 25 (+25) | 594 (+594) | 41 (+41) VAAppAnalytics | 0 (-218) | 0 | 0 (-5027) VAML | 697 (+207) | 34 | 351 (+351) VAMLSentencePiece | 2 (+2) | 3329 (+3329) | 0 Overall language distribution changes: Objective-C: 149409 (++3888, +2.67%) C++ : 225095 (++7114, +3.26%) Swift : 55389 (++12423, +28.91%)
He also posted some Xcode Instruments traces for those that want to get really deep in the inner workings of Final Cut Pro.
Long story short... Apple still has a LOT of engineering work to do under-the-hood, so I don't imagine we'll see a dramatic change in the update schedule over the next couple of years - I think it will continue to be slow and steady.
The FCP Vietnam Community has also reported that Apple is finally checking for valid App Store receipts when launching Final Cut Pro - so you can no longer just "steal" Final Cut Pro with a USB-C when visiting the App Store.
Final Cut Pro has always been really easy to share. Final Cut Pro 7 and earlier just had a license key that could be used unlimited times (although only one license could be activated on the same local network at a time).
Final Cut Pro v10 has only ever been on the App Store - but no actual verification ever took place after the initial download.
Apple also offered a very good free trial, which was also trivial to reset the trial period by just deleting a hidden file on the filesystem.
It seems Apple now wants to make SURE you're purchasing. I wonder if this applies to all of their paid Mac App Store apps now?