CloudKit on Andrew Bancroft

iOS Data Persistence: The Big Picture

Tue, 30 Apr 2019 10:03:33 +0000

We’ve all been there. Do a search on the topic of “saving data in iOS” and you’ll get dozens of search results mentioning at least six different frameworks and platforms, and a month’s worth of reading.

Wouldn’t it be nice to distill the possibilities down into just what you need in order to start down a path for persisting data in your app?

“iOS Data Persistence: The Big Picture” will be worth the hour of your time.

Resources

iOS Data Persistence: The Big Picture

Course Outline

During this one hour course, you will learn the reasons for saving data to help ground you as you begin to traverse the data persistence landscape.

You will discover how to use technologies like User Defaults and Property Lists, and I will guide you on how to work with Swift’s Encodable and Decodable protocols.

You will understand what you’re getting into if you choose to work with SQLite, Core Data, or Realm Database for local data persistence.

You will know how it feels to reach for a remote data storage option like CloudKit, Realm Platform, or Firebase.

Finally, you will see a clear picture of what it’s like to design a document-based application and integrate your app’s data with the iOS Files app.

When you’re finished with this course, you will have the skills and knowledge you need to make an informed decision about putting a reliable data storage plan for your iOS app into action.

1 – Establishing the Data Persistence Landscape

During the course, you will have the opportunity to experience a variety of data persistence scenarios and technologies.

You’ll get general feel for setup requirements and a taste of what it’s like to work with each solution in code.

To start you off on the right footing, this module will establish the data persistence possibilities and focus in on the reasons for saving data so that you’re persisting with a purpose.
You will be introduced to a player profile matrix to help you analyze your data persistence options from a number of angles.
Finally, you will get the feel for working with the Swift Encodable and Decodable protocols.

2 – Saving Settings and Configuration

Users are picky, aren’t they? Everybody has preferences though, so it’s no wonder that you as a developer are often tasked with letting your users to customize their experience within your app.

You will learn how to manage user preferences with the UserDefaults system that’s built in to iOS
Next, you will explore synchronizing settings with iCloud Key-Value Store
Finally, you will understand how to ship configuration for your app with Property Lists that are included in your application bundle

4 – Saving Objects and Object Graphs

What if you only wanted to load a subset of the data into memory instead of being locked in to an all-or-nothing situation with UserDefaults or Property Lists?

What if you needed to save a more complex data model that includes relationships?

For that, you’ll need to know about saving and sharing objects and object graphs…

Six Technologies/Frameworks will be featured in this module:

SQLite
Core Data
Realm Database
CloudKit
Realm Platform
Firebase

The goal is to help you answer two questions:

“What am I getting myself into if I pick one persistence technology over another?”
“How does it feel to work with this persistence technology in code?”

You will answer these questions by…

Scanning the arena of persistence options and explore what sets these technologies apart from UserDefaults and Property Lists.
Surveying the setup process to see what it takes to get up and running with each technology in the list
Exploring the data modeling process to wrap your head around what the data structure design process is like for each technology in the list
Getting the feel for working with data so that you understand what it’s like to create objects, update them, delete them, query and filter them, and watch for data changes so that you can update your user interface appropriately

5 – Saving Data as Documents and Files

What if you need to encapsulate chunks of content together and save it all as a packaged up file…as a single unit with a custom file extension?

For that, you need to know about saving data as documents and files.

You will explore the use-case for building a “document-based application”
Next you will walk through designing a document as a subclass of UIDocument
You will learn to create and load documents from a Document Browser
Customizing your app’s file extension is a key step that you will work through
You will spend some time understanding how to interact with document data in code as users interact with the user interface
Finally, you will answer the question, “How do I get my app’s files to show up in the iOS Files app?”

Feedback Welcome!

My goal is to help you filter the noise… to help you distill an overwhelming amount of information down into the big picture possibilities so that you’re on a trajectory for being able to make an informed decision about putting a reliable data storage plan for your iOS app into action.

I welcome feedback on this course, and on other iOS development courses you might be interested in seeing in the Pluralsight library. Happy learning!

CloudKit Fundamentals

Mon, 24 Sep 2018 17:58:49 +0000

