This answer, I'm afraid, is a bit off the wall. It depends on your having a really good grasp of programming and also a bit of design. If you have that you might consider proceeding as follows. I'll assume that your student's interest is mostly in gaming, so I'll go with that. But anything of interest to your students would do.
It uses an Agile Software Development methodology, though you don't need to ever say that or even introduce its concepts explicitly. Just do it.
The first step is to work with your student group (or groups) on an overall concept for a game, even a complex one, but not too complex. You could even do a bit of storyboarding for the game. Spend a day or so doing this.
The second step is to some up with some sort of design for your concept, even if it is very rough and not well developed. It certainly doesn't need to be complete since it will morph over time anyway. You will probably need to do much/most of this yourself. Break the concept into parts.
The third step is almost all your job. You need to act as (agile) Customer to your students by taking the design and breaking it into small tasks, each of which can be done in a day or so. Write these tasks on index cards. You will need to spend a hard week-end doing this. Some of the tasks will be programming and some will be other things (creating or finding graphics, say). You don't need a complete set of cards for the whole thing. You can add and delete cards as you progress. Using index cards makes this easy.
Since the visual is a motivator, make sure that your task breakdown makes it possible to see something early on - as early as possible. This can be as simple as a background pattern, but something moving (for a game) would be better.
Now the students can actually start development. Give a pair of students a task card and have them build just that. Make sure that your pairs of students are working on tasks that seem to fit together so that the work of several pairs can be integrated. Try to switch pairs frequently so that each student gets to work with different people. They won't get stuck so much and can help one another. Learn something about Pair Programming also so you can help them do it properly.
In other words, you grow the application organically. You can change the design at any time, making it more or less complex depending on how the students are doing. The steps are small, but they add up. Use the original concept as the incentive and organizing force to keep the students engaged. Have frequent "meetings" with students to get their feedback on how to proceed. Talk about what is working and what is not.
I'm willing to expand this if comments suggest it would be useful. But the original concept for the app needs to come from your students with your guidance. I'd suggest not making it too small or trivial. They don't need to complete it to be successful personally.