I’m thinking - per some other comments above - that you’re going to want to use a remote service for the database. Unless it’s a really static set of data, and there’s little to no chance of it needing updating in a timely manner.
I’d assume _most_ apps need data that’s easier to maintain than submitted new builds to Apple, and/or needs to be more up to date. Plus, by using a remote store, you open up your system design for web interfaces, other mobile clients, service interfaces to share with other system, etc.
If you have a requirement of offline data access, that doesn’t mean you still wouldn’t want to use a remote store, it just means you’ll need to consider some kind of sync, i.e., fetching the remote data into a local store, and updating with whatever mechanism you want (manual, polling, lots of options).
You potentially have a number of moving parts to this: the iOS app with some core network services, possibly authentication[?], all the “app basics” UI, layout, dealing with different devices, and whatnot - if you go with a remote service: some DB design, security, another language/framework (outside of Obj-C in the app itself).
Are you sold on developing an App? If it’s some simple data access, and your idea, or business model is just to get it to users (i.e., you don’t need discovery, billing or other app/store related services), then it might be easier to just deploy to a web UI, wrap it up in some nice responsive UI, maybe use a JS template engine for consuming the service output.