At the core of developing a seamless and collaborative data sharing experience for Apple’s platforms is a thorough knowledge of CloudKit.

In this course, you’ll learn to leverage Apple’s flagship framework to achieve your app’s remote data storage and data sharing requirements.

First, you’ll learn how to configure CloudKit in your Xcode project and how to save, query, update, and delete data that your users store in iCloud.

Next, you’ll explore how to synchronize data across a user’s devices.

Finally, you’ll discover how to handle CloudKit errors, test your app on physical devices, and deploy to production.

When you’re finished with this course, you’ll have a foundational knowledge of CloudKit that will help you provide a fluid, interactive data sharing experience.

Course Trailer

You can check out a trailer of the course over at Pluralsight completely free.

Resources

CloudKit Fundamentals

Course Outline

1 – Setting up CloudKit

Module 1 is the introduction to the course with discussion of the motivating factors for using CloudKit, course prerequisites, storyline overview, and a demo of the end product of the course.

The demo app for this course is a fun one! I put you in the scenario where we team up to build a hazard reporting app for our company’s Safety Department.

The final product will come complete with the ability to save, query, update, and delete text, images, and location information into iCloud using the CloudKit framework.

2 – Modeling and Saving Data

Working with CloudKit begins with an understanding of the framework Types that are used to model and save data.

You'll learn about CKRecords and CKAssets, and save your first bits of data up to iCloud in this module.

3 – Querying, Displaying, Updating, and Deleting Data

Once data has been saved into an iCloud database, the next logical step is to query it and display it within the app.

I will teach about the CKQuery class for querying the CloudKit database for records and/or assets, so that data can be retrieved and displayed in the UI.

And of course, once data is retrieved and displayed, it's fair game for updating and deleting.

4 – Synchronizing Data Across Devices

The whole point of CloudKit is to make sure that data is accessible from more than one device.

One of the primary features still glaringly missing from our Hazard Reporter app at this point in the course is the fact that it doesn’t automatically update when data changes in the CloudKit database.

In this module, I'll teach you about how CloudKit uses subscriptions and push notifications to alert other users’ devices to changes that have occurred in the CloudKit database, so that appropriate action can be taken in code to respond to those changes.

I'll also simulate hazard reports coming in from another user by adding data through the CloudKit Dashboard and watching the screen update with the new data in the iOS app.

5 – Modeling Relationships Between Record Types

Modeling relationships between Record Types is important for many scenarios. In this module I will teach how to work with CKReferences in order to represent hierarchical relationships or to represent ownership between model objects.

6 – Planning for Production

Apple engineers repeatedly warn that CloudKit error handling isn’t the difference between a good app and a bad app… it’s the difference between a functional app and a non-functional app. To that end, I cover some of the most common CloudKit errors and how to handle them.

And alas, once a version of the app is ready enough to put into users’ hands, it’s crucial to test it and then put it into Production. I will discuss creating an Ad-Hoc deployment of the app so that it can be installed on other users’ devices via iTunes. I will also discuss deploying the CloudKit database schema to Production in preparation for deployment to the App Store.

Course Resources

Demos of technology in action are super important to me. That being the case, I tried to pack as much demo content into the course as possible. You'll get to see the full array of dev-time experiences, not just the final "it works perfectly” outcomes.

The course also comes complete with working Xcode projects that gradually build you up to the final version of the app, one step at a time through each module.

Feedback Welcome!

I welcome feedback on this course, and on other iOS development courses you might be interested in seeing in the Pluralsight library. Happy learning!

The Case for CloudKit

Mon, 06 Aug 2018 11:58:32 +0000

When it comes to remote backend services for mobile apps, you’ve got options. What’s the case for CloudKit? Where does Apple’s remote data storage and sharing solution fit into the Apple Developer’s toolbox?

I recently put out a survey on Twitter, just to get a feel for what folks are using.

#iosdev folks: When your app needs a backend (ie, a remote server / remote database), what do you use?

I’m also interested in the “why” - reply with a tweet if you care to share! Thanks! 🙌🏻
— Andrew Bancroft (@andrewcbancroft) July 20, 2018

The clear winer was Firebase, followed by folks implementing their own backend server architecture. Dead last? A tie between Realm and CloudKit.

