There are two fundamental reasons for using ORM tools. Knowing which one applies to you makes the decision easier.
Many people use automatic mapping because they don't want to deal with database access at all. Maybe they don't understand it, or they don't want to think about it, or they are certain that they will never require any functionality that goes beyond the lowest common denominator of relational persistence that ORM can give you. In that case, this is a useful trade-off: less development work on peripheral issues equals more time to spend on developing core issues. The price, of course, is loss of control and expressiveness for advanced persistence strategies - usually, you'd hope, precisely the advanced stuff you weren't going to use anyway.
Others want a strong abstraction from the actual data storage because they anticipate that they might change their database, or have to support different engines from the get-go. In that case, the tools help you by ensuring that you don't intermix low-level and business-level logic at all. In other words, all the things that would cause additional work if you later changed databases are automatically prohibited. This is a useful method of enforcing development discipline for things you shouldn't do anyway (but might do by accident). However, the benefits are real only if you actually rip out and replace your persistence provider - otherwise, they contribute to the normal good practice of layering/not repeating yourself etc., but not more than that. If you're on a mobile platform and have no choice in which database will power your app, then this motivation doesn't really make sense.