You will 9 times out of 10 be better off if you design the site so that you can use the same codebase for any device, so that it adapts intelligently to your device, and so that it renders the most important/useful content/functionality for each device based on stylesheets or runtime choices of rendering/non-rendering. Remember that, unlike 6 years ago, your primary concern with mobile devices today isn't lack of processing power, but rather a different screen size and different input.
Generally, mobile users do not want to be seeing a crippled or stripped version of your site. They want to see a usable version of your site. What Usable means varies, but it often means that the most frequent functions are very easy to access, while the more obscure options are buried a little bit lower or perhaps not quite as optimized. Usable might mean that you give them exactly the same functionality as on a desktop, but styled to present better on the mobile. Or that you cut out things that make no sense on a mobile. But you'll be making it much harder for yourself if you set it up so that you have to maintain two code streams, or one code stream that branches very early on, or a fundamentally different application. It's a lot more testing, a lot more coding, and a lot more likelihood of breakage.
We follow this approach, and it works well for our very small development team -- we've successfully used it so that we can use the same codebase to run two different implementations for different customers -- one a very complex desktop-first UI as well as a very streamlined mobile-first app:
- assume that all devices will access the same URL
- assume that 90% of device optimizations will be done using CSS media queries, 7% will be done using jQuery hacks, and 3% will be done using browser detection very early on
- build your application so that the individual UI components or modules can be easily enabled/disabled through code (logic in ApplicationController? Rack Midleware?). We do this by putting our individual "widgets" in partials that are wrapped with checks for enablement of the widget (either in Rails.config or as an instance variable in side ApplicationController) so that we can turn off whether we return the corresponding HTML back to the browser
- use CSS media queries not only to style fonts and widths but also to rearrange menus/functions and other UI items so that they work on the different form factors you require
Generally, the API-for-mobile approach will be of most use to you if you're going to be building a compiled app for a mobile device and are going to be doing the heavy lifting on the UI using the device's UI libraries rather than HTML generated on the server. Then again, if you choose to use an approach such as Backbone.js or Angular.js to handle your front-end display, then going with an API-only approach MIGHT be also a good architecture for you to follow. But then you're stepping outside of Rails a lot more.