I was debugging a Swift Mac app that I’m developing that uses Realm for a database. The version of RealmSwift I was currently using was 2.10.0 as specified in my Podfile.
I opened Realm Browser to inspect a record in my database. Having been recently updated to version 3.0.1, it alerted me that my database was using an older file format and offered to upgrade it. I accepted without thinking much of it.
I was recently putting together the structure for some system level unit tests of a Swift project. The structure extended beyond a single file for these tests. I currently have:
Here is an example chain of calls coming from a test case:
BasicSystemTests
func testModified () {
// Test modification to Project
//
createProject(name: "Test Project", bundleId: "TestBundleId", appDelegate: "TestAppDelegate", fsConfig: "TestFsConfig", description: "Test Project Description")
SystemTests
func createProject(name: String, bundleId: String, appDelegate: String?, fsConfig: String?, description: String?) -> String? {
// Is Add New button enabled?
project.verifyAddNewButton(enabled: false)
ProjectTestUtils
func verifyAddNewButton(enabled: Bool) {
XCTAssertEqual(addNewButton.isEnabled, enabled, "Add New button enabled = \(enabled)")
}
My test case has a bug. When I run the test case, I see the following in Issue Navigator and the source code editor:
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.
