The current AppStore version of my app is seeing crashes for hundreds of users, where bundled frameworks cannot be found. This didn't come up in testing, and I've been unable to reproduce the problem, whether on the simulator or a device, regardless of whether I wipe the device clean and to a fresh install, or install over an existing version.
The error log I've obtained from a user indicates:
Dyld Message: Library not loaded: #rpath/OMGHTTPURLRQ.framework/OMGHTTPURLRQ
Referenced from: /var/containers/Bundle/Application/BB320110-3C64-4772-9A3A-208F4CAD84B5/PicTapGo.app/PicTapGo
Reason: image not found
However, upon review, that framework certainly IS included in the actual bundle that was sent to the App Store, in the Frameworks folder. In the Xcode project, Runtime Search Paths includes '#executable_path/Frameworks', and that's where the frameworks are bundled.
This is the first time we've linked against a dynamic lib (which is a must, because the lib includes Swift code), so it's possible (likely, even), that I'm missing something crucial about embedded frameworks here.
Again, the strange thing about this is that I can wipe my iPhone clean, and reinstall this version from the App Store, and the error does not occur. In every configuration I've tested (including with our beta testers), the library loads just fine. This means that the framework is missing for only SOME users. Further, there doesn't appear to be any rhyme or reason to the failure. It's happening on all manner of iOS devices, on all versions of iOS 9 (though I don't see any iOS 8 crashes listed in the Xcode organizer). I've been completely unable to reproduce the issue, but for affected users, it happens consistently.
Any idea why only some devices would be unable to find a bundled framework? Does the App Store monkey with your bundle configuration in some circumstances?
After some investigation, it appears that the libraries did indeed disappear. Snooping the actual library binaries that were shipped to the App Store, they ended up only getting built for arm64. Still working on how this happened (maybe some CocoaPods weirdness), but this neatly explains the dyld failures in the wild. For arm64 architectures (iPhone 5s and later), everything is A-OK. For the 4s, 5, 5c, and older iPads, dyld couldn't find the lib. Apparently, the App Store strips out non-compatible architectures when they process the app, and that portion of the bundle is just plain missing on armv7 devices. Looking at the crash reports available, none of them are on arm64 devices.
All of the "library not found" crashes, with a log like the one noted above, are on iOS9. There are similar crashes on iOS 8, but with a different message. I'm assuming it's the one I'm able to reproduce locally ("no suitable image found... Did find <somelib>: mach-o, but wrong architecture"), and this dovetails with the idea that iOS8 devices would get the full fat binary. Lib would be there, but no arm7.
This failure wasn't evident during normal development. I use an iPhone 6 as a primary testing device, and my beta team is apparently all on newer devices as well. I had relied on the simulator to test on older devices. It looks like that's a Bad Idea™ for at least one reason I can cite now. In the future, I'll be testing on an actual, factual armv7 device before sending things into the world.
So, for anyone experiencing dyld failures in the future, this is one more thing to look for. Will update this if that doesn't turn out to be the case.
EDIT: One more tidbit from the autopsy, for posterity - The way we ended up with arm64-only in the AppStore build is by bundling the debug version of the library, not the AppStore version. I bundled the frameworks by creating a new Copy phase, and dragging the frameworks from the Products group of the CocoaPods. However, the actual binary you get when configuring a copy phase that way depends on which scheme you currently have active. If you have a Debug scheme active, you get the debug build of the library. If you have an AppStore scheme active, you get an AppStore build. This is a hard-coded path in the Xcode project, and regardless of which scheme you choose for your main project's build in the future, you'll be bundling the version you originally dragged.
By default, Debug builds only build the active architecture, meaning the Debug libraries were missing armv7 support.
Related
When trying to build and install an application on an iPod running iOS 4.2.1, I'm seeing the error
This application does not support this device's CPU type
I'm trying to build the application using xcode 4.3, as well as xcode 4.4, and still seeing this. What can cause this and how can I fix it?
I have encountered such a problem today on iOS 11.2.1 with iPhone 7 devices.
The reason is that the previous project set up a 32-bit architecture that is no longer supported.
And I solved the problem as follows：
Project -> Build Settings -> Architectures value should be set Standard architectures - $(ARCHS_STANDARD)
From the project build settings -> Architectures, make sure you have both armv6 and armv7 values.
Also, you can check your Info.plist file, under Required device capabilities. If there's armv7 there, remove it.
If you are getting this error building Unity 3D application, change scripting backend to IL2CPP, and select "Universal" architecture.
This post led me to my answer. Thanks #adig and #masam
I have an iOS 8.4 enterprise signed app that would only work on certain device types when I tried to install it from our internal app store, and it was inconsistent. I wasn't getting any helpful error messages, even from the device console, until I tried to deploy it using the XCode Devices to a 5th gen iPod. It said "This application does not support this device type" which led me to here. I was debugging on a 6th gen iPod/iPhone 6.
I was archiving from a different scheme than I usually release from and I was only building the current architecture which meant that it would only work on a certain type of device depending on what was plugged in when I archived.
So make sure that "build active architecture only" is NO when you are archiving an app to sign as an Enterprise app.
I'm getting this error whenever I build in Xcode 6 GM Seed. It seems to be making my app insanely slow. What exactly does this mean and how do I fix it?
I had the following error:
Warning: Error creating LLDB target at path '.....'- using an empty
LLDB target which can cause slow memory reads from remote devices.
PS: im not able to run my app, its stuck on the splash screen
There is a thread in the Apple Developer Forum, https://devforums.apple.com/message/1010068#1010068 that describes how to diagnose this issue. I had his issue for Xcode 6 GM Seed, specifically - Version 6.0.1 (6A317). This isn't necessarily a solution, but it may help some people get a better diagnosis
Useful steps are as follows -
1) Create or modify your ~/.lldbinit and add log enable -f /tmp/lldb-api.txt lldb api to it.
2) Rerun your debugger session (no need to restart Xcode or anything)
3) Inspect the file at /tmp/lldb-api.txt. Look for a line beginning with SBDebugger::CreateTarget(...). Mine looked something like this
SBDebugger(0x7f83671fd600)::CreateTarget
(filename="/Users/xxxxxxx/Library/Developer/Xcode/DerivedData/Dino-gjuxikhuyokkqufeqmesmgjcxylu/Build/Products/Debug-iphonesimulator/Dino.app",
triple=x86_64, platform_name=(null), add_dependent_modules=1,
error=the specified architecture 'x86_64' is not compatible with
'i386-apple-ios' in
'/Users/xxxxxxx/Library/Developer/Xcode/DerivedData/Dino-gjuxikhuyokkqufeqmesmgjcxylu/Build/Products/Debug-iphonesimulator/Dino.app/Dino')
=> SBTarget(0x0)
4) Inspect the target file from the above log output, in my case -
file
"/Users/xxxxxxx/Library/Developer/Xcode/DerivedData/Dino-gjuxikhuyokkqufeqmesmgjcxylu/Build/Products/Debug-iphonesimulator/Dino.app/Dino"
/Users/apanagar/Library/Developer/Xcode/DerivedData/Dino-gjuxikhuyokkqufeqmesmgjcxylu/Build/Products/Debug-iphonesimulator/Dino.app/Dino:
Mach-O executable i386
5) So, In my case my problem was the architectures I was building for. The target architecture for your project should match the one on the SBDebugger::CreateTarget() line in the log output.
Xcode doc's point out the following. I had to go through my nested frameworks and change some outdated architecture targets -
NOTE ABOUT 64-BIT ARCHITECTURE
An app extension target must include the arm64 architecture in its
Architectures build settings or it will be rejected by the App Store.
Xcode includes this architecture with its “Standard architectures”
setting when you create a new app extension target.
If your containing app target links to an embedded framework, the app
must also include the arm64 architecture or it will be rejected by the
App Store.
For more information about 64-bit development, see 64-Bit Transition
Guide for Cocoa Touch or 64-Bit Transition Guide for Cocoa, depending
on your target platform.
https://developer.apple.com/library/ios/documentation/General/Conceptual/ExtensibilityPG/ExtensionCreation.html#//apple_ref/doc/uid/TP40014214-CH5-SW1
I am not sure if this will help in your case. But I tried this solution and it worked pretty neatly for me.
Pull up the terminal and type - rm -rf ~/Library/Developer/Xcode/DerivedData
This is supposed to remove the huge stack of DerivedData folder and make the app execute faster.
Did you use Architectures=$(ARCHS_STANDARD_32_BIT) and run your app on a 64 bit device? (iPhone 5S or iPhone 5S simulator)
Apple seems to be stricter with apps which don't support 64bit. So if there is no specific reason, I think it's better to include arm64 in your build architecture
NOTE ABOUT 64-BIT ARCHITECTURE
An app extension target must include the arm64 architecture in its
Architectures build settings or it will be rejected by the App Store.
Xcode includes this architecture with its “Standard architectures”
setting when you create a new app extension target.
If your containing app target links to an embedded framework, the app
must also include the arm64 architecture or it will be rejected by the
App Store.
For more information about 64-bit development, see 64-Bit Transition
Guide for Cocoa Touch or 64-Bit Transition Guide for Cocoa, depending
on your target platform.
Source:
https://developer.apple.com/library/prerelease/ios/documentation/General/Conceptual/ExtensibilityPG/ExtensionCreation.html#//apple_ref/doc/uid/TP40014214-CH5-SW1
This warning is solved by changing Build Settings :
Select Project -> Build Settings
Change 'Architectures' to 'Standard architectures (armv7, arm64) - $(ARCHS_STANDARD)'
This will prompt an alert stating iOS 5.1.1 and above are supported. Click 'Change Deployment Target to 5.1.1'
Repeat steps for Target (if not changed automatically)
Also, this is preferred build setting since Apple is forcing developers to build apps on 64 but architecture. Apple document Link
I am collecting crash logs for my app but sometimes I have a problem where I can't decode the CoreFoundation and other SDK related Symbols. The lines that are from my app I can read so I have no problem there, but it seems that I can't read the Apple symbols unless they came from a build of iOS that I at one point had on my phone. This is a problem because with iOS 6 it seems that there are a few different builds out there depending on which device you have and I skipped the 6.0.x updates and went right to 6.1.2.
How can I get all these symbols without tracking down friends with different iOS versions and plugging their phone in with XCode running so it will extract the symbols? There must be an easier way!
The only other way, which doesn't work for all iOS versions especially not the last bug fix versions, is answered here: Xcode software image for user iOS in order to symbolicate iOS calls
I have an SDK to achieve some special stream of video but I've got only the binary of this, I think this was built for arm7.
I have an app built with this library and it runs great on iPhone 4, 4s and iPad 2 but when building for iPad 4th generation with an arm7s xcode shows lots of errors about files being ignored.
I'm pretty sure it's the architecture cause changing the build architecture the errors appear and disappear.
Is there any way to make this work? I mean build for new architectures having only binaries files of the old one?
Unfortunately not. To build your app for armv7s all the code – which includes said library – has to be built for it. There is a hack to add armv7s support to static libraries but I would strongly recommend against using it.
That being said, for now it's not a big deal if you're building your app for armv7 only. It will still work fine on the iPhone 5.
Just go into the build settings of your Target and set "armv7" as the only architecture your app should be built for.
At one point in the future Apple will probably require that all new apps / app updates will be built for armv7s, like the did with armv7 a few years ago, but for now it's not a problem. By then the developer of the static library will hopefully have provided an update.
I have noticed that, due to a load of libraries, I could reduce my app size a lot by removing the i386 symbols. However I am unsure if this is acceptable from an Apple review point of view as I heard they test in the simulator.
Am I crazy for thinking about removing this support to make my apps smaller?
A device build does not include i386 support. If you have libraries that are compiled for i386 exlude them from the final build process (remove them from the target, so they wont be copied to the app bundle)
Your final build shouldn't be including that stuff. They don't test in the simulator. Lots of applications won't work in the simulator, such as anything requiring in-app purchases or Game Center integration.