I've been using SpriteBuilder for several months while developing Shift Escape and - let's cut straight to the chase - it's good. It's easy to use, efficient, and capable. SpriteBuilder is a free Mac App Store application providing an environment for authoring 2D games for iOS and Android. I'm more familiar with the iOS side so I'll concentrate on that, but note that Android development is only supported via a plugin where some features are provided free, others are paid for.
SpriteBuilder doesn't do everything - in order to create a game, Objective C and/or Swift programming skills are required. To aid the programmer, SpriteBuilder includes and uses the popular open source Cocos2D library, and this is now the recommended way to get and use Cocos2D. I should clarify I'm talking about Cocos2D-Swift which is for writing games in Objective-C and/or Swift. Other language forks are available but they don't integrate with SpriteBuilder.
SpriteBuilder is used to author and arrange 'nodes' (sprites, buttons, text, etc) hierarchically within scenes, author animations, apply physics, manage the game's assets (sprite sheets, audio etc), and link properties to relevant Objective C classes in XCode. SpriteBuilder helpfully creates the required XCode project at the start with all the relevant boilerplate code and the Cocos2D-Swift library code ready to go. The developer adds game specific code from there.
The workflow works smoothly. When you update something in SpriteBuilder, you press the publish button, which incrementally builds any changed assets into game ready formats for each platform. Then you switch to XCode and compile and run from there.
The hierarchy of nodes concept is strong. Each node has a name, position, rotation, scale, skew, anchor point, and content size. As a developer, obviously you can group together several nodes as children of a single parent in SpriteBuilder and they will all move together when the parent moves. You can also do the same thing in code to create a custom reusable node type. If for example you want a button that represents a single level in your game (as part of a level selection scene for example), then this can be assembled from several child nodes. It may have a button, an icon, text, a gold star when you complete it, or a padlock if it's not yet been unlocked. All these elements can be created in code as child nodes of a parent class that derives from the base CCNode type.
The UI lets you see how the game will look on different sized devices from the iPhone4s to the iPhone 6+. Nodes can be positioned relative to a corner of the screen for instance, so you can reduce the amount of code you need to keep the game looking good across all devices. One limitation is that you must choose whether your game will run in portrait or landscape - you can't support both orientations in the same game.
In the future, I'd like to see some Visual Scripting support (e.g. like Blueprints in Unreal Engine) added. Visual Scripting defines the behaviour of nodes without programming, making it quicker and more accessible to a larger audience of designers and other non-programmers.