Thank you!
One more point to add: I saw that thoughtbot (the Rails agency behind popular gems like paperclip) released a book in 2014 called "iOS on Rails". Looks like it could be a good starting point for you, though it's worrisome that the reviews are not great:
http://www.goodreads.com/book/show/21801253-ios-on-rails
Hey Mitzi! I haven't done this myself, so take my advice with a grain of salt. Typically, when you're using Rails for its back-end features only, you build an API to access the data you need through your front-end (in your case, iOS or Android). With the release of Rails 5, a new API-only mode has been released to make this approach a bit easier. You can read more about that here:
http://edgeguides.rubyonrails.org/api_app.html.
While that may be the standard way to go about this, I know there are a few alternative approaches you might want to consider as well. For starters, I'd look into RubyMotion and PhoneGap.
Hope that's useful - sorry I can't be of more help!
Just one more question then....what do most companies do if they have a ruby site and want to build an app? Is there a better way to use ruby?
If a company wants to have both a web app and a native mobile app, the two both need to run off the same back-end database. This ensures that everything will stay in sync. For example, if a user changes their account password on the mobile app, you need to make sure this new password has to be used to sign in from the web app as well.
The way to set this up is to build a Ruby on Rails app as usual, but then also set up an API to access your database. This API will then be used in the mobile app so that the one database can serve as a source of truth for both apps. Does that make sense?
Yes thank you!