The extension has a set memory limit, which is much less than that of an app. Why can you not do the iteration in the app when it first launches rather than the extension? (the extension is not part of the app, it is separate from it but data from the iteration process can be shared via the filesystem for example). Also an extension doesn't simply run for 30 seconds, it will run until the completion handler is called, if the handler is not called within 30 seconds then the system will call the handler for you. If you have to do the iteration within the extension, you will need to delay calling the completion handler until the iterations have completed. If that takes longer than 30 seconds, then that's another good reason why you need to look at doing this in the app rather than the extension. You say the iteration is part of the initialization process, hence its a one time operation, why therefore cannot it be performed by the app (I use the term app to not include the extension) the first time the app runs, and then the results of that made available to the extension?

I've never encountered any CPU restrictions with an extension. So maybe it is running out of memory. You have enough memory to load the array, but then maybe you are consuming more memory as you process the array. If you run/debug the extension (as opposed to running/debugging the app) in Xcode you can monitor the memory usage in real time just as you can with the app. I think from memory the memory limit is 20Mg, so you can see if you are getting close to and then hitting this limit (if you go over while running the extension in Xcode then it'll tell you) If you are running out of memory then you can try using autoreleasepool {} during processing to free memory. The OS churns out a lot of logging, if you search in the log console (not Xcode's log console) for your extension bundle id while its running, the OS will probably log what the problem is. Or as mentioned above, run the extension in Xcode and that'll probably tell you what the issue is.

I have the same problem. Also iOS 17's CTSubscriber.simInserted() has stopped working in iOS 18. So forwards compatibility has been broken (apps released using CTSubscriber.simInserted() no longer work).

Well that's impossible. An iPhone app doesn't have the capability to detect an incoming call never mind listen to the content. Apple themselves of course would have the ability to do this, but not anybody else unless they have a server integrated with the telephony system. An Android app could with certain permissions, but that's not for this forum.

Yes it does, I forgot to select the All tab, its set to the Basic Tab by default

I've been using RN in a large app for a few years. The larger and more complex the project becomes, and especially the more and more things that get implicitly and explicitly pulled in by RN then the more and more and more unstable Xcode becomes in being able to compile it, and then run it. I can't speculate from what you've posted what the issue is, and am not familiar with that framework being used, but from experience if you clean everything (I mean everything, including deleting the node_modules folder and the pods folder and everything in Xcode) and restart the Mac then there's a 95% chance issues go away.

You can't prevent the app from moving to the background.

No. Carrier apps can use a private api to detect the phone number, but there's no public api available to do that.

I filed a feature suggestion years ago, FB12745207. It remains open to this day. I know that similar feature requests have been filed by large well know companies.

isSIMInserted is broken and doesn't work with beta 1 and beta 2, you need to use beta 3. And the subscribers should be obtained via CTSubscriberInfo.subscribers() .

Yes there is documentation of this API, but as this feature is intended for cellular carriers the documentation is not publicly available. If it doesn't work then its for one of 3 reasons: The app doesn't have the sim-inserted entitlement The MCC/MNC pairs doesn't match that of the sim(s) present on the device The app is itself creating a CTSubscriber as in the above code rather than obtaining it from CTSubscriberInfo.subscribers()

This is a question entirely to do with React Native and nothing to do with iOS/Swift etc. and therefore is not an appropriate forum. Stackoverflow would be better. You could try adding the following to the Bundle React Native build phase to see if that works: if [ -d "/opt/homebrew/bin" ] && [ -x "/opt/homebrew/bin" ]; then export PATH="$PATH:/opt/homebrew/bin" fi

I get the exact same thing, its been present from Beta1 to Beta4. It crashes all the time, therefore I am unable to build our app using Xcode 16. I filed a radar when beta 1 came out, but that's gone ignored.

Which parts of the Apple documentation on submitting apps is lacking or unclear?

I changed the urls used from http://MacBook-Pro.local:8080 to the Mac's ip address:8080 and now get this error instead: configure failed Error Domain=com.apple.CipherML Code=1100 "Unable to query status due to errors: failed to fetch token" UserInfo={NSLocalizedDescription=Unable to query status due to errors: failed to fetch token, NSUnderlyingError=0x9fc845ef0 {Error Domain=CipherML.AuthenticationError Code=3 "failed to fetch token" UserInfo={NSLocalizedDescription=failed to fetch token}}} Presumably this has something to do with service-config.json contents: { "issuerRequestUri": "http://192.168.1.4:8080", "users": [ { "tier1": {} }, [ "AAAA" ], { "tier2": {} }, [ "BBBB", "CCCC" ] ], The instructions for this say "For the userTierToken, please set it to one of the values that you added in the service configuration file in Running the service section. For example BBBB."