”Hmm…”, I thought, “What’s up? Why no love for CloudKit?"

Of the options on my own survey, I’ve had experience building apps using three of the four: CloudKit, Firebase, and “rolling my own backend” with an app built for my employer.

So I asked myself, “When would you use CloudKit, Andrew?”

Here’s how I tend break it down. The more of these that apply to you and your app development experience, the stronger the case for using CloudKit (in my opinion):

Apple Platforms Only? CloudKit.

If you’re developing solely for Apple’s platforms, CloudKit is the natural choice.

One of the other CloudKit alternatives mentioned in the survey might have the upper hand if you’re developing for Android as well, but if you’re sticking to the Apple ecosystem, it makes sense to use their remote data storage and sharing service (ie, CloudKit).

Expand Beyond Apple Platforms with CloudKit JS

Even if you’re not developing solely for Apple’s platforms, CloudKit might still be a viable choice for you!

Apple designed CloudKit JS to create companion web apps to your iOS and macOS apps. You must have an existing CloudKit app and enable web services to use CloudKit JS, but once you’ve got an Apple app configured, you can leverage CloudKit in the web version of your app if you have one.

As I engaged with folks on Twitter about this, I learned that some were even leveraging CloudKit in an Android app using CloudKit JS as a bridge into the Apple ecosystem.

This opens up the audience for your app tremendously!

Built-in Authentication: CloudKit.

If you’re tired of creating sign up and login screens, look no further than CloudKit.

This is especially true if you’re only worrying with developing for Apple’s Platforms.

Users signed in with an Apple ID are automatically authenticated when your app uses CloudKit.

Kiss the sign up/login screens goodbye!

CloudKit is Free for Longer

All of the backend as a service providers offer a free tier or a free trial, and while I don’t have personal experience with these services’ payment threshholds, it’s my observation that CloudKit’s free tier might “last longer”. What do I mean by that?

Data of any kind stored in a user’s private database doesn’t count against your app’s storage alotment… it counts against the user’s iCloud storage plan. This extends the mileage of your app’s storage alotment.
CloudKit distinguishes between storage for non-binary data and storage for media (binary data like images, videos, audio, etc). You start off with 100 MB of non-binary data storage, but 10 GB of image/video/audio/etc. storage. In contrast… * Firebase starts to charge you $25/mo after 5 GB of media storage * Realm Platform offers a 30 day free trial, but is $30/month after that, and acts primarily as a remote data store for non-binary data.
As the number of users for your app grows, your storage and transfer limits scale with your app’s user base. I don’t have personal experience here, but I wonder… by the time your app grows to 100,000 users (the tipping point for Apple to scale your app’s alotments up), how probable is it that you’d already be paying to use Firebase?

Rolling Your Own Backend? Consider CloudKit.

Folks already invested in Realm or Firebase are already leveraging a backend as a service platform. It’s those that are maintaining backend server infrastructure themselves that I might suggest consider CloudKit.

I’ve been in the shoes of those who have to roll their own backend server and maintain those VMs, databases, web servers… the works.

Many times this is because there’s a need to connect a mobile app to an organization’s on-premise/public cloud ecosystem, and for that, I can totally empathize.

CloudKit offers a reliable alternative that organizations developing for Apple’s platforms should consider. It’s a huge weight off the shoulders to abstract the backend and let Apple maintain those servers and storage components. Data stored in the public cloud database is accessible programmatically, so your organization can get at data stored there for incorporation into its internal ecosystem.

Company Requirement: 1st Party Frameworks and Services Only? CloudKit.

This requirement is most likely to be seen within companies and organizations that have an aversion to bringing in a lot of 3rd party dependencies.

Those of us who have an employer or who work for clients that have a say in what our app development toolkit can consist of may need to consider options within the Apple ecosystem.

CloudKit is a dependable choice for risk-averse companies.

Speaking of risk aversion…

Personal 3rd Party Risk Aversion… CloudKit.

This one hits close to home for me, because I’ve experienced the pain of having a 3rd party service I depended on for multiple apps be discontinued. *Cough* Parse *Cough*

I’m usually okay with 3rd party libraries, but 3rd party services are another story altogether for me.

