Can you please answer my questions as is in apple documentations its mentioned that NSstring is thread safety: Thread Safety Objects When Apple says thread safety what do they mean: is it: crash/ no crash or the correctness of the entire value (like you gave in the above example of 2 properties)? if We look at the following property @property (nonatomic, nonnull) NSString * familyName; Without copy (I see no particular reason to set it as copy although the underline subclass is mutable, but lets assume we are not going to pass any mutable object to that property). If the following is read and written from multiple threads can it crash? can it have non correct value ? (what do you mean non thread safety in that context) From your last answer u described a case when it can crash (accessing a released object). Can you back up your answer with code snippet? Can you provide a code that will crash when you read/ write to the above property from different threads?

@DTS Engineer Any chance you can share your insight about the above question?

Sorry but I still have few follow up question. With the above definitions can I assume that @property (nonatomic , copy, nonnull) NSString * familyName; Will also be thread safe (no crash) and the value correctness in multi thread environment. My assumption arise coz from first look I would assume that the read/write occurs to the underhand ivar and the object is immutable but I am not 100% confident if there are any additional steps in the synthesized getter/setter From what I can see Apple interpretation of thread safety is the consistency of the data across the whole objets i.e in your case is the consistency between the familyName and givenName . am I correct?

ok so lets define couple of things. "thread safe" - lets define it as safe to use without crashing "correctness of the value" - basically what you mentioned, a consistent behavior between right and reads. Let's keep the discussion only to one property. In that case can we assume its thread safe and correctness of the value?

@DTS Engineer both crashes occurs in 2 different places under 2 different threads. The current one is related to the processing of the payload we received from the BE and runs in sync queue. While the previous crash runs and different sync queue and its purpose is to handle app analytics as soon as one is received. With that to say its hard for me to directly link between the two issues except of some general memory corruption

@DTS Engineer but could you please explain the crashes?

@DTS Engineer Any progress on that or some explanation about the crash?

@DTS Engineer I had a long call with that client and it seems that most of those crashes were caused by out of memory issue (indicated by instabug). Is it possible to see that information from apple crash logs? (how much memory were used by the app, how much disk is used etc )

Subclassing Notes Not common but defiantly possible, described in apple docs. Yes same client :(

@DTS Engineer ok so In the case of index out of bounds OR nil insertion. Try/Catch should prevent the crash, right?. So maybe we should (at least reduce number of crashes). What do you think about that approach?

@DTS Engineer What do you think if we rewrite apple componentsSeparatedByString with our own implementation something like that: https://gist.github.com/MikePendo/ef4eb4cfd03adfbf07dd040a1d538089 Maybe it will point out to exact place of the crash?

@DTS Engineer Why the stack trace of componentsSeparatedByString: is different between crashes? (different OS?)

@DTS Engineer So initially we tried in our sample apps but that it didnt yield any result. So I took client compiled app, compiled the SDK with Sanitizers and injected it to the client app. (I have linked the ASAN libs to prevent crashes when the app cant find those libs SDK refers to) . I tried mainly the Address Sanitizer tool (it seems like the most appropriate)

Hi, Thanks for your help. Yes Yes Currently one client reported about the issue (I tend to believe there might be more clients with the same issue) wanted to point out that I managed to reproduce the following crash on the client app: Thread 182: EXC_RESOURCE (RESOURCE_TYPE_MEMORY: high watermark memory limit exceeded) (limit=1450 MB) . That happens when the data is to big , it should not happen and we will fix it BUT no guarantee it will solve their issue

@DTS Engineer Any additional info u can provide