If you want the web front- and back-ends completely separate, just write the back-end as an API using REST or whatever works for you. This could be a CodeIgniter application or whatever makes sense to you. Use the same API for both the web and mobile versions, since the API should just manage data.
For the web front-end, I would probably focus on building a base model that works well with your API, since you're not going to be using the database in the front-end application. Where another application would load the database and use $this->db, your web front-end will be loading CURL or Guzzle and calling the API. So, you would probably build a library to access your data, possibly using a set of methods similar to those used by CI's database library, but managing the data through the API via HTTP requests. You may also want to consider caching the data on the front-end server, which would probably also be a good thing to handle primarily in your library and base model.
You may want to take caching into consideration when defining your API, too. For instance, the client might optionally supply the timestamp of its cached data when requesting that data from the server, so the server could just confirm that the data hasn't changed, or supply the data if it has changed (or if no timestamp was supplied). Of course, you'll also want to make sure those timestamps are all generated with the same timezone information, which means they should probably be supplied by the back-end server, as well.
The mobile application would just call the same API using whatever tools are appropriate for your target device.
The biggest thing to remember, though, is that your API should usually be handling very specific data for each call. If you setup the web front-end to display three distinct pieces of data, you're going to make three API calls to get it. Once you have a working base, maybe you would go back and add a special API call to combine those three calls to optimize your application, but more than likely that's just going to be additional complexity with limited benefit, and you should make decisions like that based on testing your application, rather than assuming that one API call will be faster than three (after all, maybe 2/3 of the data is cached under most conditions).
