iOS Question [Closed] B4i App Crashes on iOS 18 Devices

fredo

Well-Known Member
Licensed User
Longtime User
For the past few days, a B4i app has been experiencing previously unknown issues, and I urgently need helpful advice.

In summary, there seems to be a specific problem on devices running iOS 18.

The app has been available in the App Store for years and runs smoothly for hundreds of users.
Since the app is distributed as a high-priced subscription model, it is now of great interest to resolve the issue as quickly as possible.
The version uploaded a few days ago caused crashes for several users.
Investigation revealed that all affected users had iOS 18 installed on their devices.
There were no crash reports from any other users.

As there is no real device with iOS 18 available, an attempt was made to test the app with the online emulator "Appetize.io" to find the causes of the crashes through the debug log.
This has worked well for the past three years.

However, recently this failed as soon as iOS 18 was selected on the target device.
The app crashed immediately with the error "...incompatible architecture (have 'arm64', need 'x86_64')".

The app was compiled with the remote host, using both the normal server and the secondary server.
B4X:
primary server
test on appetize.io with iphone 14pro ios 18

dyld[62298]: Library not loaded: /System/Library/Frameworks/CoreFoundation.framework/CoreFoundation
  Referenced from: <FAC34313-4731-35A5-8B95-111E1DD31395> /Users/sim3/Library/Developer/CoreSimulator/Devices/60112ECE-2795-4B0F-83C5-B0A6073B2989/data/Containers/Bundle/Application/7922E7C4-4FF2-4991-B268-398C16B036AE/myapp.app/myapp
  Reason: tried: '/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 18.0.simruntime/Contents/Resources/RuntimeRoot/System/Library/Frameworks/CoreFoundation.framework/CoreFoundation' (mach-o file, but is an incompatible architecture (have 'arm64', need 'x86_64')), '/System/Library/Frameworks/CoreFoundation.framework/CoreFoundation' (no such file, no dyld cache), '/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 18.0.simruntime/Contents/Resources/RuntimeRoot/System/Library/Frameworks/CoreFoundation.framework/CoreFoundation' (mach-o file, but is an incompatible architecture (have 'arm64', need 'x86_64'))
b4i.myapp.com: 62298

---------------------------------------------
secondary server
test on appetize.io with iphone 14pro ios 18

dyld[58939]: Library not loaded: /System/Library/Frameworks/CoreFoundation.framework/CoreFoundation
  Referenced from: <CCE63A4F-3964-3FD7-B8F0-81273AF71C44> /Users/sim6/Library/Developer/CoreSimulator/Devices/862A58DB-5722-4BE4-A27C-EF0CD37ADE21/data/Containers/Bundle/Application/20701088-90E2-447E-B4B9-49E72A6E6750/myapp.app/myapp
  Reason: tried: '/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 18.0.simruntime/Contents/Resources/RuntimeRoot/System/Library/Frameworks/CoreFoundation.framework/CoreFoundation' (mach-o file, but is an incompatible architecture (have 'arm64', need 'x86_64')), '/System/Library/Frameworks/CoreFoundation.framework/CoreFoundation' (no such file, no dyld cache), '/Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 18.0.simruntime/Contents/Resources/RuntimeRoot/System/Library/Frameworks/CoreFoundation.framework/CoreFoundation' (mach-o file, but is an incompatible architecture (have 'arm64', need 'x86_64'))
b4i.myapp.com: 58939

  • An app that has been available in the App Store for about three years was always compiled with the Hosted Builder and successfully tested on a local device (iPhone 8+ with iOS 16.7.10).
  • Subsequently, the new versions were each successfully tested on "appetize.io" with multiple iPhones and various SDK versions.
  • Version 45 of the app was approved by Apple for distribution on January 30, 2025, and has been running smoothly for all users since then.
  • On March 12, Builder1 was upgraded to Xcode 16 (I'm not sure if this is related to my problem, but I mention it to consider the technical influences).
  • On March 14, 2025, the app was recompiled and uploaded as version 50, which was approved by Apple for distribution. Although Apple is known for rigorous testing, no crash occurred there.
The last version 50 then caused crashes for users with iOS 18 devices.

To rule out changes between version 45 and version 50 as the cause, the archived code from version 45 (which worked for all users) was used to create a new version 53.
On a real device (iPhone 8+ with iOS 16.7.10), everything ran correctly.

On the emulator (appetize.io), it ran fine with "iOS 17.2," but with the setting "iOS 18," the previously mentioned crash logs reappeared ("... incompatible architecture (have 'arm64', need 'x86_64'...).

What can I do on my end now to quickly find a solution?


______
Edit: Although I am not sure if this is relevant, I would like to mention for the sake of completeness that I renewed the Apple certificates, provision files, AuthKey.p8, and Distribution.cer on March 12th.
 
Last edited:

fredo

Well-Known Member
Licensed User
Longtime User
...will advice you get an iOS 18 Supported device...
Due to the urgency, I now have an iOS 18 device on-site and can continue the troubleshooting here.

Since some users have reported crashes during startup and others have mentioned missing content in the UI, our current focus is on "Page1_Resize".

It appears that the issue is caused by a race condition. Under iOS 18, the numerous "Wait for()" calls in "Page1_Resize" seem to be processed differently, disrupting the usual execution order.

The next step on our side will be to offload everything from "Page1_Resize" that can be executed later.
 
Upvote 0

fredo

Well-Known Member
Licensed User
Longtime User
It appears that the issue is caused by a race condition...
After the complete revision of ‘Application_Start’ and ‘Page1_Resize’, everything works smoothly again.

Although the exact cause of the problem could not be identified, all nested sub-procedures involved were cleaned up from unnecessary ‘Wait For()’ calls and ‘Sleep(...)’ statements.

It has become clear that the effects of the asynchronous processes on our side were not fully understood.

As the app was continuously expanded over the years, related code areas were created in several modules without the connection being clearly recognisable.

It's time to relearn the principles of Erel and ‘Uncle Bob’ and transfer the monstrous code relics to B4XPages.
 
Upvote 0
Top