Sensible Cocoa STV 4.0 is a framework that allows you to create native data-driven apps for iOS by defining your data model and then visually binding it to your UI in Xcode. Sensible Cocoa claims that “developers save on average about 70% of their development time when they start using STV in their applications.” InfoQ has talked to Sensible Cocoa founder Tarek Sakr to learn more about their product.
One way of describing Sensible Cocoa is as “Cocoa Bindings on steroids” for the iOS platform. Cocoa bindings “provides a means of keeping model and view values synchronized without you having to write a lot of ‘glue code,’” and is a key part of Cocoa programming on OS X. Cocoa Bindings are not available on iOS, though, and this usually leads to writing more glue code on iOS to, e.g., bind a table view to its Core Data entity, whereas the same task can be accomplished on OS X almost without writing any code to handle the data binding.
The lack of Cocoa Bindings for iOS led to the creation of many open source frameworks attempting to port Cocoa Bindings to iOS. What differentiates Sensible Cocoa STV 4.0 from other solutions is its tight integration with Xcode, so it feels like a natural extension to Interface Builder. Indeed, STV 4.0 allows you to add entities to your Storyboard to represent your data model, so you can visually bind them to your UI elements and customize them to suit a wide range of possibilites. E.g., an interesting choice made by Sensible Cocoa to allow table view cell customization is the use of curly braces to bind individual UI controls such as labels to entity attributes.
STV 4.0 supports using Core Data, iCloud Key-Value Store, Parse, and REST services sources for your data, as well as the basic NSUserDefaults store provided by iOS.
InfoQ has taken the chance to speak to Sensible Cocoa founder Tarek Sakr to ask him a few questions about STV 4.0.
On top of bindings, STV offer a very advanced visual framework deeply integrated with Xcode. Could you share some details about the way this is accomplished? Are you using IBInspectable / IBDesignable in oder to ensure stability with future Xcode versions?
The visual part was by far the most complicated part of STV to implement. We’re actually not using any IBInspectable/IBDesignable features at all, since what we needed was much more than these two can provide. To list just a few of our visual development requirements:
We needed to add our own custom objects to Interface Builder’s object library and have the user drag & drop them onto their scenes.
We needed to be able to customize the visual representation of these objects on IB’s canvas once they’ve been dropped.
We needed to create our own object trees in the document outline (the part to the left of IB’s canvas) to be able to represent data definitions in them.
We often needed to implement our own custom controls in the Object Inspector.
Because of the above and many other factors, we ended up developing this as an Xcode plugin, following the exact scheme that Apple does to add their own stuff to IB. This is of course not documented at all, and we’ve spent many months trying to figure everything out.
Can you explain what led you to focus on table views as a start? And what is your current roadmap for STV and more in general for other similar products?
STV started four years ago with focus on table views since they are the backbone of almost any iOS non-game application. STV has now evolved into much more than just table views, but still held on to the Sensible TableView name.
As for our road map, here are a few of the stuff on our pipeline:
Apple Watch components: We want to port a lot of our much loved STV iOS components into the Apple Watch framework. This way, STV apps developed for iPhone/iPad can effortlessly also be extended to run on Apple Watch.
An STV version for the Mac: Again, our vision is to enable our users to deploy their existing iOS STV apps natively on OS X, and vice versa.
Live Design: This is a very experimental feature that we’re still toying with. What we want is for our users to see a live running version of their app while they’re still designing it in Interface Builder, all with their live data right in the scene UI. This will potentially save them a lot of the time wasted in compiling and running on the simulator to visualize their end results.