Add the following to ~/.lldbinit and examine Swift objects in LLDB with “mp myobject” for both iOS and macOS, including those in NSView for macOS.
command regex mp 's/(.+)/expr Swift.print(%1)/'
Read on for more info
I wanted to share a quick tip I discovered that allowed me to more easily examine objects.
A couple of weeks ago, one of my colleagues reported that she found an issue with the iOS app for AAFES EXTRA, an app that I had developed for BlueSoHo for their client The Army & Air Force Exchange Service.
The iOS app was not displaying the expected updated content. The Android app was working fine. To make things more difficult, the problem was only occurring on one specific device and could not be replicated on any other devices, even of the same model.
Posted in iOS
Tagged certificate, charles proxy, cookies, crash, crashlytics, debugging, device token, iOS, push, urban airship
Having previously developed some Objective-C based frameworks, I set out to explore doing the same with Swift and be able to deliver the framework as a Pod.
Creating a a Swift Framework is pretty straightforward and there are some great references on the subject. One that I found very helpful was Creating and Distributing iOS Frameworks
I wanted to include some Objective-C based CocoaPods in my Swift Framework and quickly ran into an issue – you can’t use bridging headers with framework targets.
I did find a workaround which was interesting. An answer in the thread Importing CommonCrypto in a Swift framework showed how to create a module that could be imported into Swift using an Aggregate target. Using this answer as a guide, I was able to create a module for AFNetworking using the run script:
mkdir -p "${BUILT_PRODUCTS_DIR}/AFNetworkingModuleMap"
cat <<EOF > "${BUILT_PRODUCTS_DIR}/AFNetworkingModuleMap/module.modulemap"
module AFNetworking [system] {
header "${PODS_ROOT}/Headers/Public/AFNetworking/AFNetworking.h"
export *
}
EOF
This was interesting, but not the right approach.
I was asked to fix an issue with an existing app called SmartPak wherein users on iOS 10.1+ would see a warning message about the app slowing down their phone if they were using a 64 bit device. The fix itself was pretty straightforward – the architecture settings did not support 64 bit builds and a Digimarc library needed to be updated.
As I prepared to distribute the app for internal QA, I ran into a more difficult problem. I was unable to download the Adhoc Crashlytics build to any of my test devices.
Posted in Xcode
Tagged console, crashlytics, debugging, entitlements, iphone, provisioning profile, signing, Xcode
In reviewing a crash log for a recently published app, I ran across a scenario where a user could reproducibly force a crash by using a long press on a link in a UITextView.
On the first long press, I see the warning:
