Identifying conflicts with package folders during a Salesforce DX migration.
And this is what it looks like when you click on the Visualforce Tab (this example is within the iPad application). Note the header (with URL) and footer…these do not go away.
In my opinion, the biggest drawback when thinking about the ability to customize Touch is that you have no ability to surface a custom Visualforce page within the context of records. In my experience, navigation to Visualforce pages is done at least 5X as much from a custom button a record rather than a Visualforce tab. In addition, the times that Visualforce tabs are leveraged, they tend to be very data heavy pages. An example of this would be a page that allowed the user to do a mass creation of records at once, something that isn’t normally part of a mobile users use case.
To be fair, Touch shouldn’t be expected to replicate the entire Salesforce experience for users. However, it is pretty easy to see that if you are looking for a more streamlined experience on mobile that fits your business process more closely, you are probably looking at a custom solution. For a really cool example of replicating a day in the life for a user (and cutting out the aspects of a CRM that aren’t used and confuse people), take a look at the New Belgium Beer Ranger Windows 8 tablet application (a really cool use case) or sign up for the Sonoma Partners Mobility Test Drive (my employer, a shameless plug).