[byoung2]

I would store it remotely using an api, but cache it locally on the device. Storing it remotely makes it easier on users when they switch devices or want to view their data on a computer. You also get the option to send out alerts (email and push notifications) if the data is on a server. There could be some revenue possibilities there (sending out targeted offers for massage or smoothies after workouts, etc). You can also play with analytics on the workout data (e.g. if there are enough people, see how they compare to each other, see activity level by location, etc).

You may be able to use a PaaS backend like Parse to power your API.

[scribbles]

I agree with just about every bit of that :) Thanks for the response! I think this makes the most sense, remote with some sort of local caching. Leads to a bit more implementation though and questions like:

1) What happens when they post something but don't have internet, would it store locally then sync up when it can? Or, just not allow posting without internet (curious how many people workout with an iPod Touch).

2) What happens when we get a new call from the remote server, kill the local table entirely or have some field on each record like "synced" that lets you check for records that need to be updated still?

Anyways, just a few things like that but thanks a ton, you gave me some more things to think about :)