Static analysis is an essential technique for ensuring delivery of quality and secure code throughout the SDLC. Since this type of analysis is performed without the need of a compiled binary, it means developers can analyze their code while it’s being written and checked in to source control.

This is a quick informal analysis of the Obfuscator-iOS library which allows obfuscation of strings for Objective-C and Swift. It’s probably more of a tutorial than anything else and the methods presented here can be applied to any “security” library like this one. There are much faster ways to break this library but we’re going to be running under the following assumptions to make things difficult (despite their improbability):

Many applications rely on strings which contain potentially sensitive data for storing things such as URIs, tokens, keys and secrets. Many of these items are required for core app functionality and must be hardcoded in the source, they can be used as arguments for functions or stored as constants when re-used. Although hidden from the typical user, we can never make the assumption that these strings are safe.

Yesterday BuddyBuild sent out an email yesterday basically stating they are no longer collecting user data unless the users explicitly opt-in. This also means a new SDK and some big changes coming:

Sometimes with Crashlytics beta you can run into scenarios where the application will either close immediately upon launch, or won’t even install and alerts the user:

I’ve always used maxmyers’ 5 step guide when I needed a quick refresher on Pop but now that I’m starting to integrate it in more Swift projects I decided to write a Swift 4 version.

Xcode 9.0 makes keyboard input in playground Live Views almost impossible by not resizing the software keyboard based on the size of the window. The image below is the current behaviour of keyboard input.

Put up some quick code I was running for protoyping live view playgrounds for different devices with keyboard support. If I end up using this more I’ll probably move all the logic to a superclass.

Fingers crossed Jekyll will motivate me to post more. Will move over archives when I have time.

This is an updated version of my 2016 post for Xcode9

When Xcode crashes right as you think to yourself “I should restart Xcode”.

Like most developers I spend alot of time in Terminal and recently switched back to iTerm2 in hopes of increasing productivity. Unfortunately iTerm doesn’t come with any Finder services to quickly launch into folders like Terminal. I find alot of applications will let you open a project folder in Finder but lack terminal support so I end up using this feature quite a bit.

Getting precise RR intervals requires a resolution which is much smaller than a duration of RR intervals (1/100s or 100Hz). ECG machines are able to get precise measurements like this, but the pulse width when using pulse oximeters is often much more than 100ms. This is because the PPG sensors on the iWatch measure blood flow in distant capillaries vs measuring electrical ECG pulses from the heart, leaving the shape of the pulse to be stretched in time. Analyzing HRV usually requires measurements with a resolution between 40-100Hz.

So it looks like Apple’s killed XcodeColors</a> in Xcode8 (as well as virtually every other plugin), breaking the ability to have coloured log messages in the console. This is a huge letdown as colors helped to differentiate between different log levels when using CocoaLumberjack!

So I wanted to see what kind of HealthKit data types I could read which were measured from the iWatch. I tried reading every possible data type in HKTypeIdentifiers: