I am investigating what may be the best choice of cloud database service would be for my app. I am closely looking at CloudKit, however one thing concerns me. The Public Database transfer limits being 250kb per day with an additional 5kb per user.
What is the best way to measure how much I am transferring in and out of my app? I see this as the biggest issue with CloudKit, as there are no analytics provided on this.
Unfortunately there aren't any analytics to view usage. If you notice that your users are bumping into the limits you should contact Apple and they'll work with you to bump the limits.
Note that if you use the private database that data is counted against the individual users quota and not against your app. Every iCloud user gets 5GB of storage for free (shared with backups, photo streams, etc), and users can purchase additional storage if they want.
Related
I have already asked this question on AWS Developer Forum but dont have any answer, hence posting the same question here to get some help.
I have a quite well organized and fast Rails 6 app where users can upload large videos(4gb)/images and also make them public to others. Its using AWS SDK for S3 upload and CloudFront to distribute and make the content available globally.All uploaded videos are transcoded into mp4,HD.Full HD videos using Input S3 bucket - MediaConvert - Lambda - Ootput S3 bucket - Cloudfront workflow.
Now my query is -
As users are allowed to upload upto 4GB of videos and also can make them public, so does this feature of making large videos public will also increase the cost/billing, as the video is public and more and more people will watch it, raising concerns to more incoming request for CloudFront...Can someone correct me here?
If the above point is correct and will happen, what are the ways I can make videos public without effecting the billing/cost, for example using Cache(cloudfront cache) or any other way to minimize the increasing cost.
What are the ways I can allow users to share uploaded videos to share with others, without increasing the AWS billing?
There is no legal way to avoid the data transfer cost increase for the use case you described in AWS. Even if CloudFront cache your data, you still need to pay the CloudFront outbound data transfer cost.
As users are allowed to upload up to 4GB of videos and also can make them public, so does this feature of making large videos public will also increase the cost/billing, as the video is public and more and more people will watch it, raising concerns to more incoming request for CloudFront...Can someone correct me here?
You are correct. You will be paying for all these outgoing data transfers.
If the above point is correct and will happen, what are the ways I can make videos public without affecting the billing/cost, for example using Cache(CloudFront cache) or any other way to minimize the increasing cost.
The only way is to earn money based on such a service. So you either charge the users to view the videos, your charge the uploaded for the upload of the videos and subsequent data transfers, or you earn by advertisements on your portal. So still upload and download are free, but you somehow make your users go through a bunch of advertisement links to compensate for that. There are other ways to monetize a website, but it depends on how popular your website will become, e.g. collect user data and sell it out.
What are the ways I can allow users to share uploaded videos to share with others, without increasing the AWS billing?
See point two. You have to monetize your website, or simply change its architecture. Instead of you storing all the files, let users exchange torrent links. Then the files are not stored on your account nor you incur any cost associated with data transfers.
I truly appreciate the time and effort of all those who tried to help me.
I didnt got any answer though I was able to get quite close to what I needed in the link below - which is a blog post explaining the parameters and other relevant areas that needs to he considered while working on large videos, cost involved and how much total bit rate is viewed.
https://aws.amazon.com/blogs/media/frequently-asked-questions-about-the-cost-of-live-streaming/
Hope it helps someone looking for more specific answers.
I am devloping an app using CloudKit and CoreData. I currently have the app setup so that when the user changes, I use a different locaton for the persistant store. If the user loggs back in, I can switch back to that persistant store and pick up right where they left off and not have to redownload data up to that point as well as not loose any changes that might not have been synced when the account changed.
My question is I am now second guessing if this is the right approach (from a data security standpoint) and want to know if there is Apple guidance in this scenario or what other developers might think. Should I just purge the data when the accont changes (and if there is data loss, not worry about it).
Is there anything I can do about unsynced data when an account changes?
I appreciate any input.
This is a curious use case. I think the answer depends on a few things.
If people are sharing devices and signing in/out of the app, and the app data they are saving is sensitive (PII, financial data, etc.), then I would purge the data and download the new user’s stuff from CloudKit.
If people aren’t sharing devices, and the amount of data you need to pull down is pretty big (several hundred MB or more), then I would keep the local cache in Core Data.
I hope that helps.
I am so happy that I get an ID per device, so I can keep data per user anonymously with firebase! The only thing that could be better is if I could get an id per user's iCloud storage for the app.
I understand that how the authentication token is maintained per app, at least on the web, is that it is stored in local storage. It implies that a similar approach is being used per app in iOS in something like UserDefaults. I'm hoping there's an easy way to keep it instead in NSUbiquitousKeyValueStore.
edit with use case:
I have an app that is (with permission) capturing and anonymously collecting location data. I would like to have that data stored per user rather than per device, and I essentially can't use signed logins.
(actually, the reality is that I am not capturing that in firestore, I am capturing accompanying metric data from other apps designed to work with this one)
So "why anonymous?", right? I am collecting time series data for third party apps - this presents risk of "use" to the user, and loss of control for that same data for the subscriber apps using the service I am writing.
Honestly, at a later point in time this might be converted to a library that allows apps to swarm their information together instead. But there are overhead concerns, and difficulty in trust for sharing data, with that approach and for my research project that approach is further from topic.
I am building a fitness app with HealthKit integration. Ultimately I would like to use CloudKit as well to a) allow data redundancy, but mainly b) to provide a few social features which require data to be in iCloud at least temporarily.
I would like to be able to rely solely on HealthKit for data within the app, but feel that an alternate data model is necessary to persist data incase HealthKit permissions are revoked or not given in the first place. I have chosen to stick with Core Data for this.
My question is how do I go about keeping my Core Data store and my HealthKit store in sync. I have searched for an example on GitHub and for related questions on here, but cannot find any useful examples.
Ultimately I will be then syncing the data in Core Data with CloudKit, but is the Core Data intermediary really necessary?
With regards to App Store Review Guidelines 27.3
Apps using the HealthKit framework that store users’ health
information in iCloud will be rejected
I take this to mean that any Health data which was not created by your app cannot be stored in iCloud. There are many apps which store Health data on a third party server (i.e. RunKeeper). Also, without HealthKit permissions I would be allowed to store health data created by my app in iCloud. If you take third party data from HealthKit and try to put that in iCloud, then you'll be rejected.
There's a couple questions in here, so I'll try to answer them in order.
...how do I go about keeping my Core Data store and my HealthKit store in sync?
So there are two application modes you need to worry about for getting data updates: foreground and background.
When in the foreground, you can utilize HKObserverQuery which provides a decent amount of flexibility in getting the data you need. The usual caveats apply when passing data across thread boundaries (as observer queries run on background queues). Pertinent docs: HKObserverQuery Docs
In the background you have to register for background wakeup using enableBackgroundDeliveryForType(_:frequency:withCompletion:). This will wake your application at (or close to) the specified frequency, at which point you'll need to jump through whatever necessary hoops to load your Core Data stack and do your updates. Pertinent Docs: HKHealthStore Background Handling Docs
...is the Core Data intermediary really necessary?
No, and in fact using Core Data may be complete overkill for your uses. I generally recommend against implementing Core Data at the outset of an application. There are performance concerns, background wake concerns, schema migration concerns when you change schemas, and iCloud <> Core Data synchronization issues (most of which have been resolved as of iOS 9 but still crop up occasionally).
On top of all that, Apple's "template" for including Core Data in a new project generally doesn't follow best practice guidelines for integrating Core Data. Do some Google searches and take a look at Marcus Zarra's books on the subject.
That all said, not using Core Data means having to write a bunch more code to enable iCloud to synchronize with your data store of choice, so it's tough to offer a suggestion as to the "correct" route to take.
I take this to mean that any Health data which was not created by your app cannot be stored in iCloud.
Incorrect. Take the line at face value. If Apple sees you've requested access to HealthKit and have provisioned iCloud access, you're probably going to get scrutinized and most likely rejected. They are very touchy about user privacy in this regard, and correctly so in my opinion.
Your note about Runkeeper, while accurate, is also flawed as Runkeeper (last I checked) does not use iCloud and so wouldn't be subject to this, so the analogy is flawed. Also, as per Apple's other guidelines, whatever other apps do or don't do has no bearing on your application's review status.
In short, I would steer clear of storing users' health data in iCloud. Use another provider or your own server.
My client states in an iPad app brief that the data (i.e. products and images) must be taken from an online source and saved. However, the app must also have an offline mode which shows this same data from when the app was previously online for times when internet access is not available (kind of like an offline reader). What would be the best way to tackle this? Any help greatly appreciated.
Download the data when the device is online and store it locally using whatever mechanism seems most appropriate (SQLite, Core Data, property lists, your own file format, etc.). Use this cached data when offline, and when online too unless it has changed. Create some mechanism that you can use to detect and download updates (preferably just the changes) when online.
This will be a big help for your users not just when they're offline, but online too. 3G data plans for the iPad are usually limited, so the better you can avoid repeat downloads of large resources like images, the better for your users.