[quote='811949022, Apple Staff, /thread/767491?answerId=811949022#811949022'] As long as automaticallySync is true, CKSyncEngine schedules an initial sync on init, and since we're starting fresh with this instance of CKSyncEngine, it will go and fetch everything from the server (i.e. all contacts saved under the new account) and handle them locally. [/quote] Thanks a lot for the detailed explanation! I would never be able to figure it out myself if you didn't mention it.

[quote='811736022, Apple Staff, /thread/767491?answerId=811736022#811736022'] In the above case (.switchAccounts), as shouldDeleteLocalData is true, at the bottom of the function deleteLocalData() is called. That clears syncengine's current state (stateSerialization) and re-initializes, which will cause the engine to fetch the new account's data from CloudKit from scratch. [/quote] Thanks. May I ask how re-initialization could " cause the engine to fetch the new account's data from CloudKit from scratch"? In my understanding deleteLocalData() resets appData and calls initializeSyncEngine() to create a new CKSyncEngine instance. There is no code to load local data from the new account's document folder into appData. That part of code is in SyncedDatabase actor's init, which I don't think get re-called in this scenario. So I suspect, after switching new account, the app will show an empty list even if the new account has data on iCloud. Am I missing something? PS: I can't do the experiment at the moment because I don't have a proper environment to compile the project (I'm wating for the new mac mini 7 :)

