I was considering the details in rewriting the Backpacker Checklist. There were many changes that I intended to make. By far, the biggest change is replacing the SQLite data access methodology with Core Data ORM access.
When I wrote the original version of the Backpacker Checklist there wasn’t a way to share data easily across devices or across users. There wasn’t yet an iCloud and emails were limited to just 3,000 characters. But I really wanted to be able to share data! So I created a web site with some web services so that users can upload their packing lists to a shared repository.
I had grand visions that many users would be sharing their lists through the web site. And then I had thought to add some affiliate links to REI, EMS, Amazon, and the like. I wasn’t above making a few extra bucks if it worked out. Even though it didn’t evolve to match my grand vision I did like the fact that user data was available to them, if they wanted, through something other than the app. That was a very comforting thought to me. I didn’t want people to be in jeopardy of losing their packing lists if they hadn’t backed up their phones. I did not automatically synchronize data from their phones the web site though. I still left it to users to update from the app to the web site.
So it came time for me to rewrite the Backpacker Checklist from scratch with some new user interfaces strategies as well as some new data management strategies.
My main goals for the data management were:
- Enable synchronization across all of a user’s devices (e.g., between an iPhone and an iPad)
- Enable users to share their packing lists with their friends
- Simplify data access for myself as the app developer
While considering these goals I came down to two main candidate strategies for dealing with data in the app:
- Core Data
Update: On 28 January, 2016 Parse announced: “Parse’s hosted services will be fully retired on January 28, 2017.”
So, why choose Core Data over Parse.com?
I’m not sure whether Core Data was available when I wrote the original version of the app. If it was, then I didn’t really understand it. In the ensuing years I have spent a lot of time understanding the design of Core Data. I have also integrated some Core Data tools into my toolbox to speed up development greatly. Using Core Data feels very natural to me in iOS and is my first choice.
Using Core Data you get some very straightforward Object Relational Mapping. You can design your objects using Xcode’s visual interface. Then Xcode can generate classes for you from the editor. Personally, I never edit the generated classes because I often change the object attributes and relationships during development. Since I do usually want to add functionality I create my own Core Data class extensions in separate files. That allows me to have Xcode recreate the classes without losing any of my customizations.
In the main part of your app you can use your Core Data classes like you would any other class in the system. You land in this miraculous ORM world where you just use your classes and save your managed object context.
This is enhanced by iCloud. You can organize everything so that the SQLite logs caused by the Core Data framework are automatically synchronized with your other devices, within your iTunes user account. This means that Core Data and iCloud will make sure that your changes to data on your iPhone will be transported to your iPad and applied there. Magically it’s all synchronized. I like magic!
But the Core Data magic only goes so far.
Not surprisingly, the magic is limited to Apple devices. So if you want to see the data from a web browser or read the data from an Android app then you’re going to have to learn to handle disappointment well. It ain’t gonna happen.
Parse provides a very compelling value proposition. You can use their semi-ORM system to save data to their cloud directly from your iOS app. In addition, Parse supports a variety of other platforms so that you can synchronize from an iPhone to an Android phone to a web interface. And, as the developer, you can control the degree to which data is shared amongst different users of your application. To make it really enticing, Parse does not charge developers if their volume is under certain thresholds. Sounds pretty darned cool!
I was about to go ahead jump right in and start using Parse. I started looking at their code examples. The whole Parse system relies upon the device having internet access to connect to the Parse servers. If the user’s device can’t connect, say on an airplane, then Parse-based objects cannot be saved. I was not comfortable with that limitation.
Other people have been dissatisfied with the limitation too, but they have come up with some cool solutions. It seems like the consensus is that you should save your objects through Core Data first and then synchronize to the Parse engine when the device can connect. Sounds like a reasonable strategy. However, it does add quite a bit of complication.
Since either solution seemed to start with using Core Data I decided that I would start with using Core Data. For now, I figured I’d just use Core Data itself and revisit Parse as a potential enhancement some time in the future. Being a solo developer, the Parse solution seemed like too much work, meaning not a good bet. If I already knew that many thousands of users would appreciate the cross-platform functionality then I would include the Parse solution right away. However, I suspect that few people will be interested.
So I’m starting out with Core Data by itself. I expect that I can enhance the app by adding in Parse functionality if there later appears to be demand. For now, it doesn’t seem like a good bet.
Update: In light of the shuttering of Parse, it looks like I definitely made the right choice, even if for the wrong reasons. The fact parse.com was owned by Facebook should have been a warning indicator. To depend upon a company you need to know that the company is financially viable and that the service you’re using is a core business.
Thinking about deploying on Google App Engine? What do you think are the odds that Google will maintain the service? Are they making money? Will they kill the service? Maybe, customers have to buy into using their platform.
What about using Amazon Web Services? Will they maintain the services? Are they making money? Will they kill it? I doubt it…seems pretty general purpose, huge customers (e.g., Netflix), core to Amazon and cutting edge.
iCloud? Is Apple going to kill their cloud offering for sharing data? I doubt it. They’ve pushed it pretty darned hard. They may make changes that require updates, but I think they’ll stick with it.