User Profile

Hi,Anyone experiencing the same? When downloading a large zone from the private database with a large number of changes, adds and deletes (say 20k records, 15k deletes and 5k changes) cloudd crashes reproducibly along the way. This only happens when fetchAllChanges=YES. When set to NO or when using the older CKFetchRecordChangesOperation, everything works as expected.Here are some stacks where cloudd is crashing:Thread 5 Crashed:: Dispatch queue: com.apple.cloudkit.fetchAllZoneChanges.callback.0x7fa2cde154500 com.apple.cloudkit.CloudKitDaemon 0x00007fffd2420004 CKDPQueryRetrieveRequestReadFrom + 5061 libdispatch.dylib 0x00007fffdcb41128 _dispatch_client_callout + 82 libdispatch.dylib 0x00007fffdcb578e8 _dispatch_queue_serial_drain + 2093 libdispatch.dylib 0x00007fffdcb49d41 _dispatch_queue_invoke + 10464 libdispatch.dylib 0x00007fffdcb579d2 _dispatch_queue_serial_drain + 4435 libdispatch.dylib 0x00007fffdcb49d41 _dispatch_queue_invoke + 10466 libdispatch.dylib 0x00007fffdcb579d2 _dispatch_queue_serial_drain + 4437 libdispatch.dylib 0x00007fffdcb49d41 _dispatch_queue_invoke + 10468 libdispatch.dylib 0x00007fffdcb42ee0 _dispatch_root_queue_drain + 4769 libdispatch.dylib 0x00007fffdcb42cb7 _dispatch_worker_thread3 + 9910 libsystem_pthread.dylib 0x00007fffdcd8d746 _pthread_wqthread + 129911 libsystem_pthread.dylib 0x00007fffdcd8d221 start_wqthread + 13Thread 5 Crashed:: Dispatch queue: com.apple.cloudkit.fetchAllZoneChanges.callback.0x7fbcb1575f200 libobjc.A.dylib 0x00007fffdc2938a4 objc_loadWeakRetained + 1661 com.apple.cloudkit.CloudKitDaemon 0x00007fffd24292b4 __82-[CKDFetchRecordZoneChangesOperation _handleRecordChange:perRequestSchedulerInfo:]_block_invoke_2 + 472 libdispatch.dylib 0x00007fffdcb56680 _dispatch_block_async_invoke_and_release + 753 libdispatch.dylib 0x00007fffdcb41128 _dispatch_client_callout + 84 libdispatch.dylib 0x00007fffdcb578e8 _dispatch_queue_serial_drain + 2095 libdispatch.dylib 0x00007fffdcb49d41 _dispatch_queue_invoke + 10466 libdispatch.dylib 0x00007fffdcb579d2 _dispatch_queue_serial_drain + 4437 libdispatch.dylib 0x00007fffdcb49d41 _dispatch_queue_invoke + 10468 libdispatch.dylib 0x00007fffdcb579d2 _dispatch_queue_serial_drain + 4439 libdispatch.dylib 0x00007fffdcb49d41 _dispatch_queue_invoke + 104610 libdispatch.dylib 0x00007fffdcb42ee0 _dispatch_root_queue_drain + 47611 libdispatch.dylib 0x00007fffdcb42cb7 _dispatch_worker_thread3 + 9912 libsystem_pthread.dylib 0x00007fffdcd8d746 _pthread_wqthread + 129913 libsystem_pthread.dylib 0x00007fffdcd8d221 start_wqthread + 13Thread 5 Crashed:: Dispatch queue: com.apple.cloudkit.fetchAllZoneChanges.callback.0x7faca45256300 com.apple.cloudkit.CloudKitDaemon 0x00007fff88fc0004 -[CKDPCSCacheRecordFetchOperation _decryptPCS] + 64661 libdispatch.dylib 0x00007fff936e7128 _dispatch_client_callout + 82 libdispatch.dylib 0x00007fff936fd8e8 _dispatch_queue_serial_drain + 2093 libdispatch.dylib 0x00007fff936efd41 _dispatch_queue_invoke + 10464 libdispatch.dylib 0x00007fff936fd9d2 _dispatch_queue_serial_drain + 4435 libdispatch.dylib 0x00007fff936efd41 _dispatch_queue_invoke + 10466 libdispatch.dylib 0x00007fff936fd9d2 _dispatch_queue_serial_drain + 4437 libdispatch.dylib 0x00007fff936efd41 _dispatch_queue_invoke + 10468 libdispatch.dylib 0x00007fff936e8ee0 _dispatch_root_queue_drain + 4769 libdispatch.dylib 0x00007fff936e8cb7 _dispatch_worker_thread3 + 9910 libsystem_pthread.dylib 0x00007fff93933746 _pthread_wqthread + 129911 libsystem_pthread.dylib 0x00007fff93933221 start_wqthread + 13Already filed a bug report, #28461661

Hi,We had encountered an issue saving a CKShare which uses a larger parent hierarchy of more than 5.000 records (see https://forums.developer.apple.com/thread/64194)Sadly, we just received an answer from the (very helpful and responsive) Apple Developer Technical Support that CKShare is currently only designed to share a few hundred records. The hard limit seems to be 5.000 records when creating a CKShare, the recommendation is 200.Be sure to design your apps with these limits in mind when you're planning to use CKShare. It would be great if anyone with a real-world usecase for an app can file a feature request (http://bugreport.apple.com). Mine is #28548349.

Hi!I am the lead developer of MacFamlyTree and we received a very strange rejection submitting a bugfix release. It seems we're no longer allowed to use "Mac" as the app name prefix:"Your app uses Mac in the app name in a manner that is not consistent with Apple's trademark guidelines. In regards to the 5.2.5 rejection, your app uses Mac in the app name in a manner that is not consistent with Apple's trademark guidelines. Indicating Mac compatibility in the app name is not necessary for the Mac App Store. It would be appropriate to remove the term “Mac” from the app’s name before resubmitting for review."It is really odd since Apple reviewed and approved an update of MacFamilyTree just 5 days prior to this rejection. Additionally, Apple is currently promoting MacFamilyTree big time on the Mac App Store front page. Looking at the trademark guidelines for the Mac Trademark, we're in full compliance to it.I see numerous apps and companies using the "Mac" prefix at the Mac or iOS App Store. Has anybody made a similar experience recently? Is this just an overzealous app reviewer or some kind of new guideline that is not yet published?

Hi!I am trying to encode CGImages as HEIC/HEIF images on macOS 10.13. I am aware that this is only be possible if the Mac brings a hardware HEVC/HEIC/HEIF encoder, otherwise it will fail. I am using a 2016 MacBook Pro for testing which supports HEVC hardware encode and should support encoding HEIC/HEIF images just fine.Using macOS 10.13 developer beta 9, this line does not return a valid image destination (NULL):CGImageDestinationRef destRef = CGImageDestinationCreateWithData((CFMutableDataRef) data, (CFStringRef)AVFileTypeHEIC, 1, NULL);It fails with this message in the console:findWriterForType:140: unsupported file format 'public.heic'Reading .heic images using CoreGraphics works correctly.Am I missing something? Thanks in advance!