[quote='810806022, DTS Engineer, /thread/766748?answerId=810806022#810806022'] When saving a record that contains a CKReference field, CloudKit verifies that the target record exists in the same record zone. If it doesn't, CloudKit reports an error and does not proceed the save. [/quote] Hi Ziqiao, Thanks for your explanation. It has been very helpful. I'm going to create a FB to request adding information like this to CloudKit document. Your answer has covered the scenario in my original question. If you don't mind, I have a further quesiton. Can I assume that CloudKit makes sure that CKRecord.Reference is always valid in general? Let's consider a different scencairo, for example. Setup: suppose we have account a1 in the database, and there are no transactions associated with it yet. User first adds a transaction t1 on device A. The device saves the change to cloud. User then deletes account a1 on device B before the device receives the change in step 1 from cloud. Since there isn't t1 on local data store, the operation should succeed locally. Then device B tries to save the change on cloud. My question: what will happen when device B saves the change in step 2 to cloud? A) If t1's reference to a1 is created with CKReferenceActionDeleteSelf, I think CloudKit will delete t1 automatically. (A note to myself: will device B receives CKDatabaseNotification and sees t1 when doing CKFetchDatabaseChangesOperation?) B) If t1's reference to a1 is created with CKReferenceActionNone, CloudKit will do nothing and the data on cloud becomes inconsistent. Does this mean it's up to app developer to set up the reference with proper action and otherwise CloudKit doesn't guarantee reference validity? [quoted] In the case you described, where a1 is not a new record, I'd expect that CKModifyRecordsOperation returns you an error. Did you not get that? [/quoted] I'm evaluating if it's feasible to add CloudKit support (specifically, CKSyncEngine) to my app. I'm still in the early phase of trying to understand how it works. So I haven't tried any code yet (partially beause it involves timing and it's hard to get definite conclusion based on experiment results). Thanks Again.

So I believe my understanding is correct. The downloaded image was cloned and mounted by "xcrun simctl runtime add" command. That's the reason why I didn't observe many write ops when running xcrun command. BTW, the GUI message box that popped up after xcrun completed is bad UX. It's confusing.

Hmm...I think my question is a basic user question and understanding it helps me (and perhaps other users) better use Apple's technologies. I understand it's Apple's culture to not disclose its product details, but it's bad that the culture is often used as an excuse. Anyway I have deleted the simulator image file I downloaded and Xcode works fine (it would be absurd if it didn't). I compared "df -m" output on my MBP before and after I deleted the file. There is little change (as expected).

Thank @mungbeans for the information. I did the same and now my phone shows in Xcode.

Thanks, but I don't want to set anchor to nil, because it has the same result as setting anchor to .bottom in this case, which in my opinion is bad UX (I want the item to show up on top of the screen when the LazyVStack has a lot of items). Background: my app currently uses List and setting anchor to .top works well. I was considering to change List to LazyVStack and ran into this issue. EDIT: or did you suggest it as workaround? Yes, it works, but unfortunately it's bad UX. I'm thinking to keep using List until the issue is fixed.

Claude31, I'm afraid I can't agree with your opinion. Let me describe my requirements, which I believe it's very typical ones and make sense to most, if not all, people: When specifying .top option, the item to be scrolled to should show up on the top of the screen. However, if that pushes the items before it outside screen and, at the same time, there are no enough items after it to fill up the screen, SwiftUI should find a proper position to show it. The above requirements are exactly the behavior of scrollTo() in List. I don't understand why VStack/LazyVStack/LazyVGrid don't implement the same behavior. Why would anyone like to have their current (buggy) behavior? Can you think of any use cases? In my opinion that behavior doesn't make sense at all. If SwiftUI engineers really interpret the .top value that way (I really doubt it), then I think they should introduce another option value to support List like scrolling behavior. I can't use the code you suggest, because that's not my. purpose. I'd like to scroll to the last item. It's just that SwiftUI should handle the corner cases properly. Regarding the async call, it's required when navigating to a view.

when you go into settings on an iPhone (is that one screen?) then when you click (for example) notifications (is that another screen) then say you go deeper in notifications to another sub heading “scheduled summary” (is that another screen) I don't know if "screen" is a formal or popular terminology, but I think your intuition is correct. An analogy: a screen is to an app as a web page is to a web site. this may be a stupid question but i found it hard online to find the meaning of screens in apps and also think surely this can’t be included as screens because there is so many?? Whether it's fair to pay a developer based on the screens in the app depends on the details of the app. It can also be based on features or the development time needed (I'm not in this business so I don't know which is more popular). Either way you'll need some technical background to evaluate it. I'd suggest you ask people around you if you're not sure. once the app is up and running, is it easy to add more information regularly myself or would I need someone with coding experience? (this would just be some words, a photo and maybe a table) You need to add this as a key requirement to your app, because it affects how the app is designed (it sounds like you'll need a server also). BTW, software development isn't one-off thing. It needs maintenance and future enhancement. You need to take it into account when making decisions.

It's a stack overflow caused by a known issue with enum with large payload size. See discussion here. The upgrade was a red herring (sorry for the false alarm).

UPDATE: while I'm not sure, I'm investigating if it's a stack overflow issue now (I didn't realize it at first because it used to work fine). See my reply to Claude31 below. I apology for the misleading title (unfortunately I can't change it).

Hi, Claude31, thanks for the help. This is the error message (or do you mean a complete crash log as described in this page?) Thread 7: EXC_BAD_ACCESS (code=2, address=0x70000be7cfb0) And this is the stack trace of a test I written to reproduce the crash. The test contains no UI code (I ran into the issue in my app at first). The test calls API of a library in my app, so the stack trace is perhaps meanlingless to you. More on this below. I have been thinking about the issue today and now I suspect it might be a stack overflow issue, mainly because I can't think of any other reason why it crashed (more on this below). It may also explains why the issue doesn't occur on my phone (for example, could it be that the cooperative thread on phone has larger stack size than that on macOS? BTW, my laptop has Intel CPU, not sure it makes a difference) Below are some details which may help to understand the background of the issue: The code that crashed are quite simple. My app has a demo mode. When user activates the demo mode, the app runs an async func to generate demo data, and pass the generated data back to the main thread. The crash occurred in the async func to generate the demo data. While the internal of the code to generate the data are complex, it's quite simple from architecture perspective because a) it doesn't interact with any other part of the code in the app, and b) it uses only structs internally and return value of a struct. So there isn't a obvious reason why it could crash due to memeory error. I was able to reproduce the issue in a non-ui test (see stack trace above). Unfortunately I wasn't able to reproduce the issue without using my library. For example, creating a large (e.g, size of 8M) array or dictionary in an async func doens't crash. I think it's because array and dictionary have very small footprint in stack (they are mainly in heap to support COW behavior). That said, I use only value types (structs, array, dictonary, enum) in my app, so I have no idea why I could have stack overflow issue. If I change the async func to a plain old sync func and call it in main thread, the code worked fine. That's why I think it's might be a stack size issue, because main thread has larger size than worker thread. That said, I have developed the app for more than one year and did a lot of testing, including provisioning a large set of data in main thread. I never saw the crash issue in main thread (as I explained above, I suppose it's because arrays and dictonary has small footprint in stacks). So, while worker thread has smaller stack size, I didn't expect this issue. Also, as I decribed in previous posts, I run into the issue after I upgraded my OS and Xcode. It worked fine on macOS 13.0 + Xcode 14.0. Could it be some thing changed on macOS that caused the crash (I don't mean it's a bug)? Now I'm trying to figure out how to verify this is really a stack overflow issue and identify which function the overflow occurs. The internals of the demo data generation file is complex: it generates raw data, then parse the data to generate derived data and repeat (there are recursion invoved, thought I don't think recusion is the reason caused the stack overflow, I suspect it's the size of the data instead). The crash log seems helpless. The size(ofValue:) doesn't help either, because as I said above most of the storage in array and dictionary are in heap. Do you have any suggestions? I'm also thinking to ask in Swift forum what's the general approach to identify stackoverflow issue. Thanks.

More information. I find the following on Xcode 14.2 download page (emphasis mine): It includes SDKs for iOS 16.2, iPadOS 16.2, tvOS 16.1, watchOS 9.1, and macOS Ventura 13.1. (see: https://developer.apple.com/download/applications/. The same information can be found in its release notes.) So Xcode 14.2 doesn't support macOS 13.2?! I don't understand it. How come Apple releases a new OS version without a new Xcode version working on it? Now that I have upgraded my OS to 13.2, what options do I have? Thanks for any help.

(deleted)

Same issue here. It's a EXC_BAD_ACCESS error which doesn't make sense (I'm very sure because the same code worked fine in Xcode 14.0 in the past several months and I never observed the crash). BTW, the crash occurred only in simulators (it's not random and can be reproduced consistently) but not on my phone. It seems to be an issue with the iOS image in simulators, not the compiler. I developed my app in Xcode 14.0 and installed Xcode 14.2 just to prepare for submitting the app. I'm downloading Xcode 14.1 and hope it will work fine.