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
Related
I am panic. I am new in programming and in iOS development. Tomorrow I plan to publish my app to the app store for my company. but this morning I update my iPhone to iOS 12.2, and I must update my Xcode to 10.2.1 in order to make Xcode can run my app on my real device.
but I get hundreds of warnings like the image below. Unfortunately I also stuck to downgrade my iOS on my iPhone to be back to 12.1.4. so it seems that I still have to use Xcode 10.2.1 and iOS 12.2 on my iPhone. there are more than 250 warnings on my Xcode:
even though almost all the warning are:
warning: public' modifier is redundant for instance method declared in
a public extension
I can run my app without issue. but I choose not to fix the warning and leave the 'Conversion to Swift 5 is available' and also 'update to recommended settings'
because it will make error to my firebase Pod and I can't run my app. so my question is....
Can I still publish my app to app store and run without issue on the real device of the users ? because I choose not to fix the warning and leave the 'Conversion to Swift 5 is available' and also 'update to recommended settings' , but it still worked without issue on my simulator. I am worried apple will reject my app because I don't fix 'Conversion to Swift 5 is available' and also 'update to recommended settings' warning
Regarding the decision to update Xcode so you could run this on your device, it turns out that this may have been unnecessary. Largely regardless of Xcode version you use, you generally can manually install an app on an device running a more contemporary iOS version. You just won’t be able to run it via the debugger from an older version of Xcode. See https://stackoverflow.com/a/35044362/1271826, whose basic concepts about installing still apply today.
All of that having been said, the choice of minimum Xcode version is dictated by Apple’s App Store guidelines. See this March 2019 guideline which says that apps must use iOS 12.1 SDK or later. And watch the Apple Developer News feed as these minimum SDK requirements change over time.
Regarding the warnings, they will not be a problem for submission. Apple doesn’t have your source code and has no exposure to what compile-time warnings you got. The thing is that these warnings really are telling you important and helpful stuff about “such and such might be a problem”, which is why it’s good to resolve all of them. We can’t comment about which warnings are really important and what’s not without seeing which warnings you received.
But I’d suggest that you:
Make sure you install a version of Xcode that supports the minimum SDK version outlined in the Apple Developer News feed; and
Make a good faith effort to address as many of the warnings as time permits.
At the time of writing, the minimum SDK version is 12.1. But keep an eye on that feed, as the minimum requirements are periodically updated, but generally with some advance warning.
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.
I'm in the midst of squashing bugs for my App in development, and I've stumbled across a problem when it comes to addressing a crash occurring on iOS 8.0.2
The problem is that I can't actually test (On the simulator) for iOS 8.0.2 as the earliest version of iOS 8 I can use is 8.1
I am not supporting iOS 7, but did go back and try to see if I could catch the bug there as described by the tester who reported the crash. It did not occur no matter what I did, so I assume it must occur when running iOS 8 only.
I'm not sure how to address this problem. I would like to submit my App for review, but if I cannot eliminate this crash I will be rejected. Yet I can't test for it either. I've been waiting a day+ now for any crash report to come back from Test-Flight, but none have shown yet. It could take around three days for that to happen.
Can anyone assist me in finding another way or workaround to be able to test for this crash?
You could download and install Xcode 6 (Xcode 6.1 might also have the iOS 8.0 simulator) as that'll have the iOS 8 SDK and simulators (you'll have to be signed in to your Apple developer account to access those links otherwise pick from the list here).
The problem you'll then have with that though, is that you'll be compiling your code against a different SDK. But its worth a try!
Its also difficult to get specific 8.0.X versions of the simulators as they only really have the minor version release (8.X) available as opposed to the bug fix releases.
Obviously the only guaranteed way to reproduce the issue is on a 8.0.2 device.
Ok, so this guy had no problems building and submitting an App, targeting iOS 7+, using an Embedded framework.
He points out that an Apple Engineer nick-named 'SevenTenEleven' mentioned in the Apple Dev Forums that the following warning...
ld: warning: embedded dylibs/frameworks only run on iOS 8 or later
...is just a bug.
The warning is still present in Xcode 6.3 and it seems that an App store submission is the only way to know for myself, if this is actually a bug or not.
Has anyone found any documentation that suggests this is just a bug and that there is in fact, nothing to worry about ?
Building an App just to see if a framework like this can target iOS 7, and make it through the App Store submission process, is crazy. Unfortunately, my client just wants an SDK, so there is no App I can do a test run on at the moment.
Used a ticket to speak with Apple
"Hi Rob,
Thank you for contacting Apple Developer Technical Support (DTS). I am currently investigating your issue. To answer your question, I need to consult with some folks in iTunes Connect. Unfortunately this can take some time as they are very busy.
In the meantime, I will point out that it is only supported to use an embedded framework on iOS 8. The only question is whether you could use dlopen() to conditionally load the embedded framework on iOS 8, and not load the embedded framework on earlier versions of iOS.
I will let you know what I hear from iTunes Connect about this question.
Luke Rattei
DTS Engineer"
"Hi Rob,
Embedded frameworks are only supported on iOS 8 and above. Unfortunately you will not be able to use an embedded framework on iOS 7.
While it might be possible to run apps with embedded frameworks on iOS 7 during development, you will not be able to submit such apps to the App Store. You will see an error message that the MinimumOSVersion of your embedded framework must be at least 8.0.
Luke Rattei
DTS Engineer"
While it might be possible to run apps with embedded frameworks on iOS 7 during development, you will not be able to submit such apps to the App Store. You will see an error message that the MinimumOSVersion of your embedded framework must be at least 8.0.
I encountered this exact problem about a month ago. I was forced to target iOS 8.0 in my app and embedded frameworks projects.
And I just tried to submit the app again with the iOS 7 support, and this time it has been approved!
I'm crazy? To be honest I have trouble understanding the logic around this.
Alex.
Since Xcode 4.5, we are unable to build for armv6 and thus unable to support devices like iPhone 3G anymore.
Would it be possible to use, say, Xcode 4.3 to generate a properly signed armv6 binary and then use lipo to combine that binary and the Xcode-4.5-generated armv7 binary into a fat one?
How would I go about this? Does anyone know a good tutorial?
Would the resulting fat binary be allowed for submission to the App Store?
The code signature would no longer match after modifying a binary using lipo. So the bundle would need to be re-codesigned afterwards.
Apps built with Xcode 4.4 and even earlier will still run just fine on iOS 6 devices; and there are reports that Apple is still accepting apps built with the iOS 5.1 SDK.
Objective C will allow you to use some of the newer APIs not in the older linked frameworks via calling them thru the Objective C runtime by name. (Of course, the app should check for their availability on the current device first!)
You can even support the new iPhone 5 display from an earlier Xcode and pre-iOS-6 SDK by simply including a 568#2x tall Default image in the app bundle, and setting all your app's window and view sizes and resizing properties properly. UPDATE: Apple is no longer accepting apps built this way when submitted to the iTunes App store.
ADDED:
Another potential solution is to split your development into two similar apps. One for iOS 4.3 and up. And one for iOS 4.2.x and lower with not iOS 6 and iPhone 5 support. Two different apps in the app store. However it is unknown whether Apple will allow this.
It appears that someone else figured out how to do it, see this SO question.
I haven't tested it yet myself, though.