Wednesday, October 5, 2011

Real Studio, Cocoa and LLVM

Our new Cocoa-based framework for Mac OS X made some big leaps forward in Real Studio 2011 Release 3. And we continue to hear good results from our beta testers that their projects are running fine under Cocoa. We have set up a way for beta testers to alert us to any showstoppers that may prevent them from shipping their apps. Needless to say, we are prioritizing these to maximize the number of Real Studio developers that will be able to ship Cocoa-based Mac apps using our next release. This is important because starting in November Apple is placing additional restrictions that will require apps submitted to the Mac App Store to be built with Cocoa. To be clear, it's not that they are requiring Cocoa; it's that Carbon apps don't seem to be stable when built with the new restrictions Apple is requiring. To further our efforts to get Cocoa into the best shape we can for our next release, we are adding additional engineering resources.

Real Studio 2011 Release 4 will ship in November. Our Cocoa support will still be considered beta for that release. Our criteria for it to no longer be beta is that we are comfortable making Cocoa the default option for building for Mac OS X. However, although it's beta, there's a very good chance that your projects will work perfectly using the Cocoa build option so give it a try and give us feedback.

There will be more Cocoa bugs to fix for 2012 Release 1 and there are two additional features that need to be implemented for that release as well: the movie player and drawers. However, we are quite confident that 2012 Release 1, scheduled to ship in February, will bring our Cocoa support to the point where we can remove the beta label. That will be a real milestone for us (no pun intended) as the transition to Cocoa has been a long one.

Once Cocoa is no longer beta, we will return to working on our transition to LLVM for our compiler backend. While we have been focused on Cocoa, the LLVM team has been improving LLVM - and this is great news for us and you! Hooking up the Real Studio debugger was estimated to take us at least a month, due to a significant amount of work required to parse the LLVM metadata. Fortunately, the LLVM team has done this work for us which means LLVM for Real Studio that much closer.

Finally, I'd like to thank all the beta testers who take their time to help us improve Real Studio. Thank you! We really appreciate your efforts and we look forward to putting out the new releases you need.


Thomas said...

I am pleasantly with r3's Cocoa state. My app Find Any File had always had a lot of problems in Cocoa, but in r3 all these problems are solved.

The only remaining problems I can see are outside the RB framework: There's a visual problem with Einhugur's DatePicker control (i.e. a plugin problem) in that it doesn't show a Focus Ring, a problem with me using old QuickDraw code to display icons and one with using declares to use global hotkeys on OSX.

Which means I still have work to do, the Cocoa transition doesn't come for free, but at least it's now all in my hands, and that's a good situation to be in.

Redcort Software said...

Hey Geoff,
Many thanks for the extra resources you're committing to getting Cocoa out of beta. Your confidence going forward is a great encouragement!

ruffin said...

What are the details of "Carbon apps don't seem to be stable when built with the new restrictions"? How will this affect those who are building in Carbon for the MAS now?

If we swap to Cocoa in 2011R3, what are the "gotchas" that we should be ready to fix in our apps? That is, what's the best way to find the reasons Cocoa is still considered beta?

Didn't realize the MAS would (in practice) stop allowing Carbon in November. Can we make sure 2012R1 gets released before my subscription expires on 2/16? ;)

Geoff Perlman said...

@ Ruffin - Any Carbon app, no matter what tool it was made with, it's going to have problems if it uses Open and/or Save dialog boxes. They crash frequently when the app is sandboxed. It's possible that Apple will fix this problem in an Lion update but that has yet to happen.

As far as Cocoa gotchas are concerned, the two bigs ones are that the MoviePlayer and drawers are not yet supported. Other than that, test your app (sooner rather than later) using the R4 beta and let us know ASAP what problems you run into that are showstoppers for your app to be in the Mac App Store.

If you are not planning to ship your app through the Mac App Store, please test your app in Cocoa and report your issues as well but we are trying to focus on the showstoppers for those that are planning to submit their apps to the Mac App Store.

Mark said...

Geoff, is there any immediate plans to begin supporting the iPad? I know LLVM makes that technically possible but do you have anything in the works now to actually make it a reality? If so, how far down the road is iPad support?

John DeHope said...

I realize this is an older post, but I think it's a good place to ask. Is there any hope of getting a new language front end, once the back end is sufficiently stable as LLVM? It's my understanding that one of the nice things about LLVM is that once you're building on top of it, you can switch in and out of front end languages with ease. The 'basic' in RealBasic is a deal killer for me and I've always been waiting for the day when I can code with a more modern syntax, cross platform, with a nice base library, in a good IDE. RealBasic has all of that except the syntax.

Geoff Perlman said...

@ John - Our language is really not BASIC. It shares more in common with Java and VB than it does with BASIC. Having said that, where it is similar to BASIC is that you don't have to use pointers or remember a semi-colon to end a line.

What is it about our language that is a problem and what language would you prefer we support?

EB said...

Hi, any update on the LLVM project? Would be nice to know progress is being made since I see demand for native iPad/iPhone apps in factories now, and, of course, making widgets in American factories is the only way to pay off the debt. Why native? For the industrial apps in factories, the app must retain its state and be multitasking friendly and be able to be secured.