When you’re using a library that ends up fading away, it may take a little reworking to get your code to compile with an alternative.

But when you’ve got data that your app depends on living on a remote server hosted by a 3rd party, and that service goes away… Oy! Talk about the pain, frustration, and hassle of having to do a migration on top of rewriting code.

Only Need a Remote Data Store? Keep it Simple. CloudKit.

There is a ton that can be done on-device these days. If all you’re in the market for is a remote data store to facilitate data sharing across devices or with other users and have no need of remote cloud functions or analytics or remote machine learning services, etc., you might opt to keep it simple and leverage CloudKit.

Depend On What Apple Depends On: CloudKit.

What does Apple depend on for their own apps’ remote data storage and sharing needs?

Answer: CloudKit.

Clearly, Apple is in a unique situation: Apple neither needs nor cares to develop any of its apps for Android. Naturally, they’d depend on the very framework they created. Otherwise, we could argue, “What a bunch of hypocrites!”, right?

CloudKit serves the needs of apps like Photos, iCloud Drive, Notes, News, and more.

It’s almost as if Apple developed CloudKit for Apple, and decided, “Hey, let’s open this up to our developers and let them tap in to what works awesome for us!”

I like that. I like the security of knowing that Apple depends on the framework they’re delivering to us.

Tradeoffs

In fairness, I would point out a few trade-offs if you were to go with CloudKit.

No Native Android support

This tradeoff is qualified with the words “no native Android support” for a reason. CloudKit JS may actually open the door for folks developing cross platform apps, though it may take some hacking.

Expect some challenges on the Android side of things, but don’t completely count CloudKit out.

With CloudKit, you get a fully-functional remote data storage and sharing service. If you’re wanting to leverage some advanced functionality like “cloud functions”, analytics for your app, non-Apple ID authentication, remote machine learning services, and the like, you won’t find those features in CloudKit.

This doesn’t mean that Apple leaves you nanging when it comes to authentication, analytics, machine learning, etc.

Don’t forget that you’ll have built-in Apple ID authentication as I mentioned above, and analytics are provided through iTunes Connect.

On-device machine learning with CoreML might also alleviate the need to seek remote ML services.

If, after considering Apple’s component solutions, you’re looking for alternatives, Firebase offers all of the above as sort of an all-in-one package.

As I mentioned above though… if all you really need is a remote data store for cross-device data syncing, don’t over-complicate things. CloudKit can still serve you well.

Another alternative is to use a public cloud provider like Azure or AWS for “cloud functions” or remote machine learning. If you prefer to component-ize these kinds of services, this is a viable alternative to Firebase, or Apple’s own solutions to these kinds of problems.

What do you use? Why?

I’m a pragmatist. I don’t always use CloudKit. But I do like CloudKit when I can use it.

What do you use? Why? What’s your experience with backend as a service providers? What else would you consider in the case for CloudKit? What other tradeoffs do you recognize?

CloudKit on Andrew Bancroft

iOS Data Persistence: The Big Picture

Course Outline

1 – Establishing the Data Persistence Landscape

2 – Saving Settings and Configuration

4 – Saving Objects and Object Graphs

5 – Saving Data as Documents and Files

Feedback Welcome!

CloudKit Fundamentals

Course Trailer

Course Outline

1 – Setting up CloudKit

2 – Modeling and Saving Data

3 – Querying, Displaying, Updating, and Deleting Data

4 – Synchronizing Data Across Devices

5 – Modeling Relationships Between Record Types

6 – Planning for Production

Course Resources

Feedback Welcome!

The Case for CloudKit

Apple Platforms Only? CloudKit.

Expand Beyond Apple Platforms with CloudKit JS

Built-in Authentication: CloudKit.

CloudKit is Free for Longer

Rolling Your Own Backend? Consider CloudKit.

Company Requirement: 1st Party Frameworks and Services Only? CloudKit.

Personal 3rd Party Risk Aversion… CloudKit.

Only Need a Remote Data Store? Keep it Simple. CloudKit.

Depend On What Apple Depends On: CloudKit.

Tradeoffs

No Native Android support

Data storage and sharing only with CloudKit

What do you use? Why?