I am having a crash too. My feeling is that the problem could be when we include the entitlement com.apple.developer.passkit.pass-presentation-suppression in our provisioning profile the value for the key application-identifier is an array with one string, and when we do not include this entitlement the value for the key application-identifier is just the string. My assumption may also explain the error shows in the previous reply: ProductBuildVersion: 11E608c UNCAUGHT EXCEPTION (NSInvalidArgumentException): -[NSArrayM hasSuffix:]: unrecognized selector sent to instance 0x7fc1a5d47c60 Here is the part in the provisioning profile that I refer to: &#9;... &#9;<key>com.apple.developer.passkit.pass-presentation-suppression</key> &#9;<true/> &#9;<key>application-identifier</key> &#9;<array> &#9;&#9;&#9;<string>##########.###.########.######</string> &#9;</array> &#9;... And here is the diff between two provisioning profiles created with and without the entitlement com.apple.developer.passkit.pass-presentation-suppression. The two provisioning profiles were the result of running the command line security cms -D -i Mobileprovision | => diff with-passkit-entitlement.mobileprovision without-passkit-entitlement.mobileprovision 12c12 < <date>2020-12-24T01:33:51Z</date> > <date>2020-12-24T00:50:06Z</date> 27,32d26 < <key>com.apple.developer.passkit.pass-presentation-suppression</key> < <true/> < <key>application-identifier</key> < <array> < <string>##########.###.########.######</string> < </array> 43c37,40 < > > <key>application-identifier</key> > <string>##########.###.########.######</string> > 86c83 < <date>2021-12-24T01:33:51Z</date> > <date>2021-12-24T00:50:06Z</date> 129c126 < <string>######-###-###-###-#########</string> > <string>######-###-###-###-#########</string>

If you are running your test for the simulator, did you check that all your dependencies and your framework are compiled for arm64? Remember that for intel Mac the architecture was x86_64, but in the case of the M1, you should choose arm64.

Hi @Razorback2424 , I think that indeed, @RayWo provided you with a solution to your question, but there is something that isn't mentioned in your question, neither in the above response, which is if the queries associated with either model context will catch the updates in the model container made using the other model context. And I think that the answer is no. As per my understanding, the model context will take care of updating the model container without collusions, but they will not read it if any update happens. General speaking, I think that the only time that multiple Model Contex make sense is when is needed to process data of a DB in the background that doesn't care if in the meanwhile the data change and of course will never use its Model Context for data updates.