How to delete container in CloudKit Dashboard?

For demo iCloud, build many containers in CloudKit Dashboard. Now i want to delete some old containers but i can't. I need help thanks.

Post not yet marked as solved Up vote post of EarlyMorning Down vote post of EarlyMorning
22k views
Posted by
EarlyMorning
Reply

  • Maybe Apple wants the deletion of containers to be as revolutionary as the calculator on the iPad...

    —
    MWilzin

  • I would settle for renaming a container. New projects always come along.

    —
    pipobrain
Add a Comment

Replies

Lol really you cannot delete? Wooow man this is incredible and I just started with CloudKit to find out this basic functionality not working hahahah.

Posted by
Amiorkov
Post not yet marked as solved Up vote reply of Amiorkov Down vote reply of Amiorkov

  • At least they add a search! (I'm working with CloudKit since the beginning and I have a lot of unused containers)

    —
    iturrajoel
Add a Comment

Registered the container name with lowercase. Am I permanently locked out of the correct case name for the App?

Posted by
jonkimsr
Up vote reply of jonkimsr Down vote reply of jonkimsr
Add a Comment

July 19, 3145 - Still unable to delete containers

Posted by
FromDerik
Post not yet marked as solved Up vote reply of FromDerik Down vote reply of FromDerik
Add a Comment

2021, Still no change.

Posted by
megabits
Up vote reply of megabits Down vote reply of megabits
Add a Comment

I think that Apple wants to prevent at any cost that a production container gets deleted due to a software bug. And if I must choose between being able to delete containers (not deployed in production, that must be the main criterium), or a very small chance that I loose one of my production containers due to a software bug (by Apple or any other party), I would always choose to not being able to delete containers, and continue living with all those unused (incorrectly named, test or temporary) containers.

Posted by
elemans
Up vote reply of elemans Down vote reply of elemans

  • just need a flag to get it out of the interface. don't have to delete it. gets confusing with so many junk containers - causes problems and lots of wasted time.

    —
    ngb
Add a Comment

Facing the same issue, cant delete the container

Posted by
VishwanathKota
Up vote reply of VishwanathKota Down vote reply of VishwanathKota
Add a Comment

11/20/2021

Posted by
andreas_
Up vote reply of andreas_ Down vote reply of andreas_
Add a Comment

How many of you would be satisfied with being able to hide the containers from your list, without actually having them deleted?

Asking because it looks like Apple's never going to allow us to delete them (this thread is at least 5 years old), but it might not be such a big deal to Apple to let us hide unneeded containers on the UI level.

If you think you'd be happy with that kind of solution, please upvote this answer and/or add a comment for it, because I am not quite sure we can see the upvote count :)

Should the upvotes show this concept would help a lot of you, I'll work up the UX details and a template for filing the Feedback, which we can all copy-paste-submit and be loud enough to get Apple's attention about this feature. We can all end up with cleaner lists of containers (yay) and all the containers can still be there, which I suspect Apple will have no qualm with.

Posted by
iOSDevDaniel
Post not yet marked as solved Up vote reply of iOSDevDaniel Down vote reply of iOSDevDaniel

  • That's actually a great idea, Daniel. They could be just grouped under "hidden" folder or button

    —
    mallow

  • I'm all for it.

    —
    bostoned

  • Simple but effective, let's hope Apple listens!

    —
    alfavata

This unexpected user experience has far reaching effects. It is bad enough that the Core Data / CloudKit frameworks are inherently fragile and need a total re-write, but it makes everyone scared to death to try anything they have none before in the XCODE IDE. I just ruined another project --- there are edge effects evidently to having more than one container -- it now destroyed my ability to properly query data from the other container. Went to uncheck the extra container (that caused the meltdown in what should have been unrelated areas of the project) and find that I can't. Worse, find that this problem has been documented here FOR FIVE YEARS. I tried to be loyal and tried to do an app that was going to be 100% Apple (CoreData, CloudKit) -- weaving through all the ridiculous code and coding and decoding between SwiftUI/CoreData/CloudKit just to sync a few measly data elements -- only to be kicked in the face by this amateurish (college professor theoretical data structures that don't work in the real world) joke for persistence management. (Which horrible architecture earlier today destroyed a slideshow in KeyNote I had to rebuild earlier today -- just because Finder and KeyNote cratered on an edge effect they had not architected to cover in a shared KeyNote file. Just showing that the Apple persistence/syncing architecture is not robust enough for serious commercial use.) I feel I have a bit of a right to rant about this -- as I have been programming since 1977!! What takes me a day to develop in this decrepit architecture took minutes to do back in the 1980's --- with 100's of concurrent users and absolutely no data loss in syncing and persistence. It is like somehow all the great knowledge we had back in the 1980's got flushed down the toilet and had to be relearned by another generation. Anyway -- I have about had it with ignoring bugs for FIVE YEARS. Sorry, once again, for this useless rant that won't go anywhere.

