Why we built Atoll on iCloud
Yesterday we released Atoll, an app for saltwater aquarium and diving enthusiasts. The app itself is broken into two main parts: a library of coral and user submissions. The Library contains photos and information about coral, divided by genus and then subdivided by species. From the submissions page, you can submit images of coral for the community to identify. You can see your submissions and watch as other users help narrow down what coral it is. You can help others identify their coral as well by casting a vote for a particular genus and species. Atoll was built with CloudKit, using only using Apple’s iCloud as a backend. This brought a unique set of advantages and challenges compared to using other backend services. I hope that by bringing up our experiences, it might help you decide whether to consider using CloudKit for your next app.
Advantage: Native
With CloudKit being a native framework, we were able to do all of our coding for Atoll in Swift and Swift only! Not only is this obviously beneficial for native app development, but it’s a huge benefit for code reviews and deployment.
Advantage: Easy to set up
It’s true that many other backend services offer native SDKs so that developers can have the same ability to work in native code only, but with CloudKit there are no third party dependencies to set up or manage and it is incredibly quick and easy to get up and running.
We set up our Xcode project with separate targets to hit CloudKit’s Development and Production environments, and even this only took a few minutes.
Setting up NSUbiquitousKeyValueStore is as easy as checking the “Key-value storage” in the iCloud section of your project’s entitlements. While this class is quite a mouth full, it’s essentially just an NSUserDefaults that syncs information across all of a user’s devices for you. This is incredibly useful in almost any app, even if not using iCloud as your main backend.
Challenge: No server-side code
The biggest challenge that we found in working with iCloud by far is the fact that you cannot run any server-side code. This was a challenge for us in two places:
When a user in Atoll submits a coral image, we want to keep the full-size, highest quality image. However sending full-size images back and forth is not practical, so we want images of different sizes to be used at the appropriate times. Backend servers typically handle image processing and resizing, but with no server-side code available it needed to be done in our app. So the first call that we make to save an image with CloudKit, instead of just sending the one large image we had to resize it a few times on the device and send several images instead. Since all of these images were smaller than the original, it isn’t adding too much overhead, but it is still more than we’d like to be sending. It also made us plan in advance what image sizes we wanted, it will be harder to change in the future and there is no way for us to ask for dynamically sized images from our backend.
The other time that this was a challenge for us was for closing submissions after they had received enough votes. This is something that would be easier and better handled on the server side, but instead it needed to be done in our app. We handled this by having each user check to see if a submission should be closed after they voted on it and if it should they would close it. This involves a little more work for the user’s device, but not much since these were very lightweight calls. We had to be careful with the logic for these operations, though, as multiple users could all potentially be doing this at the same time.
Challenge: Limited features in the iCloud Dashboard
The iCloud Dashboard is currently missing a lot of features that a lot of other backend services have, and is not very convenient for managing your data. Still, it offers most basic necessary features and there is a lot of room for more features later to grow on its current foundation.
However, it is easy to have several different apps that you own all hit the same iCloud containers. This made it really easy for us to make a small quick database app that runs operations that are very specific to Atoll. So even though iCloud’s dashboard is missing a lot of features that other backend services have, CloudKit made it very easy for us to make our own custom features that no other service would have. This also helps offset some of the downsides to not being able to run server-side code. Operations that we need to run that we don’t want to run on users’ devices and that don’t need to be run at certain times we can just make features of our own database app.
Advantage: Invisible Login
This is one of the things that we liked best about working with iCloud. If a user has an iCloud account they are already logged in as soon as they open the app. You get a userID for that user without them needing to create an account, or connect to an existing social media account. Even if a user doesn’t have an iCloud account, they are able to access the app’s public database. This takes away a huge barrier-to-entry for users early on, making it easier to keep them using your app.
For Atoll, this meant that we are able to have our library of coral available to all users as soon as they open the app. For users that have iCloud, they can immediately submit a coral photo for identification, without any hoops to jump through first. Since they already have a way for us to identify them as a user, we are able to let them know as their submission receives votes and when it is identified. We are able to let them vote to help identify other users’ submissions while ensuring that no one is voting twice on the same coral. Letting our users get straight to the app’s core functionality as soon as the app is opened is possible thanks to CloudKit.
Also, since each iCloud userID is unique to each app, we are able to identify our users without getting any other information about them and no way to connect to their data outside of Atoll, protecting their privacy.
Advantage: Great pricing
iCloud starts free, and even better, the free tier scales with the number of users that you have, helping you keep your backend free even as the scale of your app grows. A pricing calculator for iCloud can be found around the bottom of the page here.
Challenge: Asset transfer is costly
The real sticking point on CloudKit pricing is Asset Transfer. The free limit for Asset Transfer is proportionally way lower than all the other pricing measurements. These limits are monthly, so you can go over for a few days and still balance out for the month and remain free. The pricing for iCloud is still fantastic, even when you pass the free limit and so I think that this really isn’t a problem with iCloud. However, this combined with the inability to run server side code definitely makes working with images less than ideal.
Disadvantages:
While building Atoll and learning about iCloud we ran into a few disadvantages that luckily didn’t affect us, but would be important to know when trying to decide whether or not to use iCloud:
Video
All of the challenges for images are definitely multiplied for working with videos. On top of this, there is no way to stream video from CloudKit, if you store the video as an asset in CloudKit the whole video would need to be downloaded at once. If you are working on an app that has a lot of videos, I would definitely recommend storing, processing and streaming those videos from a different backend. This would not exclude you from using CloudKit for the rest of your data, though.
Access Control
There are no ways to programmatically control which users can access which information in iCloud. There are some options for “Security Roles” in the dashboard, but users have to be added to these roles manually through the dashboard. And these permissions apply to specific record types and cannot be used for specific records.
CloudKit has a public database, that is accessible by all users, and a private database for each user that is accessible only to them. If this structure fits with your app, like it did for ours, that’s great. If you want any data shared only by certain groups of users, and especially if you want several of those groups and you want them to be dynamic, this could be a deal-breaker for using iCloud as the main backend for your app. This is still something you could do client side, but you would need to create and manage this system yourself, including the security aspects and most backend services already have something built in that already handles all of this for you. Hopefully, this is something that comes later as iCloud grows over time.
TL;DR
We really enjoyed working with CloudKit and it was a great fit for Atoll. It helped us get up and running quickly and made for a better user experience overall within the app.
CloudKit’s biggest issues are that there is no custom access control for different users and data, you cannot run any server side code, and it is not easy to work with videos.
If you can get over these points, iCloud starts free, scales with the number of users you have, is fast and easy to set up in your app, and users do not need to sign up or log in to get started.
Even if these issues are deal breakers for you, I would recommend looking into iCloud to handle at least some of your backend responsibilities.
