Chris Jones' solution of replacing 'localhost' with '0.0.0.0' worked for me.  I setup an Ubuntu 14.04 server on my Mac using Vagrant then installed Foundation for Apps with a shell script in Terminal.  (Faster than typing the commands if you have to do this multiple times or setup colleague's computers.)  In a browser on my Mac, the host machine, I could get localhost:8080 to work with NGINX and Apache but Foundation for Apps wasn't showing the welcome screen in localhost:8079.  I struggled for a couple of days until I found his post.
 
My shell script for whoever needs it.  Put setup.sh, a text file, in your dev folder, type chmod +x setup.sh
to give execute permission to the file, then type ./setup.sh to start the script.  If you need to change folder permissions type  sudo chmod 777 .  in Terminal and include that period.      
 
#!/usr/bin/env bash    
clear
printf "Hi $USER!\n\n"
printf "I'll setup Foundation for Apps for you.\n\n"
printf "First let's setup a git repository in your project folder.\n\n"
printf "Enter your email address:\n\n"
read addr
printf "Your email address is $addr.\n\n"
git config --global user.email "$addr"
printf "Enter your first and last name:\n\n"
read name
printf "Your name is $name.\n\n"
git config --global user.name "$name"
printf "Setting up your local git repository.\n\n"
sudo git init
printf "Setting up F4A globally!\n\n"
sudo npm install --global foundation-cli
printf "Next, answer a couple of questions to setup Foundation in your project file.\n\n"
foundation new

Alec, did you find an answer?  I'm getting the same message setting up F4A on a Ubuntu 14.04 server.  I'm using Vagrant to setup servers and don't want the workflow Jules suggested.  I don't want manual fixes for my front-end developer.

I suspect that the answer would be one of the solutions here:
http://stackoverflow.com/questions/11541695/redirecting-to-a-certain-route-based-on-condition

I think with one of these solutions I would leave index.html as the main app page and the initial template would be home.html as per the original F4A setup. However, one of the above solutions would check to see if the user is logged in and if so then select the route to the dashboard and load it immediately. A logged in user should see the home page / log-in at all.

I can do basic CRUD and that is most of my app but this much JS is much more than I've needed in the past. Good stuff but not easy to grasp at first.

There is no reason that someone logged in would want to see the home landing page again unless they logged out or changed computers. I'll leave a cookie at log-in to let them see the Dashboard first when logged in.

I guess index.html could be the main page if everything on it could be replaced by the Dashboard. I'm not far enough along this road to figure that out yet.

FYI post so anyone finding this thread has more diagnostic info:

The problem came back. Somehow I'm breaking http://localhost:8079 easily. Either ui-routing or the server is a sensitive beast. Chrome is more sensitive than Safari and Firefox. I couldn't get anything to show in index.html after doing the following and re-gulping.

1) I added a couple of folders to /templates and named them like /_partials. I removed them and it didn't bring the server or routing back to life. I restored them after the solution below and all works well now. We can add sub /folders and /_folders and the server and routing can handle this.

2) I created some new pages by duplicating a mostly empty one with the usual routing at the top and a and with a little text in them. Nothing on the page could break anything. Right?

I found one of the new pages with the same routing as another. This seems to cause the system to fail. Not like I found a lot of divine guidance in the Angular documents so maybe this thread will help someone.

The problem was fixed by adding the Livereload extension in Chrome and the following:

I put a /temp folder in /client to store html files that I need to rework from F4S. Gulp copied this folder to /build. When I moved that folder out to the root and Gulped again then all browser display a mess, but that is the F4S formatting in F4A. I can fix that.

So the moral of the story is don't screw with the /client folder. It is sensitive to "creativity". At least it is for newbies. Of course the Gulpfile could be modified if necessary but easier to move my temp folder to the root.

Thanks Rafi. I didn't have a Livereload extension, didn't know I needed one. It works now.

Additional info: My /build contains all the properly updated files with the partials living in /client/templates/partials. index.html lives in /client/index.html.

/build/assets/js/ contains app, foundation, routes, templates all dated for the last save.

I'm developing on my MacBook Pro with Coda 2 for my IDE but using Gulp, not their preview mode. To develop the front end do I need a more robust server for the includes and views than the simple dev one in Coda?

What else can break F4A / AngularJS??

I saw the F4A splash page after setup and I was careful not to change anything but the html from that start. Nothing in js yet.

Thanks James, and thank you for your video tuts!

I think I was trying to update from the root above /foundation. Yeti Launch put me in /foundation.

I looked through all the directories and files and didn't seem much with recent dates but maybe that is supposed to be that way.

At the bottom of a bunch of processes I have this in Terminal:

bower extra-resolution Unnecessary resolution: foundation-sites#~6.1.1
bower install foundation-sites#6.1.2

foundation-sites#6.1.2 bower_components/foundation-sites
├── jquery#2.1.4
└── what-input#1.1.4

bower.json was updated to 6.1.2. I assume that this means all of Foundation was updated in this process but Terminal didn't display files being updated.

Below are the first processes above what I posted above.

bower update
bower cached git://github.com/zurb/foundation-sites.git#6.1.1
bower validate 6.1.1 against git://github.com/zurb/foundation-sites.git#~6.1.1
bower cached git://github.com/zurb/motion-ui.git#1.1.1
bower validate 1.1.1 against git://github.com/zurb/motion-ui.git#~1.1.0
bower cached git://github.com/jquery/jquery-dist.git#2.2.0
bower validate 2.2.0 against git://github.com/jquery/jquery-dist.git#~2.2.0
bower cached git://github.com/jquery/jquery-dist.git#2.1.4
bower validate 2.1.4 against git://github.com/jquery/jquery-dist.git#~2.1.4
bower new version for git://github.com/zurb/foundation-sites.git#~6.1.1
bower resolve git://github.com/zurb/foundation-sites.git#~6.1.1
bower download https://github.com/zurb/foundation-sites/archive/v6.1.2.tar.gz
bower extract foundation-sites#~6.1.1 archive.tar.gz
bower resolved git://github.com/zurb/foundation-sites.git#6.1.2
bower cached git://github.com/ten1seven/what-input.git#1.1.4
bower validate 1.1.4 against git://github.com/ten1seven/what-input.git#~1.1.2

Please note that,
motion-ui#1.1.1 depends on jquery#~2.1.4 which resolved to jquery#2.1.4
foundation-sites#6.1.2 depends on jquery#~2.1.0 which resolved to jquery#2.1.4
foundation-sites-template depends on jquery#~2.2.0 which resolved to jquery#2.2.0
Resort to using jquery#~2.2.0 which resolved to jquery#2.2.0
Code incompatibilities may occur.

So if I leave an @include commented then it is added to the css. Uncommenting removes it from Foundation? Seems backwards.