Amin Benarieb's Blog

Hashes: A Good Tool You Shouldn't Trust Blindly

Sat, 04 Jul 2026 08:00:00 GMT

You already use hashes all day

As an iOS dev you already use hashes all day:

Set and Dictionary. Every lookup goes through a hash. Any type you use as a Dictionary key or Set member has to conform to Hashable — but you almost never write that yourself: the compiler synthesizes it for your structs and enums, usually the same models you mark Codable. That hash is just a number squeezed out of the value; it's what lets a dictionary jump straight to the right entry instead of scanning them all.
Git. Every commit is a hash of its content; the short SHA you paste in standup is just the first 7 characters of it.
Checksums and signatures. The SHA-256 under a download link, or the code signature iOS verifies before it launches your app.
Hash maps on LeetCode. Every time you go at another problem, your reflex is to throw it in a hash map.

What "broken" actually means

So it's a great tool — but you're also going to hear that MD5 and SHA-1 are broken. That's true, and it has a specific meaning. Broken here means an attacker can produce a collision: two different files with the same hash. MD5 fell to this back in 2004, SHA-1 in 2017. So if a signature or a trust decision rides on one of those hashes, it's exploitable. There are other hash pitfalls too. If you want the mechanics, a couple of older-but-still-worth-it videos from the earlier internet — Computerphile — or if you prefer something newer, The Coding Gopher.

Two hashes that failed in public

Not only that. Two more hash-related failures worth knowing:

A hash-match accusation on a collidable hash. Apple's on-device NeuralHash scanned photos as they uploaded to iCloud and hash-matched them against a database of known illegal images; enough matches flagged your account for human review. Researchers forced a beagle and a gray square to the same hash within hours. Once different images can collide, an innocent photo can be crafted to match a flagged one (false positive — even a way to frame someone), and real targets can be nudged to not match (evasion). Apple shelved it in 2022.
A hash bug that cost ~$611M. In 2021 a hash-related flaw in a blockchain bridge led to one of the biggest thefts in crypto history — ~$611M (full technical report, or a more accessible walkthrough).

But both deserve an asterisk, and the asterisks are the interesting part.

NeuralHash is a perceptual hash — built so that similar images share a value. So it's not the kind of hash we usually mean, and colliding it isn't exotic — it's the design. The real problem wasn't "fingerprints aren't unique" in the abstract; it's that an accusation system was built on a hash that collides by design.
The Ethereum hack hinged on a truncated hash — think of a git short SHA, the first 7 characters instead of the full 64. The fewer characters a system actually checks, the cheaper it is to grind out a different input that lands on the same short value. That bridge compared only 4 bytes to decide which function to run; an attacker found a throwaway function whose 4 bytes matched a privileged one, called it, and walked off with the money. A hash is only as strong as the bytes you actually compare.

“Download and verify” can create false confidence

Take vphone-aio — a one-command script that spins up a "virtual iPhone" by running a bundled binary you don't see the source of. Its README lists SHA-256 sums for the download parts. The author uses them correctly: a corruption check, nothing more — they never claim the sums prove the binary is safe or genuine. The trap is on the reader's side. A checksum sitting next to something you're about to execute feels like "verified, safe to run." It isn't. A matching sum means the bytes arrived intact — not that the code is trustworthy, not that it came from who you think. By the way — I wouldn't blindly run that vphone on your own machine: it's a closed-source binary, so you can't actually see what it does, and a matching checksum tells you nothing about that.

Integrity is not authenticity

That's the line worth internalizing:

Integrity — the bytes didn't change (accidentally). A bare hash gives you this.
Authenticity — the bytes really came from the right source, untampered. This needs a signature — the hash delivered through something an attacker can't also edit.

A matching hash on the same server as the file gives you neither against an attacker: whoever swaps the file swaps the hash line right next to it. Same on mobile — a phone that hashes a selfie and sends "image + hash" to a server proves nothing if someone in the pipeline swaps both, and if the expected images are known ahead of time they can prepare a matching twin.

The concrete mobile trap: password storage

OWASP still flags shipped apps using MD5/SHA-1 for passwords (MASTG crypto tests). But "salted SHA-256 in the Keychain," passed around as best practice, isn't ideal either — for two separate reasons:

To verify a password, SHA-256 is too fast. GPUs try billions of guesses per second, so salted-SHA-256 hashes fall in bulk. Passwords need a deliberately slow function: bcrypt, scrypt, or Argon2 — Argon2id is the current default (OWASP Password Storage).
To reuse a password, you don't hash it at all. Hashing is one-way. A reusable secret goes into the Keychain encrypted, not hashed.

