Cocos2D has been my go-to game development toolset/framework for the past 2 years. So not as long as some. I have a game in the App Store using it.
One perspective I can offer is that for 4 years I was a member, then team lead of developers working on an Open GL rendering framework for Qt, called Qt3D. I know how difficult it is to make decisions about the direction of the project, based on guesswork about where the technology is going, keeping existing customers/developers happy who are using old versions, while still adding new features and keeping up with changes in the field. Its damnably hard thing to do.
If it gets changed to Cocos2D-SpriteBuilder, that is not bad because I guess it makes the connection between the two projects, and it elides the language issue, I guess. But I think a year from now, Objective-C is going to be seen as pretty old school, it will be going the way of Carbon and plain C, and as Apple's own engineers are developing more and more of their own internal stuff using Swift - dog-fooding so to speak - we'll see it get better in leaps and bounds. I think the fact that yes you can code for Cocos2D in other languages than Swift - you can use C, C++, even Java or Lua with some integration and bridging, is not so relevant. I think a year from now Swift will be looking pretty good as a name. It will be a good signal to new and current developers that the project is about using a Cocos2D API on environments that support swift.
Regarding the issue of making Cocos2D projects without SpriteBuilder: having a tool create the base project is very important for newbie to intermediate developers getting started with a project. I think its totally reasonable that the Cocos2D team should be able to expect that folks are working from a properly configured baseline, and that is very hard to do if Cocos2D is being pulled in as a framework, or CocoaPod, or drag-n-dropped in. Its very frustrating trying to deal with a request for help when you find that some -Dswitch is missing and you have just wasted hours trying to support some new starter who got their project set up wrongly.
Back in 2012/13 I was working with Cocos2D and used the Xcode templates to create my own template project, that I then saved off as a base for future games. The problem with a project base that I saved off was keeping it up to date when Cocos2D moved ahead with bug fixes and new features I wanted. You can get pretty much the same thing by using SpriteBuilder to generate a base project for you, and it has the benefit that you can update the base library.
I understand that for power users conceptually it seems like OK, I have to get this SpriteBuilder app to create a new project, and then never use it again? I understand that thinking. Also if you've been using Cocos2D from 3-4 years ago when everything was a template, and when there was a CocoaPod, the new tight coupling with SpriteBuilder might seem like some new painful thing that's imposed.
But its a free app, is it really such a big deal? I don't think its really a problem.
I'm not sure that its really such a pain to use SpriteBuilder to do this. I can think of plenty of examples where a tool is used to generate code, either to start a project or as part of one. I've bought the Receigen app to generate my IAP code. Also it is like if I wanted a Rails project I'd type "rails new my_game". There's plenty of precedents for having an application that generates new projects.
Also I don't agree that really big games cannot use SpriteBuilder. SpaceBotAlpha is not that big at 20,000 lines and around 150 CCB files, but its big enough and I find it easy to use SpriteBuilder to include sprites and so on into the project.
The one gripe I have is that the project winds up with a large tree of Coco2D code that I have to lug around when checking in and cloning and so on. There's also a lot of tests and other cruft that I don't want in every game project's repo.
I like @slembcke's project, where you have Cocos2D as a git submodule, and then your way to update to get new features is to update the submodule. I actually have my game SpaceBotAlpha set up with my fork of Cocos2D as a submodule, and its much nicer - although I have to be a bit more aware of what I'm doing with git. I can imagine newbies might get themselves in a knot if they're not used to using git from the command line.
Maybe if Cocos2D-Swift had supported tags for minor dot point releases and a script provided to generated projects to run to update the submodule to those tags that would be good, e.g.:
/Users/sez/my_proj $ scripts/cocos2d-update.sh show
New version 3.5.6 available!
/Users/sez/my_proj $ scripts/cocos2d-update.sh get 3.5.6
And it goes off and runs the
git submodule ... commands needed. SpriteBuilder could use this to do its updates even.