Posted by
CharlesK
Post marked as downvoted Up vote reply of CharlesK Down vote reply of CharlesK

  • Respect for the seniority. I have a few corrections though. CoreData works great. If you have the latest version of swift they even added async/await concurrency functions to make it work even better with SwiftUI/Combine and is read/write safe. I've used it for years and my only complaint as of recently is that for some reason they included no delegate or handlers to tell when objects where saved. This last updated fixes that. Id much prefer it to sqlite. I am a bit biased though since I am on the Parse Platform iOS team that uses neither.

    I digress though. CloudKit is the problem here. Apple's terrible attempt to make any sort of competitor to firebase and other similar services. Its barely covered in WWDC and they've made no recent changes that have any impact whatsoever. I mean if giving them a pass for no integration with xcode wasnt bad enough...the OBVIOUS way they should have handled this would have been super easy. Do it the same as everything else tieing containers to their bundle identifiers just like you do certificates, push, app groups, etc. Deleting the bundle identifier and associated build certs automatically archives CloudKit data and gives you a super obvious place to delete the container.

    Speaking of flushed down the ******. That is what all experienced developers are going through with Apple shoving SwiftUI down our throats and telling us they will not be supporting UIKit in the long term anymore. From MVVM and MVC to a Redux style architecture on steroids.

    Just another thought. Codable makes me miss Java's Reflection and its libraries like Jackson. Thats what it is....a half-baked Jackson attempt.

    Either way it could be worse. We could still be stuck with assembly, rust, visual basic. I just wish they would stop being sooo...Apple. Where they think they. are incapable of releasing a terrible product, or even a terrible framework. They've had 5 versions of swift. How the hell is it so much to ask to get 1 update to CloudKit.

    Anyway, sorry for the randomness. I love seeing true senior developers toughing it out here with us young guys and our "cutting edge" tech(or lack thereof). You have something none of us can obtain any other way than simply putting in the years and hoping to keep learning along the way. So, keep fighting the urge to curb stomp apple. We dont have many guys like you left.

    —
    noobs2ninjas
Add a Comment

New Year Eve 2021 and still no change. Maybe 2022 will be better :(— i_Joe less than a minute ago 

Posted by
i_Joe
Up vote reply of i_Joe Down vote reply of i_Joe
Add a Comment

January 3rd 2022, still not able to delete containers

Posted by
Mehrad88
Up vote reply of Mehrad88 Down vote reply of Mehrad88
Add a Comment

jan 9, 22 ....

Posted by
cab
Up vote reply of cab Down vote reply of cab
Add a Comment

Jan 14, 2022. Is deleting containers supported now? At least, we need the ability to delete the containers that are not deployed to production.

Posted by
fysteven
Up vote reply of fysteven Down vote reply of fysteven
Add a Comment

still Fev 22 2022

Posted by
tamere22332
Up vote reply of tamere22332 Down vote reply of tamere22332
Add a Comment

I'm sorry to give you the bad news but... here we are in March 2022.

Posted by
bmnzaf
Up vote reply of bmnzaf Down vote reply of bmnzaf
Add a Comment