Note: The goal of this sticky is to provide a list of steps for users to follow as a stopgap until the Cmd and Architect team can resolve them. The expectation is that the 'Configure Cmd to work with your Architect project' section should eventually disappear.
----
All your hard work is paying off and your app is ready for production or to be put on it's first device. Great! You're ready to use Sencha Cmd utility to build and/or package your app for distribution. In this sticky, I explain the steps required to do this for Architect 2.1 projects:

Download the appropriate SDK and Sencha Cmd software

Initialize Cmd for your Architect applications

Configure Cmd to work with your Architect Project

Build your application

Package your app for production (Touch only)

If you're building a Touch 2.1 project, Architect 2.1 includes a wizard that guides you through step 1 and 2; see here for more information. Step 3 (Configure Cmd...) must still be done as described below.

Download the SDK and Sencha Cmd software
Architect projects by default reference their SDK from the cloud. Cmd however requires the appropriate SDK to be installed locally on your system. You can dowload the SDKs from the following locations:

Initialize Cmd for your Architect applications
To initialize Cmd to work for your Architect applications, you'll need to run the sencha generate command from the directory where the Ext JS or Touch SDK is installed:
open a fresh command line interface (terminal, iterm, cmd.exe, etc ...)
$ cd path/to/sdk (not project)

For the next command you need to specify the name you gave your project in Architect. The default is MyApp. To find out what name you've given it select the Application node in the inspector and find the name config.
$ sencha generate app <projectName> path/to/project

Note that this does not actually generate a new project but instead finds your project and adds the metadata required by Cmd.

Note to users of the SDK Tools v2 utilities:
If you have used the SDK Tools v2 utilities on this project, issue the following cmd to upgrade to Sencha Cmd:
$ cd path/to/project
$ sencha app upgrade path/to/sdk

Configure Cmd to work with your Architect project
Some changes will need to be made for your Architect project to work with Cmd. Find the section that corresponds to the project type you're working with below and follow the steps in order.

Ext JS ProjectsUpdate your sencha.cfg file
By default, Cmd expects Ext JS projects to have their app.js file located in the app/ directory. Architect saves that file instead at the root of the project. The sencha.cfg file defines this location in the following line:

Code:

# .sencha/app/sencha.cfg
app.classpath=${app.dir}/app

For Architect Ext JS projects, modify this line in the sencha.cfg file to look like the following:

Remove extra files - new
Cmd will create 2 files that can be a real headache if you don't remove them
app/app.js <-- this file will throw Cmd for a loop so be sure to remove it
app/view/Main.js <-- only remove this one if you didn't have your own Main.js view

Windows

Code:

del app/app.js

Nix

Code:

rm app/app.js

Update your index.html file
Update your index.html file to define the locations of the .css and .js files, similar to the definitions given in the app.html file created by Architect. Note that the declarations for the .js source files should be located between the x-compile tags:

Packaging your app for production (Touch only)
To package your app for devices you'll want to carefully configure your packager.json file either using a text editor or using Architect and the Cmd Wizard. Once you've done so you can run:

$ sencha app build native

GotchasI have no idea what went wrong after a sencha command - new
Try using the debug flag

$ sencha -debug blah blah blah

This will give you extra output to figure out what's going on

Too much output? Redirect it to a log file

$ sencha -debug blah blah blah > log.txt

Cmd can't find my javascript files?
if you change your appFolder you'll need to make that change as well in the classpath of the sencha.cfg file. As there will be no files in app/ they will be in <appFolder>/

White screen while simulating or installing on device when using Charts
You'll need to add Ext.Chart.* to your Applications requires config. Select the top most node in the inspector and located the requires config in the config pane. Add Ext.chart.*

Extra file Main.js
Cmd's generate command can sometimes create an extraneous Main view (app/view/Main file); you can just delete this file.

Error while simulating
You may see the following error when using the iOS Simulator:

Maybe a bit cumbersome, but my approach is to do a deploy to a separate directory and then I check in this directory in a different path in subversion.
I have the SA project in svn://host/project/trunk and then the deployed directory is checked in to svn://host/project/deploy When I then build a release I tag the deploy svn path to svn://host/project/tags/version
I export the tagged directory and then run it through Sencha Cmd for release.

If you are already running deploy, what's the purpose to run cmd on the deployed folder? Sounds redundant to me.

I really hope there is a solution that would:
1) eliminate the need to check in generated code, and
2) allow an automated build to compile and deploy js files from just xds and metatdata

Originally Posted by tangix

Maybe a bit cumbersome, but my approach is to do a deploy to a separate directory and then I check in this directory in a different path in subversion.
I have the SA project in svn://host/project/trunk and then the deployed directory is checked in to svn://host/project/deploy When I then build a release I tag the deploy svn path to svn://host/project/tags/version
I export the tagged directory and then run it through Sencha Cmd for release.

If you are already running deploy, what's the purpose to run cmd on the deployed folder?

This is part of a bigger build-script that replaces the app.html and (among other things) change to the non-debug version of Ext JS, adding build tags, setting correct paths to Amazon CloudFront etc. Stuff that SA doesn't do.