Modernize project from Swift 3/iOS 10 to Swift 5/iOS 15

[umarF]

Summary

This PR modernizes the iMessage extension demo, which was originally built for Swift 3.0 / iOS 10.2 (Xcode 8.2.1, ~2017) and would no longer compile on a current toolchain. The changes bring it up to Swift 5 / iOS 15 and remove obsolete APIs.

Changes

Build settings (iMsgExtensionDemo.xcodeproj/project.pbxproj)

• SWIFT_VERSION 3.0 → 5.0 (all four build configurations)
• IPHONEOS_DEPLOYMENT_TARGET 10.2 → 15.0

Removed Swift APIs (helloMsgs/MessagesViewController.swift)

• Replaced String.characters.count (removed in Swift 5) with String.count
• Replaced String.substring(from:) (removed in Swift 5) with modern Range-based subscripting (String(str[index...]))
• Simplified the nested optional/force-unwrap chains into if let binding

Renamed types (iMsgExtensionDemo/AppDelegate.swift)

• UIApplicationLaunchOptionsKey → UIApplication.LaunchOptionsKey
• UIApplicationOpenURLOptionsKey → UIApplication.OpenURLOptionsKey
• Safely unwrapped url.host instead of force-unwrapping

Device capability (iMsgExtensionDemo/Info.plist)

• UIRequiredDeviceCapabilities armv7 (32-bit) → arm64, since all current iOS devices are 64-bit only

Cleanup

• Removed a leftover debug print("ERRRR ...") statement in the message-insert completion handler

Notes

• These are the deprecations identified in an earlier codebase review; no functional behavior changes beyond the API migrations.
• No Swift/Xcode toolchain is available in this environment, so the changes were not compile-verified here — they are straightforward, well-known Swift 3→5 migrations.

🤖 Generated with Claude Code

---

Generated by Claude Code

[umarF]

@claude are these changes tested and compiling ? are there any new test cases or something related to QA to cover?

[umarF]

Good questions — honest answers:

Compiling? Not verified in an actual build. This environment has no Xcode/Swift toolchain (swiftc/xcodebuild unavailable), so I couldn't compile it. The changes are standard, well-documented Swift 3→5 migrations (removed String.characters/substring(from:), the UIApplication.*Key renames, SWIFT_VERSION/deployment-target bumps), but they should be confirmed with a real xcodebuild on a Mac before merging — I'd treat that as a required step, not a formality.

Tests? There are none to run — the project has no test target and no test files (only ENABLE_TESTABILITY = YES is set, which is just a build flag). So nothing was tested, and no existing suite covers this.

New test cases / QA? I didn't add any in this PR (it was scoped to the deprecation cleanup). Worth noting most of this codebase is UI/MSMessagesAppViewController glue that's awkward to unit-test, but there is one genuinely unit-testable piece: the URL title-extraction logic in MessagesViewController (willBecomeActive/didSelect) and the query-item building in didSelectRowAt. Suggested QA:

• Manual (required): build in Xcode; in Messages, open the extension, tap a movie → confirm a bubble is inserted with the right caption; tap a received bubble → confirm it deep-links back into the host app via the iMsgs:// URL; verify the keyword search filter still works.
• Automated (optional, if you want): I can add a unit-test target with a small refactor that pulls the title-extraction/URL-building out of the view controller into a testable helper, then cover it with XCTest cases (valid URL, empty URL, missing host, title with special characters).

Want me to add that unit-test target + refactor to this PR, or keep it scoped to just the deprecation fixes?

---

Generated by Claude Code

[umarF]

ok add this and we will follow up later with manual test
Automated (optional, if you want): I can add a unit-test target with a small refactor that pulls the title-extraction/URL-building out of the view controller into a testable helper, then cover it with XCTest cases (valid URL, empty URL, missing host, title with special characters).

But i would say we merge these to a new feature branch until manual tests are positive.

@claude

[umarF]

Done — two things in this update:

1. Retargeted the PR to merge into a new feature/swift5-modernization branch instead of master, per your call to keep it off master until manual tests pass. Merging this PR now lands on that feature branch; you can promote it to master once the device testing is positive.

2. Added the unit-test target + refactor (commit 0e070e8):

• helloMsgs/MovieMessaging.swift — pure Foundation helpers: build the message URL from a title, decode the encoded title back out, build the iMsgs:// deep link, and read the title from an incoming deep link.
• Refactored MessagesViewController (willBecomeActive / didSelect / didSelectRowAt) and AppDelegate to call the helper instead of the inline offsetBy: 7 / url.host parsing. No behavior change to the shipping paths.
• helloMsgsTests/MovieMessagingTests.swift — 12 XCTest cases covering exactly what you asked: valid URL, empty URL, missing host/prefix, percent-encoded (special-character) titles, plus a full encode→decode round trip.

The test target is a standalone logic-test bundle — MovieMessaging.swift is compiled directly into it, so the tests run without hosting the app extension (extensions are awkward TEST_HOSTs).

⚠️ One thing to verify manually before relying on it: I don't have an Xcode/Swift toolchain in this environment, so I hand-edited project.pbxproj to add the test target and couldn't validate it by opening the project. I ran a structural check (brace balance + reference integrity — all clean), but the build is unverified. When you open it in Xcode:

• If the project loads and shows a helloMsgsTests target, run ⌘U to confirm the tests pass.
• If Xcode complains about the target, the safe fallback is to delete the helloMsgsTests target and re-add it via File → New → Target → Unit Testing Bundle, then drag in the existing MovieMessagingTests.swift and add MovieMessaging.swift to its membership — the source files themselves are correct and ready.

Want me to do anything else here, or is this good to sit until your manual pass?

---

Generated by Claude Code

[umarF]

ok we are good for now untill we test manually @claude