Hashing verifies; the Keychain stores. Mixing them up — especially verifying with MD5/SHA-1 — is the worst of both. And yet even MD5 still has honest work: catching accidental corruption (a bad download, a flipped bit) and deduplication ("seen this exact file before?"). Broken-for-security isn't broken-for-everything.

Takeaways

Hashes are a good tool: MD5/SHA-1 still earn their keep for corruption checks and dedup, but SHA-256 is the baseline the moment security matters.
A checksum proves integrity, not authenticity or safety — authenticity needs a signature.
…and only if you compare all of it: check just part of a hash and that guarantee shrinks to the bytes you actually compared (that's the $611M bug).
Storing a password? Put it through a slow, purpose-built hash — Argon2id, not MD5, SHA-1, or plain SHA-256.

iOS compressionQuality Is Not the JPEG Q-factor

Sun, 28 Jun 2026 07:00:00 GMT

Have you ever checked whether UIImage.jpegData(compressionQuality:) on iOS actually gives you the JPEG quality you asked for? I hadn't. Then I did — and the answer surprised me. Here's what I learned.

Here's the setup. Say you're generating JPEGs on iOS and you want them roughly the same size as what libjpeg spits out on your Linux backend or maybe Android app. You pass compressionQuality: 0.8. Feels right — that's Q80, no? So I need a tool to check this out.

The first tool I reach for is ExifTool — Phil Harvey's Swiss-army knife for reading and writing image metadata, the thing every photographer and forensics person already has installed. It'll tell you the dimensions and file size straight out of the JPEG header:

exiftool output.jpg | grep -E "Quality|ImageSize|FileSize"

Image Size   : 720x1280
File Size    : 215 kB

And then identify chimes in. The next tool ships with ImageMagick — the big open-source image toolkit — and unlike ExifTool it'll actually dig into the JPEG's compression internals and hand you a Quality number:

identify -verbose output.jpg | grep Quality
# Quality: 94

You asked for 0.8. You got Q94. Not Q80. That's the whole problem in one line.

The reason is that compressionQuality is just a internal Apple's CGFloat number from 0.0 to 1.0, and it is not the JPEG Q-factor. It's some internal Apple knob that ImageIO maps onto its own quantization tables, along a curve that's nonlinear and — as far as I can tell — documented absolutely nowhere. The annoying part is that almost all the useful range lives in the bottom half. Look:

`compressionQuality`	JPEG Q (per `identify`)
0.35	Q53
0.45	Q72
0.50	Q78
0.52	Q80
0.58	Q85
0.67	Q90
0.75	Q93
0.85	Q95
0.90	Q96
1.00	Q100

Anything above 0.75 barely moves — you're talking one or two Q-units between steps. So the top quarter of the slider is basically wasted.

If you want to build that table yourself, here's the script I used. Runs on macOS, and NSBitmapImageRep goes through the same ImageIO that UIImage uses on the phone, so the curve matches:

#!/usr/bin/env swift
import AppKit
import Foundation

let dir = URL(fileURLWithPath: "/tmp/jpeg_map")
try? FileManager.default.createDirectory(at: dir, withIntermediateDirectories: true)

// Gradient, not a flat color — a solid color compresses too well and ruins the test
let size = NSSize(width: 100, height: 100)
let image = NSImage(size: size)
image.lockFocus()
NSGradient(colors: [.red, .blue, .green, .yellow])!
    .draw(in: NSRect(origin: .zero, size: size), angle: 45)
image.unlockFocus()

guard let tiff = image.tiffRepresentation,
      let bitmap = NSBitmapImageRep(data: tiff) else { exit(1) }

for q in stride(from: 0.05, through: 1.0, by: 0.05) {
    let props: [NSBitmapImageRep.PropertyKey: Any] = [.compressionFactor: q]
    guard let data = bitmap.representation(using: .jpeg, properties: props) else { continue }
    let filename = String(format: "q%.2f.jpg", q)
    try! data.write(to: dir.appendingPathComponent(filename))
}

swift jpeg_map.swift
identify -verbose /tmp/jpeg_map/*.jpg | grep -E "jpeg_map|Quality" | paste - -

How `identify` guesses the Q-factor

Now, a thing that tripped me up — how does identify even know the Q-factor? It doesn't read it from metadata; there's no Quality field in the JPEG standard, that number just isn't stored anywhere in the file. What it actually does is read the DQT marker (Define Quantization Table, 0xFFDB) — the 8×8 matrix of quantization coefficients — and run a cheap heuristic over it: it sums the coefficients (plus a couple of values at fixed positions) and matches that aggregate against precomputed values for libjpeg's standard tables at every Q from 1 to 100. It's an estimate, not a readout — and a collision-prone one.

And here's the catch: that heuristic is calibrated to libjpeg's tables. Apple-encoded files don't necessarily use the same quantization tables, so whatever identify reports for an Apple file is a libjpeg-equivalent Q, not Apple's real internal value. I expect it to be off by roughly ±2–5 units — fine for comparing files to each other, no good if you need an absolute number.

iOS vs libjpeg: same Q, different bytes

I wanted to see that gap with my own eyes, so I took one image — 720×1280 — and ran it through both encoders.

Make the test image:

magick -size 720x1280 plasma:fractal -blur 0x2 test_source.png

libjpeg, via ImageMagick:

for q in 80 90 95; do
  magick test_source.png -quality $q libjpeg_q${q}.jpg
done

iOS side, same ImageIO through NSBitmapImageRep, picking the compressionQuality values that map to those Q targets:

let qualities: [(Double, String)] = [
    (0.52, "ios_q0.52"),
    (0.67, "ios_q0.67"),
    (0.85, "ios_q0.85")
]

And the results, same image, same resolution:

Encoder	`compressionQuality` / Q	`identify` Q	Size
libjpeg	Q80	Q80	60 KB
iOS	0.52	Q80	64 KB
libjpeg	Q90	Q90	144 KB
iOS	0.67	Q90	87 KB
libjpeg	Q95	Q95	212 KB
iOS	0.85	Q95	132 KB

Look at Q90 and Q95. Same identify Q on both sides, and the iOS file is smaller — noticeably smaller. At first I thought I'd messed up the mapping. But no, that's the real answer: the two encoders land on the same nominal Q but clearly aren't using the same quantization — Apple's output leans harder on the high-frequency detail. So "Q90 on iOS" and "Q90 on libjpeg" are genuinely not the same picture.

Calibration table: target Q → iOS compressionQuality

So if you just want a target Q-factor on iOS without thinking too hard, here's the lookup I ended up using:

Target	iOS `compressionQuality`
Q75	0.47
Q80	0.52
Q85	0.58
Q90	0.67
Q95	0.85

Alternative: libjpeg-turbo

If you need Q80 that identify reads back as exactly Q80 — same tables, no approximation — link libjpeg-turbo directly. It adds roughly 600 KB to your binary and gives you a quality parameter from 1–100 that means what it says.

Setup: download the official iOS .a from https://github.com/libjpeg-turbo/libjpeg-turbo/releases, add a bridging header with turbojpeg.h, then call tjCompress2 with your CVPixelBuffer data and a literal integer quality. No calibration table needed.

(Note: the integration steps above are based on the API docs — not personally verified end-to-end.)

An unexpected angle: forensics and liveness

Quick context if those words aren't your world. Image forensics is figuring out an image's history from the file itself — what made it, whether it's been edited — without trusting any metadata. Liveness is the check that decides a selfie is a real person in front of the camera right now, not a photo of a photo or an injected image. Both are how banking, KYC, and identity apps stop spoofing. And it turns out the boring compression detail above is one of their tools.

Those DQT (Define Quantization Table) aren't just a quality knob — they're an encoder fingerprint. Apple's ImageIO and libjpeg quantize differently, so the tables alone often reveal what produced an image. Forensics tools use exactly this for source identification (which app or device made the file) and for tamper detection: a JPEG that's been edited and re-saved carries double-compression traces in its tables. The liveness angle is direct — a selfie straight off the camera sensor looks different from one that was saved, edited, or re-compressed before it reached your verification flow. It's a signal, not proof, but it's often the first thing that flags an injected or replayed image.

Tools

identify (ImageMagick) — reads DQT tables and approximates Q-factor
exiftool — file metadata: size, resolution, subsampling
UIImage.jpegData(compressionQuality:) — Apple docs (note: parameter is not a Q-factor)
Apple ImageIO forums — community discussion on ImageIO behavior
libjpeg-turbo API docs — tjCompress2 reference

Takeaways

compressionQuality: 0.8 → Q94, not Q80. The parameter is Apple-internal.
The 0.75–1.0 range is nearly useless: all values collapse into Q93–Q100.
identify approximates Q from the DQT tables with a sum-and-hash heuristic — expect ±2–5 units off for Apple-encoded files.
Even at matching identify Q, iOS files can be smaller than libjpeg — the two encoders aren't using the same quantization, and Apple's output compresses high-frequency content more aggressively.
Need exact Q? Use the calibration table above, or link libjpeg-turbo for integer Q control.

Turning the iPhone into a Laboratory Microscope with AI and BLE

Sat, 30 Aug 2025 13:11:49 GMT

I recently shared an exciting project where we transformed an iPhone into a fully functional laboratory microscope by combining hardware innovation with AI, if you're working on similar hardware + AI/BLE projects or interested in the technical details, check out the complete write-up on HackerNoon:

How We Turned the iPhone into a Laboratory Microscope with AI and BLE

Dealing with Floating-Point Precision in Swift

Sun, 05 Jan 2025 13:57:18 GMT

During my junior years at university, we had a course dedicated to data structures and algorithms. One of the first tasks was working with large numbers, particularly floating-point numbers. At the time, I completed the task successfully. However, I eventually forgot the key lesson about the pitfalls of floating-point numbers and their rounding errors.

Take a look at the following Swift code:

let a = 12.31
let b = 8.2
print(a + b)
// Output: 20.509999999999998

Surprisingly, instead of 20.51, you’re more likely to get 20.509999999999998. And if you print values of a and b you also get something strange:

a: Double = 12.31
b: Double = 8.1999999999999993

Another example: if you sum 0.1 ten times (which should be equivalent to 0.1 * 10 = 1), you might get it wrong again:

var sum = 0.0
for i in 0..<10 {
  sum += 0.1
}
// Result: Double = 0.99999999999999988

You can play around with this behavior here on SwiftFiddle.

Why Does This Happen?

The reason for this behavior lies in how floating-point numbers are stored in memory. This is a common issue across many programming languages, not just Swift. Here’s a great video explanation along with an interactive playground that visually demonstrates how floating-point precision works.

When Does Precision Matter?

Floating-point precision errors might seem trivial, but they can have serious impacts depending on the field — especially in scientific, engineering, or financial applications.

In iOS development, the most common cases involve billing, purchases, and paywalls. On the backend, even a rounding error of $0.01 per transaction can scale into significant financial discrepancies across thousands of users. On the mobile side, these errors can lead to misleading prices, poor user experience, and ultimately bad reviews or increased churn rates.

But generally, we don't care much about it: for UI animations, graphics, or games, floating-point errors are often negligible since small rounding errors won’t visibly affect the user experience.

How to Solve It

One solution is to store values as integers (e.g., by multiplying by 100 to avoid decimals). However, the solution I prefer is using Decimal from Foundation.

Decimal is designed to handle precise decimal arithmetic, making it ideal for financial and high-accuracy calculations. Unlike Double, which uses binary floating-point representation, Decimal relies on a base-10 system. This eliminates many common rounding errors that occur when working with currency or other exact values.

That said, Decimal does come with trade-offs:

slower performance compared to Double for large-scale computations.
higher memory usage.
more verbose API, requiring additional steps for arithmetic operations.

For a deeper dive into the differences between Decimal and Double, I recommend this great article by Jesse Squires.

How to Debug Faster With ProcessInfo

Wed, 30 Oct 2024 11:19:20 GMT

How to Debug Faster Without Rebuilding Your iOS App

Problem

Building an iOS app can be time-consuming, especially for large projects with complex dependencies. Waiting for the app to rebuild every time you make a minor change or need to test with different data can significantly slow down your development process.

Solution

To speed up debugging without rebuilding your app, you can leverage ProcessInfo.processInfo.environment and ProcessInfo.processInfo.arguments. These allow you to inject data and control app behavior at runtime, making it easier to test different scenarios quickly.

Using Environment Variables

Environment variables can be used to pass data into your app during runtime. For example, you can autofill the sign-in screen with test credentials when debugging:

func onAppear() {
    email.text = ProcessInfo.processInfo.environment["SIGNIN_EMAIL"]
    password.text = ProcessInfo.processInfo.environment["SIGNIN_PASSWORD"]
}

To set environment variables in Xcode:

Edit Scheme: Go to your project in Xcode, select your target, and choose Edit Scheme.
Select Run: In the scheme editor, select the Run action from the sidebar.
Navigate to Arguments: Click on the Arguments tab.
Add Environment Variables: Under Environment Variables, click the plus button to add new variables.

Creating a Debug Configuration Interface

To manage environment variables more efficiently, you can create a utility that abstracts the access:

#if DEBUG
let environment: [String: String] = ProcessInfo.processInfo.environment
#else
let environment: [String: String] = [:]
#endif

public struct DebugConfiguration {
    public static func string(_ key: String) -> String? {
        return environment[key]
    }
}

Now, your code becomes cleaner:

func onAppear() {
    email.text = DebugConfiguration.string("SIGNIN_EMAIL")
    password.text = DebugConfiguration.string("SIGNIN_PASSWORD")
}

Using Launch Arguments

Launch arguments can be used to toggle features or behaviors without changing code. For instance, you might want to autofill the sign-up screen or automatically run onboarding steps during debugging.

To add launch arguments:

Edit Scheme: Select Edit Scheme for your target.
Select Run: Choose the Run action.
Navigate to Arguments: Go to the Arguments tab.
Add Arguments: Under Arguments Passed On Launch, click the plus button

Handling Debug Flags

Create an interface to check for these debug flags:

#if DEBUG
let arguments: [String] = ProcessInfo.processInfo.arguments
#else
let arguments: [String] = []
#endif

public enum DebugFlag: String {
    case signupAutofill = "SIGNUP_AUTOFILL"
    case onboardingAutorun = "ONBOARDING_AUTORUN"

    public static func isEnabled(_ flag: DebugFlag) -> Bool {
        return arguments.contains(flag.rawValue)
    }
}

Applying Debug Flags in Your Code

Use these flags to conditionally execute code during debugging.

Autofill Sign-Up Screen:

func onAppear() {
    if DebugFlag.isEnabled(.signupAutofill) {
        email.text = "newuser@example.com"
        password.text = "SecurePassword!"
    }
}

Auto-Run Onboarding Steps:

func onAppear() {
    if DebugFlag.isEnabled(.onboardingAutorun) {
        onContinueButtonTap()
    }
}

func onContinueButtonTap() {
    // Proceed to the next onboarding step
}

Mocking `UserDefaults` Values

You can mock UserDefaults to test specific scenarios, such as triggering a feature after a certain number of app launches.

Set Up Mock Value via Launch Arguments:

Add the following to Arguments Passed On Launch:

-appLaunchCount
10

Modify Your Code to Use the Mock Value:

import os

let logger = Logger(subsystem: "com.example.app", category: "AppLaunch")

func onAppear() {
    let appLaunchCount = UserDefaults.standard.integer(forKey: "appLaunchCount")
    logger.debug("appLaunchCount = \(appLaunchCount)")
    if appLaunchCount >= 10 {
        logger.debug("Showing special feature on 10th launch")
        // Trigger the feature
    }
}

Sample Output:

[AppLaunch] appLaunchCount = 10
[AppLaunch] Showing special feature on 10th launch

Further Thoughts

By utilizing environment variables and launch arguments, you can:

Save Time: Test different data inputs and scenarios without rebuilding or hardcoding values. Expecially to test layout changes, mock API responses, or inject localization strings
Enhance Flexibility: Toggle features or behaviors dynamically during runtime.
Improve Collaboration: Share custom schemes with your team to ensure consistent testing environments.
Expand Testing Capabilities: Simulate edge cases, such as network delays or error states, more efficiently.

By integrating these practices into your development workflow, you can streamline testing and focus more on building great features.

Connect with Me

Have a comment or question? Feel free to reach out to me on Twitter or LinkedIn.

How to debug iOS deeplinks with local server

Thu, 29 Jun 2023 13:27:48 GMT

How to Debug iOS Deep Links with a Local Server

Problem

Testing interactions within your iOS app that require a custom web page—such as engaging with payment options in a pop-up browser via universal links or deep links—can be challenging. Capturing and modifying URLs, handling deep links that close pop-up browsers, and ensuring that various types of links work seamlessly within your app can be time-consuming without the right tools.

Solution

To streamline the testing process, you can set up a local server that hosts a custom HTML page containing all the links you need to test. This approach allows you to open the web page in the iOS Simulator and interact with your app's deep links in a controlled environment.

Setting Up a Local Server with Python

Python provides a simple way to set up a local HTTP server. Here's a Python script that serves an HTML file containing your test links:

from http.server import HTTPServer, BaseHTTPRequestHandler

class Serv(BaseHTTPRequestHandler):
    def do_GET(self):
        if self.path == '/':
            self.path = '/test.html'
        try:
            file_to_open = open(self.path[1:]).read()
            self.send_response(200)
        except FileNotFoundError:
            file_to_open = "File not found"
            self.send_response(404)
        self.end_headers()
        self.wfile.write(bytes(file_to_open, 'utf-8'))

httpd = HTTPServer(('localhost', 8081), Serv)
httpd.serve_forever()

Steps to Set Up:

Create Your HTML File:

Save your test links in an HTML file named test.html. Here's an example of what test.html might look like:

<html>
<body>
    <div>
        <a href="yourapp://branch/Settings/FavoritePlaces" class="button">Favorite Places</a>
    </div>
    <div>
        <a href="yourapp://action/RestorePurchase" class="button">Restore Purchases</a>
    </div>
    <div>
        <a href="yourapp://branch/Payment/Point/330" class="button">Branch Payment (330)</a>
    </div>
    <div>
        <a href="yourapp://action/OpenLink?url=https%3A%2F%2Fstage-app.yourapp.com%2Fpayments%2Fplans%2Fpromo-special%2F%3Fcoupon%3DPRM_may2FREE%26require_token%3Dtrue" class="button">Stage Coupon</a>
    </div>
    <div>
        <a href="yourapp://action/payment_form/plans/promo-special?coupon=PRM_may2FREE" class="button">Payment Form with Coupon</a>
    </div>
    <div>
        <a href="yourapp://action/web_payment?status=success" class="button">Web Payment Success</a>
    </div>
    <!-- Add more links as needed -->
</body>
</html>

Replace yourapp with your app's URL scheme.

Save the Python Script:

Save the Python script above in a file named local_server.py.
Run the Local Server:

Open a terminal, navigate to the directory containing local_server.py, and run:
```
python local_server.py
```
This starts a local server on localhost at port 8081. If port 8081 is busy, you can change the port number in the script:
```
httpd = HTTPServer(('localhost', 8082), Serv)
```
Access the Test Page:

In the iOS Simulator, open Safari and navigate to http://localhost:8081. You should see your test.html page with all your test links.

Testing Deep Links

With your local server running and accessible from the iOS Simulator, you can now test how your app handles various deep links:

Click on the Links: Interact with the links in test.html to see how your app responds.
Verify Navigation: Ensure that your app opens and navigates to the correct screens.
Test URL Parameters: Modify URL parameters in test.html to test different scenarios.
Handle Pop-Up Browsers: If your app uses a pop-up browser (e.g., SFSafariViewController), test how deep links from your web page close the browser and return control to the app.

Further Thoughts

Setting up a local server for testing deep links offers several advantages:

Efficiency: Quickly test web interactions without deploying changes to a live server or rebuilding your app.
Flexibility: Easily add, remove, or modify test links in the test.html file.
Isolation: Work in a controlled environment without affecting real users or requiring internet access.

Connect with Me

Have a comment or question? Feel free to reach out to me on Twitter or LinkedIn.

Amin Benarieb's Blog

Hashes: A Good Tool You Shouldn't Trust Blindly

You already use hashes all day

What "broken" actually means

Two hashes that failed in public

“Download and verify” can create false confidence

Integrity is not authenticity

The concrete mobile trap: password storage

Takeaways

iOS compressionQuality Is Not the JPEG Q-factor

How identify guesses the Q-factor

iOS vs libjpeg: same Q, different bytes

Calibration table: target Q → iOS compressionQuality

Alternative: libjpeg-turbo

An unexpected angle: forensics and liveness

Tools

Takeaways

Turning the iPhone into a Laboratory Microscope with AI and BLE

Dealing with Floating-Point Precision in Swift

Why Does This Happen?

When Does Precision Matter?

How to Solve It

How to Debug Faster With ProcessInfo

How to Debug Faster Without Rebuilding Your iOS App

Problem

Solution

Using Environment Variables

Creating a Debug Configuration Interface

Using Launch Arguments

Handling Debug Flags

Applying Debug Flags in Your Code

Mocking UserDefaults Values

Further Thoughts

Connect with Me

How to debug iOS deeplinks with local server

How to Debug iOS Deep Links with a Local Server

Problem

Solution

Setting Up a Local Server with Python

Testing Deep Links

Further Thoughts

Connect with Me

How `identify` guesses the Q-factor

Mocking `UserDefaults` Values